No Hvars loaded anymore

[LeoSchoonbroodt]

Hi,
Yesterday i Updated my FSUIPC version from 7.2.14 to 7.3.2 and now it doesn't load my Hvar file anymore.

I hae read about a new ini parameter UseAirLocForHvars but have no idee where to place it and what the values should be.
Aleady tried the FSUIPC7.ini file and also the WASM.ini file with values No and Yes but without success.

Please can anyone help, because i make heavily use of Hvars and my plane is unflyable this way.

 

Also tried to restore previous version but then it starts complaining about WAPI version conflict

 

Thanks, Lo

[John Dowson]

1 hour ago, LeoSchoonbroodt said:

Yesterday i Updated my FSUIPC version from 7.2.14 to 7.3.2 and now it doesn't load my Hvar file anymore.

Which folder is your hvar file under, and is it still there?

1 hour ago, LeoSchoonbroodt said:

I hae read about a new ini parameter UseAirLocForHvars but have no idee where to place it and what the values should be.

It takes values Yes and No (default) and goes in the FSUIPC_WASM.ini file, preferably in this file located in your WASM persistent storage area, not in the one under your Community\fsuipc-lvar-module folder. if you don't know what this means, please see the Advanced User guide. However, it does look like i forgot to add this new ini parameter to the manual - i will do this for the next update.

How are you starting FSUIPC7 - manually or via auto-start?
I have noticed that since the latest MSFS update, FSUIPC7 is sometimes/occasionally not starting everything that is needed. This seems to occur occasionally when auto-started, and when manually starting FSUIPC7 when MSFS is in the main menu. I am currently looking into this. This occurs if/when the following message is not reported (in your FSUIPC7.log file) by the time you are ready to fly:
         -------------------- Starting everything now ----------------------
If this is the case, you could try restarting FSUIPC7 once you are ready to fly and things should be ok.

If that is not your issue, please attach your FSUIPC7.log and FSUIPC_WASM.log files and tell me the name and location of your hvar file. Note the name should probably change if you set UseAirLocForHvars to Yes, so best not to set this for the time being.

John

Edited April 7, 2022 by John Dowson
FSUIPC_WASM.log file added

[LeoSchoonbroodt]

Hi John,
My Hvar files are in the Community\fsuipc-lvar-module/modules folder.
No change other than upgrading to 7.3.2

Only when i found Hvar files not loaded anymore i put the  UseAirLocForHvars first in the FSUIPC7.ini, later in the FSUIPC.WASM.ini and set it to No, but both with no result
I tried the FSUIPC_WASM.ini in the modules folder and in the persistant storage work folder, both with no result.

Have to test a little bit more tomorrow, it started working after several restarts of MSFS.

Have to structural investigate tomorrow because i copied around and renamed the Hvar files so much that i lost focus about what i changed.

Keep you informed, thanks

[John Dowson]

12 hours ago, LeoSchoonbroodt said:

My Hvar files are in the Community\fsuipc-lvar-module/modules folder.

Are they still there? Better to keep your own hvar files in the other location.

12 hours ago, LeoSchoonbroodt said:

Only when i found Hvar files not loaded anymore i put the  UseAirLocForHvars first in the FSUIPC7.ini, later in the FSUIPC.WASM.ini and set it to No, but both with no result

You don't need to do this as No is the default value.

12 hours ago, LeoSchoonbroodt said:

I tried the FSUIPC_WASM.ini in the modules folder and in the persistant storage work folder, both with no result.

Understandable as doing this doesn't change anything.

12 hours ago, LeoSchoonbroodt said:

Have to test a little bit more tomorrow, it started working after several restarts of MSFS.

Don't restart MSFS - try restarting FSUIPC7. Before you do this, please check for that line in the FSUIPC7.log file as indicated in my previous post.
To see details on the loading of hvar files, set Debug level logging in the FSUIPC_WASM.ini file and take a look at your FSUIPC_WASM.log file.

You could also consider switching from using hvar files to presets. You can activate hvars via presets without making the hvars known to FSUIPC7. To activate a hvar via a preset, create a file called myevents.txt, and in it add lines of the form
      presetName#>(H:hvarName)
