John Dowson

You will have to do this manually. First remove all the [LuaFiles] entries that you are no longer using, and move the corresponding lua scripts out of your FSUIPC7 installation folder. Then, for each lua script remaining, you can renumber it and also change the assignment reference. So, for example, if you changed: 16=Elevator_Trim to 1=Elevator_Trim You would need to replace all occurrences of 'CL16:' with 'CL1:', i.e. change the lua reference numbers in the assignments to the new index number of the lua script. If you are re-organising your luas, you should also consider moving them all to a subdirectory and using the LuaPath ini parameter under the [LuaFiles] section. John

No idea. FSUIPC7 does not generate that file on its own - there must be something else running that is generating those files, probably a lua script. Check your assignments and lua files in your FSUIPC7.ini file.

Better to keep the terminate function - always a good idea to close com connections. Cheers, John

As the offset event handling function is only called when the offsets change, you don't need to store and compare to the old value, so this can be simplified to function sendComFrequencies(offset, value) if offset == 0x05C4 then com.write(dev, "COM1:" .. formatComFreq(value) .. "\n") else if offset == 0x05CC then com.write(dev, "COM1SB:" .. formatComFreq(value) .. "\n") end end end John

First, can you please attach your lua scripts rather than pasting the contents. It would make this thread far easier to read. As I said, you should update the sendComFrequencies fumction, e.g. function sendComFrequencies(offset, value) if offset == 0x05C4 then local strCom1 = formatComFreq(value) if strCom1 ~= lastCom1 then com.write(dev, "COM1:" .. strCom1 .. "\n") lastCom1 = strCom1 end else if offset == 0x05CC then local strCom1sb = formatComFreq(value) if strCom1sb ~= lastCom1sb then com.write(dev, "COM1SB:" .. strCom1sb .. "\n") lastCom1sb = strCom1sb end end end But if its not running, try debugging it. Check the FSUIPC log file for errors, add further ipc.log to determine what is happening, and you can also set Lua Plugin logging to trace what is happening in the lua script. John

No idea. Where/what is that image from? What has this got to do with FSUIPC? You really need to provide more information....

