Pete Dowson

There is absolutely no reason why a flight save instigated by FSUIPC is any different at all from one instigated by using the FSX Menu or the ';' shortcut. All three call the same place, and definitely all three cause the PMDG code to save its own additional files. This was confirmed by Andy when he posted the useful information about managing those extra Autosaved files in this thread: http://forum.simflight.com/topic/69068-tip-autosave-and-the-pmdg-ngx/ There is no difference in files saved in any of the three ways. Therefore there cannot be any difference in how they affect things when reloaded. To let PMDG determine how loading their own saved files does not restore the aircraft to its state at the time of saving you will have to send them some samples. No one from PMDG has contacted me in years. That is most certainly a falsehood. Regards Pete

Yes. For FSUIPC to calibrate an axis but not send it on to FS you'd need to disconnect after calibration. That's done using offsets in FSUIPC -- there are bits for most of the control axes which have to be set to do a disconnection. These were intended (and used) for Fly-By-Wire implementations. For safety FSUIPC restores the connection every 10 seconds or so unless you reset the bits more often, so you need to keep setting the right bit (use the ipc.setbitsUW function).. You need really to refer to the offsets lists where these things are described. Download the FSUIPC SDK. There's a Programmers guide which covers FS9 and before, and an FSUIPC4 Offsets status document which covers FSX. Both are the same for all this. Check offset 310A for the disconnection. You can read the calibrated value which would have otherwise have been sent to FS in signed 16-bit words ("SW") in offsets starting at 3328. You can use event.offset to set an intercept for changes to the relevant value. You can read the calibrated value even if the axis is not disconnected, if that's all you want. Regards Pete

