[FS2004] Needed XML code script for an AI canopy cover

[mile high]

Hi friends,

I'm trying to place a canopy cover on my freeware FS2004 AI aircraft model that I developed in FSDS 3.5.1 but I only wish to have the canvas cover over the canopy glass at night.
I have tried several xml codes but nothing so far seems to work for me, can any of the xml guru's that understand this stuff help me out please.

Can anybody see where this script may be incorrect!

Thanks,

<part>
<name>YOURPARTNAME</name>
<visible_in_range>
<parameter>
<code>(A:TIME OF DAY, enum)</code>
</parameter>
<minvalue>2</minvalue>
<maxvalue>3</maxvalue>
</visible_in_range>
</part>

[delivery guy]

you need to specify one of the 3 choices.

General time of day:
1 = Day
2 = Dusk/Dawn
3 = Night

<code>(A:TIME OF DAY:3, enum)</code>

or

<code> 3 (A:TIME OF DAY, enum)</code>

Try this

[tgibson]

Actually his code is correct. You do not put the value as an index (:3). What's probably wrong is it should be E:, not A:. It is an Environment variable, not an Aircraft variable.

Hope this helps,

[n4gix]

<part>
     <name>YOURPARTNAME</name>
     <visible_in_range>
          <parameter>
               <code>(E:TIME OF DAY, enum)</code>
          </parameter>
          <minvalue>2</minvalue>
          <maxvalue>3</maxvalue>
     </visible_in_range>
</part>

[mile high]

Thanks guy's for the reply and confirmations, the "e" made all the difference and is working a treat. A bunch of new freeware AI models will be using this code to delight fellow simmers.

Cheer's,

Mark

[Here for the Beer]

Just noticed this while looking for ideas about canopies masking out aircraft parts for no good reason.

I know this is a late response, but is a canopy by time of day a good idea? What if the AI flight plan gets the aircraft airborne at a time when the canopy is still there?

I'm still trying to get the crew to vanish when the AI is inactive, and surely the canopy would be better conforming to that idea instead.

[tgibson]

I assumed that this part was linked to other parts that had the proper visibility tags to avoid it being present when the aircraft was flying.

For AI aircraft to display something when inactive, something like this works well:

<part>
  <name>ground_equipment</name> <!-- for AI aircraft -->
  <visible_in_range>
  <parameter>
  <code> (A:LIGHT BEACON, bool) (A:VELOCITY BODY Z, knots) 0 != || </code>
  </parameter>
  <minvalue>-1</minvalue>
  <maxvalue>0</maxvalue>
  </visible_in_range>
  </part>

So inverting the logic of the code line should give you what you want:

<part>
  <name>cockpit_crew</name> <!-- for AI aircraft -->
  <visible_in_range>
  <parameter>
  <code> (A:LIGHT BEACON, bool) ! (A:VELOCITY BODY Z, knots) 0 == &amp;&amp; </code>
  </parameter>
  <minvalue>-1</minvalue>
  <maxvalue>0</maxvalue>
  </visible_in_range>
  </part>

Hope this helps,

[Here for the Beer]

Originally Posted by tgibson

I assumed that this part was linked to other parts that had the proper visibility tags to avoid it being present when the aircraft was flying.

Ah, I'll be getting into that area once I sort out my vanishing flap problem, so I may be able to use an adaptation on that code snippet (using "LIGHT NAV" to unhide the crew, I hope, since nav lights come on when the aircraft comes out of sleep and may be the only way to determine that it is active).

Maybe something like

<part>
<name>cockpit_crew</name> <!-- for AI aircraft -->
<visible_in_range>
<parameter>
<code> (A:LIGHT NAV, bool) ! 0 = &amp;&amp; </code>
</parameter>
<minvalue>-1</minvalue>
<maxvalue>0</maxvalue>
</visible_in_range>
</part>

[tgibson]

True for jets and turboprops, but nav lights for piston aircraft come on when the engine starts (on my computer, anyway), which occurs *after* pushback. So I would have no crew in the plane as it pushes back.

