Auto door lock

[Ormoc44]

Looking to create a gauge to prevent opening the two main doors while in flight or greater than 70 knots on the ground.

Tried this which will shut the door in flight once the door is fully open, but would like to keep it from opening at all.

<Element>
<Select>
<Value>
(A:SIM ON GROUND, bool) ! (A:AIRSPEED TRUE, knots) 70 &gt; (A:EXIT OPEN:0,percent) 99 &gt; and and if{ 1 (&gt;K:TOGGLE_AIRCRAFT_EXIT) (&gt;K:SELECT_0)}
</Value>
</Select>
</Element>

Any good ideas or edits would be appreciated, thanks!

 

[spokes2112]

Perhaps?

<Element>
    <Select>
        <Value>
            (A:SIM ON GROUND, bool) ! (A:AIRSPEED TRUE, knots) 70 &gt; || (A:EXIT OPEN:0, percent) 0.01 &gt; (L:Logic_Latch, bool) ! and and if{ 1 (&gt;K:TOGGLE_AIRCRAFT_EXIT) (&gt;K:SELECT_0)  1 (&gt;L:Logic_Latch, bool) } els{ (A:EXIT OPEN:0, percent) 0 == if{ 0 (&gt;L:Logic_Latch, bool) } }
        </Value>
    </Select>
</Element>

 

[Ormoc44]

Roman, think this is very close to working Roman.

When using the "...0.01 &gt" (or other small percentage number) the door jitters. Starts to close then tries to open again.

If using 99&gt once the door is fully open it will close. But it is still possible to reopen in flight.
So the smaller percentage would make sense but don't know why it is jittering.

 

[Anthony31]

When you say "jitters" do you mean it constantly jitters or only for a short time?

I tested Roman's code and the door opened about 31% before closing so it's not a particularly useful method. I think this is just due to the delay FSX has when processing aircraft exit commands and there is nothing wrong with Roman's code. It's just not the ideal method to use. The best option is to use simconnect to capture any door opening commands and discard them if necessary.

However, if you want to stay with XML you can try hiding the jitter by only having the door start animating after the 30th-40th keyframe has passed. It will, however, delay the door opening even longer.

 

[Heretic]

When using the "...0.01 &gt" (or other small percentage number) the door jitters. Starts to close then tries to open again.

The simulation engine runs at 36 Hz (or more or less), while 2D panel gauges run at a maximum of 18 Hz. So, with these values, you'd get two commands from the sim engine for a single one from the 2D gauge, which produces the jittering. For FS9, there is nothing you can do about this. In FSX, with XMLTools, you can at least set the door variable to a fixed value to minimize the jittering.

 

[Luka]

I think Roman's code is pretty good. Visual problems can be avoided by modifying the animation code in modeldef.xml/MakeMDL.parts.xml:

<code>(A:SIM ON GROUND, bool) ! (A:AIRSPEED TRUE, knots) 70 > || if{ 0 } els{ (A:EXIT OPEN:0, percent) }</code>

 

[Ormoc44]

When you say "jitters" do you mean it constantly jitters or only for a short time?

I tested Roman's code and the door opened about 31% before closing so it's not a particularly useful method. I think this is just due to the delay FSX has when processing aircraft exit commands and there is nothing wrong with Roman's code. It's just not the ideal method to use. The best option is to use simconnect to capture any door opening commands and discard them if necessary.

However, if you want to stay with XML you can try hiding the jitter by only having the door start animating after the 30th-40th keyframe has passed. It will, however, delay the door opening even longer.

Thanks Anthony, yes it constantly jitters and never closes unless I set the value to virtually fully open.

Not familiar with how Sim Connect works. With the door start animating 30th-40th keyframe, where would you adjust this value?

Is it the Exit_rate in the aircraft.cfg?

 

[Ormoc44]

I think Roman's code is pretty good. Visual problems can be avoided by modifying the animation code in modeldef.xml/MakeMDL.parts.xml:

<code>(A:SIM ON GROUND, bool) ! (A:AIRSPEED TRUE, knots) 70 > || if{ 0 } els{ (A:EXIT OPEN:0, percent) }</code>

Yes, thanks for the code and all these great ideas and advice. Wouldn't have a clue otherwise.

Where could the MakeMDL.parts.xml be found?
Have located the Modeldef.xml in the SDK. Found these lines for a door or canopy, but not sure that is what you're referring to:

