John Dowson

No need to attach event files or licenses - they are installed by the installer. The two log files you attached are very different. The FSUIPC7.log file (from last time it was ran) shows that you manually started FSUIPC7 once MSFS was running and it started, connected and ran without issues. Were thinks working in this session? The FSUIPC7_prev.log file (from the previous time it ran) shows that FSUIPC7 was auto-started by MSFS but failed to connect. This looks to be because your MSFS is taking a long time to start and FSUIPC7 has not been tuned correctly. FSUIPC7 would usually auto-tune itself but it needs to actually connect to MSFS todo this. Your _prev.log file shows that auto-tuning was active but never completed as it never connected to MSFS. I am not sure why it never connected when it weas auto-started - it could be that you ran out of Simconnect connections. What other add-ons are you running? Please read the section 'Auto-tuning of initial start-up ini parameters' in the Advanced User guide, or read this FAQ entry: Also increase the number of simconnect connections allowed if you have not done this already. Do this by increasing the maxClients entry in your SimConnect.xml file to 128 (default is 64). So it just started on its own? Was there a sim update? Did your start-up times change drastically? Your DetectToConnectDelayAuto ini parameter is set to 50 (seconds), which seems reasonable, but your log from the auto-start shows that the last attempt to connect was after 220 seconds and for some strange reason this never succeeded or timed-out. What is the (approximate) time it takes from when you start MSFS to when FSUIPC7 is started (i.e. you see the FSUIPC7 splash-screen), and then how long does it take from FSUIPC7 start until MSFS arrives to the main menu state? Have this times increased/changed dramatically recently (i.e. when your issues started)? That may have been a coincidence. What version of FSUIPV were you using before updating to 7.5.1? If it was 7.5.0, and everything was working, then that parameter isn't needed, It does no harm to have it though. Sorry but this just doesn't make any sense. That ini parameter is never written or removed, only ever read. As other ini parameters can be added/removed, it may change position but will never be removed. John

No. It is up to you how you handle this. You can use profiles if the aircraft names are different. Otherwise you will need to separate installations of FSUIPC7, one for MSFS2020 and one for MSFS2024. Please see the section MSFS2020 / MSFS2024 Selection in the FSUIPC7 Installation and registration guide, John

Thanks. Note its probably easier just to assign directly to the Input Event itself. In the button assignments tab, select for Input Events and then select the 'FUEL_PUMP_MAIN_FWD_1' input event from the drop-down - note the actual Input Event names differ from the B-vars. This saves you having to figure out the B-var name, You can also see the available Input Events using Log->List Input Events, and you can see what input event is being used by setting Log->Input Events, opening the logging console (Log->Open Console) and operate the switch/button/dial in the VC and see what is logged. You can also add Input Events to offsets and trigger them by updating the offset. This is useful when you need to know the current value of an Input Event, or if you wan to increment/decrement an Input Event. I recently showed how to do this in the following post (just FYI): Cheers, John

Then please take care to post in the correct place. I have moved your original post, and merged your second post into the first. I have also updated the title - please get into the habit of giving a descriptive title for your issue, and always specify the a/c if its a question on a specific aircraft. This helps me and others. And isn't this the same issue you asked about last year? What has changed, and why not use that same topic if its the same issue (i.e. ProSim737 cut-off). You are creating a lot of additional work for me...! I already answered this question the last time you asked it... Normally you would use TOGGLE_FUEL_VALVE_ENG1/2, which you have assigned to buttons 17 & 16 of your JoyWarrior A8-16 controller. Do these not work? As I don't have the ProSim 737, I cannot advise on what to use. Try using FSUIPC's logging facilities and see what control is logged when you cut-off in the VC, and then try assigning to that. John

I presume you are using FSUIPC7 / MSFS, no? If so, please use the FSUIPC7 sub-forum. Otherwise, please state which FS you are using (this forum is for P3D and FSX). Didn't you already ask about this last year? See: Is this the same issue you reported there, and if so why not continue there? If the standard controls don't work, you should really ask in the ProSim forums for support. There don't seem to be any presets available for the ProSim 737, and as I don't have this aircraft I cannot really advise on this. You can use FSUIPCs logging facilities to see if any controls/lvars/input events are available for this, otherwise you can use the MSFS tools to see how the switch works - see the following article on how to do this: https://www.badcasserole.com/uncovering-input-events-using-the-msfs2024-model-behavior-dialog/ No - I have never used and cannot support MobiFlight. For help with MobiFlight, use the MobiFlight discord server. John

