Pete Dowson

I'm very sorry, but I really know nothing about either of those products. I don't even have them. Isn't there support available on their site(s)? Regards Pete

At 32F0? Per documentation (did you look?): bits 0-7 = 0 (no change to FSUIPC options) bits 8-15 = 2^10 (0x00000400 bit) for World, 2^11 (0x00000800 bit) for Aircraft, 2^12 (0x00001000) for Flights, so 0x00001C00 for all three. bits 16-23 = 0 (reserved) bits 24-31 = your timeout, eg, 0xFF000000 for 255, or up to 14 seconds. Putting all together gives you 0xFF001C00. Regards Pete

No, that is indeed very strange. An entire PC re-booting is very unusual these days, especially with Windows XP or Vista (which as you use FSX I must assume you are on). In fact the only things I'm aware of which can cause such an event are drivers and hardware faults. Are you using a driver supplied by Saitek? If so you could try uninstalling it and letting the joystick be operated by one of the default XP or Vista drivers, just to see if the problem is there. Otherwise I would start suspecting RAM or the motherboard. I really don't think it can be anything specific to FS or FSUIPC, the difference between FSX and FS9 I suspect is more coincidence than determined. Regards Pete

FSInterrogate is a tool for monitoring values and trying things out. It is NOT intended as "documentation" nor a list! The only list and documentation which should be used is the one provided in the SDK, a DOC or PDF file. I spend a lot of time making sure that it is not only up to date but as detailed as it needs to be for folks to use and understand "offsets". The main FSUIPC SDK is available from http://www.schiratti.com/dowson , and the documentation is the "Programmer's Guide" therein. There's an FSX update and "progress report" for the offset list in the SDK addendum available in the FSX Downloads Announcement above. I've really no idea how the notion that FSinterrogate is the prime reference comes about. Isn't it clear that it is merely a tool for experimentation and verification? Regards Pete

Well, you evidently must have clicked the wrong link in the first place, because you didn't even post your question to "my forum"! I am Pete Dowson, and "my forum" is named "Pete Dowson's FS Modules", so it should have been a doddle to check (even for a "Dodo with manuals"). Having got here you will, if you look, notice a number of Announcements at the top. One of them is "FSX downloads ...". MixW is in there. Please don't ask for any 'good documentation' for MixW. It isn't my software, but freeware from elsewhere. Regards Pete

Why have you entered the ServerName and Protocol parameters? When using all modern Windows versions (XP or Vista), WideFS is self-configuring. You should not need to touch the INI files. The error "connection refused" is from Windows. It is simply refusing to connect to the Server PC. This could be due to any number of reasons, but the usual ones are: 1) FS+WideServer isn't actually running on that PC. 2) The access is blocked by a firewall 3) The two PCs are not in the same WorkGroup Unfortunately you only show here half the story anyway. Where's the WideServer log file from the FS PC please? Regards Pete

The FSUIPC log shows it just getting as far as loading a flight, so I'm guessing there is something wrong either with the flight being loaded, or possibly the default one which would have been loaded beforehand. When this happens is it usually a corrupt "WX" file (weather). When FSUIPC is installed the weather is read more often than it would be otherwise (so the details can be passed on to client programs), which may account for the difference you get with FSUIPC loaded or unloaded. To verify this, please just temporarily rename or move your FS9.CFG file. You will find it in your Documents and Settings\\Application Data\Microsoft\FS9 folder. Don't delete it for now as you will lose your FS9 option settings. Then when you run FS9, don't ask it to load any existing Flight, just in case it gets a bad one. Create a new flight (as you did, I think the time you made this log). If this works, then I think your default flight, and probably any made from it, have something wrong and are best not used. Although, looking at the log again, I see you are still loading the original default flight (FLIGHTS\OTHER\FLTSIM.flt) from the FS9 flights folder. To get over this, you can either start from the new FS9.CFG it made on this test run, ad go and set up all your options again. If you do this, delete your currently saved flights (from your "My Documents\Flight Simulator Files" folder), and then Save a new flight, marking it "default". If you want to go back to your old FS9.CFG, delete all the flights before you put it back so that a bad one doesn't get re-loaded. FS might complain but it will get by and load a base default flight. Then you can make and save a new one. If you are interested, bad WX files can occur as a result of flights saved after a real weather download goes wrong in some way. The WX files are binary representations of FS's internal weather tables, and don't get checked like normal text files would be. If none of this seems to work, then we are looking instead at possible corruption in other areas. Probably either add-on aircraft gauges, or other DLLs added in the Modules folder. But try the above first. Regards Pete

