John Dowson

I have added the steering tiller axis to keys Numpad7 and Numpad9 in the attached script. These work slightly different from the other keys as there is no simvar for the steering tiller position - what this means is that when you press one of those key, the initial start value would be 0 (i.e. centered). Try it an see if that helps. Maybe I should add a call to set the steering tiller axis back to 0 (centered) on key release... Numpad5 will also centre the steering axis. I have also added a max limit on the delta value, currently set at 512. Just the one limit for all the axis at the moment - you can update if you want separate limits for each axis. I checked the centering (Numpad5) in the PMDG 737 and that seems to work as expected. I don't understand how that is not working for you in the Twin Otter - is it working in other aircraft? John nmpadFltCntrls.lua

Your log and ini files show that you have never had the FFB yoke assigned in FSUIPC, so your issue is not related to an MSFS or FSUIPC update - unless you had previously assigned in MSFS and calibrated in FSUIPC7 (which is no longer possible at the moment). You do have one controller assigned that is now missing: Your FFB yoke is not supported by FSUIPC, you will have to assign in the sim. Previously it was also possible to calibrate in FSUIPC7 when assigned in the sim, but since SU10 this is no longer possible, sorry. John

The problem is here: The lvar will be updated, but if you read the lvar directly after the update, you will be reading the old value as the new value will not yet have been received back from the WASM. The lvar gets updated in the FS, but lvar value updates are only sent back to FSUIPC7 6 times per second (by default, can be changed via a WASM ini parameter). So you would need to wait for a short period after updating an lvar before reading, i,e, ipc.execCalcCode(" 1 (>L:AE_FD, Bool) ") -- update Lvar ipc.sleep(200) -- wait for lvar update to be received fd_val = ipc.readLvar("L:AE_FD") Maybe, but better to use the provided function to create the lvar, and then the new lvar will automatically be pushed to any WASM/WAPI client. So, try: ipc.createLvar("AE_FD", 0) -- create Lvar while (ipc.getLvarId("AE_FD") == nil) do ipc.sleep(50) end -- wait for lvar to be received ipc.execCalcCode("1 (>L:AE_FD, Bool)") -- update Lvar ipc.sleep(200) -- wait for updated value to be received fd_val = ipc.readLvar("L:AE_FD") if fd_val == 1 then ipc.control(66288) -- toggle FD end John

That message signifies WideServer is active and waiting for connections (in FSUIPC7). If you start WideClient, it should connect one you have an aircraft loaded and ready-to-fly. If its not connecting, see the WideFS User guide section Configure your Network IT IS IMPORTANT FOR ALL USERS TO READ AT LEAST PART OF THIS! And also consult the Technical guide for further issues. If your server and client PCs are in the same workgroup and it still won't connect, try temporarily disabling all firewalls (i.e. client PC, server PC, router) to see if that helps, and if so the issue will be a firewall problem that you need to resolve. Otherwise, if all else fails, show me your log and ini files - FSUIPC7.log, FSUIPC7.ini, WideServer.log, WideClient.log and WideClient.ini. Do not post the files without reading the manuals and trying what is suggested there first. John

👍 Maybe you could add the Rotor Brake parameters you used so that if others come across this post they can find them rather than having to calculate them. I can also create a preset for these and submit to the MF HubHop resource for others to use. John

No - line continuation characters are not supported, sorry. John

And you could see the FFB yoke axis in FSUIPC previously? There really should be no change in controller/axes recognition as nothing has changed in this area - FSUIPC reads hardware devices directly and not via the sim. So I think something else must be going on. Can you show me/attach your FSUIPC7.ini and FSUIPC7.log files please. John

Since the release of SU10 / SDK 0.9.3.0, there are issues with masking events for calibration purposes. I am still investigating these issues and will file a bug report with Asobo, but for the time being I have had to remove the ability to calibrate an axis if not assigned with 'Send direct to FSUIPC Calibration'. Therefore if you want to use FSUIPC's calibration facilities, you must assign in this manner. Note you can still scale (and reverse) an axis assigned with 'Send to FS as normal axis', but such assigned axis will no longer be calibrated by FSUIPC. John

