Jump to content
The simFlight Network Forums

ark1320

Members
  • Posts

    677
  • Joined

  • Last visited

  • Days Won

    17

ark1320 last won the day on January 3

ark1320 had the most liked content!

1 Follower

Profile Information

  • Gender
    Male
  • Location
    Colorado, USA

Recent Profile Visitors

5,858 profile views

ark1320's Achievements

Community Regular

Community Regular (8/14)

  • Posting Machine Rare
  • Dedicated Rare
  • Reacting Well Rare
  • First Post Rare
  • Collaborator Rare

Recent Badges

33

Reputation

  1. Hi John, Below are two tiny Lua scripts to calculate the total weight (e.g., landing weight) of a plane (Learjet in this case). If I run the scripts a number of times as the plane flies and burns off fuel, the first two-line script using an offset works reliably and always provides the correct updated weight. However, the second script that creates an Lvar in order to read the TOTAL WEIGHT Avar fails approximately 40 to 50 percent of the time. When it fails the script usually reports the initial value used when creating the Lvar (the 10361 value), or just doesn't update from the previous value. Using the sim's SimVar tool I monitored the TOTAL WEIGHT simvar and it always was updating as expected. I assume the (0x30C0) offset is using that simvar value. The main purpose of this post is to make sure I understand the Lvar creation process. It was this "Lvar script" that I tried first until seeing it was not working reliably. If the code in the Lvar script looks correct to you, then I would assume the sim has some kind of timing issue or bug. This happens in both MSFS2020 and MSFS2024. I know you are on Holiday and this issue can certainly wait until a convenient time. Thanks, Al ldg_wt = ipc.readDBL(0x30C0) -- get total weight ldg_wt = math.floor(ldg_wt_offset + 0.5) -- round to no decimal places ==================================================================================================== ipc.createLvar("L:Lear_LDG_Weight",10361) -- create Lvar, just using Lear's empty weight as the initial value ipc.reloadWASM() ipc.sleep(1000) ipc.execCalcCode(" (A:TOTAL WEIGHT, pounds) (>L:Lear_LDG_Weight) ") -- get current total weight ipc.sleep(100) ldg_wt = ipc.readLvar("L:Lear_LDG_Weight") ldg_wt = math.floor(ldg_wt + 0.5)
  2. Hello Fragtality, PilotsDeck profile switching (MSFS2020/2024) has stopped working. I am using the latest version of PilotsDeck (ver 0.8.9) and recently updated to the latest version of StreamDeck (ver 6.9.1). The profile switching problem started at some point after the StreamDeck update. I have tried reinstalling PilotsDeck, and have checked and resaved the profile settings in the Profile Manager. No matter which plane I load, I get the Default Profiles on the SD+ and the 15 button SD. EDIT: I just saw PilotsDeck ver 0.8.10 was released, and when I installed it the profile switching problem was fixed. Thanks, Al
  3. I don't understand the above because I think the rotor K-event refers to a helicopter rotor, not some aspect of a B737. But I am not familiar with Open Cockpits equipment and maybe they have "repurposed" that K event somehow. Regardless, the FS2020 SDK says the below (and the FS2024 SDK says something similar). So maybe try (K:ROTOR_BRAKE_ON) in place of (K:ROTOR_BRAKE) if some type of rotor brake event is really what you need to use.
  4. Yes I do. And I have separate Community folders in case that makes any difference. Al
  5. Just as another data point, auto Lua scripts are working for me after the FS2024 SU2 update today. Al
  6. Thank you John! Beta 7.5.4a works with ENTER key in both FS2020 and FS2024. Al
  7. Hi John I have a Lua script that makes use of the code event.key(13, 0, "keyPressed") to detect the CR (ENTER) key. The script works in FS2024, but not in FS2020. I am using the exact same script in both sims. It seems something in FS2020 might be trapping the ENTER key so it is not seen by the lua script. There are no control bindings assigned to ENTER. Using an empty Community folder or different aircraft does not help. Based on your MS2020 experience do you have any ideas on what the issue might be? Thanks, Al
  8. Thanks for that info, John, very good to know. If you are creating the Lvar in order to read an Avar value, it seems you would still have to use calculator code to get the Avar value into the new Lvar. But then no WASM reload is needed. In my particular application I needed to read the value of 4 different Avars, so I used one long calculator code to do that and then followed up with one wasm reload. Al
  9. Excellent! I was not aware of that reload WASM function. Thanks very much! Al
  10. Update to the above, did some experimenting: If I start FS2020 and load the plane onto the runway, the above code does not work. If I then go back to the sim's main menu and reselect the plane and again load it onto the runway, the code works. If I start FS2020 and load the plane onto the runway, the above code does not work. But if after the code fails if I then open FSUIPC7 and click on WASM > Reload and List Lvars, the code works. So if there was a way to rerun (or reactivate) WASM with programmatically with Lua code, that would be a "work around". You could run the calcCode to 'create' the Lvar, and then reactivate WASM to make the Lvar known. BTW, as an aside, the Relist part of the WASM function to Reload and List Lvars does not seem to work. After activating that I have to then click on List Lvars to see the list. Thanks, Al
  11. Hi John, I am trying to use the code below to access the value of the Avar (A:CG PERCENT, percent), but is not working. It seems the Lvar (L:ac_MAC, percent) is not "created" as expected. I can't display the the value of mac in a window, and when I test it the value of mac is nil. And the Lvar does not show up in the FSUIPC7 Lvar list. The Avar is valid, I can view its value it in the Simvar tool. Am I forgetting something? Thanks, Al (FS2020, FSUIPC7 1.7.3) ipc.execCalcCode(" (A:CG PERCENT, percent) (>L:ac_MAC, percent) ") -- get Mean Academic Chord (MAC) ipc.sleep(500) -- time to create Lvar Lear_MAC mac = ipc.readLvar("L:ac_MAC")
  12. Hi John, Thanks for making Lvar names case insensitive in Lua scripts in the recent FSUIPC7 update! Al
  13. Hi John, Making Lvar names in FSUIPC insensitive would certainly be helpful when you have time to do it. Thanks very much, Al
  14. In my experience Lvar names are not case sensitive in XML coding. But when used in Lua scripts with commands such as ipc.writeLvar("L: Name", value) or ipc.readLvar("L:Name") they are case sensitive, I assume because when enclosed in quotation marks they are treated like strings. This caused me a problem lately in MS2024 because in the XML code for an aircraft, the developer accidentally (I assume) was not consistent case-wise with some of the Lvars names. As a result my Lua scrip, which used Lvar read and write commands like the above, did not work as expected. So I'm posting this in case it helps someone in the future. What I eventually noted was in the Lvar list that the FSUIPC7 wasm provides, a few of the Lvar names had a different case then in the section of XML coding I was trying to access. Perhaps the wasm Lvar list "uses" whatever case the first Lvar it comes across is using -- don't really know. The Lvar list did not include both case variations of the Lvar name. It would be convenient if commands like ipc.readLvar( ) were not case sensitive, but that may not be possible. In my case, I had to use ipc.execCalcCode(" ") to get around the case issue because the Lvar names are not case sensitive in the XML CalcCode. If something above is not correct, or there is a better solution to this case sensitive Lvar issue, please let me know. Thanks, Al
  15. Hi John, I did in fact try some things that didn't work. FSUIPC has added some Lua functionality (such as all the ipc.wxy commands) that are not in the formal Lua documentation, so I thought I'd ask here "just in case". Thanks for checking, Al
×
×
  • 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.