So is there any possibility to control the simobject's visibility within the aircraft?
-
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.
MSFS20 Visibility
- Thread starter Christian Bahr
- Start date
So is there any possibility to control the simobject's visibility within the aircraft?
For background about what I'm writing see variable types here.
A static simobject's query a variable only seems to be working for environment variables (E:*) and a limited number of local variables (L:*).
L:XMLVAR_YokeHidden1 as mentioned before works fine but I haven't been able to find local variables that work as nicely.
A: variables like A:LIGHT LANDING do not seem to have any effect at all, which leads me to the conclusion that static simobjects simply don't read them.
Environment/weather (E.*) variables listed here work (but none of them are useful for opening gates...)
Which makes it impossible to control them directly via an aircraft variable from inside the cockpit (with the Yoke being a rare exception bot not being a feasible solution because not all aircraft have a yoke you can activate/deactivate).
Of course I would be more than happy if someone could proof me wrong.
Last edited:
...but they can only be called using A:*
I now ended up using one of the seemingly few variables left that a user can call from the cockpit with every aircraft, not causing major changes to weather like wind direction/speed, rain/snow...
(A:SEA LEVEL PRESSURE, hectopascal) 1020 >= if{ 400 } els{ 0 }
Haha... very strange indeed, but obviously not very practical. I will try to dig more and see if there is any working aircraft variable. Hopefully there is a way to use NAV2 freq as a trigger....but they can only be called using A:*
I now ended up using one of the seemingly few variables left that a user can call from the cockpit with every aircraft, not causing major changes to weather like wind direction/speed, rain/snow...
(A:SEA LEVEL PRESSURE, hectopascal) 1020 >= if{ 400 } els{ 0 }
- Messages
- 6,233
- Country
(A:SEA LEVEL PRESSURE, hectopascal) 1020 >= if{ 400 } els{ 0 } is reading the pressure on the simobject, not on the aircraft.
Correct. But the weather can be changed from inside the cockpit and the pressure slider is an easy one the user can pull up and down to open a gate.
But I agree this solution is far from being perfect!
In my case I am looking to turn on runway lights by user demand so changing pressure before landing can be a bit dangerous haha
OK, some good news. Managed to get it working by using the L:LIGHTING_LANDING variable with the following code:
Watch the video in the rar file
[/U]
<?xml version="1.0" encoding="utf-8"?>
<ModelInfo guid="{f6f1120f-e2fe-461f-9c6e-6b3c27d5404a}" version="1.1">
<LODS>
<LOD MinSize="0" ModelFile="ColemanLanternXPDR.gltf"/>
</LODS>
<Behaviors>
<Component ID="ColemanXPDR" Node="node0">
<Visibility>
<Parameter>
<Code>(L:LIGHTING_LANDING_1,Bool) 1 == if{ 1 } els{ 0 }</Code>
</Parameter>
</Visibility>
</Component>
</Behaviors>
</ModelInfo>
[U]Watch the video in the rar file
- Messages
- 6,233
- Country
The landing light switch also can control animation. Good find!
LandingLightHangar.zip
LandingLightHangar.zip
Good find but unfortunately not an universal solution for our problem. L:* are local variables that do only work with aircraft that have them (similarly to the Yoke discussed earlier).
L:LIGHTING_LANDING works with the default King Air 350 (that has it mentioned as B:LIGHTING_LANDING in its Library.xml - which begs the question why it's B.* there...).
But it does not work with the default TBM930 for example, which seems to use another local variable for the same purpose. Of course we could go ahead and check for all the local variables we can find for landing lights. But there will always be aircraft using a different local variable for them. The only variables we can use that are universal seem to the the weather environment ones sadly (and I agree that a hectopascal setting isn't something you want to play around with when in the air...
)There is an index that has to be used with the variable, therefore it is possible to have several lighting system coded into the aircraft. For the default C152, for example, the NAV lights are indexed as 1 and for the default G1000 172 it is indexed as 0.Good find but unfortunately not an universal solution for our problem. L:* are local variables that do only work with aircraft that have them (similarly to the Yoke discussed earlier).
L:LIGHTING_LANDING works with the default King Air 350 (that has it mentioned as B:LIGHTING_LANDING in its Library.xml - which begs the question why it's B.* there...).
But it does not work with the default TBM930 for example, which seems to use another local variable for the same purpose. Of course we could go ahead and check for all the local variables we can find for landing lights. But there will always be aircraft using a different local variable for them. The only variables we can use that are universal seem to the the weather environment ones sadly (and I agree that a hectopascal setting isn't something you want to play around with when in the air...
Therefore I am using an "OR" statement to overcome this:
(L:LIGHTING_NAV_1,Bool) 1 or (L:LIGHTING_NAV_0,Bool) == if{ 1 } els{ 0 }
Tried that and another version.
(L:LIGHTING_NAV_1,Bool) 1 == OR (L:LIGHTING_NAV_0,Bool) 1 == if{ 400 } els{ 0 }
Neither of them works with with any aircraft. Not entirely sure about the correct syntax of an "OR" condition though...
Try if{ 1 } instead of if{ 400 }
Anyway, I tried to create my own lighting system. The problem is, the SimObjects dissappear at a specific distance from the camera. I tried to set
DistanceToNotAnimate to 10000 meters in sim.cfg file so the light will be visible 10km out but it seems like MSFS igonres it.
DistanceToNotAnimate to 10000 meters in sim.cfg file so the light will be visible 10km out but it seems like MSFS igonres it.
That is due to the LOD management meaning because of the size of the object, the sim assumes it is not small to be displayed.
Yeah, I figured it out. I think indeed the object is too small so I am going to draw a transparent rectangle in the bottom and see of it works for longer distances
As I understood it from @rhumbaflappy 's example, the 400 (or any other matching number depending on the model) is the number of animation frames required for opening/closing the gate in this case. When I set this to 1, only the first frame will be played, so essentially nothing happens.
Yes, but keep in mind: With various LODs each of them needs to have the same rectangle for MSFS to respect the new size. It's not sufficient to have it in only one of the LODs.
I am creating LODs with MCX so its all automated. Hopefully that would work.