• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

Nav light replacement for FSX

Messages
160
FSX equivalent?

Trying to redo some of my FS9 AI coding for FSX.
Been told FSX no longer turns on the Nav lights 15 prior to departure!

A lot of my AI FS9 visibility code is based on the Nav light.
Had a look at the SDK and nothing seems to jump out as a suitable replacement.

Tried the FSX (A:TRAFFIC STATE,string) variable - doesn't seem to work for AI!
for eg.

<Code>
(A:TRAFFIC STATE,string) 'taxi out' scmp 0 ==
if{ 1 } els{ 0 }
</Code>

So what can I use in place of the LIGHT NAV variable to get the 15 mins before departure for an AI aircraft in FSX?

Cheers
 
According to the SDK, there is a variable (A:AI TRAFFIC STATE, string), and one valid value is 'taxi out'. Try that?
 
@Milton - Wouldn't be any good, I need a way of checking if it becomes active, LIGHT NAV was great for this in FS9.

@Tom - Doesn't appear the AI TRAFFIC STATE variables work for AI aircraft (go figure)

<Code>
(A:AI TRAFFIC STATE,string) 'taxi out' scmp 0 ==
if{ 1 } els{ 0 }
< /Code>

Produces zilch, nothing,nada, when used in a visibility block of code.
 
AI TRAFFIC ETD Estimated time of departure for the current schedule entry, given as the number of seconds difference from the current simulation time. This can be negative if ETD is earlier than the current simulation time. See Note 2. Seconds

note 2 These variables only make sense for aircraft generated by the traffic database, and so have schedules. If an aircraft does not have a schedule, the value returned will be 0 (or false), or an empty string, depending on the units.
 
Hi Folks

WeeScotty -
? MAIW coming to the darkside ?
Looking forward to it.

Caveat -
Apologies in advance for any 'sucking eggs' aspects.
Don't know much about the gauge side of things,
only replying as I'd recently been playing with similar in 'MS Flight',
and previous with ODG AI choppers.



There's 2 aspects you might have to address.

The code you are using to -
- Detect the event occuring.
- Indicate that the event has been detected.

It may be that the detection method is working,
but your indication method might not be FSX compatible.



Try test detecting something more obvious.
i.e. Any event for which FSX gives direct visual confirmation.
e.g. For a prop plane, engine combustion will show turning props

Use that test to check against whether your own indication method is working.

Once confirmed your own indication method is functioning correctly,
then substitute your 'AI TRAFFIC STATE' test.

Rather than 'taxi out',
I'd expect 'flt plan' or 'startup'
to be the types of 'AI TRAFFIC STATE' you are looking for.

N.B.
These particular 'AI TRAFFIC STATE's
are only available from ATC controlled simobjects,(traffic.bgl),
but are not available from an injected AI simobject.



You can confirm your aircraft's current 'AI TRAFFIC STATE' by -
- Observing the simobject in either 'Traffic Explorer', or 'Traffic Map'
- Listening to the simobject/ATC comms.


SDK Info -
Simulation Variables - AI TRAFFIC STATE

If the object is an aircraft under ATC control the string will be one of:

"init"
"sleep"
"flt plan"
"startup"
"preflight support"
"clearance"
"push back 1"
"push back 2"
"pre taxi out"
"taxi out"
"takeoff 1"
"takeoff 2"
"T&G depart"
"enroute"
"pattern"
"landing"
"rollout"
"go around"
"taxi in"
"shutdown"
"postflight support"

If an aircraft does not have a flight plan,
the value returned will be 0 (or false),
or an empty string, depending on the units.


If the AI object is not an aircraft under ATC control, the string is one of:
"Sleep"
"Waypoint"
"Takeoff"
"Landing"
"Taxi"


HTH
ATB
Paul
 
@Tom - Yup its a real PITA
@mgh -
Will try using

<Code>
(A:AI TRAFFIC ETD,seconds) -600 &gt;
if{ 1 } els{ 0 }
</Code>

