Jump to content
The simFlight Network Forums

SU10 and FSUIPC7 MSFS


bangaroo

Recommended Posts

Hello!

I suspect the answer is beta software is buggy, but figured I'd ask.

I'm flying the Fenix a320 on MSFS SU10, the most recent beta. I am using the registered version of FSUIPC7 with the WASM extensions installed and PilotDeck on top of it connecting to a preset for the Fenix.

I get feedback and updates on the switches as far as the button status in the game... but no buttons do anything. Stuff mapped inside of the setup for the Stream Deck does not work however, and the log is filling with "attempted to perform arithmetic on a nil value." I suspect the answer is "SU10 broke LVars" and I have to wait for an update, but couldn't shake the feeling I was doing something wrong.

Link to comment
Share on other sites

I don't have the SU10 beta installed so it is difficult for me to advise and this may have to wait until SU10 is released, which should be in the next few days... However, if you could attach your FSUIPC7.log and FSUIPC7.ini files, together with your FSUIPC_WASM.log file, then I will take a look.

Has this been an issue with the SU10 beta since release or has this started in a recent beta update? Did you check the SU10 beta support forum to see if others were havung similar issues?

John

Link to comment
Share on other sites

Ok, this will also be the issue for @bangaroo. If the lvars are available on a reload, then this indicates that the scan for lvars is being performed to early. To fix this, set or increase the value of the FSUIPC_WASM.ini parameter LvarScanDelay. It is recommended to do this in an  FSUIPC_WASM.ini file in your WASM permanent storage area, not the one under your Community\fsuipc-lvar-module folder, as that will be overwritten when you update/re-install. See the Advanced User guide for further details.

John

Link to comment
Share on other sites

do you intend to investigate why this behavior changed between the two versions? or is this going to be the recommended fix going forward? i'm fine just using the reload workaround in the short term if you believe you'll be making a fix for this.

edit: really appreciate you tagging me in for the fix, by the way!

Edited by bangaroo
Link to comment
Share on other sites

5 minutes ago, bangaroo said:

do you intend to investigate why this behavior changed between the two versions?

No need - it is just a timing issue, and it is taking longer (somewhere in loading the aircraft) before the lvars (being used) are available..

8 minutes ago, bangaroo said:

or is this going to be the recommended fix going forward?

This has always been a recommendation when using complex aircraft. The default value for the LvarScanDelay parameter is 5 (seconds), but I recommend a value of 45-50 when using complex aircraft and/or airliners.

11 minutes ago, bangaroo said:

i'm fine just using the reload workaround in the short term if you believe you'll be making a fix for this.

There will be nothing in the next release, but I do have some ideas to make sure that all lvars are available without having to reload, but I will look into this after I have released an updated version for SU10, now that it has been released..

7 minutes ago, bangaroo said:

So the reload option is grayed out - I'm not sure what I'm doing wrong here. I'm much more of an incidental user of fsuipc than a power user. I verified the LVar module is installed -- what am I missing?

The WASM menu options are enabled once the lvars have been received, indicated by the number of lvars/hvars/presets available being logged in the FSUIPC7 main window. This only occurs one you have a plane loaded and ready-to-fly, and after LvarScanDelay seconds.

2 minutes ago, bangaroo said:

I do see counts of loaded LVars but it doesn't seem to solve the issue.

If the issue is that the lvar isn't available, then you just need to reload until it is....
You can always have a simple lua script that auto-runs for each aircraft and checks that any lvars you are using are available in a loop, and if not then issue a reload, followed by a short pause/sleep, and exit the loop once the lvar is available. You only need to do this for the lvar you are using that has the highest id (as that will be created last), and you can use the lua function 
    n = ipc.getLvarId(“name”)
To see if the lvar is available - it will return nil if not available.

Link to comment
Share on other sites

I guess my biggest question here (so I can reason around what changed) is why would this behavior change so substantially between SU9 and SU10?

This wasn't an issue in SU9 - is the guess that something changed regarding when the LVars are made available in SU10 that are now delaying them further and leading to this behavior?