You can then assign to the presetName in the drop-down as 'Preset: presetName''.

John

 

[LeoSchoonbroodt]

Hi John, 
Did some testing today with logging set to Debug, and found, on my system it is always looking to the folder name instead of the title in the aircraft.cfg

No matter if i put the UseAirLocForHvars to No, to Yes or leave it out at all in the FSUIPC_WASM.ini in my Community\fsuipc-lvar-module folder
I always deleted Persistant storage folder as to be not hindered by any cached values.

I have the folowing Folders:
hpg-airbus-h145
hpg-airbus-h145-civ
hpg-airbus-h145-mil

and the folowing Titles
Airbus H145 Luxury Liery 1
Airbus H145 Civilian Livery 1
Airbus H145 Military Livery 1

With version 1.14 i used the Airbus H145.hvar which worked for all three planes
now with version 2.3 i have to use hpg-airbus-h145.hvar which works for all regardless of the UseAirLocForHvars setting.
So looks like it is always looking for the folder name.

Did not yet test with restarting FSUIPC while MSFS still running because i always wanted a clean start.
if you want to i can test this tmorrow because today i run out of time.

[John Dowson]

Just checked the code, and it looks like I forgot to initialise the  default value for the new ini paramater UseAirLocForHvars to false... Sorry about that. Please try with the attached WASM - use it to replace the one in your Community\fsuipc-lvar-module\modules folder: FSUIPC7_WASM.wasm

If you get the same problem with that one, please attach your FSUIPC_WASM.log file (preferably with Debug enabled) and I will take a look.

John

[John Dowson]

42 minutes ago, LeoSchoonbroodt said:

I always deleted Persistant storage folder as to be not hindered by any cached values.

Btw, this is not cached values... This is the location for your preferences/files that will not be affected by FSUIPC updates. If you want to preserve your hvar files and ini settings, you should use this location. Anything you change in the Community\fsuipc-lvar-module folder could change on an update.

John

[LeoSchoonbroodt]

Hi John,
unfortunatedly had only limited time today but did one test with UseAirLocForHvars set to No and the Airbus H145.hvar.
Hvar file was not loaded also not when i executed a Wasm reload via lua.

I included the WASMFSUIPC_WASM.logFSUIPC7.logFSUIPC_WASM.inifor you.

Setting the UseAirLocForHvars parameter back to Yes and using the Hvar file with a subset of the folder name worked well.

I also did some tests with starting FSUIPC when MSFS was running and always got the -------------------- Starting everything now ----------------------
message when starting, but forgot that you mentioned that MSFS should be in the main menu, sorry about that.

Could do some more testing tomorrow, for me the problem is solved because i am using a subset of the folder name now for my Hvar files.

Leo

[John Dowson]

On 4/9/2022 at 9:37 PM, LeoSchoonbroodt said:

unfortunatedly had only limited time today but did one test with UseAirLocForHvars set to No and the Airbus H145.hvar.
Hvar file was not loaded also not when i executed a Wasm reload via lua.

Was this test with the new WASM module I poste above? I forgot to update the version number so it is difficult for me to tell. Please try the attached version where I have update the version number - I have also added an extra logging statement to log the value of UseAirLocForHvars   being used.

On 4/9/2022 at 9:37 PM, LeoSchoonbroodt said:

Could do some more testing tomorrow, for me the problem is solved because i am using a subset of the folder name now for my Hvar files.

I would like to get to the bottom of this issue if possible, so please ret with the attached and report back, including your FSUIPC_WASM.log file.

Thanks,

John

FSUIPC7_WASM.wasm

[John Dowson]

Hi Leo,

The WASM has ben updated and released with v7.3.3 so please download and use that version before reporting back.

[LeoSchoonbroodt]

Hi John,

Sorry had not much testing time lately.
Tested today with V7.3.3 as you asked and the ini parameter UseAirLocForHvars=No worked.
I included the FSUIPC_WASM.log.

Thanks for repairing it.

FSUIPC_WASM.log

[LeoSchoonbroodt]

Hi John,

Encountered another problem today, a new HEMS variant of the Hype Airbus H145 uses more than your max of 2044 Lvars, so i miss several important Lvars.

