Jump to content
The simFlight Network Forums

Luke Kolin

Members
 View Profile  See their activity

  • Posts

    379

  • Joined

  • Last visited

 Content Type 

Posts posted by Luke Kolin

  4. LUA LVAR logging not working on FSUIPC7

    in FSUIPC7 MSFS

    Posted

    23 hours ago, John Dowson said:

    But why don't you use the lvar logging facilities provided in FSUIPC7? This will log to the log file and optionally also to an ext window. See the section Logging Lvar Updates in page 48 of the Advanced User guide.

    I had forgotten about that, but I would strongly urge an enhancement to this functionality - the modification that I made to Pete's original Lua script was to add optional filter substrings so I could automatically include and exclude LVARs based on name. This would avoid a fair bit of work adding entries to the INI file one LVAR at a time.

    I'm attaching my FSUIPC7 log the second time around. It appears that Lua execution is very, very very slow. I terminated the sim before the script did a single execution to completion.

    Cheers

     

    FSUIPC7.log

  5. LUA LVAR logging not working on FSUIPC7

    in FSUIPC7 MSFS

    Posted

    I am using a modified LVAR logging script with the ability to selectively include/exclude LVARs. It works fine in FSUIPC6 and below, but attempting to run in FSUIPC7 and MSFS gives me no data. I tried removing the ipc.display() line (I vaguely recall that may be unsupported in MSFS), but it doesn't log to the FSUIPC log and I see the script getting killed even though I don't trigger a LuaKill.

    Is there something obvious I am missing?

    Cheers

    FSUIPC7.log LogLVars.lua

  6. Incorrect Aircraft.CFG location

    in FSUIPC7 MSFS

    Posted

    18 hours ago, John Dowson said:

    In MSFS I thought (but didn't check) that icao_type_designator would be distinct from ATC MODEL, and so added it, but it also may be the same as ATC MODEL...but I thought that would maybe match icao_model...

    You are correct. They are distinct data in MSFS, and can be different. My preference was to have a single offset but I realize we can't do this if they will be different, and my code path doesn't look too ugly (but give it time - it's only 6:30am here!)

    You are correct to remove in FSUIPC6. Sorry for the extra work.

    Cheers

  13. How to shut down LUA cleanly?

    in FSUIPC Support Pete Dowson Modules

    Posted

    I have a LUA script for my aircraft that runs and handles custom actions for button presses. I've registered a shutdown handler to run when the sim shuts down, and it is being called correctly. The last three lines in the shutdown handler are as follows: 

    event.cancel("HandleShutdown")
ipc.log("TFDi MD-11 Button Handler shutdown (" .. btnCount .. " buttons, " .. updCount .. " LED updates)")
ipc.exit()

    When P3Dv5 shuts down, the handler is called correctly, and I can see the last log line execute. However, in the log I see a 2150ms wait time, then the LUA thread gets killed. Should it not be dead already given the ipc.exit()?

    Full FSUIPC log attached.

    Cheers

     

    FSUIPC6.log

  16. Incorrect Aircraft.CFG location

    in FSUIPC7 MSFS

    Posted

    It looks like order of operations is significant. I tried a quick test case which was reversing the order of loading the aircraft - starting with the custom texture variant. It looks like FSUIPC may be getting two aircraft loaded events - one with the "main" aircraft.cfg that's an absolute path, then a buggy relative path. What's interesting however is that it gets the correct model ID from the first load, then overwrites it with an empty string subsequently.

    Cheers

     

    FSUIPC7.log

  17. Incorrect Aircraft.CFG location

    in FSUIPC7 MSFS

    Posted

    I did some basic switching around with the custom build you enclosed, and I also started to log three offsets to see if the tail code and aircraft ID were loaded. It appears that with the custom build, I'm getting back the parent aircraft.cfg, and the correct model and tail code in the offsets?? I started with the base model, then switched to the custom texture variants.

    If there's a specific test case you want me to walk through, happy to do it.

    Cheers

     

    FSUIPC7.log

  19. Incorrect Aircraft.CFG location

    in FSUIPC7 MSFS

    Posted

    3 hours ago, John Dowson said:

    Do you mean in offset  0x3C00? What is the value in that offset, and which aircraft are you using? Could you add logging for that offset and show me the FSUIPC7.log file.
    Note that this should be the full path name but sometimes its a relative path (reported to Asobo several years ago, but I haven't checked this for a while). This also may not ne available/correct for encrypted aircraft,

    I did some more digging (and upgraded to 7.501) and here's what I found. Aircraft is the Headwind A330-900neo with an add-on Delta texture pack. If I use the base version of the aircraft, all is well. It reports the aircraft path as following:

    d:\program files\fs2020\community\headwindsim-aircraft-a330-900\simobjects\airplanes\headwind_a330neo

    ... which is correct. I can read the file and offset 618h is populated and correct. Now if I switch to one of the add-on textures, the path is reported as

    D:\Program Files\FS2020\SimObjects\Airplanes\Headwind_A330neo

    ... which obviously is not correct. The correct path should be as follows:

    D:\Program Files\FS2020\Community\headwind-a339-Delta-Pack\SimObjects\Airplanes\HWD-A339_DAL3414

    What I think is happening is that the aircraft.cfg that is in that folder is just a stub with the variant information, and has a reference to the parent like this: 

    [VARIATION]
base_container = "..\Headwind_A330neo"

    Which may be confusing FSUIPC7?

    Cheers

  20. Incorrect Aircraft.CFG location

    in FSUIPC7 MSFS

    Posted

    I am attempting to read values from the aircraft.cfg in FS2020 using FSUIPC7. It looks like it is not getting a correct value for the aircraft location (it is in the community folder) which therefore gives me the wrong path for the aircraft.cfg. Offset 618h would give me what I want, but it looks like FSUIPC7 reads that from the aircraft,cfg, so it appears that is empty as well.

    Happy to provide more details - with the community folders there's a fair bit of redirection going on.

    Cheers

  24. Reading LVARs

    in FSUIPC Support Pete Dowson Modules

    Posted

    On 6/13/2024 at 2:09 PM, John Dowson said:

    I would have to check the code for that offset to see that happens if the lvar doesn't exist, but I would think that this is not handled. it just calls the next level function (whatever that is) to get the lvar value and lets that handle the case where it doesn't exist and then just writes the value returned to the offset. I can check the code if needed, but better to just test and see what you get.

    This seems to match I've discovered... if the LVAR does not exist then the previous value that was in the offset is retained. I can work around this by clearing the offset block in advance (I'm only reading from 24 to 48 bits at a time, so a since 64-bit long write can clear them out in one operation).

    In a perfect world, I'd prefer them to be set to zero, but I can also see advantages to this behavior as well (I can write a default value to the offset prior to the read). At the very least, it may be helpful to annotate the programmers guide to note this behavior in the case of an uninitialized LVAR.

    On 6/13/2024 at 2:09 PM, John Dowson said:

    Ok. But why are you using offsets to read lvar values? If doing this in code, maybe better to use the WAPI API directly (or one of its wrappers) rather than the old FSUIPC SDK. But that is for MSFS only,  so I guess if you want compatibility for both FSUIPC6 and FSUIPC7 then you would have to use offsets.

    I need to maintain compatibility back to FSUIPC4 🙂 so this is my preferred way to go. (Technically even farther, but I can no longer validate the FS2002/FSUIPC2 path and the FS9 path doesn't have GSX support). It's a testament to the great work that you and your father have done - I've been working on this application since the FS9 days and it's usually just a day or two of work to support a new simulator. It's a a great abstraction layer.

    Cheers

  25. Reading LVARs

    in FSUIPC Support Pete Dowson Modules

    Posted

    1 hour ago, John Dowson said:

    If you are reading the lvars via lua, the ipc.readLvar documentation (for both FSUIPC7 and FSUIPC6) states:  Is that not the case? Otherwise, how are you reading lvars?

    Sorry I wasn't more clear. I am not using Lua, I'm using offsets 0x0D6C and 0x0D70.

    To give the sequence of operations, I read the LVARs FSDT_GSX_BOARDING_STATE and FSDT_GSX_STATE to detect whether FSDT's GSX package is installed and operational. When called, I get the value of 1 back for the former, and 3 for the latter. I then ready FSDT_GSX_NUMPASSENGERS to see if a passenger count has been set by GSX. It also returns 3 What's interesting is that when I then fire up a LUA macro that selectively dumps LVARs to the SimConnect message window, FSDT_GSX_NUMPASSENGERS does not exist. It is curious and suspicious to me that the value returns is the same from the last LVAR successfully read.

    I'll try and make a test case where I manually set an LVAR, read it, then read an LVAR I know does not exist via the 0xD6C/0xD70 method.

    Cheers

     

×
×
  • 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.