Pete Dowson

Download 4.951 released yesterday, then, as it is implemented. And it does it whenever an assignment section is used, it doesn't wait for any changes to be made. For profiles it does it when the profile is used. Pete

Evidently not. Let me see the log from actually running the 4.95 installer. The installer saves a copy of its log in the same folder (or desktop, even) from where you execute it. THAT's the relevant log. Pete

So, let's see the new log. If it is identical to the one in the other thread, as you did VERY explicitly state, then you are obviously still using 4.1! Pete

No, not without some information. Are you only assigning in FSUIPC? Have you disabled controllers in FSX? Are you assigning buttons to keypresses, instead of buttons to controls? Why? If you assign to keypresses you are relying on something else converting them to controls. Why do that? FSUIPC provides logging facilities. If you enable Event logging (one check mark on the logging tab in the Settings), then the log (FSUIPC4.LOG) in the Modules folder will show the results of your button or key pressing. If you (temporarily) run FS in Windowed mode, you could also enable the Console Log on the Logging Tab, and see what happens in real time on screen. If you can't figure it out, show me the Log file and also your settings file (FSUIPC4.INI, also in the Modules folder). You can paste them into a reply here. Pete

If your log is identical to that one then the answer too is exactly the same -- version 4.152 is from July 2007, not long after FSX was published. It knows nothing about any later versions. The earliest supported version is 4.95. He fixed it by doing what I told him to do, update to the current version. Why don't you do the same? Pete

Er, yes, that's what I said, and that's why I moved it here. You must have actually sought out the "FAQ" subforum for some reason, because all the links in my documentation and on the SimMarket and Schiratti websites would bring you here, not to any sub-Forum. You don't need to remove anything in FSX is you disable controllers. That will d it all. Okay. so, then, so far you have not made ANY assignments for aircraft generally, only specific ones for the F6F. Of course, because you've not made any assignments whatsoever which aren't specific to the F6F Your FSUIPC4.INI file shows this clearly. You have assignments for the F6F, but none for any other aircraft. You have yet to make any. How do expect controls which aren't assigned to do anything to do anything? Pete

Linking to a thread about a VERY old version of FSUIPC, and providing no information at all about your problem, is just a waste of time. At least the other thread does have the Install Log. Where is yours? Please show it to me. Without seeing that there's no way I can possibly help! Pete

You posted to the FAQ sub0forum, which is a repository for answers to Frequently Asked Questions, not the Support Forum. Please only ever post support questions here, in the Forum proper. You are lucky I saw it. By "normal FSX" do you still means with things assigned in FSUIPC. You can't mix FSX assignments with FSUIPC ones. Did you make any assignments before setting Profile Specific for the F6F? If not, then you obviously need to make whatever assignments you need, now. If you started off only making Specific assignments, the naturally they won't apply to anything else. That's the whole point. "Messed it all up"? Does this imply you did have assignments before you started on the Profile for the F6F? If so I can only see what you've done by taking a look at your settings. Find the file called FSUIPC4.INI in the Modules folder -- it'll be tagged as configuration settings. Paste its contents into a reply here. Pete

Sorry, you spent money on a tool that enables you to do what you want. But a tool needs work. I am not the author of the Lua plug-in you seem to need to use, and the facilities you want from FSUIPC were never promised in the product package. Everything Lua can do is a bonus, and there's NEVER been any extra charge made for any of the many additional facilities implemented over the many years FSUIPC has been in continuous development. I take strong objection to your attempted use of something tantamount to blackmail to cajole me into spending time on some rather odd and unrealistic facility (to my mind) which I did not invent and with which I have no interest nor time. If the original author cannot help then I'm afraid you'll have to work it out yourself. If you had just asked for specific help in understanding something in the Lua code, or in the other User's instructions, then maybe I could have looked. But your attitude is wrong. Pete