[Here for the Beer]

Originally Posted by tgibson

True for jets and turboprops, but nav lights for piston aircraft come on when the engine starts (on my computer, anyway), which occurs *after* pushback. So I would have no crew in the plane as it pushes back.

Thanks, Tom, I had no idea different types were coded differently WRT the lights, although it makes sense from a real-world PoV, where we GA people only load up the electrics after we're got the ability to generate some power for them that isn't a big battery more useful for engine starts.

First I'll be investigating why nav lights don't show when the a/c operates as AI, since it might affect that phase of development anyway. My job for today...

[Flusirainer]

First I'll be investigating why nav lights don't show when the a/c operates as AI, since it might affect that phase of development anyway. My job for today.

Has AI_Aircraft only one engine, functions not the NAV_Light.


aircraft.cfg (example: Jet)


before

[GeneralEngineData]
engine_type= 1
Engine.0= -18.200, 0.000, 0.800
fuel_flow_scalar= 1.000
min_throttle_limit = -0.2


[jet_engine]
thrust_scalar =1.000


after

[GeneralEngineData]
engine_type= 1
Engine.0= -18.200, 0.000, 0.800
Engine.1= -18.200, 0.000, 0.800
fuel_flow_scalar= 1.000
min_throttle_limit = -0.2


[jet_engine]
thrust_scalar =0.500


And this is the configuration of my AI_MiG-21 UM / AI_MiG-21 US(MakeMDL.parts.xml)



Canopy

<part>
	<name>Kanzel_Haube</name>
	<animation>
		<parameter>
			<code>
                       (E:TIME OF DAY, enum) 1 ==
                        if{
                           (A:LIGHT NAV, percent) 50 &gt; 
                           (A:LIGHT CABIN, percent) 50 &gt; and
                                   if{ 100 } els{ 0 }
                          }
                       els{
                           (A:LIGHT NAV, percent) 50 &gt; 
                           (A:LIGHT BEACON, percent) 50 &lt; and
                           (A:LEFT WHEEL RPM, rpm) -0.001 &gt; and
                                   if{ 100 } els{ 0 }
                          }
                         </code>
                        <lag>25</lag>
		</parameter>
        </animation>
</part>

Pilot

<part>
	<name>Pilot</name>
	<visible_in_range>
		<parameter>
			<code>
                       (E:TIME OF DAY, enum) 3 ==
                        if{
                           (A:LIGHT BEACON, percent) 50 &gt;
                           (A:LEFT WHEEL RPM, rpm) 0 &lt; or
                                  if{ 1 } els{ 0 } 
                          }
                       els{
                           (A:LIGHT NAV, percent) 50 &gt; 
                           (A:LIGHT CABIN, percent) 50 &lt; and
                                  if{ 1 } els{ 0 }
                          } 
                 </code>
		</parameter>
		<minvalue>1</minvalue>
        </visible_in_range>
</part>

The cabin lights switches off 6 seconds before clearance. But only when TIME OF DAY = 1
During other options, it is always turned on.

parking


10 minutes before clearance (NAV_LIGHT on)



taxing

[Here for the Beer]

Wow Rainer, you're a life-saver. I was about to waste days trying to figure out the lights thing and you just gave me those days back to do, well, house decorating in fact... hmm.

I wonder if FS is as full of these idiosyncratic things as it seems - one engine = no nav lights? How counter-intuitive is that? I'd not have figured that one out in a month of Sundays because I try to apply logic to things. I wouldn't even have found that one by my normal searching (in fact I only got back to this post because I did a google search web-wide for a solution and it brought up this thread).

In light of what Tom mentioned (about recip engines vs jets and how they use their lights) I would need to adopt Tom's code or adapt yours, but so long as it does the job to some degree, I'm okay with that. I will still think "around the code" and see whether I can possibly get the pilot showing up sooner, but I'm well aware that there are more informed minds than mine on top of the subject. Many thanks again for such great help.