Unlikely. The process of assigning an FS control and sending it to FSX is the same for all those FS controls actually listed, and the list is from a table in CONTROLS.DLL, part of FS. If it was going wrong for one it would go wrong for all. In actual fact, this particular control (ATC Menu Close) does work, as I've now had a chance to verify! I tested it by assigning it to a button, not to a keypress. I'm thinking now that you assigned it to a keypress and what is actually happening is that when the ATC window is open, it is "stealing" the keypress indications before FSUIPC manages to see them, or at least it is altering some of them so they don't get recognised. There is a known problem in this area. When the ATC window is open, none of the Num-Pad based keypresses for actually flying the aircraft work (throttle, trim, aileron and elevator). This is a new problem in FSX, and though it was certainly reported to Microsoft long ago it evidently never got to a high enough priority to be fixed. I may delve deeper to see if it possible for FSUIPC to trap the keys before the ATC window sees them, instead of after. No guarantees though. Well, for FSX I don't really know. Many of the controls date back to FS98/FS2000 days. In fact a large number were added in that phase of FS development thanks to "Beatle", a friendly Microsoft guy who does post in these and Avsim Forums from time to time. He left after FS2000 and only rejoined relatively recently and in the intervening period I'm afraid a few of his additions "lapsed" in terms of implementation internally. The problem for me is simply finding the time to test them all, and then understanding whether they worked or not -- which in some rather obscure cases is not so easy. So, I gave up trying to document them that far, and leave it as a trial-and-error process for those with time and knowledge. [LATER] Well, it was easier than I thought! I managed to hook into the ATC window and get the keystrokes before it processes them, so i can now make FSUIPC keypress assignments work all the time! This improvement will be in the next interim version, probably 4.218. Look in the FSX Downloads Announcement above towards the end og the week. Regards Pete

It didn't appear. It is a text file. you can paste it into your message. Pete

Unlikely. The process of assigning an FS control and sending it to FSX is the same for all those FS controls actually listed, and the list is from a table in CONTROLS.DLL, part of FS. If it was going wrong for one it would go wrong for all. In actual fact, this particular control (ATC Menu Close) does work, as I've now had a chance to verify! I tested it by assigning it to a button, not to a keypress. I'm thinking now that you assigned it to a keypress and what is actually happening is that when the ATC window is open, it is "stealing" the keypress indications before FSUIPC manages to see them, or at least it is altering some of them so they don't get recognised. There is a known problem in this area. When the ATC window is open, none of the Num-Pad based keypresses for actually flying the aircraft work (throttle, trim, aileron and elevator). This is a new problem in FSX, and though it was certainly reported to Microsoft long ago it evidently never got to a high enough priority to be fixed. I may delve deeper to see if it possible for FSUIPC to trap the keys before the ATC window sees them, instead of after. No guarantees though. Well, for FSX I don't really know. Many of the controls date back to FS98/FS2000 days. In fact a large number were added in that phase of FS development thanks to "Beatle", a friendly Microsoft guy who does post in these and Avsim Forums from time to time. He left after FS2000 and only rejoined relatively recently and in the intervening period I'm afraid a few of his additions "lapsed" in terms of implementation internally. The problem for me is simply finding the time to test them all, and then understanding whether they worked or not -- which in some rather obscure cases is not so easy. So, I gave up trying to document them that far, and leave it as a trial-and-error process for those with time and knowledge. Regards Pete