You have posted with an IDENTICAL thread title to one just a little below here. Why didn't you read that one first? It certainly seems relevant and has one possible answer! But taking your words as they are, why do you think it is anything to do with FSUIPC, and how do you "load FSUIPC" with scenery? FSUIPC has no relation to scenery. It doesn't load it and doesn't do different things with different sceneries. Can you not at least provide the Windows crash data? Does that say it's FSUIPC? Why have you enabled so many FSUIPC logging options? Best to turn them off. Did you think they were telling you something? If you think it is related to FSUIPC, then, looking at the last message logged above, I suspect the first thing to do is as recommended in some of the other messages here -- delete your wxstationlist.bin and the .wx files. If it is down to corrupt weather files, then it is actually P3D which is crashing. FSUIPC merely asks SimConnect to supply weather data, and that is normally returned in the form of an extended METAR string -- provided it doesn't crash first due to bad data. As an observation, both UK2000 and Aerosoft Heathrow's work very well in P3D, albeit at a big performance hit if you also have realistic traffic levels. I've tested both extensively in P3D 3.2 because I was thinking of moving over to P3D, but the performance at those airports with realistic traffic levels isn't good enough for me, and not as good as FSX-SE, so I changed back. Pete

It was easier than I thought. I've added annotations into the settings file in version 4.951, now available. The assignments of axes, keys and buttons are all commented automatically in the INI with decodes of key values and controls. Pete

Good. But I find that rather odd when the IDs already assigned, 0 and 1, were fine. Pete

Apart from the fact that you are using an older, unsupported version, of FSUIPC (current is 4.95), the only big problem I see with tat setup is that you have 7 joystick type devices attached which could, depending on powering, connections, Windows updates, r maybe just USB glitches, switch around in terms of their Windows IDs (0-7). I strongly recommend that you use the Joy Letters facilities provided for just these sorts of configurations so that if the IDs do get swapped around, FSUIPC will be able to still match the devices to their recorded assignments. Please refer to the FSUIPC User Guide, Read the Chapter entitled "Keeping track of multiple control devices ("Joy Letters")" on page 25. If you do get things apparently swapping around from the way they are as shown in your files above, compare ths section of your INI file with the way it has become: [JoyNames] AutoAssignLetters=No 0=Pro Flight Cessna Rudder Pedals 0.GUID={EB824460-B7FD-11E5-8008-444553540000} 1=Pro Flight Cessna Yoke 1.GUID={EB826B70-B7FD-11E5-8009-444553540000} 2=BU0836A Interface 2.GUID={EB82B990-B7FD-11E5-800A-444553540000} 3=BU0836X Interface 3.GUID={D6D4CCB0-DE48-11E5-8001-444553540000} 4=Button Box Interface 4.GUID={D6D4F3C0-DE48-11E5-8002-444553540000} 5=Button Box Interface 5.GUID={D6D51AD0-DE48-11E5-8003-444553540000} 6=Button Box Interface 6.GUID={4A1EF780-1153-11E6-8001-444553540000} The numbers (0= etc) may get swapped about, but FSUIPC will then use the device names and unique GUIDs to adjust the assigned Letters to make sure each device does what you assigned it to do. It cannot do that whilst you are still using the Windows IDs, which are not fixed. NOTE: If your devices are incorrectly assigned right now, with the assignments shown above, you should try to match them up first, BEFORE changing to letters. To do this use the little utility JoyIDs in order to change the Windows ID numbers around. Pete