Please update to the latest version of FSUIPV6, v6.2.2 if you require support. Only the latest version of each product is supported. What would I need that? That is a file that FSUIPC6 generates once it acquires a connection to P3D. You are using an unregistered version of FSUIPC and so all your assignments are elsewhere (P3D I guess), not in FSUIPC. I cannot see how FSUIPC can have anything to do with your issue. Again that would indicate your issue has nothing to do with FSUIPC and I have no idea what could be causing this. Try re-installing the P3D client, and maybe also the aircraft/spitfire. Btw, how do you handle the differential braking in the spitfire using the rudder and single brake lever when assigned in P3D?

@Airbuspilot As well as posting your solution, could you let me know where the fuel pump switches are in the B747-8i - I would like to check a few thinks with 2 params for a control and check the input events, but I can't seem to find the fuel pump switches... Later: The fuel pump switches in the overhead seem to work using input events - just assign to the Input Event FUEL_PUMP_FWD_2 with a parameter of 1 for on and 0 for off. No need to use presets. In fact, there are a lot of Input Events for this aircraft....

Yes You could do that, but probably better if I delay the auto-start of the WebSocketServer until FSUIPC is connected to MSFS. Your update would also help if/when the WebSocketServer is manually started before MSFS is running, but I could also disable the manual start until MSFS is available. Great - thanks for the confirmation. Note that you should set a value of 14 if/when using MSFS2024! John

That is the assignment tab - you calibrate for detents in the calibration tab...

Ah, ok - that is interesting. Maybe the websocket server is expecting an FS version in offset 0x3308 when started, and that is now not populated until a simconnect connection is established. You could check if this is an issue by adding Init3308=13 to the [General] section of your FSUIPC7.ini file, which will initialise that offset on start-up. I could also delay the auto-start of the WebSocket server until a connection to MSFS is established, or until an aircraft is loaded? Maybe @Paul Henty could advise on this?

Yes, but the latest Asobo documentation on RPN is a vast improvement on what was previously available: https://docs.flightsimulator.com/flighting/html/Additional_Information/Reverse_Polish_Notation.htm No... Offsets are a memory area that hold data and/or trigger functionality. Most offsets are already defined to hold various bits of data (mainly simvars and lvars) and you can read this (e.g. for display purposes) or write to them to trigger an update or an action. There are many free/spare offsets as well, which can be used to add further data not yet available (e.g. simvars, lvars or input events) fir both reading and writing, Please see the included Offset Status document for details on what is held in offsets and what thehy allow (read, write or both). The example I gave above adds the value of the input event SF50_LIGHTING_INSTRUMENT_LIGHTS to an offset, so reading that offset will give you the current % of the instrument/panel lights, and if you write/update that offset this will update the input event and thus adjust the instrument lighting. The assignments increment/decrement that offset by a value of 5, so will inc/dec the lighting by 5% on each activation. This memory is pre-allocated and available for use. As I said, please see the FSUIPC7 Offset Status document,

Was it working with a previous version of FSUIPC7, and if so, which one? Note that there is one recent change that can affect some add-ons expecting a value in offset 0x3308 (FS version) at start-up, as this is no longer set until FSUIPC has connected to MSFS. If that is the issue, you can add Init3308=13 to the [General] section of your FSUIPC7.ini file. Is FSUIPC actually running? If so, you can attach your FSUIPC7.log file and I can take a look for any errors there, but I do not support CPFlight and you should contact their support. This is also continually getting reported - check out one of the other threads on CPFlight with MSFS.

You could always try debugging this yourself....if you look in the log, you will see: This is also incorrect: and should be either: oldNav1 = ipc.readUW(0x0350) or oldNav1 = ipc.readUW("0350") And this is wrong: I am pretty confident that there is no such lvar as NAV1_RADIO_SET_HZ. You should either write the new frequency to offset 0x0350 (so that is correct when in BCD) or use the (key) control NAV1_RADIO_SET_HZ (67251) via ipc.control. Your string.format is also incorrect.... Try something like: currentNav1 = ipc.readUW(0x0350) -- read the current NAV1 frequency currentNav1Nav1_string = "1" .. string.format("%04X", currentNav1Nav1) -- get frequenct as a string newNav1 = currentNav1Nav1_string + 100 -- lua has lazy types and will convert the string to a decimal and we increment by 1MHz newNav1Hz = newNav1*10000 -- convert to HZ ipc.control(67251, newNav1Hz) -- send to frequency to sim John

What aircraft are you using? Did you click the Set button? Can you please attach a screenshot of the flaps calibration panel.

Ok, glad its working but I don't understand from that what your issue was. By Ctrl do you mean repeats? If so, having that checked or not really depends on how your rotary buttons work, but you would usually not use repeats in rotary buttons. Sorry but I cannot help with this - I don't have any VRInsight devices and know nothing about SerialFP2. John