<PartInfo>
<Name>f_canopy</Name>
<AnimLength>100</AnimLength>
<Animation>
<Parameter>
<Sim>
<Variable>EXIT OPEN:0</Variable>
<Units>percent</Units>
</Sim>
</Parameter>
</Animation>
</PartInfo>

 

[rcbarend]

When using the "...0.01 &gt" (or other small percentage number) the door jitters. Starts to close then tries to open again.

What you are most probably doing, is applying the "....0.01 &gt;" in your own code from post#1 (replacing the "....99 &gt;" ) Right ??
Because that explains fully what you observe.

Instead, use Roman's full code in post#2 ; exactly that code, just copy/paste it to avoid errors like missing space characters, like in your original code between "(&gt;(K:SELECT_0)" and "}"
The usage of the Lvar (L:Logic_Latch, bool) is there for a reason ...LoL

I tried it in FSX, and it works perfect.
That is: no jittering of the door, and the door is fully closed again (when it starts to open) within 50-100 msec.

Rob

PS: Of course you can also change the animation code in the visual model (as suggested, which is even better), but then you have to re-compile the whole model.

 

[spokes2112]

One thing to remember is that the door speed can be adjusted in the aircraft.cfg -
in my test aircraft, the Baron 58:
[exits]
number_of_exits = 1
exit_rate.0 = 0.4 ;Percent per second
My test in this aircraft showed no ill effects except a very slight opening, like if the passenger was trying to force the door open with their elbow.
Changing the exit rate above (for a test only) to 0.1 gave me excellent results, but now the door opens very slow during normal operations.
I completely agree with all the posts above, the best way is in the model code, followed by XMLTools. A pure XML gauge will only act as an incomplete solution.

Spent the last 3 hours with the morning coffee trying to get XMLTools make this work better..
After about 20 different iterations of code, monitoring via FSUIPC non axis events and a lua to monitor L:Var latches it was found that even in the best iteration it worked worse than the XML gauge method..
One thing very strange -
When the command for TOGGLE_AIRCRAFT_EXIT is given, FSX-A automatically applies 2 same events simultaneously acting like a "lock out" perhaps? : ATC_MENU_CLOSE
Another thing i assume thru testing is happening - FS will not accept another TOGGLE_AIRCRAFT_EXIT command until the door movement subroutine has either started or finished. Trapping TOGGLE_AIRCRAFT_EXIT via xml tools and then immediately performing another TOGGLE_AIRCRAFT_EXIT (logic lockouts used to prevent endless looping) within the trap does nothing.

Model code / Modeldef mods... Hmmm, this could get complicated too.

<code>(A:SIM ON GROUND, bool) ! (A:AIRSPEED TRUE, knots) 70 > || if{ 0 } els{ (A:EXIT OPEN:0, percent) }</code>

What would happen when a TOGGLE_AIRCRAFT_EXIT is performed in the air? Of course, door will not open. But when you land or get under 70kts guess what? The door will automatically open unless some other background checks are made. Such as a combo of my original XML gauge & the modeldef mods too.

 

[rcbarend]

What would happen when a TOGGLE_AIRCRAFT_EXIT is performed in the air, of course, door will not open. But when you land & get under 70kts guess what? The door will automatically open unless some other background checks are made. Such as a combo of my original XML gauge & the modeldef mods too.

Exactly right …...
The event TOGGLE_AIRCRAFT_EXIT probably is the weardest and most complex event implementation in the history of FS*, which all its variants in usage now and it's built-in delay-of-execution.
Like:
- " (&gt;K:TOGGLE_AIRCRAFT_EXIT) "; toggles only the first exit (EXIT:0), after a 0.7 sec. or so delay.
- " (&gt;K:TOGGLE_AIRCRAFT_EXIT) (&gt;K:SELECT_0) " ; has the same result, same delay.
- " (&gt;K:TOGGLE_AIRCRAFT_EXIT) (&gt;K:SELECT_1) "; toggle the second exit (EXIT:1), same delay.
- " (&gt;K:TOGGLE_AIRCRAFT_EXIT) (&gt;K:SELECT_0) (&gt;K:SELECT_1) "; toggles first and the second exit, but still the same delay.
- " 1 (&gt;K:TOGGLE_AIRCRAFT_EXIT) "; toggles the first exit (EXIT:0), NO delayed execution.
- " 2 (&gt;K:TOGGLE_AIRCRAFT_EXIT) "; toggles the second exit (EXIT:1), NO delayed execution.
etc etc. for the other Exits.
Also, just forcing the Exit state A:EXIT OPEN:0 via SimConnect to 0 (eg. from XML, using SIMVARS in XMLTools) doesn't work either: the moment you stop overwriting A:EXIT OPEN:0, the Avar will be increasing/decreasing to fully open/closed again, depending on the last detected ToggleExit event for that Exit. Apperantly FS maintains internal states for this, for each Exit.
Meaning that, like with the animation code solution, you still need additional code issuing ToggleExit events to force this internal state to the desired position (open/closed).