Are those file extracts from currently dated files, ones generated since you had the problem? (Check the file date/time). If so, then the two X55 devices ARE being seen, the Stick is ID 0, the Throttle ID 1. So it looks okay, they are both seen. They should be seen in P3D too. If there's then no response in P3D or FSUIPC to button presses or axis movements, then I would have thought that the device must be broken. The USB connection must be okay because it is identifying itself. However, you say that it works in other programs. So it doesn't make sense -- unless those other two programs use the old joystick API, the one used before DirectInput became standard. (FSUIPC3 for FS9 and earlier uses the old interface). If that is working but DirectInput is not, it sounds like it could be a DirectX installation bug in your system. So try finding a DirectX update on the web and apply that. No. You can have all the available versions of SimConnect installed. Each add-on program selected the one it was built with. It's called the Windows side-by-side library system (WinSxS), and applies to multiple versions of many types of libraries. Sorry, apart from trying to fix DirectX, I'm afraid you'll need now to deal with Saitek support or Lockheed-martin. As I've said several times, if P3D can't see the buttons and axes, neither can FSUIPC as they use pretty much the exact same methods. I can't really help further. Pete

If you have several USB devices it is always best to use the Joy Letters facilities in FSUIPC, so the assignments can be re-matched should the Windows-assigned ID number get changed. What changed in your system between the "some time" it all worked and the time now where it doesn't? That might be a clue. I don't know of any way the IDs can change unless devices are unplugged and reconnected, or something happens which makes that appear to happen in Windows. Perhaps a good start would be to show me some files -- your FSUIPC4.INI file, which is is the one with your settings, and the FSUIPC4.LOG file, which is the run-time log of FSUIPC's actions. You'll find them in the Modules folder. They are both text files and can be pasted into a message here. Pete

