Pete Dowson

Okay, thanks. Hopefully there are no adverse effects? Are you using Flitering on any of the axis calibrations (the "F" option checked)? If not sure, please show me your FSUIPC4.INI file. The only way I can see a potential hang is when filtering is enabled, though even then it seems unlikely. I'd like to know because there might be a better way. Regards Pete

Best, then, to post in the Support Forum, where help is provided. I've moved your post for you. I'm afraid FSUIPC version 4.6 is now well over two years old and is unsupportable. Please update to the currently supported version -- 4.827 or later. See the Download Links subforum, or get it from the usual www.schiratti.com/dowson site. Regards Pete

I cannot think of anything in FSUIPC or its files which could possibly change just because you had an FSX crash -- unless your FSUIPC4.INI file, the one in the Modules folder where FSUIPC4.DLL is also, was corrupted in the process. That is very unlikely unless the FSX crash occurred whilst you were actually making changes to FSUIPC4 settings. Anyway, I cannot really help at all with no information. I would need to see your FSUIPC4.INI file and the FSUIPC4.LOG file, both from the Modules folder, and also I need to know what you actually are trying to do with the settings. Are you talking only about calibration, for example (when it matters little where or how you assign), or a specific method of assignment? What is your goal, what are you trying to achieve by using FSUIPC for your throttle? You can paste files in a message here. Close FSX down first, though. Pete

Indeed a puzzle considering the functions used to read the axis values are identical between FSX and FSUIPC4. Not sure about "Flight" though. That's a different matter. But it certainly did sound like a driver issue. Pete

I moved your Support question out of the "User Contributions" subforum where it was inappropriate and unlikely to be answered. No offset sepcifically. You'd need to read the latitude and longiture values to get the aircraft position, and determine where it is in relation to the runway by using a database of runways (eg such as that created by my Freeware program Makerunways) and trigonometrical computation. Regards Pete

Does FSX recoginse the slider? Does Windows' own Game controllers recognise it? FSUIPC4 uses exactly the same Windows facilities to read these things as both of those. Maybe you have installed some Logitech software which intercepts the slider to program it for itself. Have you checked? Regards Pete

I'm afraid my mind is boggling over all this, and I am not understanding the intimate details. So I'm simply assuming the problem is to do with a loop of control, due to the lack of a disconnection of the axis input whilst moving the lever automatically. If this is what you mean then it is the same problem as with auto-throttles when the A/T is in control. FSUIPC's offsets do provide ways of dealing with this. I'm surprised you haven't mentioned similar problems with your throttle levers -- or aren't they motorised? If you check the FSUIPC offsets lists you'll find that, as with throttles, you can dsconnect the spoiler axis from the spoiler controls via a bit in offset 341A whilst stil reading the axis value at offset 3412. Normally drivers for moroised quadrants make use of these as well as those for throttles in order to get things working correctly. I'm amazed in that case that you don't have much worse problems with motorised throttle levers - or don't you have such, or never use Auto-Throttle? If you don't want to write a driver you still need to contrive to break the feedback loop which is presumably what is causing your problems. You can do this with a Lua plug-in and that is probably the easiest. Alternatively you could simply have a switch which sets the bit in the offset to disconnect the spoiler axis. The problem then is two fold -- the bit needs re-setting at intervals (unless you only set it less than 10 seconds before it is needed), and you'd need to have it switched on by touch-down. A Lua plug-in could do this easily enough and be triggered by the arm range on your lever assignment, or simply be looping checking for the arming action in any case (or using an event on an offset). There are several (multitudinous in fact) ways of doing it with a Lua plug-in, some more ambitious than others. I still don't understand how you've arrived at the spoiler being a problem without finding the auto-throttle problem first, if you have no driver for your motorised quadrant. Yours is the first such implementation I've heard of which uses no driver software. Regards Pete

