joeherwig

Dear sim enthusiasts, I have a strange issue with the new MS/Asobo Flight simulators. It seems that hovering the mouse over undocked Panels is causing full freeze of all sim assigned controls. See https://forums.flightsimulator.com/t/all-controlls-disabled-while-mouse-hovers-over-undocked-gauges-panels/676639 Doeas anyone of you have a hint for me how to resolve that? Best regards, Joe

Just one addition... If i could just add the calculator code as free text directly to a btn press/release or axis range without the (my) events.txt in between, it would also be a huge improvement. I suppose this would be also ways easier to implement. Currently it seems that we're adding the presetName from (my)events.txt, writing it to the FSUIPC7.ini and on btn event it needs to be resolved again to send the calcCode from the txt. Having the option to directly paste in just the calccodes i retrieved for instance from the hubhop.mobiflight.com and keeping that in the FSUIPC7.ini might be an option for you as well. Joe

Got it. I'm sure you'll find a helpful way somehow that improves the performance and ease of selecting of the presets or showing them - if already assigned - in the context of which vendor/aircraft/system. Thanks for the again super fast response.

I like that idea especially if that tree selection would keep the selection until deliberately changed. Then the dropdown/combobox would just hold the stuff of the single selected aircraft I'm currently working on. Really a brilliant idea. 😎👏👍

Hi John, I see, you've already a couple of great ideas for improvements for that topic in one of the next releases. Really cool. Looking forward for it. Btw. There has been a new (beta) of the websocket server released by Paul Henty which resolves a couple of stability issues. Would be great, if you could pack it with the next FSUIPC7 update as well. All the best to you guys, Joe

Hi John, Just wanted to get back to this one... Over time even with a reduced myevents.txt with "just four aircraft plus the MSFS generics, i get nearly 3000 lines. Assigning presets is still not very comfortable as it is often hard to distinguish which one is the right. Nearly no chance without having the txt open in an editor aside. And even then it's hard as the dropdown always loads quite long until I'm able to key-in what i want. As the source of mobiflight seems to structure the stuff like //SimWorks Studios/Kodiak 100/Engine Kodiak_100_Ignition_Off#0 (>L:SWS_ENGINE_Switch_Ignition_1, Bool) Kodiak_100_Ignition_On#1 (>L:SWS_ENGINE_Switch_Ignition_1, Bool) Kodiak_100_Ignition_toggle#(L:SWS_ENGINE_Switch_Ignition_1, Bool) ! (>L:SWS_ENGINE_Switch_Ignition_1, Bool) KODIAK_100_IGNITION_SWITCH_OFF#1 (>K:TURBINE_IGNITION_SWITCH_SET1) KODIAK_100_IGNITION_SWITCH_ON#2 (>K:TURBINE_IGNITION_SWITCH_SET1) KODIAK_100_IGNITION_SWITCH_TOGGLE#1 2 (A:TURB ENG IGNITION SWITCH EX1:1, enum) 2 == ? (>K:TURBINE_IGNITION_SWITCH_SET1) //SimWorks Studios/Kodiak 100/Engines Starter_Switch_Hi#2 (>L:SWS_ENGINE_Switch_Starter_ThreeState_1, Enum) Starter_Switch_Off#1 (>L:SWS_ENGINE_Switch_Starter_ThreeState_1, Enum) Would it probably be an option to use a combination of a treeview and a combobox which lazy-loads the available functions just after entering the leaf in the tree view? It would definitely speed up the process of finding the right presets. Of course I'm also open for any other options that help to work with the brillant feature of having Presets. I'd also add them directly into the FSUIPC.ini by text editor if I could easier grab the colored stuff: especially the device (Joystick and Button) stuff behind the line index (does it have a purpose?) and the preset name. The rest seems to be parameter and the static identifier to use the preset. So if I could "copy" from the assignment-page somehow the Device+Button it would help at least a bit. Sorry for bothering again, Joe

Wilco. Thanks so far!