I don't know anything about the GFDevFSX.exe part at all. That and GFDev.dll are not connected, and they don't use each other. As you understand correctly, FSUIPC just uses GFDev.dll for the button detection and the Lua gfd library. You can drive GF modules more directly, without GFDev.dll, via the HID provisions in the Lua com library too, but it shouldn't be necessary as GFDev.dll covers pretty much all you need to do. No. The GetValues function only gets the state of switches and dials. It has nothing to do with displays and indicators. The SetLight and ClearLight functions use GFDev.dll to read the LED states, perform an OR or an AND to set or clear the bit referred to by the "id" parameter and send it back. Assuming there's nothing else talking to the device then the only way that might be able to go wrong is if the other Lua thread got in between those two actions (I don't have it protected by a critical section enclosure), but as they are only a line of C code apart this is an extremely unlikely thing to happen. I have several different GF modules here. Just testing running these two Lua programs one after the other: gfd.SetLight(GFRP48,0,1) [gfd.SetLight(GFRP48,0,2) I end up with both LEDs 1 and 2 lit, as expected. Maybe you'd better tell me which version of FSUIPC you are using (things do change and there have been bugs corrected over the years and months), and maybe show me your code. I am using FSUIPC 4.728b at present, but any recent version will be the same in this regard. Check the Download Links subforum. Regards Pete

What does "no dice" mean? You couldn't download it, or no log at all? If there's a log you can see if you downloaded 4.728b or not. If you haven't refreshed your cache you probably have the older one as the filename is the same. I'm afraid saying "no dice" is totally unhelpful. Pete

No. Please read my earlier reply. If you are completely taking over the Goflight devices you only need GFDev.DLL. The other Goflight modules (DLLs) or EXEs aren't needed and will just confuse the issue and may stop your Lua programs or whatever working. But if you want to only do bits in Lua or just assign some switches via FSUIPC, then you'd need both. It won't matter if the GFConfig install path in the Registry points correctly to the folder containing GFDev. You most certainly must never put a non-FS DLL into the FS9 modules folder or it will crash FS. Having GFDev.DLL in the modules folder only applies to FSX and later. Isn't the Goflight driver for the MCP separate from the other drivers? If so then you could keep that loading, of course, and just dispense with the others. Depends how you are setting them in the Lua. Unlike GoFlight's software FSUIPC reads the state of the LEDs before changing only the ones you want changing. You'd need to elaborate. Regards Pete

What is wico doing using offset 5648? That is allocated to Project Magenta! As far as I am aware Wilco aircraft do not use FSUIPC at all. Sorry, i think you've come to the wrong place. I really don't know how you are expecting to interface to Wilco aircraft through FSUIPC, but for a Wilco aircraft not working you need their support. WideFS never works at all unless it is registered. There is no time limited demo. Pete

65820 is THROTTLE1_SET, the old FS axis control, the one which allows a reverse range. When you were editing the Lua, were you reloading FS to test it, or changing aircraft? If neither it wouldn't have reloaded and recompiled, but remained running as it was. The file on disk is not being re-interpreted all the time, it is only loaded the once. To develop and test Lua plug-ins I assign two keypresses -- one to to Kill it ("LuaKill <name>") and the other to run it ("Lua <name>"). Then you can keep changing it, testing it, etc, in the one session without any other reloads. Or you can get away with just the one keypress, to run it -- when you run a Lua which is already running it kills the existing one automatically. Regards Pete

Earlier you said "throttle decr small", which is not the same control as "throttle1 decr small". the are numbers 66634 and 66635 respectively. The FS keys will operate the general all-engine controls, not the individual engines. There's no difference between assigning a control in FSUIPC and using the ipc.control function in Lua. both do the same thing -- send the control number to FS. BTW I noticed the thrust logged in one of the logs above going to -16384 -- full power reverse! Is that actually allowed on that aircraft? I know jets tend to have a max of 25% (-4096) or less in reverse. Regards Pete

Because the filename has not changed your cache is not refreshing the file. Try refreshing it (Ctrl + F5) first. Pete

And this is only with the J41? Definitely sounds like it intercepts these things and overrules my writes to SimConnect, though I suppose it could have a built in delay for "realism". Try 100 or even 500mSecs, just to check. Could you use the FSUIPC logging tab, please? On the right-hand side put 088C as an offset, type S16, then check "Normal Log" below. Reproduce this, then show me the resulting FSUIPC.4 Log file (or a relevant extract). Thanks. Pete

Please download the new 4.728 installer again. I found a bug which should explain your problem. Note that it now installs 4.728b, because that's my latest. Regards Pete

Okay, fixed it I think. Somehow the uploaded version was my test version, with a deliberate fail on the first test to check the other path! Grr! Stupid! Anyway, in retesting i did find another problem which would cause a crash on WinXP but not Vista or Win7. Please download the updated installer, same place, same name, but now it installs 4.728b because that's where I'm up to! Regards Pete

Not necessarily. The write instigates a write to SimConnect, which updates the throttle and sends the new value back to FSUIPC. It could happen fast enough for Lua not to notice the difference, but it isn't guaranteed. Really? That's strange. You could do that, but for safety check if it changed by the next loop. The FS one may still change in any case -- maybe the J41 simply ignores the FS one? But then how can it work to detect reverse? Hmmm. If you use throttle increment you'd need to adjust the time of the loop to match. my 32 at 50 mSecs would need to be 256 (small incr) at 400 mSecs if you wanted the same slow speed. Pete

That's because 4.728a did not include that function. Weird. I'm cross-checking now ... ... Oops, yes, you're right! It's this new Forum software. I'll never get used to it! You have to edit both the visible text and the link text AND click a "confirm" button, not just press return, or it reverts! I'll fix the link in the original post. Please try again. Apologies. Pete

Thank you. I'm a bit bewildered now, because the part that does this: has not been changed -- at least not intentionally. The new code was to try the more likely folders when the Windows call to get that path failed! I'll check it all again, here. Regards Pete

But that part only fails if the request to Windows to supply the correct path fails. Fine, but the Installer cannot guess this, and if the earlier request to Windows to obtain the correct user AppPath fails, I have no other choice but to assume English/American, for i have no way of knowing what version is installed after such a failure. Please, show me the whole of this Install Log, then try the original 4.70 Install and show me that log. I cannot see how this one can fail if the earlier one succeeds. It makes no sense. I only made the latter change to deal with the case that the original method, asking windows for the correct path, fails, as it has in the partial log you showed me. In case you no longer have such an earlier installer, please get it via this link: http://fsuipc.simflight.com/beta/Install_FSUIPC470c.zip Regards Pete

Are you using Saitek drivers or default Windows ones? If the latter then the fault must be in the hardware or its firmware, and the values seen in FSUIPC will reflect the true ones from the device. Otherwise you'd need to use a Lua plug-in to read the HID stuff directly, or maybe a USB monitor program -- but in the latter case you'd need to know how to decode the stuff coming in. But this spike comes from a non-moving lever? Presumably something else on the same unit is being moved? I can't imagine something generating spikes by itself when nothing's happening to it. It would be possible to write a Lua plug-in to check the calibrated inputs and change them to eliminate these oddities, like Fly-by-Wire type interjection. But it isn't totally straight forward. It would involve reading and writing FSUIPC offsets. Regards Pete

But that is an assignment in FSUIPC's "axis assignments"! How can it operate the ranges if it doesn't know the joystick and axis to check? Well it isn't essential if you already have it assigned as you say, but dual assignments in both FS and FSUIPC aren't a good idea, even if to different purposes. Both will be scanning independently -- a waste of time and resources. Regards Pete

FSUIPC is NOT scanning the axis if it isn't assigned in FSUIPC! Calibration is on the FS control, NOT on the hardware axis! That's why it works with FS assignments as well as FSUIPC assignments. It doesn't know about the hardware and doesn't care. If you aren't assigning in FSUIPC how did you hope to apply your conditional button to a range? ======================================================= Download this update: http://fsuipc.simflight.com/beta/FSUIPC4728b.zip Then edit this little Lua program as described below and place it in the FSX modules folder as, say, J41Throttle.lua. Edit the FSUIPC4.INI file and add a new section: [Auto.<name of aircraft>] 1=Lua J41throttle where <name of aircraft> is either the full title, or, better, if you have "ShortAircraftnameOk=substring" set then just J41 (assuming that's part of the name). That will make it run automatically when you load that aircraft. -- Lua program to manipulate throttle in calibrated idle dead zone joy = 1 axis = "S" zonelo = -14000 zonehi = -12000 bestincr = 32 interval = 50 throttle = 0x088c --0x088C is for Throttle 1. For 2 use 0x0924 function pollaxis() val = ipc.axis(joy, axis) if (val &gt; -zonelo) and (val &lt; -zonehi) then thr = ipc.readSW(throttle) if thr &lt; 0 then inc = bestincr if thr &gt; -inc then inc = -thr end ipc.writeSW(throttle, thr + inc) end end end event.timer(interval, "pollaxis") You'll need to change these bits: joy = 1 change to the joystick number or letter shown in the axis assignment for this axis axis = "S" change to the axis letter shown in the axis assignment for this axis zonelo = -14000 the low end of the range in which you want the throttle incrementing zonehi = -12000 the high end of the range in which you want the throttle incrementing bestincr = 32 the amount you want the throttle to increment each loop interval = 50 the frequency of checks and increments (50 = 20 per second) throttle = 0x088c 0x088C is for Throttle 1. For 2 use 0x0924 Note that rather than use the "small throttle inc" control as you proposed i've simply incremented the throttle directly. That gives you precise control over the fineness of the increments. I think the FS INCS are 512 and 256 respectively. Just adjust the time interval and/or the increment to get the speed you want. This example is only for throttle1. If you are using the generic single throttle it should still work for both engines because they should be in sync. If you are using two throttle levers then you either need to run two Luas with the throttle offset and axis changed to match, or, more efficiently, do both in the one loop by duplicating this part: val = ipc.axis(joy, axis) if (val &gt; -zonelo) and (val &lt; -zonehi) then thr = ipc.readSW(throttle) if thr &lt; 0 then inc = bestincr if thr &gt; -inc then inc = -thr end ipc.writeSW(throttle, thr + inc) end end with the appropriate changes to joy, axis and throttle. Have fun! Pete