It must be all pure coincidence, then, because your unregistered free version of FSUIPC doesn't even look at any flight controls or axes, and wouldn't no matter which version you use.. Again, this is nothing to do with FSUIPC. You must go to Ariane support. Regards Pete

Okay. I see your previous version of FSUIPC was 4.749d, so there's nothing changed in FSUIPC which could possibly affect either calibrations or assignments. In fact the only differences in the INIs are the additional option lines in [General], and these lines: 0=Saitek Pro Flight Yoke 0.GUID={6A69DD10-C5A6-11DF-8001-444553540000} 1=Saitek Pro Flight Rudder Pedals 1.GUID={FFE23710-BEA9-11DF-8001-444553540000} 2=Saitek Pro Flight Throttle Quadrant 2.GUID={52910170-5AA6-11DF-8001-444553540000} which are the connections FSUIPC found. It is extremely odd that your saved older INI contains NO identiies for any joystcks at all. It looks as if that INI has never been used, or has been edited since being used! My earlier analysis still applies. Somehow, somewhen, your device identities have been changed or you have old remnants left. There are no differences in the actual assignments or calibrations. In fact you have very few assignments in any case, so it is easy to see what needs doing. You have axis assignemnts to devices "B", "C" and "D", and, for "STICK AIRCRAFT" only, device "E". "B" is obviously the pedals, device 1 above, with rudder, left and right brakes. "C" is obviously the yoke, device 0 above, with aileron, elevator, plus a generic throttle and prop pitch. "D" is a mixture (only!?) -- presumably one lever of your quadrant (odd?), so device 2. These pretty well agreed with the settings, excet for the wrong GUIDs. I don't know how that arose. They shouldn't really change. You also have assignments for "STICK AIRCRAFT" for a device 'E' but that's not currently connected. But it seems that's the X52. So the correct [JoyNames] section as a whole should be: C=Saitek Pro Flight Yoke C.GUID={6A69DD10-C5A6-11DF-8001-444553540000} B=Saitek Pro Flight Rudder Pedals B.GUID={FFE23710-BEA9-11DF-8001-444553540000} D=Saitek Pro Flight Throttle Quadrant D.GUID={52910170-5AA6-11DF-8001-444553540000} E=Saitek X52 Pro Flight Controller E.GUID={2B6FC180-9B78-11E0-8001-444553540000} 0=Saitek Pro Flight Yoke 0.GUID={6A69DD10-C5A6-11DF-8001-444553540000} 1=Saitek Pro Flight Rudder Pedals 1.GUID={FFE23710-BEA9-11DF-8001-444553540000} 2=Saitek Pro Flight Throttle Quadrant 2.GUID={52910170-5AA6-11DF-8001-444553540000} There is one oddity remaining. In the section for Buttons on "Yoke Twin Jet" you have a single lone assignment to a device "A": 6=PA,6,C66226,0 which is for a "THROTTLE 20" control. That's very odd indeed. I have no idea why you'd want that, but if you do it appears to belong to this: A=3 axis 9 button joystick A.GUID={52910170-5AA6-11DF-8001-444553540000} which has the exact same GUID as the Saitek Quadrant above. If you do have this as a separate device, just add this line: A=3 axis 9 button joystick to the Joynames section. If it is really the Saitek, then change the assignment line to 6=PD,6,C66226,0 That's it. There was really not much wrong at all, just left over bits resulting presumably from changes in devices or manual editing. On your later message: Unless you actually disable controllers in FSX, when it sees what it thinks is a new connection it will do its automatic default assignments. If you've a habit of disconnecting and reconnecting controls, as it appears you have, then FSX will do this quite a bit. This is why most folks diable controllers in FS completely if they are using FSUIPC. Er, mixture and prop pitch should be usable independently. Why would you want them "in sync"? And there's no difference anywhere in your calibration between you old and new INI files. I've really no idea what you can possibly mean in any case. There's ansolutely nothing the updating of FSUIPC has done which could have affected anything you are experiencing. Nothing at all. The INI files prove this. Regards Pete

