Pete Dowson

There's a very very good reason for having an initial delay before repeating kicks it. Without any at all it is very difficult to do single one step changes. FSUIPC is here merely emulating the way the mouse action on gauges also operates, and for the same good reasons. The delay is built in to the way FS works, so no. It is there for the reason I stated. Keyboard repeat delays are actually part of the Windows/BIOS keyboard programming and are also done for the very same reason. Regards Pete

Sorry, but FSUIPC has nothing to do with the names spoken by all the volunteers who made the WAVE files used by RC for ATC enunciations. There's actually no artificial speech synthesis used in any case -- words have to be recorded by real live people! And FSUIPC is an interface program for applications, not a specific tool for RC. Both questions should have been put to the RC Support Forum on AVSIM. Neither are anything to do with my programs. Sorry. Regards Pete

Both of these odd things appear to be true, yes. Must be some function of the specific gauge coding, even a bug possibly. You never saw all of the Magneto controls? How hard did you look? They start with the word "Magneto" so there is really no excuse! Here's a list: MAGNETO 65586 MAGNETO1_BOTH 65930 MAGNETO1_DECR 66126 MAGNETO1_INCR 66127 MAGNETO1_LEFT 65929 MAGNETO1_OFF 65927 MAGNETO1_RIGHT 65928 MAGNETO1_SET 66400 MAGNETO1_START 65931 MAGNETO2_BOTH 65936 MAGNETO2_DECR 66128 MAGNETO2_INCR 66129 MAGNETO2_LEFT 65935 MAGNETO2_OFF 65933 MAGNETO2_RIGHT 65934 MAGNETO2_SET 66401 MAGNETO2_START 65937 MAGNETO3_BOTH 65942 MAGNETO3_DECR 66130 MAGNETO3_INCR 66131 MAGNETO3_LEFT 65941 MAGNETO3_OFF 65939 MAGNETO3_RIGHT 65940 MAGNETO3_SET 66402 MAGNETO3_START 65943 MAGNETO4_BOTH 65948 MAGNETO4_DECR 66132 MAGNETO4_INCR 66133 MAGNETO4_LEFT 65947 MAGNETO4_OFF 65945 MAGNETO4_RIGHT 65946 MAGNETO4_SET 66403 MAGNETO4_START 65949 MAGNETO_BOTH 66026 MAGNETO_DECR 65634 MAGNETO_INCR 65635 MAGNETO_LEFT 66025 MAGNETO_OFF 66023 MAGNETO_RIGHT 66024 MAGNETO_SET 66028 MAGNETO_START 66027 Not sure why you think it bizarre. It is quite possible to code compete cockpits without ever using L:Vars. Good. Well done. And are you going to keep this method a secret rather than share with others? Regards Pete

I suppose it depends how it is used inside FSX compared to FSUIPC. It is also interesting to see other users being successful with the device and FSUIPC. Have you checked with what they might be doing differently? I take it that you have disabled controllers in FSX before assigning in FSUIPC? Otherwise, even without assignments in FSX it will still be interrogating it. Pete

There's some conflict going on at the driver level somewhere. Did you check for other, now redundant, drivers? Look through the stuff in Device Manager. Also try making sure your DirectX is bang up to date. Doesn't the Hotas Warhog work as a joystick device without their drivers? Maybe some programmable functions are lost? If you can disable/uninstall it and try without you may at least elmiinate it as the cause -- or not. You could always reinstall it again afterwards. Have you tried their support forum? Pete

The "autoscandevices" option only changes what FSUIPC does when you enter its options. You never said anything that indicated that was the only time it crashed. In fact you didn't really say much helpful at all, but the implication was that it occurred when you were flying not when you were doing something so specific. The routine to scan for devices called up when you enter the options is exactly the same routine entered when FSUIPC starts up. It sounds very much like a Hotas Warthog driver bug which doesn't like being queried when it is already operating. You should contact Thrustmaster to see if there's a fix. I notice that as well as issuing new drivers from time to time they also have updated firmware for your device. Maybe you should check? Pete