This can only be because the Registration process cannot access the Vista registry, and that happens when FSX (the process in charge) hasn't enough privilege. You must run FSX "as administrator" when registering. Unfortunately, Vista prevents the registry being changed without any comeback to the program trying to change it. Some sort of "silent defence mechanism" I suppose. Horrible. What do you mean, "nothing happens"? It doesn't run, or it doesn't make any difference? You are right-clicking on it and selecting "run as" then "administrator", aren't you? If nothing happens when using the short-cut icon you have on screen (which is most unusual), just find the FSX.EXE file in the FSX folder and do it to that. Folder properties are not relevant. The elevated administrator status is needed for registry access, unfortunately. The FSUIPC4 installer already set the FSX Modules folder properties for full read/write access, which allows the KEY, INI and LOG files to be written there -- check if you like.

Is there an FSUIPC log file you can show me in the FS Modules folder? Do you have anything else installed? I've never really heard of anything which will cause this -- FSUIPC isn't really doing anything at all at that stage. I assume you are starting with no FSUIPC.INI file? If there's no INI file it isn't scanning joysticks. In fact it is doing nothing anyway until FS is ready to fly. Pete

I really don't know the ATC Menu Open and Close controls. The normal keyboard control, (actioned by the ' key, I think, or is it the #?) would be the one called just "ATC", which is a toggle. Have you tried simply using that to both open and close the menu? Just because an FS control is listed in FS's "CONTROLS.DLL" (and therefore included automatically in FSUIPC's drop-down assignments list) doesn't mean it actually works, I'm afraid. There's a long history of such entries not being implemented or having been omitted in subsequent releases but never deleted from the table. Regards Pete

Yes. You will have to re-enter the details, exactly as before. Best to use a backup of your FSUIPC.KEY file (from the FS Modules folder) and cut-and-paste from there. Regards Pete

Sorry, I really don't know what wmpro offers or does. The facilities in FSUIPC are all described in the documentation. I expect it's a mix and match to suit yourself. But note that FSUIPC doesn't actually "make" any weather, it just provides some filtering actions. Pete

You are most certainly not entering it correctly, then. It doesn't matter how much you re-checked if you are making the same mistake each time. Use cut-and-paste to avoid getting 1's and l's, 2's and Z's and 0's and O's mixed up. Note that all three parts (name, email, key) must be identical to that supplied. Pete

This will be because you have a SimConnect.XML file in the FSX PC which stops local SimConnect connections on that PC. There still needs to be a "local" entry -- having only a "global" entry just gives you remote connections. It works with SP2 because Microsoft fixed this in thar rellease so that you still have local connections without a specific entry for it in the SimConnect.XML file. One way to (probably) fix it with SP1 or before is simply to re-run the FSUIPC4 installer, as that will add a local entry to the SimConnect.xml file. If it doesn't work it will be because you do have a "local" section but have incorrectly supplied it with an IP address or port. In that case it will need editing to fix it. Regards Pete