This is a motorised spoiler lever, then, just for the auto-action on landing? How is the input being made? Normally it would be a function of your quadrant driving software to take care of this. I've never heard from anyone before with a motorised spoiler handle. But if your quadrant software can't deal with it you could have the spoiler input axis assigned to a Lua plug-in which dealt with all this, instead of directly assigning to an FS axis. Why? The "arm" zone in the calibration delas with the arming. You do not have to use any key press at all. What is the point of that? It sounds like you are testing or claibrating whilst on the ground. FS is flawed in this regard, and when the lever is moved to or even just through the arm detente it reacts as if you had lanfed and deploys full speed brake. always get off the ground to set them up and test them. Regards Pete

Did you delete your INI file or edit it at all? And what was your previous version of FSUIPC? When updating you only have to run the Installer. Never delete anything first. Which ones are duplicated? Instead you appear to have a complete Saitek installation screwup. If you've not edited the INI file, it appears the Windows registry is in a bit of a mess as far as your Saitek devices are concerned. You haven't messed with the Registry, have you? Look: All this refers to the same device -- the GUID is the same. However, the same GUID (which MUST be unique) has devices with two different names: A=3 axis 9 button joystick A.GUID={52910170-5AA6-11DF-8001-444553540000} F=Saitek Pro Flight Throttle Quadrant F.GUID={52910170-5AA6-11DF-8001-444553540000} 2=Saitek Pro Flight Throttle Quadrant 2.GUID={52910170-5AA6-11DF-8001-444553540000} Assuming your assignments to the Quadrant are to device A then I think you'd better delete the first two lines above and change the "F=" oin the next two lines to "A=". Your pedals seem to be okay: B=Saitek Pro Flight Rudder Pedals B.GUID={FFE23710-BEA9-11DF-8001-444553540000} 1=Saitek Pro Flight Rudder Pedals 1.GUID={FFE23710-BEA9-11DF-8001-444553540000} But there are some devices which either aren't connected or which have rubbish still in the Registry: a Saitek X52 and a Saitek Yoke. Which are you using? If device E is the one you have assigned, delete the other 4 lines here. E=Saitek X52 Pro Flight Controller E.GUID={2B6FC180-9B78-11E0-8001-444553540000} C=Saitek Pro Flight Yoke D=Saitek Pro Flight Throttle Quadrant 0=Saitek Pro Flight Yoke 0.GUID={6A69DD10-C5A6-11DF-8001-444553540000} Delete the 0 lines in any case. Do you have any C and D assignments? You should be using your own INI file. You only need to delete the INI file if you want to start again because things are in a mess. Unfortunatle, if your registry is in a mess, which it looks like, it is possible that FSUIPC may again see the devices differently to the way you've assigned them. I can help more if i understood how you got into this state. It most certainly cannot come about simply by updating to a newer version of FSUIPC. Regards Pete

There's already a few Lua plug-in solutions for this which work reasonably well. They use accelerated increment/decrement controls when the rotary is turned faster. Take a look at these threads: http://forum.simflight.com/topic/70537-rotarieslua-with-leo-bodnars-card/page__hl__rotaries.lua http://forum.simflight.com/topic/68260-rotary-encoder-input-speed/page__p__426533__hl__rotaries.lua#entry426533 These are just two of the more useful ones I think, found by a quick search. There are also threads on this subject over in http://www.mycockpit.org/forums/. Regards Pete

Sorry, no. I suppose you could read it from the FS CFG file, assuming the user hasn't changed it since starting FS (the CFG file is only saved on FS exit). Regards Pete

The FSUIPC steering tiller assignment is merely one to the rudder with a different calibration. If the rudder does not steer your aircraft, then neither will the tiller as there is no difference as far as FS is concerned. Therefore, if it only affects that one aircraft, it sounds like it is broken. Maybe try reinstalling it, or contacting the maker's support? Regards Pete