The run-time log from FSUIPC4 is called FSUIPC4.LOG and is in the Modules folder, next to FSUIPC. It is always produced and always needed. There is no specific crash log for P3D that I know of. Windows itself logs the information from application crashes, giving the module and offset where it happened. This too is always needed. It you failed to capture it at the time of the crash (it's in the "details" drop-down offered at the time), you will find it logged in the windows Event Viewer. But if you have solved your problem then there's no point, is there? I was only pointing out that if it was a corrupted weather file, which is the most likely, it would have been clearer and more immediately suggested by such information. Pete

It's the list of weather stations for weather set in SimConnect and for reporting weather on ATIS and the like It is an essential file which is regenerated automatically, and updated by web downloads. No, but it will be used if there. Why remove it? Only the last two might have fixed it, not the others. But without a log file from a problem load to look at there's no way I can tell! Pete

The 3.0.10.1945 is from the crash log posted just above by "Beavis". Why are you referring to that? I was replying to Beavis. Of course, and that is the main version supported in FSUIPC. You seem to have tagged onto a thread of some one else using a different version of P3D. If you have a problem, why not post your own details, not make assumptions ... please? Pete

As I said, if P3D doesn't see it, neither can FSUIPC. Does Windows even see it? Is it identified in the Device Manager in Control Panel? Can you calibrate it in Windows? You didn't even answer my previous questions! Here, I'll repeat my very first paragraph, highlighting the questions you missed: FSUIPC uses the same Windows methods to read joysticks as FS and P3D. Does P3D see it? What have you changed since it worked? If nothing, it sounds like it is broken. I don't use Saitek. I don't actually like their stuff. But there is nothing Saitek specific in FSUIPC at all. It just uses standard Windows joystick facilities in DirectInput. You could also look in the FSUIPC4.INI file (in the P3D Modules folder), see if the [JoyNames] section lsts it, and in the FSUIPC4.LOG file, also there, to see if it gets scanned on loading. Pete

FSUIPC uses the same Windows methods to read joysticks as FS and P3D. Does P3D see it? What have you changed since it worked? If nothing, it sounds like it is broken. What do you mean by "4.9x" for the FSUIPC version number. That's too vague. There have been many 4.9x releases! And if it isn't at least 4.95, then it isn't supported. If the hardware is okay then I expect it's the Saitek driver. Try uninstalling it and just using the Windows default drivers. Saitek do seem to have a lot of problems. There's no "steps" to take, baby or otherwise. It is isn't seen then it can't be used. Pete

It really shouldn't upset your taxiing. Those figures are pretty good. I don't know if you've ever watched a cockpit video showing real aircraft being taxied or flown, but the throttle levers are very often not perfectly aligned. Slight differences are bound to occur, especially with the more common mechanical linkages being used. Elecronic control like in the later Airbuses and probably the 787's might well be perfect. And most airliners will achieve taxi speed with only a nudge to start with and then maintaining only a little more than idle throttle, at which point your inputs to FS should be IDENTICAL if you've calibrated properly. On top of that you have toe brakes and steering tiller to control taxiing with, and at 10-20 knots normal taxiing speeds it should be a doddle. However, as aua668 says, you can synchronise them further, by making the calibration work in smaller chunks between fixed positions which are always kept identical (as your idle should be). One thing puzzles me. I thought PMDG aircraft (or at least the NGX)didn't like you using FSUIPC's calibration on throttles, because they read the throttle values directly, at the same SimConnect priority as FSUIPC's calibration intercept? I don't know which model you are flying, but isn't that true for it? Also, you say "the filter box checked". Why? Are the axes jittering really badly? The filter is rather a drastic measure to take, and may be partially responsible for any discrepancies you see as in order for the filter to work it has to receive several values before sending one average value back. This makes a very small delay. Filtering was introduced to help some users in somewhere like Thailand or Cambodia where there power supply was very variable, causing fluctuations in potentiometer read-outs. If your TQ6 is that bad I'd get it repaired or replaced. Pete

I've thought about that, and I think that I might just optionally add a comment at the end of any line which contains an encoded control or keypress, to give the same text as in the assignment dialogues -- ie control name or keypress labelling. If there's already a comment on a line, that will get left intact instead. I know that many users have put their own comments in to assist them remembering what they've done, and I wouldn't want to undo all that. It will only do this when re-writing a section in any case, so only for the current Profile and when pressing OK in Settings after a change in the relevant section. It really isn't worth adding a large amount of code to do it in one complete pass. Sections are never read in bulk like that at the moment. Pete

Actually, looking at the Log that's not so likely. This line, being the last logged, is a very clear indicator: 351016 Advanced Weather Interface Enabled Not sure why it took nearly 6 minutes for FS to get to this stage. Was it sitting at the selection screen a while? Anyway, the fact that the crash occurred immediately after FSUIPC started reading the weather from SimConnect points to a corrupted file -- either the .WX file being loaded, or the wxstationlist.bin file in the folder where your main FSX.CFG file resides. These files are just binary data, with no checks included, and if the get corrupted -- perhaps from a previous crash, or partial update from a weather supplier, then when SimConnect interprets them in order to provide FSUIPC with the extended METAR strings being requested, it cause a crash -- sometimes in WEATHER.DLL, sometimes in it's callback in FSUIPC, sometimes actually in simconnect itself, though that's pretty unusua because that DLL is really just a sort of "stub" passing things on to the relevant part of FS. Try deleting, or moving out, the .WX files from your FS files folder in your Documents, and just deleting the wxstationlist.bin file. As you are using ASN you don't need the .wx files, and the .bin file will be regenerated in any case. Pete

Why in the INI file especially? You seem to be asking for a general method of programming to be implemented within the INI file! This is what Lua plug-ins are for. It is so easy with a few lines in Lua, it would be rather daft of me to implement the same sort of decision making and resulting action in an INI file, don't you think? If the Lua plug-in facility had been implemented first I wouldn't have added that rather complex and arcane method of conditional button assignments in the INI file -- it is so much simpler and more flexible and obvious in Lua that it would have been far preferable, and would have saved all that tortous explanation with examples in the Advanced User's manual! Just think of Lua plug-ins as other types of INI file, but with a saner syntax. :-) Pete

The data you've posted would be useful if it related to the currently supported version, 4.95. Please update and try again. Also, next time, please show me the FSUIPC4.LOG file, as far as it gets. That could also provide a vital clue. From the offset the most likely area of FSUIPC is the Lua interpreter, so details of any Lua plug-ins you have running may be relevant too, as well as a description of what might have been going on at the time. Pete