Edit: I added in another engine entry and the performance is a lot better (it was pretty sluggish in some flight modes), but the nav lights still aren't there even when airborne as AI. I have some more experimenting to do.

[Here for the Beer]

I tried returning the Vans to 1 engine since it should be okay. The nav lights are not working for some reason, but I don't think it is a lack of spare engines. There are other GA planes in my setup that have single engine entries and working lights. In fact I'm considering moving my contact points over to a copy of the default Mooney CFG and working up from there, from scratch.

The removal of the pilots when inactive is failing too, so I'm considering making a cockpit cover that comes off after pushback, or something similarly compromised. I will scour the XML for errors, since I assume an error above the code for the canopy can just as easily stop it from being used.

[Here for the Beer]

Trying out Tom's code for the crew, I can make them vanish when the aircraft is running, but the inverse logic is evidently different. I've done a few experiments around the code and have managed hybrids (visibility responding to lights but not movement etc) but have run out of time now. I'm not a fan of reverse Polish notation at the best of times, but I suspect there's some problem with inverting the conditions and the tests too.

Visible if lights or movement
Invisible if no lights and no movement (not either).

Either that or the visibility range needs to be shifted to reflect the results of the tests. If adding together 2 falses do we end up with -2 (&&) or does the logic say "they are 2 boolean results, therefore the answer is -1 because they're both false, so the overall condition is false".

I spent a day believing that grouped and/or animated items were perhaps immune to these XML operations, which is why I made the canopy - partly to test the theory.

I'd still prefer the crew to vanish (fewer polys to display when inactive - and the crew have a lot of polys for their size), so I'll come back to this later. The nice thing is that by sensible naming of the crew components, at least the same snip of XML can apply to them both.

Ugh. Anyway, have to get the car in to the garage now...they managed to unfix it while they were fixing it yesterday. I think in logic terms that comes out to zero. And it's raining.

Edit: I was on my way out and had a small thought, went back in and tried it out. I'll post the changed stuff later, but suffice to say my changes worked on both crew. If you call teh XML ai_pilot and have your crew as ai_pilot_01 and ai_pilot_02, the same code is good for them both. When I'm away from the computer I just think about the logic and not about experimentation, and I think that makes all the difference. Anyway, to the garage... oh joy.

[Here for the Beer]

<part>
  <name>ai_pilot</name> <!-- for AI aircraft -->
<visible_in_range>
  <parameter>
  <code> (A:LIGHT BEACON, bool) (A:VELOCITY BODY Z, knots) 0 != || </code>
  </parameter>
  <minvalue>1</minvalue>
  <maxvalue>2</maxvalue>
  </visible_in_range>
  </part>

Does the job. I assume body velocity works because a running engine creates vibrations or perhaps a little forward creeping? I'd have thought sampling prop RPM would be better, but the crew seem to flicker momentarily when that value is sampled. I know how they feel.

[n4gix]

Originally Posted by Here for the Beer

Does the job. I assume body velocity works because a running engine creates vibrations or perhaps a little forward creeping? I'd have thought sampling prop RPM would be better, but the crew seem to flicker momentarily when that value is sampled. I know how they feel.

That variable need only be 0.0000000000000001 for it to return as "true" (1)...

...prop rpm is much less precise.

[Here for the Beer]

So the people flicker because the passenger is nervous, got it.

The bind with the prop RPM is that at least for AI, it just means the prop is stopped instantaneously - going by the value. I'd been hoping that by adding a little prop inertia in the FDE, I could have the crew there for a few moments longer and have them disappear definitively once the prop had spun down, but prop spinning and not spinning is an instantaneous binary state for the sim, more's the pity, and there's nothing more wrong-looking than an empty aircraft with a spinning prop!

Still, it works better than it did this time yesterday, so I'm grateful for that. Just a shame our car doesn't...

[tgibson]

Hi,

My original code wouldn't work because of a missing equals sign. I've now added it.