Change to function processInput(dev, datastring, length) -- Parsing the received string to set COM1 standby frequency ... and wait for the data event using event.com(dev, 256, "processInput") For the sendComFrequencies function, you can use event.Offset on offsets 0x05C4 and 0x5CC, and refactor the function to use the value passed in with a conditional on the offset (or use two functions, one for each offset. John

No, obviously not. They should work in most aircraft, but not in all - as I said, they don't work correctly with the FBW A320neo that implements its own pushback system via the flypad. No, As the offset document states, both offsets 0x31FC and 0x31F8 are write-only, you cannot read the current value of the speed/heading from these offsets. I don't think there is anything available that holds the tug speed, although the tug heading is available in the simvar PUSHBACK ANGLE (in Radians).

Like most add-on aircraft then! Many (most) add-on aircraft in MSFS2020/2024 seem to implement their behavior in non-standard ways and not use the standard events or simvars.

Ok, interesting. With P3Dv4, it is always advised to start with a default aircraft, and then switch, especially if using complex add-ons, but probably a good idea to do this when using any add-on aircraft. Thanks for the update.

Electronic Flight Bag, also called a flypad (looks like an ipad), usually attached to the door below the pilots window. Used by many complex add-ons (airliners and airbuses) to configure the aircraft (fuel, weights/passengers, even throttle set-up and calibration, brakes etc) and control ground services amongst other things.

Ok, thats interesting - and I also don't understand why this would fix your issue - maybe there was an option you set that disabled this for some reason. But glad its now fixed! Maybe try comparing the old prepar3d.cfg (if you saved it) to the new one, to see what has changed that could affect this.

Tested in the FBW A320. You need to switch the pushback system on in the EFB, and then you can only attach the tug via the offsets. Looks like you need to set the direction in the EFB and control from there really.

The idea with the logs was to compare the working v5 log with the non-working v6 log, to see if any additional controls were being sent in v5. But as now v5 isn't working, this is not possible. And I don't know this aircraft. For most aircraft that I know, you would manually switch fuel tanks. Is this not the case in this aircraft? There's not much else I can do at the moment, until I have re-installed P3Dv4, installed this aircraft and taken a look.

I would think its more likely a config issue with the aircraft. But strange it was previously working in v5. I noticed that there was something about install additional dlls in that post you refrenced - do you have the dsd_p3d_fuel_dump_x64.dll file installed?

Tested in the PMDG 737 and the offsets seem to work with that aircraft as well. Have you tried to use these offsets? If not, why not just try them. Any issues, let me know what the issue is and with which aircraft. John

Seems ok now. However, the log is useless as it doesn't show anything. Did you get your issue from the session where this log was generated? The log ends after < 5mins. I need to see a log from when you get the issue, and one from FSUIPC5 when you didn't, so I can see if there is any difference. Also, as I said, if you can let me know the steps to recreate this issue here, I can do that - after I have re-installed P3Dv4 and this aircraft.

Sorry, this is not correct - I was writing to offset 0x31F0 rather than 0x31F4. Writing to offset 0x31F4 seems to control pushback as documented, at least in the Cessna 172, and writing to offset 0x31F8 controls the heading. So it seems that these offsets are working, at lease in the Cessna 172.

I have not enabled direct axis assignment to input events due to this calibration issue. There are some issues adding calibration for input events directly to the axis assignment tab for various reasons, and it certainly won't be possible via the calibration panels for various reasons. What I could possible do, for an initial attempt, would be to allow assignment to input events, but these would then need to be calibrated using FSUIPC's axis scaling functions, only available by manually editing the ini file. I will put this on my todo list to look into. But for now, you need to use lua scripts for this, as you are doing. John

Sorry - these are't new and are already available.

That log is not available for some reason (I will delete the post shortly). Please also provide the log files for both FSUIPC5 (where it is working) and FSUIPC6 (where it isn't). Please also make sure that you have enabled logging for Events. As this is a freeware aircraft, I can also install and take a look. Could you let me know how to reproduce this problem - and quickly if possible. This may take me a while however as I recently suffered a severe crash and have had to re-install Windows. I haven't re-installed P3Dv4 yet - I will do this over the weekend. John

I don't think those offsets are working to control pushback. The state is reported correctly, but writing to the offsets does not trigger pushback. To trigger pushback, use the Toggle Pushback event. Not sure about controlling the heading or speed at the moment. There are 2 new sim event that I will add and test - Tug Heading and Tug Speed. I have tested Tug Heading here and that seems to control the direction once pushback is initiated. However, generally it seems pushback is controlled by the Ground services in MSFS. Also, more complex add-ons tend to use either the FlyPad/EFB or FMC to control pushback. They may also respond to the standard controls, but also these may not work for such aircraft. I will test/check this in a few complex aircraft - maybe the PMDG 737, FSLabs A321 and the FBW A321. I will add those 2 tug control events and look into this on more details, and maybe update those offsets to use these new control. But this will be after the next patch release of FSUIPC7. maybe next week... John

I have no idea what that is or where its from.

For your landing light buttons (135 and 136), use the PMDG_B777_Landing_Light_All_On and PMDG_B777_Landing_Light_All_Off presets I showed you above. Presume you know how to define your own presets - if not, check the Advanced User guide, but basically you just need to add those preset definitions above to a file called myevents.txt (create this if not present in your FSUIPC7 installation folder). For the buttons that control the runway + taxi lights, define your own preset by combining the preset code from the other presets, e.g. PMDG_B777_Runway_Turnoff_Taxi_Light_All_Off#(L:switch_121_a) if{ 12101 (>K:ROTOR_BRAKE) } (L:switch_119_a) if{ 11901 (>K:ROTOR_BRAKE) } (L:switch_120_a) if{ 12001 (>K:ROTOR_BRAKE) } PMDG_B777_Runway_Turnoff_Taxi_Light_All_On#(L:switch_121_a) ! if{ 12101 (>K:ROTOR_BRAKE) } (L:switch_119_a) ! if{ 11901 (>K:ROTOR_BRAKE) } (L:switch_120_a) ! if{ 12001 (>K:ROTOR_BRAKE) } PMDG_B777_Runway_Turnoff_Taxi_Light_All_Toggle#12101 (>K:ROTOR_BRAKE) 11901 (>K:ROTOR_BRAKE) 12001 (>K:ROTOR_BRAKE) Otherwise, you could try adding a short delay after sending each preset. I have done this for you in the attached with a 25ms delay. If it still has issues, try increasing that. John FSUIPC7.ini

I don't understand this - I am on the exact same version of Security intelligence and get no issues, and have no allowed threats. Not sure what I can do - I already reported this to MS yesterday as I did get this, but was later fixed. Maybe you could report as well: https://www.microsoft.com/en-us/wdsi/filesubmission?persona=HomeUser Otherwise, just restore the blocked file - you may need to temporarily allow the threat (presume its Program:Win32/Wacapew.C!ml).