No, provided the same axes are not assigned in both. Also be aware that FS does have a nasty habit of auto-assigning devices which it thinks are newly attached. This is why most folks who assign in FSUIPC disable controllers in FS. I don't think this problem is so prevalent in FSX as it was in FS9 and before, but just wacth out. If things start playing up, look in the FSX assignments to see if this has happened. It shouldn't unless you unplug and replug-in controllers. Regards Pete

The same as in the "press". You are forgetting how a rotary encoder works, or perhasp you don't know. Each click either makes contact or breaks it, so it is either a "press" or a "release". It isn't like a button which is only "pressed" when you press it. A rotary encoder can stay pressed or released depending where it was when you stopped turning it. So, if you don't program both press and release you are only using half the "clicks". Yes, they will be as they make direct calls into the gauge code. They don't even send any messages, and they don't call SimConnect or send keystrokes. Just direct execution of the same gauge code which would have been executed if you'd clicked the mouse on the switch instead. LINDA appears to use a mixtures of all sorts of things, but, yes, particularly Lua plug-ins. However, i don't know much about it and I certainly don't know if it implements value storage and updates as opposed to using INC/DEC controls. It probably varies. LINDA has its own suport forum I think. Best ask about such things there. Regards Pete

I don't use any GF ones myself, but generally for dual speed rotaries like those you should at least program both speeds to do whatever it is you need doing, and to both "press" and "release" -- i.e. 8 assignments per rotary, 4 in each direction. You should also try to avoid assigning to keystrokes if at all possible because they are slower to process through Windows into FS and build up to make a queue which will induce overrun. FS controls are best, or the PMDG 737NGX equivalent where available. I don't know what the Wilco and iFly models can use I'm afraid.. Most decent hardware implementations of things like MCP display updating use an internal copy of the value and send an updated value instead of using INCs and DECs. Then they update their own local copy of the value from FS only when there hasn't been a button input for a while -- say half to one second. This gives the smoothest result by far and is the closest equivalent to what you are comparing it with. It can be done for FSUIPC by using Lua plug-in programming, but it isn't suited to non-programmers. If the problem you have is simply that it appears to be missing some rotary "clicks" then, yes, you can increase FSUIPC's button pollng rate. There's a parameter in the main Buttons section of the INI file for that. But it will always be a compromise, for performance. Regards Pete

Actually, I used the info in the WinDbg log with my later version of FSUIPC4, and it isn't so far away as to be completely useless. The problem appears to be related to a critical section lockout within the joystick axis checking. I can't see how a lockout can happen, though -- but if it did you'd expect FSX to hang, not crash -- hence the "AppHangB1" label rather than a specific crash code. I've made a small change to the routine I think might just possibly be responsible. Please try FSUIPC version 4.838 here: FSUIPC4838 test.zip If this still fails in the same way, I could still really do with the most up to date information (the WinDbg and Log). But either way, working or non-working, I really could do with seeing your FSUIPC4.INI file, so I can work out what is so different on your system. I suspect it might be related to joystick axis filtering being enabled in the calibrations. That's always been a pain because it needs multiple threads accessing the same information in order to smooth over a timeframe. Thanks, Pete

Just assign the button to an existing key using the GUI, then change the keycode in the INI file line to the keycode for the key you don't have. You can do this without closing down FS. In the buttons tab just press the reload button to get the change loaded. That's probably the easiest way. An alternative is to assign the button on the FS control side of the assignments tab, using the "Key press & release", "Key press/hold", and/or "Key release", as you wish. You use the keycode with shifts encoded in the parameter. Regards Pete

