FS2004 <Update> - some entries are ignored

[tedcook]

I need to set the Fuel Selectors of a 4 engined aircraft, 1&3 to the Left and 2&4 to the Right tanks, when the model is first loaded The Balance cock, (L:xfeed,bool), simulates a connection between the tanks before the Fuel Valves.
I have an <Update> as the first section of code which will not recognize the (>K:FUEL_SELECTOR_n_...) entries and so the model starts with the 'ALL' tanks, default, option selected

The section of code for the Balance cock works properly,but not in update.

This is the style that usually works for me.
----------------First Go
<!-- This sets the start position to Main tanks and balance cock off. -->
<Update>(L:Firstrun,bool) 0 ==
if{{ (>K:FUEL_SELECTOR_LEFT) (>K:FUEL_SELECTOR_2_RIGHT) (>K:FUEL_SELECTOR_3_LEFT) (>K:FUEL_SELECTOR_4_RIGHT) 1 (>L:1cock,bool) 1 (>L:2cock,bool) 0 (>L:xfeed,bool) 1 (>L:Firstrun,bool)
}
</Update>
------------------------------------

I also tried the code section used in the Balance cock.
--------------------------Second Go
<!-- This sets the start position to Main tanks and balance cock off. -->
<Update>(L:Firstrun,bool) 0 ==
if{ 1 (>L:1cock,bool) 1 (>L:2cock,bool) 0 (>L:xfeed,bool)
(A:Recip eng fuel tank selector:1,enum) 2 !=
if{ (>K:FUEL_SELECTOR_LEFT) }
(A:Recip eng fuel tank selector:3,enum) 2 !=
if{ (>K:FUEL_SELECTOR_2_RIGHT) }
(A:Recip eng fuel tank selector:2,enum) 3 !=
if{ (>K:FUEL_SELECTOR_3_LEFT) }
(A:Recip eng fuel tank selector:4,enum) 3 !=
if{ (>K:FUEL_SELECTOR_4_RIGHT) }
1 (>L:Firstrun,bool)

}​

</Update>
-----------------------

 

[ddawson]

You've got two opening brace brackets after the 'if' statement.

 

[tedcook]

You've got two opening brace brackets after the 'if' statement.

Sorry about that Doug. It is just a bit left over from several editis/trials and missed when I edited the post. It still will not work.like this:-

<Update>(L:Firstrun,bool) 0 ==
if{(>K:FUEL_SELECTOR_LEFT) (>K:FUEL_SELECTOR_2_RIGHT) (>K:FUEL_SELECTOR_3_LEFT) (>K:FUEL_SELECTOR_4_RIGHT) 1 (>L:1cock,bool) 1 (>L:2cock,bool) 0 (>L:xfeed,bool) 1 (>L:Firstrun,bool)
}

 

[rpmc]

Looks like you have Events firing immediately after aircraft Load or Re-load and that could be the problem. The sim may not yet be ready to handle Events properly. Have you checked out this thread?

Alternatively, you might consider something like this to see if you get proper results:

<Update>
(L:CycleDelay, enum) 27 &lt;=
if{ (L:CycleDelay, enum) ++ (>L:CycleDelay, enum) }

(L:Firstrun,bool) 0 == (L:CycleDelay, enum) 27 &gt;= and
    if{
        (>K:FUEL_SELECTOR_LEFT)
        (>K:FUEL_SELECTOR_2_RIGHT)
        (>K:FUEL_SELECTOR_3_LEFT)
        (>K:FUEL_SELECTOR_4_RIGHT)
        1 (>L:1cock,bool)
        1 (>L:2cock,bool)
        0 (>L:xfeed,bool)
        1 (>L:Firstrun,bool)
    }
</Update>

As you can see, this just builds in a second and a half delay to allow the sim sufficient time to finish loading before Events are fired. 27 cycles might be excessive so you could experiment (for me, 20 works) or go with the approach shown in the referenced thread - might be a more universal solution.

Hope it helps.

Bob

 

[tedcook]

Looks like you have Events firing immediately after aircraft Load or Re-load and that could be the problem. The sim may not yet be ready to handle Events properly. Have you checked out this thread?

Alternatively, you might consider something like this to see if you get proper results:

<Update>
(L:CycleDelay, enum) 27 &lt;=
if{ (L:CycleDelay, enum) ++ (>L:CycleDelay, enum) }

(L:Firstrun,bool) 0 == (L:CycleDelay, enum) 27 &gt;= and
    if{
        (>K:FUEL_SELECTOR_LEFT)
        (>K:FUEL_SELECTOR_2_RIGHT)
        (>K:FUEL_SELECTOR_3_LEFT)
        (>K:FUEL_SELECTOR_4_RIGHT)
        1 (>L:1cock,bool)
        1 (>L:2cock,bool)
        0 (>L:xfeed,bool)
        1 (>L:Firstrun,bool)
    }
</Update>

As you can see, this just builds in a second and a half delay to allow the sim sufficient time to finish loading before Events are fired. 27 cycles might be excessive so you could experiment (for me, 20 works) or go with the approach shown in the referenced thread - might be a more universal solution.

Hope it helps.

Bob

Bob - Thank you. That has cured the problem. [ N.B.-- It fails to work with a delay of less than 26 on my system and program sequence in this instance. I tried reducing the selectors to two but it still needed a minimum of 26 to work ]
Thanks again for saving what little sanity I am clinging onto.
Regards. Ted.

 

[rpmc]

I'm happy to help, Ted.

By coincidence, a few days ago I had a similar problem that took a day or two of testing to finally stumble onto the delay solution.

At which point, Tom Aguilo reminded me of that thread (which I had actually read but obviously forgot) and added the following:

Events are queued and executed following a serial pattern.
While the event system is not started, all triggered events are sequentially stored in a queue and, as soon as event processing is enabled, they are executed alltogether, along with their trap routines (providing there is any). Then control to regular code does not come back until that event/trap queue is completed

As a revealing, although academic, test case, consider the following:

<Update>
    (L:MyVarA, enum) 0 ==
        if{
            (>K:FLAPS_INCR)
            (L:MyVarB, enum) ++ (>L:MyVarB, enum)
        }
</Update>

<Keys>
    <On Event="FLAPS_INCR">
        (L:MyVarA, enum) ++ (>L:MyVarA, enum)
    </On>
</Keys>

With my particular aircraft, I obtain the following results 19 cycles after reloading the aircraft:

The Init loop goes through 19 cycles during which MyVarB is incremented each time, but FLAPS_INCR is apparently not 'executed' nor, apparently, is the Event Trap code (L:MyVarA, enum) ++ (>L:MyVarA, enum) 'executed'.

On the next cycle, these values are returned:

The flaps have been increased to the maximum position, not just one notch, and both MyVarB and MyVarA are 19. This result seemingly does not make sense.

If <Update> is edited to include a cycle skipping delay after aircraft reload,

<Update>
    (L:CycleSkip, enum) 20 &lt;=
        if{ (L:CycleSkip, enum) ++ (>L:CycleSkip, enum) }

    (L:MyVarA, enum) 0 == (L:CycleSkip, enum) 20 &gt;= and
        if{
            (>K:FLAPS_INCR)
            (L:MyVarB, enum) ++ (>L:MyVarB, enum)
        }
</Update>

then the following results are obtained. One notch, only, of flaps and both MyVarA and MyVarB are 1, and that is what I intended to occur:

This was all very counter-intuitive to me until Tom explained some things. Thanks, Tom!

To consolidate a few widespread comments on Events, I'm wrapping up a wiki entry on Events and Traps, and this issue will be included.

Bob

(note: I added this test script to the Altimeter gauge ... no particular reason ... just convenient to edit that one ...)

 

[tedcook]

Thanks for the time invested in this Bob - I was just about to play with the <Keys>....<On Event= > part of the gauge. This is very welcome
I look forward to the Wiki .

Regards, Ted.

 

[rpmc]

The approach that Rob Barendregt proposes in the referenced thread is an elegant and potentially more fool-proof method of introducing the necessary delay rather than a cycle counting routine. He lets the sim tell you when its ready.

Rob suggests to simply fire an event, in his case, the infrequently used (>K:CABIN_SEATBELTS_ALERT_SWITCH_TOGGLE), and when its associated system variable, (A:CABIN SEATBELTS ALERT SWITCH, bool), returns 1 that means the sim's event handling system is operating. Following that, his desired initialization events can be executed successfully.

In another recent thread, Roman Stoviak posted a number of Event Trap examples that show some interesting things that can be done. Check out Response #18.

Bob