Yes, of course. In fact you are expected to keep up to date, especially if you want any support. The purchase covers FSUIPC4 forever. No. the installer merely updates the program and documentation. no changes are made to any settings. Pete

Not to provide any information about the problem, then. but the log shows there was no crash! When does the crash happen, and why didn't it happen then -- how did you get a good log? It is likely a compatibility problem with the Hotas Warthog driver. Try without. Also check what others have found. I see in AVSIM there are folks happily using the device with FSUIPC -- see for example this thread: http://forum.avsim.net/topic/396940-thrustmaster-hotas-warthog-fsx-configuration/ Does it all work in FS, without assigning in FSUIPC? They both access joysticks in the same way, via standard DirectInput functions in Windows. Maybe you need a DirectInput update? Regards Pete

I don't know why you showed me a Log depicting a perfect session, no crash at all. What was the reason for that? It sounds to me as if you have a bad joystick driver -- neither Dinput8 or NTDLL are part of FSUIPC, but both are involved in accessing or checking joysticks. First try uninstalling the Hotas Warthog, as that is the most obvious culprit. Otherwise use the Windows device manager to disable each device in turn till you find the culprit. There's no other useful information here. You've not said what you use FSUIPC for, even, so I cannot help further. Regards Pete

Two points there. First off, FSUIPC4 is only for FSX and later. FS9 uses only FSUIPC3, and the correct offsets list to use is the Programmer's guide, not the addendum "FSUIPC4 Offsets Status". Second, none of those systems were modelled in FS9. Add-on aircraft do their own thing and add systems themselves, within their code. FSUIPC's general offsets can only supply base FS data,. I don't know if Wilco Airbus A320 uses FSUIPC, nor, if it does, where it makes such things accessible. You'll need more inforemation about the add-on aircraft. Regards Pete

They will appear, but as "Lua b377 reverse" and "Lua b377 exit reverse", as I already explained. The prefix "Lua" is always there to show that it is a Lua plug-in you are assigning to. Sorry, you've lost me there. It doesn't matter what the code in the plug-ins does, you need some way of making them run. That's normally by a button or key assignment, unless you want them running all the time, which for these certainly doesn't sound likely! No no. You evidently did not really read my previous reply. I explained there that all you needed to do was press the Reload button. Any added files will then be recognised. They don't need arranging. Please just read what I write a little more carefully and you'll be okay. Regards Pete

Sorry, I don't understand this. Can you explain (a) what you are actually doing, (B) what you actually want to do, and © what the problem is? Regards Pete

This can happen if your previous session of FS9 did not terminate properly. There's no way FSUIPC's installer can invent an error report from Windows -- it simply logs what Windows reports. Use the Windows Task manager and examine the list of processes still running. Delete forcibly the one with FS9.EXE identified. Regards Pete

Don't see what good deleting the INI file will do. If one axis is readable on a device, they all are readable as it is one call into Windows to read all axes, POVs and buttons, all at once. There's no way to separate them. And FSUIPC does the same thing when you enter the Options as it does when it is started, exactly the same. I assume you are using an up-to-date supported version of FSUIPC, by the way? 3.999z. Pete

Since FSUIPC is not aware of those in any way, I'm afraid I can't help there. Sorry, there's not enough information. What version of FS? What version of FSUIPC? What are you assigning it to, exactly? Note that versions before 4.86 (for FSX and later) and 3.999z (for FS9 and before) are not supported any more. Please update if your version is older. Pete

That looks like some corruption someplace. I think "BEX" is to do with attempting to execute data. But I'm not sure. You might be better off referring to the CTD and Crash forum over in AVSIM. they have lots of examples and solutions over there. If you Google BEX error you'll find lists of possibile causes, some to do with BIOS settings I think. Here was one reasonably clear explanation, though I don't know if it is correct: Buffer overflow is a condition when some process tries to store data beyond the capacity of the fixed/available buffer so it tries to overwrite some other memory locations, too. And in Windows we have some security feature called Data Execution Prevention that is intended to prevent similar processes to prevent buffer overflow attacks (that can introduce some malicious codes). But in some cases DEP can prevent some legitimate software from executing, too. And then you can get a BEX error. I don't really think I can help a lot more. Sorry. Pete