Not really at first glance. The information on the stack would be useful if you were using the current version of FSUIPC4 (4.837) as then I should be able to pinpoint exactly what it was up to at the time (I gave up trying to keep compilation maps of every version ever released, so I only have the current one). It looks very much related to SimConnect, so I'm wondering if you have a SimConnect mis-match (i.e. the one not relating corrctly to your FSX.EXE and its modules). I've seen that happen before, and it is usually deducible from the information FSUIPC logs.. One part which is interesting is this: ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION} Breakpoint A breakpoint has been reached.[/CODE] [font=arial,helvetica,sans-serif]which implies that something in FS or add-ins has reached some place which it should never do and has given up. There are no breakpoints in any of my code, for certain. There are some in FS related to anti-piracy measures I think. But I really don't know anything about them. They can be encountered when using a debugger, but those are always recoverable -- i.e. you can tel the debugger to continue execution and FS carries on quite happily.[/font] Without the FSUIPC4 log file, as a start, I can't help further, but if you can supply that AND another WinDbg file as above[b][i] but using 4.837[/i][/b] (or whatever is current at the time you send it), I'll pursue it further. Regards Pete

Sorry, what do you think the difference is between a "virtual key" and a "real key"? FSUIPC only knows how to send keycodes. "Real keys" can only be sent by real keyboards, keyboard emulators, or low level driver-like monitors which hook into the keybaord system low down enough to fool Windows. What's a "dx button" BTW. Do you mean a "joystick button", i.e. one recognised by FSUIPC's button assignments tab? Regards Pete

Do you know why? Sorry, I don't have any CH hardware nor either aircraft but P3D is identical to FSX+SP2 for all intents and purposes. Have you never used these in FSX? What are the problems you have with normal FS assignments? Are you sure it isn't a question for the support folks for those add-ons? I'm not going to try making a sale on a promise that i cannot possibly know can be fulfiled! Regards Pete

Easiest way to delete them all is simply to delete the [Axes] section completely. One problem if you keep unplugging and plugging things in again is the possibility of Windows assignng different ID numbers to them next time. This will not only mess the Axis assignments up but also all the button assignments. It isn't just a matter of always using the same USB sockets, but the order in which you reconnect them (if power is on). With multiple devices you should really consider using the joy letters instead -- you can assign them mnemonically, or just let FSUIPC assign them automatically (A, B, C ...). After that FSUIPC will identify them by their names and GUIDs (that's why thast section in the INI is there). Regards Pete

You have assigned the throttles to "throttle set", not "axis throttle set" as I instructed. I don't think the now defunct "throttle set" can be handled in the way you want. It's of very secialist use within certain add-ons. You also have an unknown (not connected) axis assigned the Throttle1 direct, as shown in this line: 2=1S,256,D,9,0,0,0 That assignment can easily interfere. Best delete it, as with other assignments to non-existent devices. You have axis assignments for three devices which aren't listed as connected (devices with joystick nmbers 1, 2 and 4), including two axes on the same unknown device both assigned to the right toe brake: 5=2Y,256,D,8,0,0,0 6=2Y,BR,-16384,12544,x05006DB0,x02,x0B006DB0,x00000002 7=2Z,256,D,8,0,0,0 8=2Z,BR,-16253,11008,x05006DB0,x02,x09006DB0,x00 with a third on a different unknown device: 12=4Y,256,D,8,0,0,0 13=4Y,BR,-16384,9216,x05006DB0,x02,x09006DB0,x02 You only have two assignments to the left brake, though. Finally, you don't seem to have (yet) gone through the calibration steps on either the ailerons or elevator. These are the defauls: Aileron=-16380,-512,512,16380 Elevator=-16380,-512,512,16380 I've never known any device which exactly suit the defaults! Regards Pete

I just found this support question in the FAQ subforum, where it won't get answerred, so I've moved it to the Support Forum. What do you mean "before anything happens"? No window appearing showing progress? That's the first thing it does, open a Window, which surely Win8 is capable of? No. The installer is a standard Windows program using only standard windows facilities. It doesn't need any compatibility settings and certainly doesn't need any of FSX folders to be made read/write. I need more information -- you say it does nothing, not even open a Window? What does the Windows application log show for the error. It should tell you the module offset and error code at least. Regards Pete