Is there a possibility to increase this max, or maybe to create a new ini file parameter in which you can specify a substring to not load Lvars that match that substring.
As i expect that this plane will be the most used helicopter in MSFS it probably will hinder a lot of users.

Have a nice evening,

Leo

[John Dowson]

14 hours ago, LeoSchoonbroodt said:

maybe to create a new ini file parameter in which you can specify a substring to not load Lvars that match that substring.

This isn't possible with the current implementation as all lvars are passed from the WASM to FSUIPC7 as a list/array, with the position being the if of the lvar. If I don't pass all lvars, I would also have to pass the lvar ids. This would be a major change which I certainly won't be considering at the moment.

14 hours ago, LeoSchoonbroodt said:

Is there a possibility to increase this max

I could do this. I am having a break from new development at the moment to catch-up on other things, but I will add another CDA (or 2) for lvars in a future release, maybe in a month or so.

There are a few other things to consider/try. Lvars are loaded for many aircraft that are in your community folder even if not being used. which can reduce the number of lvars available for the aircraft that you are actually using. Try clearing your Community folder to contain only the items you are using for each flight. Many people use the MSFS Add-on Manager (a free utility) to do this.

Also, even if lvars are not known to FSUIPC7, they can still be used in Presets (or in calculator code). So you can create presets to use the lvars which are out of the 2044 range. However, you cannot get the value of such lvars (or add them to FSUIPC offsets). You can, in the preset calculator code, check the value of the lvar and change it or send a control based upon the value (as many of the MF presets do).

John

[LeoSchoonbroodt]

Hi John,

Sorry just saw your reaction, must have missed the notification.
The dev for Hype Airbus H145 reduced already the number of Lvars used, so the problem is solved in a way.

Nevertheless will more CDA's possibly prevent future issues like this. But i don't know what the costs are in terms of memory use or processing time.

Thanks for your tip to remove unused items from my community folder, i will certainly do that as i have some I rarely use.
I never used Presets, and need indeed the values of the lvars which i send to my Arduino micro to base decisions on.
The Lvars for the H145 are ReadOnly anyway.
Guess i have to do a little readup to see how i can use Presets.

Anyway thanks for your response.

Leo

[John Dowson]

1 minute ago, LeoSchoonbroodt said:

Nevertheless will more CDA's possibly prevent future issues like this. But i don't know what the costs are in terms of memory use or processing time.

The problem with adding another CDA for lvar names is that I would also need to add another CDA for the values, as the current 2044 restriction is actually on the value CDAs. I can increase at some point, but would rather not unless essential. I don't think memory is much of an issue these days, as each CDA is only 2k.

4 minutes ago, LeoSchoonbroodt said:

I never used Presets, and need indeed the values of the lvars which for the H145 are ReadOnly anyway.
Guess i have to do a little readup to see how i can use Presets.

Presets are only for actions and cannot be used to get values - they would need to be known to FSUIPC for this (e.g. to add to an offset).

John

[LeoSchoonbroodt]

2 minutes ago, John Dowson said:

The problem with adding another CDA for lvar names is that I would also need to add another CDA for the values, as the current 2044 restriction is actually on the value CDAs. I can increase at some point, but would rather not unless essential. I don't think memory is much of an issue these days, as each CDA is only 2k.

Presets are only for actions and cannot be used to get values - they would need to be known to FSUIPC for this (e.g. to add to an offset).

John

Ok, thanks so Presets are like Hvars, i understand. These i use also extensively.
Well as i said in fact the problem is solved by the dev of the H145, so it's not needed to create them anymore, was just thinking that with the complexity of most planes the problem could maybe return later.
 

I am so glad that FSUIPC together with lua and a few Arduino sketches does a marvelous job in interfacing hardware with MSFS and the Planes developed for it.
Therefore my thanks.

Leo

[John Dowson]

12 hours ago, LeoSchoonbroodt said:

Ok, thanks so Presets are like Hvars, i understand.

No. Presets are names associated to a string of calculator code which is executed by the FS ('calculator code' is a scripting language used by XML gauges), and you can use/activate hvars in calculator code, as well as set lvars, read lvars, send events, perform logical operations, etc.

John