Regardless, will follow your advice and appreciate the time and personal attention.

Edit:

I've now sat Reloading the LVars for 8 minutes and still no dice. Is there some logging I could provide to help you investigate?

Edited by bangaroo
More changes
Link to comment
Share on other sites

44 minutes ago, John Dowson said:

Ok, this will also be the issue for @bangaroo. If the lvars are available on a reload, then this indicates that the scan for lvars is being performed to early. To fix this, set or increase the value of the FSUIPC_WASM.ini parameter LvarScanDelay. It is recommended to do this in an  FSUIPC_WASM.ini file in your WASM permanent storage area, not the one under your Community\fsuipc-lvar-module folder, as that will be overwritten when you update/re-install. See the Advanced User guide for further details.

John

Thanks for your help, I set LvarScanDelay = 25 in FSUIPC_WASM.ini and actually fsuipc loaded more LVARs for me. Previously it was loading around 1700 now it's 1912. Everything works ok. I found the file FSUIPC_WAMS.ini in Community \ fsuipc-lvar-module only. There is no such file in the location mentioned in the Advanced User guide. Should I copy the teen ini file from the community folder?

Link to comment
Share on other sites

 

9 minutes ago, bangaroo said:

I've now sat Reloading the LVars for 8 minutes and still no dice. Is there some logging I could provide to help you investigate?

8 minutes? If the number of lvars loaded aren't changing, then all are loaded and no point continuing to reload. If the lvar isn't available, then it doesn't exist and no amount of reloading will make it available. FSUIPC can only use the lvars that are provided.

4 minutes ago, Dominik said:

There is no such file in the location mentioned in the Advanced User guide. Should I copy the teen ini file from the community folder?

There is not one there by default, and yes you should copy the one from your Community folder and then edit, as it says in the Advanced User guide:
        It is recommended to leave this file as is, and copy to your persistent storage area and modify as and when needed from there.
 

Link to comment
Share on other sites

15 minutes ago, bangaroo said:

I guess my biggest question here (so I can reason around what changed) is why would this behavior change so substantially between SU9 and SU10?

It us not a substantial change - it is only that the aircraft is taking longer to load and therefore longer to make lvars available. However, if the lvar never becomes available then maybe the aircraft has been updated and the lvar name has changed or is no longer available. What aircraft and lvar are you missing?

I am updating to SU10 at the moment. I am finishing for the evening and will look at the SU10 release tomorrow.

 

Link to comment
Share on other sites

1 minute ago, John Dowson said:

 

8 minutes? If the number of lvars loaded aren't changing, then all are loaded and no point continuing to reload. If the lvar isn't available, then it doesn't exist and no amount of reloading will make it available. FSUIPC can only use the lvars that are provided.
 

So I'm still struggling to understand here. This did work in SU9. I haven't changed anything. It also seems like extending the delay time has revealed more LVars, but the issue of using button presses on my streamdeck via pilotdeck has not yet been resolved.

Is there a log or something I can send you to help illustrate my problem? I'm mostly using several pieces of software piled together on top of FSUIPC and the developers all say they are waiting on a compatibility update; not sure if they're correct, though.

Link to comment
Share on other sites

1 minute ago, John Dowson said:

It us not a substantial change - it is only that the aircraft is taking longer to load and therefore longer to make lvars available. However, if the lvar never becomes available then maybe the aircraft has been updated and the lvar name has changed or is no longer available. What aircraft and lvar are you missing?

I am updating to SU10 at the moment. I am finishing for the evening and will look at the SU10 release tomorrow.

 

It's the fenix, so it hasn't yet updated - it will be later today, but same version of aircraft.

The only thing that changed in this time period was the version of MSFS. I even downgraded to SU9 and got the functionality back (which I no longer have the option to do, because of the beta ending.)

Link to comment
Share on other sites

56 minutes ago, bangaroo said:

but the issue of using button presses on my streamdeck via pilotdeck has not yet been resolved.