Ah... I suppose also about the timing stuff... Sending the following (looped through) commands fast one after another, {"command":"vars.calc","name":"calcCode_wifinode-overhead_1","code":"(A:FUELSYSTEM PUMP SWITCH:2, Enum) 0 == (L:A32NX_OVHD_INTLT_ANN) 0 == or 1 and (L:A32NX_ELEC_AC_ESS_SHED_BUS_IS_POWERED, Bool) and (L:A32NX_OVHD_INTLT_ANN, number) 2 == if{ 1 } els{ 1 } * (A:CIRCUIT GENERAL PANEL ON, Bool) * (>L:A20N_FUELSYSTEM_PUMP_SWITCH_OFF_ANNUN:2)","interval":200} {"command":"vars.calc","name":"calcCode_wifinode-overhead_2","code":"(A:FUELSYSTEM PUMP SWITCH:5, Enum) 0 == (L:A32NX_OVHD_INTLT_ANN) 0 == or 1 and (L:A32NX_ELEC_AC_ESS_SHED_BUS_IS_POWERED, Bool) and (L:A32NX_OVHD_INTLT_ANN, number) 2 == if{ 1 } els{ 1 } * (A:CIRCUIT GENERAL PANEL ON, Bool) * (>L:A20N_FUELSYSTEM_PUMP_SWITCH_OFF_ANNUN:5)","interval":200} {"command":"vars.calc","name":"calcCode_wifinode-overhead_3","code":"(A:FUELSYSTEM PUMP SWITCH:1, Enum) 0 == (L:A32NX_OVHD_INTLT_ANN) 0 == or 1 and (L:A32NX_ELEC_AC_ESS_SHED_BUS_IS_POWERED, Bool) and (L:A32NX_OVHD_INTLT_ANN, number) 2 == if{ 1 } els{ 1 } * (A:CIRCUIT GENERAL PANEL ON, Bool) * (>L:A20N_FUELSYSTEM_PUMP_SWITCH_OFF_ANNUN:1)","interval":200} {"command":"vars.calc","name":"calcCode_wifinode-overhead_4","code":"(A:FUELSYSTEM PUMP SWITCH:4, Enum) 0 == (L:A32NX_OVHD_INTLT_ANN) 0 == or 1 and (L:A32NX_ELEC_AC_ESS_SHED_BUS_IS_POWERED, Bool) and (L:A32NX_OVHD_INTLT_ANN, number) 2 == if{ 1 } els{ 1 } * (A:CIRCUIT GENERAL PANEL ON, Bool) * (>L:A20N_FUELSYSTEM_PUMP_SWITCH_OFF_ANNUN:4)","interval":200} {"command":"vars.calc","name":"calcCode_wifinode-overhead_5","code":"(A:FUELSYSTEM PUMP SWITCH:3, Enum) 0 == (L:A32NX_OVHD_INTLT_ANN) 0 == or 1 and (L:A32NX_ELEC_AC_ESS_SHED_BUS_IS_POWERED, Bool) and (L:A32NX_OVHD_INTLT_ANN, number) 2 == if{ 1 } els{ 1 } * (A:CIRCUIT GENERAL PANEL ON, Bool) * (>L:A20N_FUELSYSTEM_PUMP_SWITCH_OFF_ANNUN:3)","interval":200} {"command":"vars.calc","name":"calcCode_wifinode-overhead_6","code":"(A:FUELSYSTEM PUMP SWITCH:6, Enum) 0 == (L:A32NX_OVHD_INTLT_ANN) 0 == or 1 and (L:A32NX_ELEC_AC_ESS_SHED_BUS_IS_POWERED, Bool) and (L:A32NX_OVHD_INTLT_ANN, number) 2 == if{ 1 } els{ 1 } * (A:CIRCUIT GENERAL PANEL ON, Bool) * (>L:A20N_FUELSYSTEM_PUMP_SWITCH_OFF_ANNUN:6)","interval":200} I get { "command": "vars.calc", "name": "calcCode_wifinode-overhead_1", "success": true, "errorMessage": null, "errorCode": null } which is fine. But afterwards I receive a couple of times the following: { "command": "Unknown", "name": "Unknown", "success": false, "errorMessage": "Additional text encountered after finished reading JSON content: {. Path '', line 1, position 355.", "errorCode": "BadMessage" } Unfortunately without the "wrong" JSON content nor the command nor its name. So it's hard to check for me. Joe

Hm... Tried it a lot right now... Seems to be a timing issue as well when the vars.calc is sent. So if I wait inbetween it seems to work. function sleep(delay) { var start = new Date().getTime(); while (new Date().getTime() < start + delay); } let calc = { command: "vars.calc", name: "calc", code: "(A:FUELSYSTEM PUMP SWITCH:2, Enum) (>L:A20N_FUELSYSTEM_PUMP_SWITCH:2)", interval: 200 }; let calc2 = { command: "vars.calc", name: "calc2", code: "(A:FUELSYSTEM PUMP SWITCH:2, Enum) 0 == (L:A32NX_OVHD_INTLT_ANN) 0 == or 1 and (L:A32NX_ELEC_AC_ESS_SHED_BUS_IS_POWERED, Bool) and (L:A32NX_OVHD_INTLT_ANN, number) 2 == if{ 1 } els{ 1 } * (A:CIRCUIT GENERAL PANEL ON, Bool) * (>L:A20N_FUELSYSTEM_PUMP_SWITCH_OFF_ANNUN:2)", interval: 200 }; let declare = { command: "vars.declare", name: "myVarSet", changesOnly: false, vars: [ { name: "A20N_FUELSYSTEM_PUMP_SWITCH:2" }, { name: "A32NX_ELEC_AC_ESS_SHED_BUS_IS_POWERED"}, {name: "A20N_FUELSYSTEM_PUMP_SWITCH_OFF_ANNUN:2"}, {name: "A32NX_OVHD_INTLT_ANN"}, {name: "A20N_CIRCUIT_BREAKER_GENERAL_PANEL_ON"} ] } //let vars = {command: 'vars.list', name: 'list',notify: 'auto' } let read = { command: "vars.read", name: "myVarSet", changesOnly: false, interval:200 } let socket = new WebSocket("ws://myIP:2048/fsuipc", "fsuipc"); socket.onopen = function(e) { sleep(200); socket.send(JSON.stringify(calc)); sleep(2000); socket.send(JSON.stringify(calc2)); sleep(2000); socket.send(JSON.stringify(declare)); sleep(2000); socket.send(JSON.stringify(read)); }; socket.onmessage = function(event) { console.log(`[message] Data received from server: ${event.data}`); }; socket.onclose = function(event) { if (event.wasClean) { console.log(`[close] Connection closed cleanly, code=${event.code} reason=${event.reason}`); } else { console.log('[close] Connection died'); } }; socket.onerror = function(error) { console.log(`[error] ${error.message}`); }; Regarding the crashes... You can reproduce it, if you send in an CalcCode causing an error and you get the Message and then try to "Reload" from that tab, in my case it freezes the application reproduceable. To avoid that, I first stop the Websocket on the "Web Services" Tab, then do the "Reload" and afterwards re-enable the Web Socket serving and need to reconnect. Not sure, whether that makes sense... But at least it helped. As long as I only update the vars.calc with codes that do not cause throwing errors within the application UI I can confirm, that I can update hundreds of Times without Issues. For me it seems that sending a faulty CalcCode will be the "calcCode of death" ;-). So probably there's room for improvement on error-handling. What about checking whether a CalcCode is throwing the above error and then stopping with sending it again and just displaying something like the above just once? Probably the timing-issue can be fixed as well. The same code sometimes works and sometime doesn't... Waiting long enough solves it. It would be really helpfull, if there is a timing issue with the variable service on sim side, if the Websocket server could ensure the required delay before pushing the received commands to the sim. Hope that helps a bit. And keep up the great work! Really love working with it. The options it provides are really great! Joe