Hence the charm of your code in post#2: extremely simple, if one accepts the (almost invisible, depending on the specified ExitRate in the aircraft.cfg) short opening/closing of the door after a user ToggleExit command.

With the added advantage that it works independantly for all Exits; I personally wouldn't even start thinking about the complexity to maintain this independancy, by using an event-capturing method, to make it fool-proof.
Given all variations of possible event sequences for this ToggleAircraftExit event.

Cheers,
Rob

 

[Luka]

Yes, thanks for the code and all these great ideas and advice. Wouldn't have a clue otherwise.

Where could the MakeMDL.parts.xml be found?
Have located the Modeldef.xml in the SDK. Found these lines for a door or canopy, but not sure that is what you're referring to:

<PartInfo>
<Name>f_canopy</Name>
<AnimLength>100</AnimLength>
<Animation>
<Parameter>
<Sim>
<Variable>EXIT OPEN:0</Variable>
<Units>percent</Units>
</Sim>
</Parameter>
</Animation>
</PartInfo>

MakeMDL.parts.xml is for FS9.
In Modeldef.xml (FSX, P3D) code should be:

<PartInfo>
    <Name>f_canopy</Name>
    <Animation>
        <Parameter>
          <Code>
            (A:SIM ON GROUND, bool) ! (A:AIRSPEED TRUE, knots) 70 > || if{ 0 } els{ (A:EXIT OPEN:0, percent) }
          </Code>
        </Parameter>
    </Animation>
</PartInfo>

<code>(A:SIM ON GROUND, bool) ! (A:AIRSPEED TRUE, knots) 70 > || if{ 0 } els{ (A:EXIT OPEN:0, percent) }</code>

What would happen when a TOGGLE_AIRCRAFT_EXIT is performed in the air?

Your code from post #2 will close the door.
The additional code I suggested only blocks unwanted animation on the visual model during this time.

 

[spokes2112]

The event TOGGLE_AIRCRAFT_EXIT probably is the weardest and most complex event implementation in the history of FS*, which all its variants in usage now and it's built-in delay-of-execution.

Microsoft owes me hair implants now! Nearly pulled it all out on this one.
Rob,
Thanks for the extensive testing! It makes complete sense.
Almost all K: commands have a "listening" period for a subsequent value unless already given during the command. ( if command value is null then wait )
Perhaps this could be a workaround for constant firing of commands in some sense, although proper programming to first check values is better .

 

[Ormoc44]

What you are most probably doing, is applying the "....0.01 &gt;" in your own code from post#1 (replacing the "....99 &gt;" ) Right ??
Because that explains fully what you observe.

Instead, use Roman's full code in post#2 ; exactly that code, just copy/paste it to avoid errors like missing space characters, like in your original code between "(&gt;(K:SELECT_0)" and "}"
The usage of the Lvar (L:Logic_Latch, bool) is there for a reason ...LoL

I tried it in FSX, and it works perfect.
That is: no jittering of the door, and the door is fully closed again (when it starts to open) within 50-100 msec.

Rob

PS: Of course you can also change the animation code in the visual model (as suggested, which is even better), but then you have to re-compile the whole model.

Yes, copied Roman's code but was still getting the jittering.

Remember at the time his code worked better than mine because the door on my version would not auto close at 70knots, but his did. After getting the jittering again, then tried the 99&gt which would not jitter but the door would have to fully open.

Was beginning to think it may have something to do with the model itself or some other possible issue as noted here.

However, this was good advice to retry the code. Looked through the code I copied. Turns out there was a "}" at the end which did not get copied over, as I only highlighted the value section and missed this.

This time copied from the Element to the Element section and retried it.

You are right. Works great now!

Sorry for any trouble - or any lost hair!

Thanks for all the help Roman and for everyone's great input!

 

[rcbarend]

Ok, glad you solved it and are happy with it.
And Yes, simple syntax errors (like missing spaces or } characters) will spoil things ...LoL

Rob