You only need that to restart the lua script if you change it, i.e. while tuning it. Once you have set it up to your liking, no need to restart it again so you can remove that assignment. That is what your 'End' key assignment is for - to restart the script when you change it... I don't understand this either - this is using the same controls that move the elevator/aileron/rudder, so if the other keys are working, so should this. Did you try in the C172 - it works in that aircraft here. I can't see how any if this relates to reversers - that only affects thrust/throttle. Ground steering for airliners is done in combination with the steering tiller axis, and the rudder only takes affect as the speed increases. You could maybe use the '7' and '9' keys to control the steering tiller. There is also a new nosewheel steering control, but unfortunately this is not yet available for 3rd party apps as it isn't exposed by the SDK. I don't have the PMDG 738m but I have the 737-700 - I can take a look at this, but it will be over the weekend. I can also check the Num5/centering in this aircraft. John

No...that will start the script when you press the End key, and then kill it and start it again when you release. Remove the control sent on release - you don't need that. And you only need this to restart the script to reload the changes made when tuning. If always using the script, it should be started automatically using the FSUIPC7.ini [Auto] section. That is strange as the other keys are working. Also no point keeping it pressed as the '5' key is only assigned to a press, and not a repeat press. Is anything centered (rudder, elevator or ailerons)? You can add trim centering as well if that is the issue. Maybe also check with a default aircraft, e.g. the C172. John

You need to provide more information - what aircraft? What switches? Can you show me your FSUIPC7.ini and FSUIPC7.log files, the latter generated with logging for Buttons & Keys and Events activated, load an aircraft, press one or two of your assigned switches (that are not working) and then exit FSUIPC7 before attaching the log file. John

I will provide a new license later this evening or tomorrow.

No - the calculator code must all be on one line, currently up to a maximum of 1024 bytes. It is not possible to change this for various reasons. John

Thanks for this, but it really belongs in the User Contributions sub-forum - I will move it for you. Regards, John

What is complicated? You just check the preset box in the button assignments panel and you wo;; see those presets and you can just assign to them to test....nothing complicated.... Maybe, but that was P3D....the PMDG 737/738 for MSFS is quite different. It uses the Rotor Brake control for a start, and not custom controls. But if you have the PMDG header file you can calculate the Rotor Brake parameter to use - see the following FAQ entry: I really have no idea - I do not own the 737-800 and have never seen any documentation for this aircraft. You can try the P3D custom controls converted to Rotor Brake parameters, as that FAQ entry shows, or use the standard method of determining what control/parameter to use: Logging. Activate logging for Events, open the logging console (Log->Open Console) and then flip the switch in the virtual cockpit with the mouse. See what is logged, the control/event name (most probably Rotor Brake) and the parameter, and then try assigning to that.

Ok, thanks for the update, but I really have no idea what can be causing this: The only time I have seen such issues is due to logging, i.e. so much is written to the log that it can prevent UI interaction (due to resource hogging). Other than that, I cannot see how this can occur. Except if there is a resource locking issue somewhere, but if that is the case I would expect this to occur and have been reported a lot more often (this is the first time I have heard of such issues!). Ok, makes sense. You can use the old ini to see what the original assignments were and duplicate/copy as needed. Would be interesting to see if this issue occurs again, and if so what assignment/ini file change provoked this.... John

Yes - there are presets available for the 737-700 - the ones for the 737-800 are the same, see https://hubhop.mobiflight.com/presets/. You should always use that site as the first point-of-call for such questions, as that is the THE community-driven resource for such things, led by MobiFlight. For the recirc fans I find these: which translate to: PMDG B737 Recirc Fan: 87201 (>K:ROTOR_BRAKE) PMDG_B737-7_PNEUMATIC_RECIRC_FAN_TOGGLE: 19601 (>K:ROTOR_BRAKE) PMDG_B737-7_PNEUMATIC_RECIRC_FAN_OFF: 100 (L:switch_196_73X, number) == if{ 19602 (>K:ROTOR_BRAKE) } PMDG_B737-7_PNEUMATIC_RECIRC_FAN_AUTO: 0 (L:switch_196_73X, number) == if{ 19601 (>K:ROTOR_BRAKE) } The first two are simple Rotor Brake assignments, and the second the same but have an initial test on an lvar value before setting. You can either just use the presets, or assign to the Rotor Brake control with the required parameter. For the lvar checks, you can add the lvars to an offset and also check those, or maybe those values are already available in the PMDG offset area, I don't know... But easier just to assign to the presets. John