And this LevelD SDK uses this offset for its NAV1 radio frequency? That is very strange. Why does it not use the FS-provided radios? They seem to be implemented really well. Either NAV can support ILS functions. Yes, it is possible to increment any number in any radix, whether decimal or hex is irrelevant. they are just numbers inside the computer. The problem is that is is NOT actually hexadecimal, but "BCD" -- binary coded decimal. Each group of 4 bits represents a decimal digit, from 0-9. But the value of 4 bits runs from 0 to 15. so if you add 5 you can go from 0 to 5, but then you go from 5 to 'A' (10 in 4 bits). Add 5 again and you get to F. To go from BCD digit 5 to 0 and add 1 to the next digit up you'd have to add not 5 but 11 ('B' in hex). This is made easy in FS by having frequency INC and DEC controls. Hasn't this "LevelD" aircraft got anything to operate its (weird?) radios with? It seems rather a poor implementation to provide non-FS radios with no support for frequency changing. Er .. you presumably mean FSUIPC control, not FS? FS has no such controls. These are pure luck. it must be the way the LevelD software is interpreting the "impossible" BCD values x80A and x80F. I would have expected it to go wrong with most of these increments. You are just lucky it works for some. Well, it gets complicated, but with buttons (you can't do it directly with keypress programming) I suppose you could get a bit further with conditions using the offset tests. Check the Advanced Users guide. for example: W8B00&000F=x5 to check for an ending in '5', so inc by 11 but you then have to worry about the next high digit, for when that reaches 9 you have to add another x70. And so on. Suppose the frequency at present is "1ab.cd": The d goes 0 + 5 to 5, + 11 to 0. The c goes 0 + 1 from below till 9, then you have to add another x70 The b is even more complex. if the a is 1 is only goes to 7 then a to 0, b to 0, else it acts like the c with add increment addition of x700. Ugh. Surely, there MUST be better provisions in a well-thought-of aircraft such as the LevelD for controlling their radio frequencies. Chedck their documentation. Look for a radio frequency inc/dec assignment you can make. Regards Pete

Sorry, no. I don't think I ever did. If you want me to hazard a guess, try again, enabling FSUIPC "IPC read" and "IPC write" logging (in the FSUIPC options, Logging menu), then run the culprit aircraft/gauge, get the problem, close FS (if it hasn't crashed) and show me the FSUIPC Log file which you'll find in the FS Modules folder. I don't hold out much hope as on a crash the Log is usually well behing what happened, but you never know. A crash in a gauge is almost always a sign of either an incompatibility with that version of FS, or a definite programming error, so either way I think you will eventually need the author to help. BTW if you are not a registered user of FSUIPC, make sure you are not attempting to use any suspect keys for it -- delete the FSUIPC.KEY file from the Modules folder then try again. If you are not registered you are not losing anything by deleting it. Some bad (especially pirated) keys will make FSUIPC supply bad data to programs. Regards Pete

You showed me the WideClient log, not at all the result of seeking support from the SIOC folks. nothing here tells me anything about what this "iocp"client and server business is all about or how their IP addresses are anything to do with either WideFS or FS itself. The wideClient log clearly shows a good connection to though to be sure everything is okay you should also check the WideServer Log. Then it looks like your "sioc" program connected 5 times: before you did something at the FS end to force a re-connection. I'm sorry, but I do not know "sioc" nor have I any idea whatsoever about what you are talking about when you say "the iocp server and the iocp client have the same ip and this ip´s don´t much with the ip of the computer running FS2004". As far as I can see these things bear no relation to anything I provide or support. Regards Pete

Sorry, I have no idea what these "iocp" server and clients are, nor what "sioc" is doing with them. They certainly are not anything to do with either WideFS or FSUIPC. Can you try SIOC support, please? Regards Pete

sorry, there is really no way I can diagnose problems with individual gauges. Gauge registration isn't needed now. Please ask Bill what is happening. I'm sure he can sort it out. Regards Pete

I don't know that offset. It isn't one controlled by FSUIPC, so it must be an FSConv allocated one. Why not adjust the VOR1 using the standard VOR INC/DEC controls? Well, FS's frequencies are like that, but I'm afraid I don't know FSCONV. You'll have to ask there. Regards Pete

FSUIPC won't work in FSX. You need the new program, FSUIPC4. Please review the Announcements above which are there to keep everyone informaed about what is going on. Neither. You need to download and install FSUIPC4 (it comes with an Installer. Please read the instructions). Then you can purchase a new License key for it from SimMarket. All the details are provided in the documentations. Regards Pete

Good. I'm glad you managed to sort it out! Pete