Jump to content

new AFC Bridge issue


Recommended Posts

Ben,

 

Sorry to bring another topic, but I keep getting configuration issue when using "old" (working) profiles : the ">" is no more recognised with the new bridge

 

znCy3oU.jpg

 

I get it for all the >K:  (and >L:) variables...

 

Cheers

 

Gérard

 

 

 

Link to comment
Share on other sites

  • Aerosoft

Just took a quick look into the code and think I know whats happening. As with 2.1 I started to introduce more thourough mechanics to check variable integrity during profile loading, I strictly adhered to the output that is coming from the Configurator. And as this one is not producing >X: as output, I am also not seeing this as a valid input anymore.

Link to comment
Share on other sites

Hi Ben,

 

On 3/21/2021 at 12:03 PM, BenBaron said:

I am also not seeing this as a valid input anymore.

 

In a old thread about this ">" question you answered

 

On 1/4/2021 at 2:18 PM, BenBaron said:

This is, because if the ">" is missing for variables where it needs to be (aka where you want to set a variable), it will be added automatically while parsing the .json. So, basically, it does not matter, if it is in the .json itself, or not.

 

Easy to fix with Notepad++, but maybe the Import Configurator function should take care of it ???

 

Just a suggestion for people afraid to tweak the json files (and you don't like it either...)

 

Cheers,

 

Gérard

Link to comment
Share on other sites

  

Hi Ben,

 

It seams that I have another backward compatibility problem.

 

In LED section, I get this

 

FWefygO.jpg

 

Seams to be linked the L:Vars only ... and only at "check variable integrity", because the LED are lighting as expected.

 

EDIT : deleting the LED conditions and recreating sems to fix the error message, by suppressing the ", Bool" ...

 

EDIT 2: All LED condition with A:Vars use the format (A:XYZ, unit). So, should I keep the ", Bool" for L:Vars ???

Please help... before I make further updates.

 

Cheers,

 

Gérard

Link to comment
Share on other sites

  • Aerosoft

Hi Gérard,

 

Zitieren

In a old thread about this ">" question you answered

of course you are right about that one. In the depths of adding some more variable checks I just forgot about it again ;). Easy to add that back in, though.

 

Zitieren

Seams to be linked the L:Vars only ... and only at "check variable integrity", because the LED are lighting as expected.

 

EDIT : deleting the LED conditions and recreating sems to fix the error message, by suppressing the ", Bool" ...

 

EDIT 2: All LED condition with A:Vars use the format (A:XYZ, unit). So, should I keep the ", Bool" for L:Vars ???

Please help... before I make further updates.

This is also part of trying to do a more thourough check if the variables which are being used are also actually there when the panel has loaded up.

 

Prior 2.1 I had studied some profiles which most likely could not have worked at all, as they were using a unit together with an LVar while the unit should have only been used if it was ACTUALLY part of the variable name. Which most of the time it is simply not. Also in the code snippet above from "AP_MODES.xml" the unit is only there as part of the reading method, not of the variable name itself. As we figured this might not have become clear enough I decided we should scrap the unit field alltogether to reduce confusion and you just put in the unit into the "Name" field, should that actually be required by the simulator itself.

 

When this message comes up and you are 100% sure that the variable naming is correct you can always press "Oui" to continue using the current variable, or "Annuler" to continue using this variable AND stop checking the next ones for the device the profile is being loaded for.

 

So most likely you will scrap the the unit bool for your LVars but continue using the unit as part of the "Name" field for AVars as there they are part of the name itself and the sim would not know how to retrieve them without.

Link to comment
Share on other sites

  • 3 weeks later...
On 3/22/2021 at 7:30 AM, gaab said:

Hi Ben,

 

 

In a old thread about this ">" question you answered

 

 

Easy to fix with Notepad++, but maybe the Import Configurator function should take care of it ???

 

Just a suggestion for people afraid to tweak the json files (and you don't like it either...)

 

Cheers,

 

Gérard

After upgrading to v2.1 I'm getting the same errors on a whole string of K: variables (and a couple of L:) when loading past working Yoke profiles for the A2A Cessna 182.  Happens with the Default, and also on importing the A2A 182 profile from the Aerosoft download site.  I looked at the .json file and those variables are preceded by the ">".  What exactly is the fix with Notepad?  Thanks!

Link to comment
Share on other sites

7 hours ago, BenBaron said:

Hi,

 

for now the easiest fix is to open the file with notepad and simply removing all ">" from it. Then it should load up in sim again without any problems.

Thank You Ben!  Did a notepad Find/Replace to substitute "K:" instead of every instance of ">K:" in the old profile.  That profile now loads almost without issue.  The "almost" is because v2.1 still flags that two LVARS for the A2A Cessna, "L:Eng1_GeneratorSwitch,bool" and "L:Battery1Switch,bool" don't apply to that aircraft when they are listed in the local variables list for it from A2A.  I imagine that is directly related to your answer on AVars and "bool" earlier on March 24th, so will look to apply the same suggested way to deal with it for now.  

 

Is there then consideration for an enhancement to v2.1 to handle necessary changes to previous profiles on import?  

Link to comment
Share on other sites

  • Aerosoft

We will of course refine the process in the future. I was aware that introducing such mechanic might cause some issues at the first installment.

 

Regarding that two LVars: it is also possible that the 10 second delay for the bridge module before it tries loading a profile for the current aircraft is simply not enough for the panel to initialize all local variables. So...if you are sure that the variables are correctly named and, more importantly, work for your profile, you can just select "Yes" (which will only accept that one variable but continue scanning the rest of that profile), or select "Cancel", which will also accept this and every other variable of the profile without further checks.

  • Like 1
Link to comment
Share on other sites

  • Aerosoft

Looking at "L:Eng1_GeneratorSwitch,bool" and "L:Battery1Switch,bool" again: i am pretty sure they are not correctly named and thus the error is legit. Try removing the ",bool" part of of them ("L:Eng1_GeneratorSwitch" and "L:Battery1Switch") and  and see if the error disappears with that aircraft.

Link to comment
Share on other sites

On 4/15/2021 at 6:56 AM, BenBaron said:

Looking at "L:Eng1_GeneratorSwitch,bool" and "L:Battery1Switch,bool" again: i am pretty sure they are not correctly named and thus the error is legit. Try removing the ",bool" part of of them ("L:Eng1_GeneratorSwitch" and "L:Battery1Switch") and  and see if the error disappears with that aircraft.

You were right Ben!  I removed the "bool" from these entries in the json file in Notepad, and it loads to the A2A Cessna 182 now without error.  I was working originally from the A2A - C182 Skylane Template that Rafael posted/updated here from December.  It has the "bool" included in the Lvar Condition checks for the Master Alt and Battery switch toggle functions.  But that predates V2.1 of the Configurator with the new tests on import.  It matches the Lvars in A2A's published list for the Skylane (in the attached under Switches), so I see where it came from. 

 

For now, older/existing profiles may apparently require some "find/replace" amendments in Notepad around any messages that come up.  Not hard to do and afterward it works great.

 

Glad not to have the extra clicks now on each load of the aircraft.  Thanks for your help Ben!  Appreciate it.  

A2A C182 Skylane - Variable list.pdf

Link to comment
Share on other sites

  • Aerosoft

Thanks for letting me know...most of the time LVars don't have a unit as part of the actual name in sim...and things can get confusing. That is also why I decided to remove the unit field alltogether. Once there is some time I will look through the existing profiles and try to find issues like this.

 

Glad it is working now for you, anyways.

 

Also the ">" as part of the name should be fixed in 2.2 and thus be recognized again.

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
 Share

×
×
  • Create New...