In Your Server, i tried to "reload" within the MSFS variables tab. I expected, it would do the WASM reload as from within the FSUIPC7 Add-ons | WASM | Reload Function. But in my case it crashes the Websocket Server.

Take the FBW A32nx. On the overhead the fuel tank pump 1 left Check the updating of the (off) LED annunciator which should only be on, if the bus is powered and the fuse is in and either the pump is off or the annunciator light testis active. According to hubhop. Mobiflight there is an working output calccodee but i tried simpler ones as well..

That's really great Paul. Thanks a lot! Probably it also helps to get this unhandled exeption error that has been thrown by the Websocket-Server: It's quite strange... If I setup for instance {command: "vars.calc", name: "calc", interval: 200, code: "(L:A32NX_ELEC_AC_ESS_SHED_BUS_IS_POWERED) 1 == (A:FUELSYSTEM PUMP SWITCH:2, Enum) 0 == + d (>L:A20N_FUELSYSTEM_PUMP_SWITCH_OFF_ANNUN:F2)"} it works for quite well a while before it stops working and doesn't update the LVar anymore. within the logfile I couldn't find anything valuable. If I set the LogLevel to DEBUG, I get quite a lot of crashes... So sorry for being not more helpful at the moment. Joe FSUIPC_WASM.log

@John Dowson, @Paul Henty On trying to debug it seems, that I struggle on "redefining" or "killing" my LVar definitions. Of course on setting the interval for the vars.calc using the Websocket Server I'm able to stop the updating. Setting and interval > 0 afterwards re-enables the auto updating as expected. But when I again set a changed vars.calc definition with the same name and an interval > 0 and a new "calc" definition, it seems the old one is still active and can't be "redefined." The behaviour remains even after stopping and closing the websocket server, reloading the FSUIPC WASM (via FSUIPC Menu) and restarting the Websocket server. So after I set {command: "vars.calc", name: "calc2", interval: 200, code: "(A:FUELSYSTEM PUMP SWITCH:2, Enum) 0 == d (>L:A20N_FUELSYSTEM_PUMP_SWITCH2)"} I'm getting and then redefining it using {command: "vars.calc", name: "calc2", interval: 200, code: "222 (>L:A20N_FUELSYSTEM_PUMP_SWITCH2)"} I'd expect to be the LVar set each 200ms to a value of 200 but I don't get that. It still toggles between 0 and 1 on setting the afore mentioned Simvar. So if I want to check the CalcCodes, I currently always need to at least stop the Websocket Server and then reload the WASM from within FSUIPC and restart the Server. 1. Is there an working and easier option to reset the WASM and FSUIPC websocket and let them forget all the before commands including my LVars without restarting the sim and tools completely? I'd be happy to get an hint how to proceed best. Joe

I'm not at the sim right now... But I noticed, that when I ran the calculator code via FSUIPC7 the change of the changed Lvar is not published to the subscribers. But if I read the LVar within FSUIPC7 it shows the correct value. Hope, that helps at least a bit. I'll check asap and get back to you.

@Paul Henty hm... No idea, what happened. The above script doesn't retrigger the calculator codes reliable as it seems. The first read is correct, but afterwards I don't get any further updates. For offsets the regular updates are fine. btw: Also got with Version V1.1.1 of FSUIPC WebSockets Server: