SODE 1.7.1 Environment Probe Not Working in v5.1

[downscc 1,327]

I discovered that the environmental probe that is a part of SODE and used by developers to trigger events does not appear to work in P3dv5.1.  At LatinVFR KMSY New Orleans that developer uses the environmental probe to turn on runway lights at night or low visibility as well as control windsocks and terrain features.  None of that stuff is working.  I commented out ( with <!-- comment marks -->) the environmental probe and lighting conditional test entries and now the lights remain on all the time.  That is better than always off.

[Patco Lch 1,482]

Had the same experience a couple hours ago landing my 747-8F at LVFR KMIA. Had taxi way and turn off lights but no runway lights. 

[pmemery 4]

I'll make a test today and report.

Did you send a note to the developper on SODE site ?  

[mpo910 2,112]

Yes, indeed. Please send Jeffrey, aka 12Bpilot, a note about this incl. the steps to reproduce the issue.

He is in contact with LM about a defect within simconnect which in this case did cause some ucrtbase.dll issues based on SODE Jetways and also AI Traffic.

So, maybe during this "defect" also this, you guys reported, is affected.

As LM is working on this, it would be good if they know the whole "circumstances" regarding this.

Do you please post him at SODE Support? 

@12bPilot: Just to get you in the loop in that case you are around here "sniffling" 😉

Marcus

[Wolkenschreck 270]

Nothing wrong with SODE here. The scenery or better the xml needs to be updated. Starting with 1.70, the later versions of SODE require that the data probe elevation is set to the correct #AGL. The EnvironmentalDataProbe should read something like Alt="3.999" for KMSY (you can read out the AGL value in the AFCAD of the scenery).
 

[pmemery 4]

Ok so I did couple tests using the latest release of SODE. On the tested airport both windsock and PAPI was using SODE and I did not notice any issue here.

[downscc 1,327]

9 hours ago, Wolkenschreck said:

Nothing wrong with SODE here. The scenery or better the xml needs to be updated. Starting with 1.70, the later versions of SODE require that the data probe elevation is set to the correct #AGL. The EnvironmentalDataProbe should read something like Alt="3.999" for KMSY (you can read out the AGL value in the AFCAD of the scenery).
 

According to ADEv1.79, the AF file for LatinVFR KMSY already is correctly set to 3.999 ft.  But, I think you are saying the LatinVFR provided placement xml for SODE needs to reflect the correct AGL value... yes?  In fact, their xml file placement for the EnvironmentalDataProbe is Alt="0#AGL."

Ok, will change that key to the value "3.999#AGL" and see if that gets the conditionals working again (this is the reason I commented out stuff and not delete anything).  Thanks!

Edited November 10, 2020 by downscc

[Wolkenschreck 270]

Yes, that's correct Dan. The value in the xml needs to be changed, while AFCAD is only used to get the AGL. But for the value do not insert the word AGL. It has do lock this way:
        <Placement Lat="51.42173007" Lon="12.23648026" Alt="141.732" Hdg="355.7"/>

This in only an example from Leipzig, as I do not own KMSY. But it should give you an idea about the formatting. And only the EDP needs to be changed. All other SimObjects in the xml can keep their AGL entries. 

Edited November 10, 2020 by Wolkenschreck

[downscc 1,327]

6 minutes ago, Wolkenschreck said:

Yes, that's correct Dan. The value in the xml needs to be changed, while AFCAD is only used to get the AGL. But for the value do not insert the word AGL. It has do lock this way:
        <Placement Lat="51.42173007" Lon="12.23648026" Alt="141.732" Hdg="355.7"/>

This in only an example from Leipzig, as I do not own KMSY. But it should give you an idea about the formatting. And only the EDP needs to be changed. All other SimObjects in the xml can keep their AGL entries. 

Thank you sir for the quick reply.... I didn't fully understand the "3.999#AGL" value, it looked strange LOL.  It also didn't work.

Will run with the numeric value ("3.999") instead of the wonky one.

................  Yup! That works.  Many thanks again.