Jump to content
The simFlight Network Forums

Leaderboard

Popular Content

Showing content with the highest reputation since 01/17/2025 in Posts

  1. There's no copyright claim on the original script, so I've uploaded my version of it here... Original file courtesy of Manolo Velez. You'll need to open this in the SIOC utility. Open SIOC.exe Choose "Edit Script" Files -> Import TXT (and select this attached file) Save As... (it'll compile as an .ssi file) Once compiled you may need to click the "Reload" button in the man SIOC utility window. All done! (hopefully) I'm a novice when it comes to this stuff, so I'm afraid I can offer no support. (See latest version below...)
    2 points
  2. Hi @jonas_llubi, @Abt. I share you frustration with this. In fact, I spent the last 6 hours vibe coding an AI-assisted solution for a SIOC script that correctly handles the COM1/2 active/standby frequencies for both 25kHz and 8.33kHz frequencies. I also changed the logic so that it truly does work as a slave device, in that if MSFS changes the frequency itself (or another app like BATC etc does) then the updated frequency will appear in the panel, and it won't keep overriding MSFS. Limitations: It's really nasty code, made with the assistance of AI. Works with MSFS2020, but not yet tested for MSFS 2024. The SIOC script also doesn't appear to work for the Nav radios. I based it off the originally provided SIOC scripts from opencockpits (I'm not sure if I can share it openly with you, but there is no copyright notice on the original), and that original script doesn't work for Nav radios in MSFS2020 either. For me, the COM 1/2 radios were much more important. I can revisit the NAV modes later perhaps. In testing, the display does sometimes go black, and the panel appears to fail. To fix it, you have to just press the "Reload" button in the SIOC utility. I changed the logic so that it always initialises with the active COM1/2 frequencies from MSFS so that it doesn't reset anything if you have to restart multiple times in the middle of a flight. I hope it works as a stop-gap until something better comes along though! Edit: The NAV VOR and ADF radios don't work, but the ILS mode frequency and course values do work! If you're interested, let me know and I can send the script to you privately. Linguini
    2 points
  3. Urgent Fix / Update Some Things slipped through, sorry for the Inconvenience! Version 0.8.9 - Fixed Lua Scripts not properly stopped/started (and therefor not working) - Fixed InputEvents.txt (detected B-Vars) not being created - Fixed Version-Check not notifying about new Dev-Builds
    2 points
  4. To add lvars to offsets, see the Advanced User guide, page 47. The Python wrapper around the FSUIPC was provided as a user contribution, and as such comes as-is and I cannot support this. In fact, it is quite old now and may need updating to be compatible with MSFS2020/MSFS2024, as otherwise it may not recognise the FS version. It may work as-is - I just don't know as I have not used this wrapper. I have attached the README.txt. John README.txt
    1 point
  5. Confirmed John. ScruffyDuck has retired and no one else is picking up the baton. Another reason to stay with v5.
    1 point
  6. Yes - its just a name (string) attached to the calculator code - you can use whatever is appropriate. You can also give a fixed value rather than using a parameter ($Param) if you prefer, and have several presets each setting a different fixed value. John
    1 point
  7. Hi Ray, That offset is just for the 'Fuel Tank Selector', and it is not a custom control. To set this, you would use the Offset Word Set control. To empty the tanks, try writing 0 to the tank level offsets (using Offset Dword Set😞 John
    1 point
  8. Well, its added now - but I may make this dependent on an ini parameter, as I said. John
    1 point
  9. You can limit the range of the axis by manually editing the FSUIPC calibration entry. If you assign and calibrate the spoilers, then open and find the calibration entry: It will look something like this: You can decrease the minimum value and increase the maximum value to fool FSUIPC into thinking the axis range is larger than it is, and then the calibrated down to the standard -16384 - +16384 range. So, for example, if you doubled the top range: Spoilers=-16383,32768/16 the axis would only move half way through its positive range as your axis input value of 16384 would be calibrated to 8192.Try different numbers to get the range you require (change this when the FSUIPC axis assignments or calibration window is open, and click to reload your settings once the changes have been saved). John
    1 point
  10. Yes, I should have mentioned that. Basically, if one program needs admin privileges, then for auto-start (either via FSUIPC or MSFS) then everything needs to be ran with elevated privileges. Previously this was possible, but windows OS is getting stricter and stricter on each release, for obvious reasons I think... I don't think there is anything I can do about this, but will look into it further when time permits. I think that for now you will just have to manually start anything that requires admin privileges. You could also ask/enquire on the support forums for any program that does this as to why this is necessary in the first place... If you find any solution, please update this thread! Regards, John
    1 point
  11. What aircraft are you using? Look for available presets - either using the Find Preset button in FSUIPC, or search on the MobiFlight HubHop site (https://hubhop.mobiflight.com/presets/). You can also try listing available lvars (Add-ons->WASM->List Lvars) to see if any look applicable and if so try them. You can also use logging: set logging for Events, open the logging console (Log->Open Console) and then open the doors using the virtual cockpit and see if anything is logged, and if so, you can use that. John
    1 point
  12. Yes - I saw that when I made the second script and corrected it! As reading the value of an lvar by name is quite time consuming (as it has to go through the list of available lvars) , the script cant also be more efficient: id = ipc.getLvarId("L:Lear_LDG_Weight") if id == nil then ipc.createLvar("L:Lear_LDG_Weight",10361) while (id == nil) do ipc.sleep(50) id = ipc.getLvarId("L:Lear_LDG_Weight") end end ipc.execCalcCode(" (A:TOTAL WEIGHT, pounds) (>L:Lear_LDG_Weight) ") -- get current total weight ipc.sleep(200) ldg_wt = ipc.readLvarById(id) ldg_wt = math.floor(ldg_wt + 0.5) Basically if you are accessing an lvar by name more than once, it is better to get the id of the lvar and use the id functions. John
    1 point
  13. Top tip. Also I never realised about the profile thing. If I got a new paint I'd have to point it to the appropriate profile. In the end I'd have l list as long as your arm of Comanches. 😂 Thanks for your time John. I expect I'll be back in the future with more 'insurmountable problems' 🙄
    1 point
  14. Ok, that can happen. Thats fine - whatever works for you. Just pointing out that for most things, the various FSUIPC logging facilities should be proficient enough, but you do have to 'connect the dots; as you say. Yes - you need to do it this way anyway if the position lvar only changes the position but not the actual function/lights.
    1 point
  15. Note that you can see available lvars by listing them (Add-ons=>WASM->List Lvars) - no need to use the MSFS behaviors dialog, except as a last resort (i.e. usually to discover b-vars or h-vars). No problem about the incorrect lvar name - these things happen...! Now you have the correct name, you should check if setting that directly works to control the switch. If so, the assignments can be simplified as you don't need the compound condition on the position of your switches, and you only need to send the one one command to change the lvar two positions instead of three (e.g. switch up, pause, switch up). Anyway, you should try and understand those assignments and try to assign yourself the next time you want to make a conditional assignment. I will help if you run into problems, but you should have enough info in this thread to make a start. Regards, John
    1 point
  16. Just took a quick look at the logs. You started to test BEFORE the lvars were available (5 seconds or so too early), so the first two button presses (26 and 29) had no effect. then the next few had no effect as the switches were out-of sync with the VC. The log does show some movement of the switch (or change of value of the lvar) - three switch-down commands were sent: 13672 [DEBUG]: Calculator code sent: 31 (>L:VC_Miscellaneous_trigger_VAL,number) 13735 [DEBUG]: Calculator code sent: 31 (>L:VC_Miscellaneous_trigger_VAL,number) 15485 [DEBUG]: Calculator code sent: 31 (>L:VC_Miscellaneous_trigger_VAL,number) Did you not see any movement of the switch at all? Also add logging of offset A002 (using Log->Offsets). Show me /attach another file with the lvar (L:VC_POSITION_LIGHT_SW) and offset logging activated, and also wait a bit before you start testing, and I will take a look at the new logs tomorrow.
    1 point
  17. I don't know - I don't have this aircraft. Have you tried it? Use the Add-ons->WASM->Execute Calculator Code menu option, and try sending each of the following: 30 (>L:VC_Miscellaneous_trigger_VAL, number) 31 (>L:VC_Miscellaneous_trigger_VAL, number) to see if those move the switch. They should work, as that lvar controls the dome switch (with parameters 38 and 39). Also try the following: 10 (>L:VC_POSITION_LIGHT_SW, number) 0 (>L:VC_POSITION_LIGHT_SW, number) 20 (>L:VC_POSITION_LIGHT_SW, number) to see if those move the switch. If they work, we can simplify the assignments. If you still have issues, please activate WAPI Debug level logging (Log -> WAPI -> Debug) and logging for Buttons & Keys, and show me / attach your FSUIPC7.ini file and FSUIPC7.log file, the latter showing you using the assigned buttons. And always exit FSUIPC before attaching files please. John
    1 point
  18. Yes - sorry, I forgot to add the conditional letter 'C and the conditional comes after the press 'P' letter'. Should be 7=BA002=10 CP(+M, 29)M,27,CPNav_Strobe_Switch_Down,0 -{Preset Control}- 8=BA002=10 CP(+M, 28)M,27,CPNav_Strobe_Switch_Up,0 -{Preset Control}-
    1 point
  19. Ok, then we have: Nav switch Down, Strobe Switch Down: VC_POSITION_LIGHT_SW = 20 (NAV lights steady, strobes OFF) Move nav switch up: VC_POSITION_LIGHT_SW = 10 (NAV and strobe lights OFF) Move strobe switch up: VC_POSITION_LIGHT_SW = 0 (NAV and strobe lights ON) Nav switch Down, Strobe Switch Up: VC_POSITION_LIGHT_SW = 0 (NAV and strobe lights ON) Move Nav switch up: VC_POSITION_LIGHT_SW = 10 (NAV and strobe lights OFF) Move strobe switch down: VC_POSITION_LIGHT_SW = 20 (NAV lights steady, strobes OFF) Nav switch Up, Strobe switch down: VC_POSITION_LIGHT_SW = 10 (NAV and strobe lights OFF) Move Nav switch down: VC_POSITION_LIGHT_SW = 20 (NAV lights steady, strobes OFF) Move strobe switch up: VC_POSITION_LIGHT_SW = 10 (NAV and strobe lights OFF) Nav switch up, strobe switch up: VC_POSITION_LIGHT_SW = 10 (NAV and strobe lights OFF) Move nav switch down: VC_POSITION_LIGHT_SW = 0 (NAV and strobe lights ON) Move strobe switch down: VC_POSITION_LIGHT_SW = 10 (NAV and strobe lights OFF) Re-arrange these by switch movement: Button 26 (nav switch up): set VC_POSITION_LIGHT_SW = 10 when VC_POSITION_LIGHT_SW = 20 set VC_POSITION_LIGHT_SW = 10 when VC_POSITION_LIGHT_SW = 0 Button 27 (nav switch down) set VC_POSITION_LIGHT_SW = 20 when VC_POSITION_LIGHT_SW = 10 & strobe switch down set VC_POSITION_LIGHT_SW = 0 when VC_POSITION_LIGHT_SW = 10 & & strobe switch up Button 28 (strobe switch up) set VC_POSITION_LIGHT_SW = 0 when VC_POSITION_LIGHT_SW = 20 set VC_POSITION_LIGHT_SW = 10 when VC_POSITION_LIGHT_SW = 10 (i.e. no change) Button 29 (strobe switch down): set VC_POSITION_LIGHT_SW = 20 when VC_POSITION_LIGHT_SW = 0 set VC_POSITION_LIGHT_SW = 10 when VC_POSITION_LIGHT_SW = 10 (i.e. no change) Note that button 27 is the only state change that needs a dependency on the state of another button as the VC_POSITION_LIGHT_SW value condition is the same. The next thing to determine if you can write to the lvar VC_POSITION_LIGHT_SW ti change the position? If so, this makes things easier, as you can then just write to the offset holding the lvar to change the position. But, as you said you need to use VC_Miscellaneous_trigger_VAL (with 30 for up and 31 for down) we will use that, So, define 4 presets (in your myEvents.txt file): //iFly/737-Max8/Lights Nav_Strobe_Switch_Up#30 (>L:VC_Miscellaneous_trigger_VAL,number) Nav_Strobe_Switch_Down#31 (>L:VC_Miscellaneous_trigger_VAL,number) Nav_Strobe_Switch_Up_Two#30 (>L:VC_Miscellaneous_trigger_VAL,number) 30 (>L:VC_Miscellaneous_trigger_VAL,number) Nav_Strobe_Switch_Down_Two#31 (>L:VC_Miscellaneous_trigger_VAL,number) 31 (>L:VC_Miscellaneous_trigger_VAL,number) I am not 100% sure about the _Up_Two and _Down_Two presets: we need to move the switch two positions for some assignments, but setting the same value to an lvar twice in the same calculator code string may not allow this. If not there are a few other things to try (see below). Now we can define our assignments: For Button 26, send switch-up when when VC_POSITION_LIGHT_SW = 20, and switch down when VC_POSITION_LIGHT_SW = 0 to send a switch up, using B as your Bravo device letter and starting the indices from 1 will give the following assignment entry: 1=PB,26,CPNav_Strobe_Switch_Up,0 -{Preset Control}- then add the offset condition on the value of VC_POSITION_LIGHT_SW held in offset 0xA002 1=BA002=20 PB,26,CPNav_Strobe_Switch_Up,0 -{Preset Control}- Next, we can duplicate that, change the index number, the preset and the offset condition for the switch down when VC_POSITION_LIGHT_SW = 0: 2=BA002=0 PB,26,CPNav_Strobe_Switch_Down,0 -{Preset Control}- Doing this for each button 27, we get: 3=BA002=10 PB,27,CPNav_Strobe_Switch_Down,0 -{Preset Control}- 4=BA002=10 PB,27,CPNav_Strobe_Switch_Up,0 -{Preset Control}- and then we need to add the additional condition on the strobe switch position (buttons 28 and 29): 3=BA002=10 CP(+B, 29)B,27,CPNav_Strobe_Switch_Down,0 -{Preset Control}- 4=BA002=10 CP(+B, 28)B,27,CPNav_Strobe_Switch_Up,0 -{Preset Control}- Doing this for all buttons, we end up with: 1=BA002=20 PB,26,CPNav_Strobe_Switch_Up,0 -{Preset Control} 2=BA002=0 PB,26,CPNav_Strobe_Switch_Down,0 -{Preset Control}- 3=BA002=10 CP(+B, 29)B,27,CPNav_Strobe_Switch_Down,0 -{Preset Control}- 4=BA002=10 CP(+B, 28)B,27,CPNav_Strobe_Switch_Up,0 -{Preset Control}- 5=BA002=20 PB,28,CPNav_Strobe_Switch_Up_Two,0 -{Preset Control} 6=BA002=0 PB,29,CPNav_Strobe_Switch_Down_Two,0 -{Preset Control}- So try that - just paste those entries into your profile buttons section, and change the joystick letter to the one you are using (also in the compound condition) and also make sure the index numbers are unique in your section. If the presets to move two positions don't work, you could try the following instead: 1=BA002=20 PB,26,CPNav_Strobe_Switch_Up,0 -{Preset Control} 2=BA002=0 PB,26,CPNav_Strobe_Switch_Down,0 -{Preset Control}- 3=BA002=10 CP(+B, 29)B,27,CPNav_Strobe_Switch_Down,0 -{Preset Control}- 4=BA002=10 CP(+B, 28)B,27,CPNav_Strobe_Switch_Up,0 -{Preset Control}- 5=BA002=20 PB,28,CPNav_Strobe_Switch_Up,0 -{Preset Control} 6=BA002=20 PB,28,C1152,5 -{pause (ms)}- 7=BA002=20 PB,28,CPNav_Strobe_Switch_Up,0 -{Preset Control} 8=BA002=0 PB,29,CPNav_Strobe_Switch_Down,0 -{Preset Control}- 9=BA002=0 PB,29,C1152,5 -{pause (ms)}- 10=BA002=0 PB,29,CPNav_Strobe_Switch_Down,0 -{Preset Control}- Here we are sending he preset twice, with a short pause between each one. The trick here is to get the pause large enough so that both presets are executed, but small enough so that the update of the lvar has not been received yet to update the value in the offset condition on 0xA002. I have used 5ms - you can use logging to determine if this needs to be increased or decreased (probably increased if anything - try 10ms next and so on). Give those a try and let me know if either works as expected. John
    1 point
  20. Yes, I understood. Just trying to point out that when using two switches, one for each light, its never going to work in the same way as one 3-position switch to control the lights. The honeycomb light switches are designed for on/off of each of the lights, so however you implement this is going to be a fudge, but maybe ne that you can live with. And no need for the pictures either... Yes, that's fine. No, but you can assign to a preset and then make that assignment conditional on an offset value. Or just also add the lvar VC_Miscellaneous_trigger_VAL to an offset, and just use assignments with offset conditions, as I advised. If you can just tell me what you want the switch position to be in the UP/UP state I can show you how to do this - its easier to do it this way than in lua.
    1 point
  21. Hi Peter, Nice simple solution. I have had P3D controls disabled for years and assign everything through FSUIPC. Rock solid! 👍
    1 point
  22. Better to keep the terminate function - always a good idea to close com connections. Cheers, John
    1 point
  23. 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.
    1 point
  24. Thanks John. Greets..Hope you are well..
    1 point
  25. This was released in version 7.5.2, on 14th February. From the FSUIPC7 Offset status document: Looks like I forgot to add this to the changes.txt and history document - sorry about that, I will correct this. John
    1 point
  26. No problem - permission granted (well, not even needed really!). You could also add it to the User Contribution section if you like, and/or I could include it in the FSUIPC SDK download. Let me know. Regards, John
    1 point
  27. All I know is everything works in 15.10.1 until I load FSUIPC then CTD without hesitation. I don't know if it crashes by itself or through Simconnect.
    1 point
  28. Thanks a million John, I wired it up and works perfectly!
    1 point
  29. Thanks very much John, as always, just done what you explained, works perfect.
    1 point
  30. I am not sure how to embed a pause/wait in a calculator code string and that sleep syntax is not familiar to me. There are a couple of other ways you could do this: 1. Use lua instead, e.g. ipc.execCalcCode("23 (>L:VC_Miscellaneous_trigger_VAL, number)") ipc.sleep(100) ipc.execCalcCode("25 (>L:VC_Miscellaneous_trigger_VAL, number)") 2.Define two separate presets: IFLY_RWY_ONa#23 (>L:VC_Miscellaneous_trigger_VAL, number) IFLY_RWY_ONb#25 (>L:VC_Miscellaneous_trigger_VAL, number) and then create a macro to call the first one, then pause (using the FSUIPC-added pause control), then call the second preset. You can also overload the assignments instead of using a macro if you prefer.
    1 point
  31. Thanks, John, that has worked perfectly. I don't know why my system thought I had the Steam version installed, I have never purchased or installed MSFS 2024 on Steam, only from the Xbox store. Anyway, followed your steps, and FSUIPC is now starting automatically with the sim. Thanks so much for taking the time to resolve this for me, and thanks again for a great product.
    1 point
  32. First, to understand profiles you should read the section User profiles for all control settings, on page 22 of the FSUIPC7 User manual/guide. Profiles are enabled automatically. Having profiles in separate files is generally only used if you have many profiles and these are quite large, as it separates them into different files. You do not have to use this feature when using profiles if you don't want to, but if you have already switched to profiles-in-separate files then thats ok. The changes you made will only be saved in the profile (and in the profile-specific file) if you clicked the profile-specific checkbox (in the assignments panel) when adding the assignment, and when you have added the currently loaded aircraft to a profile (or have created a new profile for the aircraft). Check your FSUIPC7.ini - they will have been added there to the general sections if you did not specify profile-specific. Note that when you create a new profile for an aircraft, or add an aircraft to an existing profile, it is a good idea to shorten the aircraft name (listed under the [Profile.xxx] section of your FSUIPC7.ini file) to a substring that matches all variants of that aircraft. This will prevent issues with the profile not being loaded when you use a new variant. Alternatively, you can set the UseAirLocForProfiles in parameter to Yes to perform matching on the aircraft folder name instead, but if you want to use this then do it now before adding the aircraft name/title to the profile. Again, see that section in the User manual for more details. John
    1 point
  33. Hi, Try this function in LUA to toggle the fuel switch: function SetFuelPump(joynum, button, downup) -- toggle FuelPump if ipc.readLvar("L:cap10") == 0 then ipc.writeLvar("L:cap10",1) ipc.writeUB( 0x3104 ,1) else ipc.writeLvar("L:cap10",0) ipc.writeUB( 0x3104 ,0) end end -- track every change of the FuelPump toggle switch event.button( <your joystick letter> , <your joystick button> , 1 , "SetFuelPump" ) I use P3Dv5 - but I assume, this won't have changed from FSX. Rgds Reinhard
    1 point
  34. Any issue with button assignments, I need to see both your FSUIPC7.ini and FSUIPC7.log files, the latter with logging for Buttons & Keys activated, and if assigned to presets also WAPI->Debug level logging. Note that it could be that you are using an aircraft with a different name that is not covered by your profile. You should shorten your aircraft names in your profile sections and use substring matching. i.e. change: to You should do the same for all the aircraft names in your profiles. i.e. use the shortest substring)s) of the name that matches all the aircraft you want to capture in that profile and no others. You should get into the habit of editing the aircraft name in a profile whenever you add an aircraft to a profile or create a new profile. John
    1 point
  35. I tested 7.5.4a as provided above. Confirm that the enter key work in both 2020 and 2024
    1 point
  36. Dear all - the attached lua scripts work for me, maybe you will also find them useful. Thanks a lot to John for all his help. Single Radios.zip
    1 point
  37. Yes, but it is a different sim, and I have no idea what the issue currently is - previously it was due to the WASM not starting, which looks to be due to the strange permissions issues you are having. Are these now solved after a re-install? Did you try renaming the Community folder as I suggested? I really cannot help you if you do not tell me what you are trying and at least answer my questions - I have no idea what you have done and what the current state is... Is the WASM now running? Is an FSUIPC_WASM.log file now generated? Do you still have the same permissions issues? I am still waiting for this information and to see a log file if available....if the WASM isn't running, then you need to determine why, and if it the permissions are still an issue.
    1 point
  38. Hi @John Dowson, thanks for the help, I used the LVAR command and it worked.
    1 point
  39. Yes, thanks Paul.
    1 point
  40. The ! symbol is the logical not operator so !TRUE is FALSE, and !FALSE is TRUE (or, in RPN, TRUE! is FALSE, and FALSE! is TRUE. So the expression (L:someLvar, bool) ! (>L:someLvar, bool) flips/toggles the value of the lvar, i.e. changes it from TRUE to FALSE or from FALSE to TRUE. John Also explained here: https://docs.flightsimulator.com/flighting/html/Additional_Information/Reverse_Polish_Notation.htm
    1 point
  41. Cheers Paul! That is a very welcome update!
    1 point
  42. When FSUIPC7 is auto-started, 'Exit with FS' is always set and the options menu entry for this is removed.
    1 point
  43. Version 3.3.16 of FSUIPCClientDLL is now on NuGet. When using FSUIPC7: Connection will now fail with FSUIPCError.FSUIPC_FS_NOT_READY if the flight sim (MSFS2020 or MSFS2024) is not running or is not ready Version 1.1.4 of the WebSocketServer is now on the website: http://fsuipcwebsockets.paulhenty.com Fixed problem of not detecting the Flight Sim version when using FSUIPC7 and the sim is still starting up. Paul
    1 point
  44. This issue is generally due to the axis of your device being defined as a digital on/off axis in the windows registry. See the following FAQ entry: That is specifically for Saitek devices but applies to all - just use the correct VID and PID numbers for your device,
    1 point
  45. Hi John, As I mentioned, I wouldn’t call myself a "coder," so I often rely on ChatGPT for help. But when I get stuck, I turn to the forum for deeper insights. Thanks to your hints and guidance, I now have a working script again. I really appreciate your help—thank you so much! Best regards, Isak Here is the working lua script: dev = com.open("COM6", 115200, 0) -- Open COM port with baud rate 115200 ipc.display("Lua script is running...", 3) function processInput() local datastring, length = com.read(dev, 256) if length then ipc.log("Raw data received: '" .. datastring .. "' [" .. length .. "]") if datastring:match("^NAV1SB") then local frequencyStr = datastring:match("NAV1SB%s*(%d+%.%d+)") -- Extracts the frequency if frequencyStr then ipc.log("Extracted frequency: " .. frequencyStr) -- Debug log local bcdValue = convertToBCD(frequencyStr) ipc.log("BCD Converted: " .. string.format("0x%X", bcdValue)) -- Debug log ipc.writeUD(0x311E, bcdValue) -- Send to FSUIPC ipc.display("NAV1 standby set: " .. frequencyStr, 3) ipc.log("NAV1 standby frequency set to BCD: " .. string.format("0x%X", bcdValue)) else ipc.log("Error: Failed to extract frequency!") end end end end -- Convert frequency to BCD (e.g., "113.45" → 0x1345) function convertToBCD(freq) local cleanFreq = freq:gsub("%.", "") -- Remove decimal (e.g., "109.2" → "0920") local decimalNumber = tonumber(cleanFreq) -- Convert to number if not decimalNumber then return 0 end -- Return 0 if conversion fails local bcd = 0 local shift = 0 -- Convert each decimal digit to BCD format while decimalNumber > 0 do local digit = decimalNumber % 10 bcd = bcd + (digit * (16 ^ shift)) -- Use base 16 shift instead of bitwise left shift decimalNumber = math.floor(decimalNumber / 10) shift = shift + 1 end return bcd end while true do processInput() ipc.sleep(100) end
    1 point
  46. okay, found the issue, @Paul Henty program did not have time to start the service 🙂 wil clean up my code and fix the code to read it here
    1 point
  47. Hello again, that works very well Thank you very much !! Can be closed. Matthias
    1 point
  48. I've tried this here using the Key_Press_and_Hold control. It may not do what you're expecting. It doesn't repeat the key until you call the release command. So you don't get the action repeating. You can try it for yourself and see if it does what you're expecting... Just paste this into your code and call. sendKeyHoldToFS - holds the key for the specified HoldTime (in milliseconds) then releases it. sendKeyDownToFS - presses the key down but does not release it. snedKeyUpToFS - releases the key. private void sendKeyHoldToFS(Keys Key, SendModifierKeys Modifiers, int HoldTime) { // First make sure FSX has the focus SendControlToFS(FSUIPCControl.Key_focus_restore, 0); // Wait for focus change Thread.Sleep(150); // Send the key down SendControlToFS(FSUIPCControl.Key_Press_and_Hold, (int)Key + ((int)Modifiers * 256)); // Wait Thread.Sleep(HoldTime); // send the key up SendControlToFS(FSUIPCControl.Key_Release, (int)Key + ((int)Modifiers * 256)); } private void sendKeyDownToFS(Keys Key, SendModifierKeys Modifiers, int HoldTime) { // First make sure FSX has the focus SendControlToFS(FSUIPCControl.Key_focus_restore, 0); // Wait for focus change Thread.Sleep(150); // Send the key down SendControlToFS(FSUIPCControl.Key_Press_and_Hold, (int)Key + ((int)Modifiers * 256)); } private void sendKeyUpToFS(Keys Key, SendModifierKeys Modifiers, int HoldTime) { // First make sure FSX has the focus SendControlToFS(FSUIPCControl.Key_focus_restore, 0); // Wait for focus change Thread.Sleep(150); // Send the key down SendControlToFS(FSUIPCControl.Key_Release, (int)Key + ((int)Modifiers * 256)); } Paul
    1 point
  49. It's not obviously clear from the SDK what the new (2024-native) livery structure should look like... But essentially liveries are now a child of the parent aircraft in 2024 VFS Child liveries don't have their own aircraft.cfg (and therefore no TITLE= line). Instead, they now have a livery.cfg that defines the parent aircraft (and engine-type relationship), with a [General] section where you can give a livery a name [Version] major = 1 minor = 0 [General] name="<Livery Name here>" So in 2024 native aircraft/liveries, TITLE returns the name of the parent aircraft only, and the new LIVERY NAME simvar exposes the name in [General] from the livery.cfg FS2020 aircraft and liveries that are "compatible" with 2024 (but are literal copy/pastes into the MS2024 community folder), still exhibit 2020 behaviour when it comes to TITLE, so aren't "problematic". But as developers slowly adopt the new 2024 livery packaging format, this will become more and more problematic to those of us who need livery info exposed. Thanks for the clarification around which SDK you're compiling against, and appreciate that FSUIPC serves both sims simultaneously at present. I'd have thought though, that any application that has historically relied upon livery detection would be interested in this feature potentially. As a VA we certainly have a requirement from an ACARS perspective, but appreciate this is probably the first your hearing of it. If this thread starts the ball rolling for others to chip in, awesome. If not, we'll have to potentially consider an in-house solution as you previously advised. TITLE has been around for donkey's years, has always served its purpose, and its frustrating that Asobo have decided to suddenly change this in 2024. Going forward, I for one certainly consider the new simvar as "core" as TITLE has always been. Thank you for engaging with this thread, and I'd ask (if possible) to keep this in the back of your minds when it comes to your wider development roadmap.
    1 point
  50. I have created Voice-Interactive Checklists (using Windows Speech Recognition and Text-to-Speech facilities) for a variety of airplanes in FSX, though not by using this LUA script, but using a third party freeware: VoiceMacro. For details please visit: https://voicemacro.net/ and then proceed to my post in the VoiceMacro forums at: https://voicemacro.net/ForumVM/discussion/405/flight-simulator-co-pilot-for-cockpit-checklists-fsx-and-windows-7-x64#latest Checklists and Profiles I have already created for some common aircraft are referenced here: PMDG B747-400: https://forum.pmdg.com/forum/main-forum/general-discussion-news-and-announcements/pmdg-747-queen-of-the-skies-ii-forum/71104-voice-interactive-checklists-for-the-b747-400-qots-ii PMDG B737-800 NGX: https://forum.pmdg.com/forum/main-forum/pmdg-737-ngx/75062-voice-interactive-checklists-for-pmdg-b737-800-ngx PMDG MD-11: https://forum.pmdg.com/forum/main-forum/pmdg-legacy-products/67885-voice-interactive-checklists-for-the-pmdg-md-11 SimCheck A300B4: https://forum.aerosoft.com/index.php?/topic/154190-voice-interactive-checklists-for-simcheck-a300b4/&tab=comments#comment-986217 Flight One ATR72-500: http://atr.flight1.net/forums/voiceinteractive-checklists-for-flight1-atr72500_topic6739.html?SID=10078-f5dc6bdea27f27a7bdf42075462963 Flight Sim Labs A320 X: https://forums.flightsimlabs.com/index.php?/topic/25728-voice-interactive-checklists-for-fslabs-a320x/ Majestic Dash 8 Q400: http://majesticsoftware.com/forums/discussion/793/voice-interactive-checklists-for-mjc8-q400 Level D B767-300: https://www.dropbox.com/sh/51bgejl2j83anjf/AACmtjJDcMbJBLvvcTL7oJMwa?dl=0 PMDG B777-200: https://forum.pmdg.com/forum/main-forum/pmdg-777-forum/71229-voice-interactive-checklists-for-pmdg-b777-200 Chakko Kovoor.
    1 point
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.