Pete Dowson

NEVER EVER post confidential information such as your key in an open Forum. I may have to disable your registration now, if it becomes circulated by pirates! The key is a perfectly valid FSUIPC3 key purchased on 4th April 2010. You are making an error entering it or your name and email address. Cut and paste if you can't get it right normally. Pete

Your install log shows it is okay. First, did you let FS install into the default place, in "Program Files"? If so, are you perhaps running FS "as administrator"? If you are you must run all FS applications the same way -- Windows doesn't allow programs of differing privilege levels to exchange data. Otherwise, maybe it is a registration problem. Is FSUIPC registered? If so, do those programs work if you remove the FSUIPC.KEY file from the FS Modules folder? If so then either one of your registration keys is bad or your System date is wrong. Regards Pete

Not directly, as they are USB HID devices. But Massimo ("maxx") made a driver which allows you to do that: maxx's free SPAD: Saitek Panels Advanced Driver Go to http://fstools.weebly.com Regards Pete

The reason it isn't obvious is because it really doesn't work well -- the facilities it needs simply aren't there in FSX. I simply didn't rip the code out as folks might like to experiment, and, in any case, they do work okay if your weather is supplied via an external program using FSUIPC to set the weather. That would be unusual, though. Correct. ASE uses SimConnect direct. You need to use the ASE options to do those things. Regards Pete

Is the switch for selecting the mode detected as a switch or button in FSUIPC? If so you simply make your FSUIPC assignments conditional upon that switch setting. If not then you'd need some other switch to act as the selector. How do you work that out? The condition test only determines whether that line, that assignment, should activate when the primary button/switch is used. That's why that assignment becomes "conditional". You make other assignments for the same primary button or switch with different conditions. Hence you get different modes. If you only have one condition button you only have two modes -- with the condition button or switch off or on. With multiple switches or buttons, or a multiway switch, you'd have 2^N modes (2 buttons --> 4 modes, 3 buttons -> 8 modes, etc). You can also use one button to make as many modes as you can, by using it to cyclically increment a user offset (Offset byte cyclic increment control). You can use User Offset x66C0. Then the condition you'd use would be an Offset test: "B66C0=0 ...", "B66C0=1 ..." etc. One Byte can have 256 values, so256 modes. The only trouble with that method is keeping track of which mode you are in. You could use a Lua plug-in to display that, however. All you need to do is set things up in cold and dark mode and save that as your default flight. Regards Pete

I doubt itthey may simply be still miffed at Microsoft's actions! ;-) I've been following all of your experiments and conclusions and find them very interesting. Thank you! I noticed today that even Mathijs Kok begin_of_the_skype_highlighting end_of_the_skype_highlighting of Aerosoft has endorsed your work! That is any achievement! ;-) Unfortunately I've no inside or intimate knowledge of any of the graphic components of FS. Like multiplayer, it is an area I've never delved into. The only places I used to know a reasonable amount about, of the innards, were the simulation engine itself (SIM1), the weather (Weather.dll) and the controls mechanism, working through CONTROLS.dll and PANELS.dll. And even that knowledge is limited to FS9 and before, as for FSX I took full advantage of SimConnect to save the many 1,000's or hours I spent hacking into things on each previous Release of FS. Best Regards Pete

You don't ever actually lose them -- they are still in the INI file. But your device number will be changed by Windows. There is an easy answer. First, make sure you are using the currently supported version of FSUIPC (3.98 or 4.60 or later). Second, take a look at the chapter in the User Guide called "Keeping track of multiple control devices". It's listed in the Contents near the front. This facility allows Letters (A-Z) to be used in assignments instead of the Windows ID numbers, so that if the numbers change, FSUIPC can still identify which device is which. Regards Pete

Yes, that is okay. Regards Pete