First you need to find out what IVAO is using to determine the altitude. I suggest you try monitoring offsets 0x0574 (as S32) which is the Plane Altitude in meters, and also offset 0x0590 (also as S32) which is the Indicated Altitude Calibrated in feet. First, monitor those offsets using FSUIPCs offset monitoring facilities to see if the indicated altitude is the one that you need. If the latter is holding the correct value, then you can spoof offset 0x0574 to the value of offset 0x0590 converted to meters. I have attached a script that does this for you - to use it, save it to your FSUIPC7 installation folder and auto-start it by adding it to your [Auto] (or profile specific [Auto.xxx] section) as follows: If IVAO is not getting the altitude from that offset, maybe ask them how it is getting the altitude...I cannot support IVAO, sorry. Maybe also raise a bug/request with IVAO to ask them to use this calibrated value. John calibratedAltitude.lua

Please try the attached lua. Take a look at it and adjust the delta and delta increment (on repeat) values for each axis as you like. To use, add it to the [Auto[ section of your FSUIPC7.ini., e.g. I also suggest that to tune the script, assign a button or key to run the lua using the Lua nmpadFltCntrls - then pressing that assigned button/key will kill the running lua and restart it, so you can test your changes. One thing I noticed is that the axis values and simvar values for these controls seem to be negated/reversed, i.e. sending a positive axis value results in the relevant simvar taking a negative value and visa-versa., hence the script is changing the sign when reading the offset value. Let me know how it works and if you have any issues. John nmpadFltCntrls.lua P.S. Make sure you also delete the MSFS assignments to the numpad keys that you are using!

Your ini file is in the folder where you installed FSUIPC6. If you don't know where that is, use the 'Open Folder' button in FSUIPC's logging tab. That should only contain that file, and is the location prescribed by P3D for 3rd party add-on.xml files. You can install FSUIPC6 there, but I recommend that you don't do this as it can cause issues (due to windows protection on the Documents folder). John

Thanks for posting the solution. Note that there is also a preset available for this: PMDG_B737-7_HGS_HUD_UP_DOWN_SWITCH If you select the Preset check box, you can assign to this preset instead. You mentioned this preset in your second post! John

Maybe a small lag but shouldn't be that noticeable. Standard trim up/down controls can be quite slow, but you can assign to update the trim offsets and specify the increment required. I'll take a look at some point, probably at the weekend. Note also that you can also assign the keys directly to update the surface controls without using lua. The advantahe of using lua though would be that you could start with a small increment/decrement (delta) and then increase this delta value on key repeats (i.e. if you hold down the key). John

No they are not - they are only loaded om first aircraft load or on an aircraft change. When you start FSUIPC7 with MSFS running and an aircraft already loaded, lua autos will not be started. You would have to assign a button or key to start the lua script or scripts.. I will look into seeing if I can also start the lua [Auto] scripts in such situations. John

Check to see if there is an lvar that can be used. i.e. list them and see if any look applicable. If so, you can then add that lvar to a free user offset. https://forum.pmdg.com/ Cheers, John

Sorry, missed this one: The throttle in the TBM930 has always been problematic...I think the throttle is/was working, when assigned correctly, but the animation of the throttle in the VC was broken, i.e. it works but no the animation. I believe there was a dux if using the TBM improvement mod, possibly in conjunction with an XML file update. However, I am not sure if the current status, with or without the mod. In fact, I can't use the mod anymore as most of the aircraft isn't visible any more when using this! Here are the references to this issue when previously reported, although I am not sure how relevant they are since SU10, but worth reviewiing: John