Ok, strange. What version of the defender anti-virus definitions are you using? Could you send me the Defender report please and I will check and report to Microsoft. Thanks, John

Can you please show me / attach your FSUIPC6.log and FSUIPC6.ini files, the former with logging for Buttons & Switches as well as Events activated, showing your issue. As you are new to the forum, you will have a very low upload limit, and the files may be too large to upload directly. If so, try compressing them, and if still too large, use one if the free file transfer services. John

Very strange - I (and probably almost everybody) use Windows Defender, I am up-to-date with the latest anti-virus definitions and do not see this. Download again form fsuipc.com and try again. If you get the same error, it will be a false positive, but I do not understand why I don't get that here. When this happens with Defender I report to Microsoft and they are usually pretty quick in rectifying this. John

Which is? Please can you post the solution for others that come across this post. It is quite annoying when people find a solution to an issue they have posted about but don't share the solution....

Then it should have been obvious that ipc.control does not (yet) support more than one parameter to the control. There is only one way: "1 7 (>K:2:FUELSYSTEM_PUMP_SET)" Did you try assigning to the Input Event? I will take a look later (or tomorrow), if/when I have time... John

That log shows the lua exited16ms after it was started. How are you starting/stopping this lua? The lua didn't actually run and was killed during start-up... Also, the lua scrip is incorrect. As I said, 0ffset 0x0350 is in BCD format. Do, as an example, if the NAV1 frequency is 123.45, then that offset holds 0x2345, so when you read that as a decimal you will get 9029. Add 100, you get 9129, which is 0x23A9, i.e. a frequency of 123.A9, which is incorrect. There are also other issues. For speed you should have this lua auto-started and wait for the parameter event to be triggered, but you need to get the current value and increment it within the callback/handling function. You are not doing this and are just sending the same value in each parameter event... If you want further help, please attach the lua script, and your FSUIPC4.log and FSUIPC4.ini files. Please turn off log lua separately, and turn on logging for lua plugins and Buttons & Switches before generating the log file. John

Why would you expect that to work? Please consult the documentation - ipc.control only accepts 1 parameter for the control: I will look into allowing two parameters for this, and once this is done the documentation will be updated to reflect this. Please don't guess on lua functions and parameters - consult the documentation. I provide that for a reason. The only way to yse a control with multiple parameters at the moment is using calculator code, and in lua you can use the ipc.execCalcCode function. Here's the MSFS documentation on this (from https://docs.flightsimulator.com/flighting/html/Programming_Tools/SimVars/Simulation_Variables.htm#SimVars😞 However, the log extract you posted shows the Input Event FUEL_PUMP_FWD_2 is used. Try assigning to that first instead. There may also be some B-vars (also called input events) available that can be used via calc. code (not all b-vars are available/mapped as Input Events). The following tutorial shows how to discover and use B-vars, although once discovered you would use to define calc. code for a preset (and don't have to use MobiFlight!): https://www.badcasserole.com/uncovering-input-events-using-the-msfs2024-model-behavior-dialog/ I may take a look at the 747 in MSFS2024 later to see how it works, but if you find anything before that then please update. John

The previous disableInDrone.lua only disabled for 10 seconds, and in the previous FSUIPC7.exe all main flight axes (including the helicopter specific ones) were disabled except for the collective. There is always some latency with these type of things (nothing to do with resources) and it won't be instantaneous - nothing is! However a second seems way to high and it should be a couple of hundred ms at the max. Appropriate logging would give more exact times, from FSUIPC's point-of-view (i.e. it only knows, for example, that drone mode is activated once it receives an update of the CAMERA STATE simvar which is going to take time getting from the FS to FSUIPC). As I said it does work when not calibrated. You can calibrate this in the prop pitch panel (on page 2 of the calibration screens, not the separate ones in page 5) but if you do this it stops working, As I said previously, you can post-calibrate (i.e. calibrate when assigned with 'Send to FS as normal axis') most axes for most aircraft, but this can cause issues with sine due to priority levels. If this is the case, you cannot calibrate in FSUIPC's calibration tabs and would have to use the scaling functionality (or lua) instead. John

It does work, but not if calibrated (in prop pitch calibration panel). Try the attached please: FSUIPC7.exe

Does the Axis Collective Set axis work for you with the Bell then? Tried it here and that axis doesn't work - I have to use the throttle axis. Can you try this attached version please: FSUIPC7.exe That disables most of the helicopter axes via offset 0x310A, but I am not sure about the collective as the calibration for this is mapped to prop pitch which isn't suppressed by that offset, and I cannot test here as that axis isn't working in the Bell for me anyway. Here is an updated lua script which keeps updating offset 0x310A until drone mode has exited: disableInDrone.lua John