Hmm. It's an error in the FSI file, not in FSInterrogate itself. That file is a data file which is created when you edit entries in FSI's tables, and all that has been composed by many folks, least of all myself, but AFAIK it hasn't been checked in the level of detail you are using. I think it even still refers to lots of usable offsets as "unsupported" or something similar. I will edit the file entry, as you can, and it will be corrected in the next release, but you should be using the proper documentation for details of offsets -- FSUIPC for Programmers or FSUIPC4 Offsets Status for FSX. Those are the documents which are maintained, more than the FSI data. Good! ;-) Regards Pete

No. As Paul said, that system doesn't apply these days. I just like the courtesy of folks asking, which you have, so please do carry on. Regards Pete

Yes. Please use the currently supported version of FSUIPC. You are using an old unsupported version. Pete

There is no such message in any program of mine! The nearest I have is this one: There are duplicate copies of FSUIPC installed! Please remove older copies! Never simply rename modules, move them OUT of the Modules folder! If you mean this one, and you do not have any copy of FSUIPC in the main FS folder and no renamed ones in the Modules folder, then the only other possible cause is that your last FS session did not terminate, so there is still an FS process running including FSUIPC in memory. That would look like a duplicate entry. Check for this before next loading FS by using the Windows Task Manager -- Ctrl+Alt+Del. Select the Process tab and look for "FS9.EXE". If it is there, then, even though you have no window or other visible sign of FS, it is still actually running. Something you have added is stopping it closing down. Try terminating the process forcibly in the Task Manager, then load FS -- yuo will no longer get the error. Regards Pete

Best to read the "Ready to Fly" offset, 3364. If you read 2 bytes from 3364 and check that both are zero, then you will know that the Sim is ready. Pete

If you assign them all via FSUIPC assignments, then FSUIPC will arbitrate, selecting the one with the highest value. So what you want could work, PROVIDED that you don't raise your "secondary" throttles further than the "primary" setting. If you did you'd need to correct it by moving them back and then moving the primaries slightly. This is because only changes have effect, not static values. Not if assigned in FSUIPC. As I said, it arbitrates between axes assigned to the same control, taking the highest (or furthest from centre for controls like aileron, elevator and rudder). That's what the arbitration would do. You could write a plug-in to do such things in clever ways, assigning the throttles in FSUIPC to different user offsets then programming whatever manipulations you like in the plug-in before sending them on as FS controls. But do try the normal arbitration first. I think you'll find it is close to what you want in any case. You don't need to do anything special, just assign them all in FSUIPC "direct to FSUIPC calibration". The arbitration is automatic for duplicate assignments. In a few hours I am leaving for a holiday, not back then till April 8th. Regards Pete

Those are unsupported. The earliest currently supported version is 3.98, as stated in the Announcements in this Forum. Please update! Sorry, that is not one of my messages. Where do you see that? From an third party installer program? Just install using the the FSUIPC installer included in the downloaded ZIP file. It will take care of things. Does "Fehlermeldund" mean failure message? What is the actual failure message you get? It certainly isn't as above. I also need to know what program gives you that message. The FSUIPC installer produces a Log file. Why not refer to that? It contains ALL of the details of the install process! Regards Pete

Yes, from your last log I did expect this version to crash also. I'm afraid it isn't something I can fix -- it is definitely in DirectInput, as I said. Looks like your KVM switch doesn't treat the connections very nicely and Microsoft's code objects. All you could possibly try, apart from the work-around I gave you, is updating the DirectX on that PC. Maybe it was a bug and is fixed now. Yes, thought it would. It simply stops WideClient scanning joysticks in order to send buttons to FSUIPC. That's an okay solution providing you don't want to connect anything on that PC. Regards Pete