No, assigned in FSUIPC whichever way you like. If it isn't being scanned even by FSUIPC you cannot really do anything with it -- including your proposed "conditional button on range". So i'm now confused. Are you not already assigning in FSUIPC? Do not assign anything both in FS and FSUIPC! Pete

Hmmm. So it isn't the smoothing you are talking about, but the turbulence, gusts and variance? They are not part of smoothing -- they are separate parameters in FS's weather. I have smoothing on all the time because it helps remove FSX's (and FS9's) terrible sudden wind shifts, which are errors not deliberate effects. I assume you do not want those re-introduced for any aircraft, whether PMDG or not? Well, I can put something on my list to look at , but please clarify first: exactly what menu items ARE you disabling or enabling? I think the subject is a bit muddled here. Regards Pete

A new Lua function: value = ipc.axis(joystick, axis) which, like the button facilities operate only if the joystick is one being scanned by FSUIPC (i.e. the axis is assigned). The joystick can be a number or a letter (if joyletters are in use), and the axis is one of X Y Z R U V (plus S T on FSUIPC4). I've implemented this already, it was so easy. I will post a link for you to download the update, and an example Lua for your problem in a short while. I think turboprop levers have fairly strong detents. Regards Pete

Correct. You should NOT assign in FS and in FSUIPC, only one or the other. Otherwise they will conflict. Just do so. In FSUIPC which allows up to 4 assignments for each axis and any number of axes assigned to the same control. But I very strongly advise against doing that. It is pointless and will simply destroy your ability to control rudder or rudder trim correctly. I don't understand why you'd even consider it. You'd have to use one or the other when flying, which just doesn't make any sense. But then you have no rudder trim and cannot fly correctly with the rudder because your trim control will override it UNLESS you keep it centred, in which case it is a waste of a control. Why not use the rudder trim as you do the elevator trim -- by feedback? You don't need indicators for trims, they are a superfluous luxury. Regards Pete