I suggest that you wait to see if there is an update to the Fenix, and also wait until I have released a new version of FSUIPC7 updated to the latest SDK. Then, if you still have issues, provide more information - including your .ini and .log files.

I will be busy tomorrow reviewing the SDK changes and preparing a new FSUIPC7 release, I can look into specific issues once this is done and not before. Please be patient.

John

 

Link to comment
Share on other sites

Just now, John Dowson said:

I suggest that you wait to see if there is an update to the Fenix, and also wait until I have released a new version of FSUIPC7 updated to the latest SDK. Then, if you still have issues, provide more information - including your .ini and .log files.

I will be busy tomorrow reviewing the SDK changes and preparing a new FSUIPC7 release, I can look into specific issues once this is done and not before. Please be patient.

John

 

Appreciate all your help and the great software - thank you.

Link to comment
Share on other sites

The behavior is that LVars aren’t getting set, the best I can tell. I am not the person who wrote the scripts I’m using, so I cannot tell you specifically all the details - I just know that the tools I was using (PilotsDeck and a Fenix a320 overlay for it) worked fine in SU9 (button presses would trigger buttons in the sim set via LVars) and now they do not work, which is new behavior. i am observing the exact same problems with AAO and similar extensions for it, therefore I’m assuming it’s something at the AAO/FSUIPC level and not with the extensions I am using as the only common thread in both is MSFS - it seems like something changed there that then broke the AAO/FSUIPC and now we are here.

Reading LVars seems to work fine. I don’t have any issue with that and the StreamDeck updates perfectly fine. Writing still does not seem to work. I apologize that I’m not super technically knowledgeable about the details here, I am not an expert in the internals of MSFS, I’m just a user of others’ tools. Here are the two files you've asked for.

Reloading LVars does nothing to solve the problem, as was suggested above. I still observe the same behavior regardless of how late I reload LVars.

I am fairly certain I am using the latest WASM module, as well:

{
  "dependencies": [],
  "content_type": "MISC",
  "title": "FSUIPC7 WASM Event Module",
  "manufacturer": "John L. Dowson",
  "creator": "John L. Dowson",
  "package_version": "0.5.10",
  "minimum_game_version": "1.27.21.0",
  "release_notes": {
    "neutral": {
      "LastUpdate": "22/09/2022",
      "OlderHistory": ""
    }
  }
}

FSUIPC7.log FSUIPC7.ini

Link to comment
Share on other sites

The log shows a couple of issues:

Quote

    14703 *** LUA Error: C:\FSUIPC7\PilotsDeck.lua:1: unexpected symbol near 'ï'

That should be self explanatory - take a look at line 1 of that lua.

Quote

   205953 *** LUA Error: C:\FSUIPC7\FNX320_SYNC.lua:24: attempt to perform arithmetic on a nil value

That one is probably due to an lvar not being available, but look at line 24 and that should tell you.

22 minutes ago, bangaroo said:

Reloading LVars does nothing to solve the problem, as was suggested above. I still observe the same behavior regardless of how late I reload LVars.

Writing to an lvar is working ok here, but it won't work if the lvar has not been loaded, which is what I suspect is your issue.
Reloading should work now (was broken before) - do you see the lvar count increase when you reload? Did you adjust the LvarScanDelay WASM ini parameter, and if so to what value?
You can try listing the lvars - do you see the ones you use? Then reload & list, and see if you see it then, and repeat until no further ones are found.

Note that if the lvar is not available when the lua starts, it may not function correctly if later found on a rescan - that would depend in how the lua is written. That is why it is a good idea to set the LvarScanDelay to a reasonable level for the aircraft that you are using.

I have plans to implement a feature to provide all lvars as available/created by implementing an auto-scan (for new lvars) functionality in the WASM, but that will be after the next release for SU10 compatibility.

Try the above, and if you still have issues, please activate Debug level logging in the WASM/WAPI by adding the following to the [WAPI] section of your FSUIPC7.ini file and to the [General] section of your FSUIPC_WASM.ini file:
    LogLevel=Debug
and then generate another FSUIPC7.log file and show me that, together with your FSUIPC_WASM.log file.