Sounds like they are asleep. Are you sure you actually need to scan them? Normally just entering the options and exiting again will do the trick. Check your USB power management in Windows Device Manager. It defaults to "on" which makes Windows remove the power when the device isn't used for a while. If they are asleep when fS + FSUIPC is starting up, then the devices won't be seen. Regards Pete

Right. No, do not do that. As I said GPSout is built into FSUIPC, and you configure it in the FSUIPC options, whilst in FSX. You need to be registered to use these facilities. On FS9 GPSout does not need FSUIPC. If it isn't working then your port is wrong or not working. Use a port monitor to check the output -- there's a free one at www.sysinternals.com Yes, it is part of the registered user benefits of FSUIPC4. With Microsoft providing the SimConnect application interface free for all to use I had to build in more benefits for user registration. GPSout is just one of them. But it is built in, you do NOT use GPSout.DLL or a separate INI file. No. Do NOT do that. It will make a mess. To register you only need to re-run the Installer. Regards Pete

Ah! Well spotted! Seems I forgot to add it to the user documentation!!! I'll fix that read for the next full update. Sorry. Meanwhile, check the FSUIPC4 History document, first item in the Version 4.84 section. Regards Pete

No, you posted in a Subforum intended as a repository for answers to commonly asked questions ("FAQ"). For all support questions you post here, to the Support Forum. I've moved it for you. The crash is actually in SimConnect, not in FSUIPC. Since FSUIPC does not use SimConnect for axis assignment or calibration, I suspect this crash is a result of some of the other software you have running. Maybe you are also using Saitek's own software and there is a clash? Or else try stopping your other recent changes - A2A and ActiveSky 2012. Regards Pete

Logging is always a useful way of seeing what is going on. You could also, of course, actually check that the FS controls you are assigning to actually do what they appear they should do by their names. There are a number of instances where Microsoft have got them mixed up. e.g. possibly the "OFF" actually does the "Right" and vce versa? I shall check that here and now ... ... No. In FSX with the default Cessna 172, Off does go Off and Right does go Right. But, oddly, on pressing "Left" after "Right", it goes to "Both" not Left. It only goes to Left from Both. Weird. Anyway, you'll need to do the logging yourself to see what is happening. As I did, testing controls by direct assignment to keypresses would help work it out too. Regards Pete

Ah, when you said it was varying strangely I assumed you meant when looking directly in the assignments tab. You need to double check at the SIOC end using FSInterrogate, and at the FS end using the Monitoring facility, as I suggested. It's a waste of time repeatedly talking about odd things happening with no actual information. And as I said, it isn't the software "deteriorating" so it must be related to the link or SIOC. But the checking I suggested will confirm or deny this. Pete

It sounds like it must be a hardware or wiring problem. Maybe power? How is it connected? The software isn't going to be deteriorating in any way. Regards Pete

Time to update, then. Support for 4.85x ceased when 4.86 was released. No, not strange really. That's how Cessna does them, and Piper too I think. As the OFF position is not a contact, I have tried the following assignment for engine 1 when controll is pressed: Sounds like the switch you are using only has a momentart contact, so it goes on and off for each position? but if that is the case there should be a connection for the OFF position, or it would be unusable. Have you verified what is happening by using the Button and Event logging options in FSUIPC? Ah, then it certainly sounds like you actually have the wrong assignment. Try the logging. If you don't understand the log, paste an extract here so I can see what is happening. But please update FSUIPC first. Regards Pete

HidScanner is provided in the Download Links subforum, in the thread with the Lua plug-ins package which it complements. Regards Pete