But unless they've programmed their own reading of the joystick, which would mean assigning it in their software not FS or FSUIPC, the aircraft would only receive any conflicting values from the throttle if they were changing. Neither FS nor FSUIPC take notice of values which remain static. Only because they are indistinguishable, the way that aircraft is programmed! Why not park it in the full throttle position? You should have a dead zone at both ends -- unless you've not followed the advice I provide in the documentation. ALWAYS calibrate the maximum a little BEFORE the maximum value the lever can provide. This does too things: it ensures you can always reach maximum even with variations in joystick readings (which do occur, due to temperature and voltage), and it provides another place to park the throttle, just as you need here. Pete

If your program is only reading and writing FSUIPC offsets, then it should work just as well over a WideFS connection. That's the idea of WideFS. If not then maybe you haven't got a connection working? Does Wideclient say it's connected? Check the WideClient and WideServer log files. After today (Wednesday) I am away until April 8th. Regards Pete

Yes, that is the idea. There are some differences I could not avoid, and of course extra things in FSX (as there are extra in FS9 over FS8 etc). Best to check the "FSUIPC4 Offsets Status" document in the SDK as well as the main Programming one to see whether any of the offsets you use are annotated with differences (normally in red). . Yes. No procedure needed, just go ahead. Regards Pete

You've not changed FSUIPC, only WideClient? If so, it cannot make a difference on the FSX PC -- there's no contact made till it's "ready to fly". Reinstalling what? Replacing FSUIPC4.DLL with an identical FSUIPC4.DLL won't make any difference. It looks like a clash between two modules being loaded simultaneously by SimConnect. That's the only time I've seen that. Check to see if there's any log fragment produced -- I don't think there will be. If you want to try the latest FSUIPC4 there's a 4.604 available in the Updates Announcement. Regards Pete

One more thing, as well as trying that later version, please let me see your WideClient.INI file. One interesting thing is that the crash occurs in Windows' DirectInput module: I suspect that address in WideClient isn't far off where it would be in the later version, as it is very near the beginning of the code module. It looks like it is in the Button scanning routine, within the call to Windows "joyGetPosEx", used to get details of button states. If this is the case it might be simply that the DirectInput routines in Windows don't take kindly to a HID (Human Interface Device -- keyboards and mice as well as joysticks fall into DirectInput's lap) disappearing whilst being looked at. Most KVM switches I know of maintain some correct signals or voltage levels or whatever it takes in order to make sure that the device doesn't look like it has actually disappeared suddenly. Does yours? Is it connecting to USB or to older type PS/2 sockets? If not the latter it might be a good idea to try connecting to the old round sockets (via adapters) if your Client PC has them. Alternatively you could turn Button Scanning off on the Client -- put "ButtonScanInterval=0" into the [Config] section of the WideClient.INI file. Regards Pete

Don't know how that could be -- it wouldn't know how to detect it. Could you try it with this version please: http://fsuipc.simflight.com/beta/WideClient6797.zip This is the one I am using and I can use the Log details to narrow it down a bit then. Unfortunately I've only tomorrow left before I take a week's holiday. I might not solve it before then. Pete

Thanks! Glad the fix was easy. I would still prefer you to update to the latest version of FSUIPC. ;-) Regards Pete

Well there are many hundreds of LevelD users for sure. They can't all be flying without A/T all the time, surely? The answer must be to stop your throttle jittering. Either park it in a stable spot (or make your dead zones wider), or assign in FSUIPC and make the Delta larger to cover the jitter. The trouble with a larger delta value is that you get coarser control. Regards Pete

Don't you mean 4,11? Else what you say doesn't relate to what you show. If you do mean 4,11 then it seems your 4,12 button is always on, which would explain exactly what you see. Please enable Button logging in the FSUIPC logging Tab, and reproduce the problem. Show me the log AND the whole of the Buttons section of your INI file, please. I need to relate the real button state to the line being executed. That's what the log will show. For larger files pasted here, just select them after pasting and use the "code" button to envelop them. It makes them independently scrollable and selectable. Ah. not supported. Please update to 4.60 (minimum) before doing any more tests. I really cannot support old versions. I am away after tomorrow (Wednesday) until the 8th. Regards Pete