@BASys -
It's something I am considering, although if I can't find a trigger to use instead of the nav light most of my XML won't work correctly.

Another major issue is that G:Vars don't seem to initialise at 0 when aircraft are compiled using xtomdl.
Although I am going to see if the P3D xtomdl makes a difference.

AI TRAFFIC STATE - I don't think are available for use by AI aircraft (thanks Microsoft!).

<Code>
(A:AI TRAFFIC STATE,string) 'preflight support' scmp 0 ==
if{ 1 } els{ 0 }
</Code>

Doesn't work, in fact all of the available 1st block of conditions don't produce anything.

All that's left if the 2nd block of 4, maybe an inactive aircraft is classed as not being under ATC control.
<Code>
(A:AI TRAFFIC STATE,string) 'Sleep' scmp 0 ==
if{ 1 } els{ 0 }
</Code>
 
G:vars do not work at all outside of the single gauge in which they are invoked. They are not "global" in scope, but are strictly "local". They are also completely ignored in any modeldef.xml scripts.

Use only (L:var,unit) types for custom variables during your experimentation!
 
Update.....

Looks like NONE of the variables beginning with AI are recognised by AI aircraft :-(

@ngix -
Will try L:Vars, but never been able to get them to work with AI aircraft.
<Code>
(L:FSXTEST,number) 0 ==
if{ 1 } els{ 0 }
</Code>


G:Vars - Can be used in the modeldef, its just that for some reason they don't work the same way as G:Vars for FS9

For eg
Pointless coding as you can do easier, but just to demonstrate
<Code>
(G:Var1) 0 == if{ (A:LIGHT BEACON,bool) if{ 1 (&gt;G:Var1) 0 } els{ 0 (&gt;G:Var1) 0 } }
(G:Var1) 1 == if{ 1 }
</Code>
Works for FS9 aircraft in FS9 and FSX, but not aircraft compiled with xtomdl for FSX.

However, changing it to
<Code>
(G:Var1) 1 == if{ 1 }
(G:Var1) 1 != if{ (A:LIGHT BEACON,bool) if{ 1 (&gt;G:Var1) 0 } els{ 0 (&gt;G:Var1) 0 } }
</Code>
Will work for aircraft compiled with xtomdl for FSX

In both cases the only way to get a 1 (visible) returned is if (G:Var1) = 1, and the only way for this to happen is by the other line of code assigning 1 to (G:var1).
As the assignment { 1 (&gt;G:Var1) 0 } also returns 0 (not visible), it has to be the (G:Var1) 1 == if{ 1 } line that is triggering the visible condition.

So G:Vars have to be working, its just the initial value that seems NOT to be 0 with xtomdl compiled aircraft.

Oh, and you can't use the P3D xtomdl to work, you get an error 'failure due to an invalid compiler'.
unless there is a way to disable the compiler version check?

Looks like FSX may be a bust for me.
 
Last edited:
So G:Vars have to be working, its just the initial value that seems NOT to be 0 with xtomdl compiled aircraft.

Oh, and you can't use the P3D xtomdl to work, you get an error 'failure due to an invalid compiler'.
unless there is a way to disable the compiler version check?

Looks like FSX may be a bust for me.
I suppose I should add some clarification to my comment regarding (G:vars). Yes, they will "work" if all reference to them is in the same <Code> section. However, as you remarked, that is essentially useless... :rolleyes:

You can export from Max using any of the SDK's (FSX, P3Dv1.x, or P3Dv2.x), but...

You must use the FSX XToMDL.exe to compile the .x and .xanim files for use in FSX or P3Dv1.x or v2.x

You must use the P3Dv2.x XToMDL.exe to compile the .x and .xanim files for use in P3Dv2.x

L-M has changed the header information in the compiled .mdl file(s) to make them P3D only.
 
@n4gix - Ah, got ya.

Still leaves with two problems....

1) What to use instead of LIGHT NAV for a 15 min or so prior to pushback/startup
2) G:Vars and xtomdl

