John Dowson

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

Sorry, but I have no details on the SDK for the PMDG 737-800, and the SDK for the 737-700 has not even been published yet. I cannot look into the PMDG specific offsets until PMDG have published the SDK details. Try asking on the PMDG support forum. John

It, then that indicates that something in your TBM profile is causing this issue. I have just looked at your ini again and it is a bit of a mess....you have this a the top, that is not part of any section: That needs to be removed. This is the [JoyNames] section that is used, which indicates missing devices: You still have many assignments to those missing devices, which presumably were previously your Homeycomb Alpha and Bravo. I have tried to correct these issues for you in the attached ini, so could you please try this: FSUIPC7.ini Note that there are still some axis duplications that can cause issues, so please review these: 1. Throttle an PropPitch axes assigned twice in Axes.TBM930 : 2, Throttle1 axis assigned twice in [Axes.FBW 320 NEO]: 3. Throttle2 assigned twice in [Axes.CJ4]: 4. Rudder assigned twice in [Axes.Drone]: So, download that and and review and correct those axes assignments mentioned above, if needed, and then try the updated ini. John

Btw, maybe you just need to use the trim controls rather than the primary surface controls?

The PMDG data is just supplied as received from the aircraft, and I only have the information supplied in the SDK header file. You should check that file for any further information, otherwise I suggest you redirect your question to the PMDG support forums, as it is they that supply this data. Sorry I canny be of any further assistance with this. John

No need to do this.... First, your ini shows that you have two missing controllers: There are no GUIDs associated with these, but you still have quite a few assignments those controllers - I suggest you clean-up your inii by removing them. Restore the full ini and remove the TBM from its profile, i.e. change to and see if you get the same issue. Are you using a VRInsight device?

First, you posted in the FAQ sub-forum where it explicitly states NOT for support requests. Please take care to post in the correct forum for your issue. I don't have the Fenix so it is difficult to advise, but first check to see if there are any controls logged when you do this in the VC - activate logging for Events, open the FSUIPC logging console window and flip the switch to see if anything is logged, and if so you can try assigning to that. If nothing is logged, you can try listing the available lvars to see if any of them look appropriate, and if so see if the value of the lvar changes when you flip the switch. If so, you can try manually changing the lvar value to see if that has the same effect, and if so then you can assign to use that lvar either by adding to an FSUIPC offset, using a macro or defining a preset. John

You should really have tried with the trial license first to see if FSUIPC7 is suitable for your needs.... There are various things you can try to achieve this. The first, an easiest, would be to assign your key presses to the *_UP, *_DOWN, *_LEFT, *_RIGHT controls, but this would probably just duplicate the movement that you see when assigning in MSFS. For more refined control, you would need to write a lua script which would wait for your key press (using event.key) and in the handling function read the offset with the current value, most probably offset 0x0BBA for rudder, then adjust thus value with the required change and then write the value back to the same offset. I am a bit busy at the moment but when I get time I can look inot providing you with a lua script that does this for the rudder to get you started. What keys are you planning to use? Noe that if you have keys assigned in FSUIPC, you should remove any assignments to those keys in MSFS. John

It is no secret...just perform the operations in the VC with event logging activated, as you did before, and you should see the control and parameter logged, then use those. I cannot help you with this if you do not show me your FSUIPC7.log and FSUIPC7.ini files, the former with logging for Buttons & Keys as well as Events activated. You need the FSUIPC WASM module installed and the WAPI enabled, but that should already be the case, but your log files would tell me.... John

Yes, thats fine. If you are using the same controllers, you can also copy across your FSUIPC7.ini file, although the GUIDs will probably change and your ini will need manually updating to handle this. If you want to do this, you can show me your FSUIPC7.ini and FSUIPC7.log files from your new computer and I can take a look and adjust for you. By the way, you posted in the FAQ sub-forum where it explicitly states NOT for support requests. I have moved your post to the correct support forum, but please take care to post in the correct place, John

If you cannot change the offset that the IVAO client is using to read (0x0574) the altitude, you can spoof the offset to the value of this new offset (0x0590) using FSUIPC's spoofing facility at offset 0024.. To do this, you need an auto-running lua script. I have attached a similar spoofing lua script that some folks use for the FBW A320 parking break - you should be able to adapt this to your needs. You need to adapt to read the offset value (as opposed to the lvar value that he script currently uses) of the new offset, update the spoofOffset and adjust the type/size of the value being spoofed from 1UW to 1UD John A320ParkBrake.lua

This is very strange. I cannot understand how anything can stop/prevent mouse interaction in all other programs except MSFS Also FSUIPC7 does nothing with the mouse at all - except receive input (button presses/releases) from it, of course. As a final test, could you maybe rename your FSUIPC7.ini so that a new empty/default onw is created and try again to see if you get the same issue. If not, show me your (renamed) FSUIPC7.ini. John

Just tried the TBM930 and its working ok here (except that I can't seem to get the Throttle axis working....). I also trued with the TBM improvement mod - FSUIPC7 still functioning normally by that mod is broken (half of the aircraft has disappeared!). Try with Linda disabled (just temporarily rename your ipcReady.lua) - if FSUIPC7 functions normally then it will be an issue with Linda and should be reported to the Linda support forum. John

I am asking you NOT to create a new log - just don't use the 'New Log' menu entry, and just one log file will be created. The 'New Log' button closes the existing log file and starts a new one. As it says in the User guide: I have just release 7.3.10 - please update., This fixes an issue where presets assigned in the general Buttons and Axes sections were lost, as the preset file was loaded after these assignments, resulting in them not being found. John