Ah, but when you have problems the first thing you should do is come here, to the Download Links subforum, and see if there is a later version. Things get fixed and added in interim updates all the time -- 27 since the last Schiratti site update. The reason is that it takes much longer for me to overhaul and update the documentation for a full release there than it does to provide a quick updated version here. Also I am not in control of the Schiratti site -- it isn't mine -- so i can't change things there easily or quickly. You cannot. The calibration is on the resulting FS control, not on your hardware. The only purpose of assigning two axes to the same control is for two pilots. One will override the other, so you only use one at a time -- the pilot flying. For axes assigned direct to FSUIPC calibration FSUIPC will arbitrate between the two inputs, giving the one with the biggest deflection the control. Not really. Rudder trim is not the same as rudder, especially in FSX. I have just checked. The rudder and aileron trims are working perfectly, with FSUIPC calibration. You can't see the trim tab operating on the default 737, but load up the Baron and look from the rear. It does model the trim tab moving -- you can see it quite clearly. Also, with the Baron, bring up the main panel and see the aileron and rudder trim dials on the right. Those will move when you operate the trim. Does your lower EICAS show trim positions? They normally only show the main controls plus the speed brakes/spoilers. There's really little reason to know the exact trim position, only that it is centred for normal flight -- check that on your control knob or lever before takeoff. When a trim needs adjustment in flight you adjust it using feedback on the feel of the controls. If you constantly need pressure on the rudder you use the trim to alleviate it -- exactly as you do with elevator trim. Check your controls with the Baron. You can see it quite clearly on screen operating correctly. If you still don't see it, in case it is a change in FSUIPC since your version, download and install 4.728 from the Download Links subforum. Regards Pete

From here (Download Links), or over on the Schiratti site? If the latter it'll be 4.703 I think. If here I'm not sure. 4.72x something. I'll check with 4.728 in any case, as that is the current interim release. Well on the real aircraft is moves a little bit, the "tab", which affects how the rudder then moves. You wouldn't notice that. But I suspect many FS aircraft just implement it as an off-centre rudder. So ... it depends how sophisticated the modelling is on the aircraft you are looking at. Yes, it is possible in FSUIPC to assign multiple hardware inputs to the same FS control, and vice versa. However, if you do what you suggest then one will override the other each time you use it. You won't get any effective trim operating on the rudder, because the pedal value will simply override that -- and vice versa. Please let me check things out and get back to you. Pete