I supposed if I had a way of monitoring an AI aircraft in FSX and seeing what variables are being triggered I could get an answer to 1. But honestly I have NO idea how to do that!

As for the G:vars -
0 &lt; - produces nothing
0 &gt; - produces nothing
0 == - produces nothing

So can only imagine its a null on initialisation?

Would I use
(G:Var1) '' scmp 0 ==
or
(G:Var1) '' ==

To test for a null?
 
What is your fixation on (G:Vars) anyway? Why not use (L:Var,unit) as suggested?
 
Tried L:Var both in FS9 and FSX.
Don't work with AI aircraft.

Eg pseudo code

(A:LIGHT BEACON,bool)
if{ 1 (&gt;L:TESTVIZ,number) (L:TESTVIZ,number) } els{ 0 }


If when the beacon is on you assign 1 to an L:Var and return the value of the L:Var the part will not become visible.

Tried various times with L:Vars.
Taken a good working piece of code with a G:Var, substituted it with an L:Var and got nothing.

The example isn't the way I would normally do this, it is just to show they don't work with AI aircraft.
 
Last edited:
UPDATE ---

Either something weird is going on with G:Vars in FSX or my mate has a problem when he is compiling.....
Using a brand spanking new modeldef file...

Adding -
<PartInfo>
<Name>VIZ_TEST</Name>
<Visibility>
<Parameter>
<Code>
(G:Var9) 1 == if { 1 }
(G:Var9) 1 != if{ (A:LIGHT BEACON,bool) (&gt;G:Var9) 0 }
</Code>
</Parameter>
</Visibility>
</PartInfo>

Works as you would expect.
Once the beacon comes on, the part becomes visible on that AI aircraft only.

Add some more code to the modeldef....
<PartInfo>
<Name>Canopy_AI</Name>
<AnimLength>100</AnimLength>
<Animation>
<Parameter>
<Code>(A:LIGHT BEACON,bool) ! if{ 100 } els{ 0 }</Code>
<Lag>20</Lag>
</Parameter>
</Animation>
</PartInfo>

The previous code block seems to become GLOBAL.
I.e. Every aircraft using that G:Var has the part become visible, irrespective of whether the beacon is on or not.

Bill - How did you get L:Vars to work with AI aircraft?
 
Honestly, I'm not at all sure I ever did get L:Vars to work with AI, for the simple reason I don't do AI on a regular basis. The most I've ever done is convert a few flyable models to AI aircraft, and that was with some program I've long ago forgotten about. All I remember is that it would take a "flyable model" as input, and spit out a complete AI package, headed with the name GA-AI, such as
GA-AI Eaglesoft Diamond TwinStar
 
L: vars don't work for AI.


Btw:
Install the traffic monitoring thingy from the FSX SDK. It might help figuring out some AI aircraft states.

"Sleep" is a pretty popular state for AI aircraft, so you could try assigning nav light visibility to the aircraft when it's NOT sleeping.
 
@bill - Thanks

@Heretic - The SDK lists the states, but they seem to be unavailable for use by actual AI aircraft. Running out of options here :( .
Can't find anything that I can use to replace A:LIGHT NAV to get the same behaviour in FSX.

Add to that the G:Var issue it is looking like I will be sticking with creating FS9 AI Aircraft.
As I said aircraft compiled for FS9 in FSX show none of the G:Var problems that FSX compiled aircraft exhibit. So it is reasonable to suspect the xtomdl compiler.
 
Last edited:
FS9 compliant models use an alternate set of instructions in the sim. That is, they are 'interpreted' by the sim using the FS8/9 "name-based" code.

FSX compliant models use the new instructions, which rely on the relevant actions being compiled into the model file.
 
So are we saying there is a problem with the FSX instructions then?
In which case there is no way around the G:Var issues apart from using FS9 aircraft (using G:Vars) in FSX?

We have had some weird results...
Single LOD model -
a) Part with G:Var visibility code will appear and disappear while zooming in and out.
b) Linking the part to a parent will make it appear or disappear (same G:Var code).
 
Back
Top