You can also attach the luas if you want me to take a  look at them.

 

Link to comment
Share on other sites

13 hours ago, John Dowson said:
Quote

    14703 *** LUA Error: C:\FSUIPC7\PilotsDeck.lua:1: unexpected symbol near 'ï'

That should be self explanatory - take a look at line 1 of that lua.

@bangaroo You don't have to install that Lua File - it is just a kind of "Template" for a continuously running Script to run some Logic and generating Values (writing Offsets/LVars) that PilotsDeck could read and display that. I'll guess you never really did anything with the File except installing it? In that case you can safely remove it 😉 
(For the Fenix Integration: That is exactly what the SYNC Script is doing)

@John Dowson Line 1 starts with a Multline Comment ("--[["). See https://github.com/Fragtality/PilotsDeck/blob/master/PilotsDeck/lua/PilotsDeck.lua

 

13 hours ago, John Dowson said:
Quote

   205953 *** LUA Error: C:\FSUIPC7\FNX320_SYNC.lua:24: attempt to perform arithmetic on a nil value

That one is probably due to an lvar not being available, but look at line 24 and that should tell you.

@John Dowson Yep, your Guess is 100% correct 😉 There are two ipc.readLvar() Calls in that Line: https://github.com/Fragtality/PilotsDeck/blob/master/Integrations/Fenix A320/FNX320_SYNC.lua#L24
So either it is the ipc Function not working correctly, the ScanDelay is too short or Fenix renamed the Variable.

 

All I can say at the Moment: Everything worked with SU9 (and Fenix 1.0.2.104).
During SU10-Beta I got reports from Users that Lvars are not working/behaving strangely. On the Plugin-Side I made a workaround which seemed to help: it uses the "legacy way" (via Offset 0x0D70) to read LVars instead of using WASM (through Pauls C# Client). So the Sim and/or FSUIPC are behaving differently.
@bangaroo Try Plugin Version 0.7.2 and set "Fsuipc7LegacyLvars" to true - maybe that helps still on the Plugin-Side (Consult the Readme how/where to set it and how to upgrade from a 0.6.x Version if you're not already on a 0.7.x Version)
For SU10 GA: I hope to install it soon and hopefully get a better Understanding of what the Issue/Solution is and to Update the Plugin and Integrations accordingly! 🙂 

Link to comment
Share on other sites

33 minutes ago, Fragtality said:

So either it is the ipc Function not working correctly, the ScanDelay is too short or Fenix renamed the Variable.

The ipc function is working correctly - as I said, try listing the lvars to see if those are available: S_OH_EXT_LT_LANDING_L and S_OH_EXT_LT_LANDING_R

33 minutes ago, Fragtality said:

During SU10-Beta I got reports from Users that Lvars are not working/behaving strangely. On the Plugin-Side I made a workaround which seemed to help: it uses the "legacy way" (via Offset 0x0D70) to read LVars instead of using WASM (through Pauls C# Client). So the Sim and/or FSUIPC are behaving differently.

Reading lvars should have been ok with SU10, it was the writing/updating that was broken - and fixed in the latest beta 7.3.9f. That offset still uses the lvars read from the WASM, so I can't see how switching to using the offset would make a difference... the lvar has to be available to FSUIPC via the WASM however it is read.

33 minutes ago, Fragtality said:

For SU10 GA: I hope to install it soon and hopefully get a better Understanding of what the Issue/Solution is and to Update the Plugin and Integrations accordingly! 🙂 

Ok, thanks. I don't have the Fenix, so cannot check the available lvars here.

Thanks @Fragtality

Link to comment
Share on other sites

Good morning, John. 

I can confirm the current version of FSUIPC seems to work well with every aircraft, except the FENIX;.  I can read the LVARs via 'legacy offset' fine but can't seem to set them via WASM.   Interesting enough, the new FSUIPC seems to work just fine with the PMDG and every other aircraft.  So, I'm at a complete loss.  If there's something I can do to assist, please don't hesitate to ask. 

Matt

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • 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.