Is there a way to slow a gauge down?

Apologies in advance. I don't want to give away too much yet about the gauge. I know how annoying that can be. Makes it difficult to help. Sorry.

I have made a gauge.

Invisable. No images, No clickspots.

It listens for several variables. (A variables)

When a certain csituation is TRUE, a K: variable is fired.

If the condition is not true.another K: variable is fired.

the basics is:

listhen for A variable

TRUE: 1 K:smoke on

ELS: 1 K: smoke off.

trouble is, that made it a "runaway" condition. ("race condition" gauge.

either K:Smoke_On or K:SMOKE_OFF is constantly fired.

THis leads to the issue that if you try to manually press:

Shift+E, then 3

what the sim recieves is, for example, "Shift+E, then 1>K:SMOKE_ON, and only then 3.

Meaning door three does not open.

(instead, door 1 opens. Because the shift+E command means open main door.)

I thought about fixing that with an L variable, but I can't figure it out. If it had a clickspot as trigger that would work, but I don't see it with an A:Variable as trigger.

So, I thought of a different way.

At the to of the gauge I added:

Now the gauge updates (runs) only once a second.

And, (hurray), if I'm really quick about it, I manage to open door 3.:)

But, I would like to slow it down a bit more.

I tried:

and

but that did not take. he gauge still worked, but the door 3 couldn't be opened.

THen I thought, maybe I can create some sort of timer to slow it down.

something like:

set G:var1 to value zero

add 1

repeat

when G:var1 equals 6000

continue executing the rest of the gauge.

I was thinking that by making that number (6000) larger, I could slow the gauge down.

Is something like that possible?? In xml?

Or would that onl be an option in C++

Any other way to do it in xml?

--------------

I cna give a snippet of code, but I'll change the A variable for other ones.

Sorry, but I don't want to share the real thing just yet.

(A:GENERAL ENG THROTTLE LEVER POSITION,index) 80 &gt: (A:ENG TRANSMISSION TEMPERATURE,Celsius) 400 &gt: ! &&

if{ 1 (>K:SMOKE_ON) }

els{ 1 (>K:SMOKE_OFF) }

I ried with L:vars again.

I keep ending up wit something that switches the effect on all the time,

or for example this, which switches the effect on and off all the time.

element

select

(A:var,bool) (L:SMK1) ! &&

if{ 1 (>K:Smoke_on) 1 (>L:SMK1) }

els{ 1 (>K:Smoke_on) 0 (>L:SMK1) }

/select

/element

I'm trying to switch the effect on when a keyboard shortcut is used.

This keyboard command results in a boolean true/false.

I don't see a way to switch it on just once, and to switch it off again only when the keyboard key is pressed again.

Best I can come up with so far is: reduce update frequency. That works if I'm quick opening a door.

Any other way, because the gauge repeats all the time. Because when the shortcut has been used the "bool" stays 1 untill the keyboard key is used again.

Now thinking of maybe using a trap.

To make effect come on once only when key is pressed, and swithc off once only when key pressed again.

1 (>L:switchflick,bool)

---------basic plan for total thing:

(L:Flick_Switch) (A:var) && (L:SMK1) ! &&

if{ 1 (>SMOKE_ON) 1 (>SMK1)

(L:Flick_Switch) (A:var) && (L:SMK1) &&

if{ 1 (>SMOKE_OFF) 1 (>SMK1)

1 (>L:Flick_Switch,bool)

-------------So:

When switch gets flicked (=keypress), and A:var true, and L:SMK1 is still 0

then smoke switched on, and SMK1 set to 1

this to make sure, that when switch flicked again, smoke does not get switched on again.

separate section:

When switch gets flicked (=keypress), and A:var true, and L:SMK1 is value 1

then smoke switched off, and SMK1 set to 0 again.

this time to make sure, that when switch flicked again, smoke can get switched on again.

Tired now, will pick this up again later.

I think I managed to get it working.

three elements. each has if statement only.

condiditon (A:Var) (L:SMK1) ! &&amp----if---1 (>K:smoke_on) 1 (>L:SMK1)

other condition (A:Var) (L:SMK1) &&amp---if---1 (>K:smoke_off) 0 (>L:SMK1)

No els statements.

The above together was originally one if-els statement,

there were four if-els statements in the whole gauge,

each will turn into three or 4 separate elements. makes long gauge, but that's ok.

I had tried the L"SMK1 trick several times already. But using if-els.

Each time that gave a race condition.

This way door opens as normal so far. shift+e, take your time, then 3, opens door three nicely.

-------I did not use:

1 (>L:Flick_Switch,bool)

Just wanted to add some info:

The effect of that code, using the if statemements only and also a 1(>K:SMOKE_ON)

is as follows:

A:var is a Boolean.

it is normally false.

You can switch it to true in game. With a button (gauge) or with a keyboard shortcut.

A:Var

if 1(>K:SMOKE_ON)

else 1(>K:SMOKE_OFF)

would switch on smoke all the time the Avar stays true. And off all the time when Avar Not true.

but with:

(A:Var) (L:SMK1) ! &&

if{ 1 (>K:SMOKE_ON) 1 (>LSMK1) }

the smoke is only urned on ONCE when the Avar turns and remains true.

(It's turned on only whae A:var is true, and L:SMK1 is not true.)

Then, when the smoke is turned on, also L:SMK1 is turned to 0

Then, while Avar remains true, first line no longer returns TRUE. Avar is true, but SMK1 is true so (SMK1) ! returns FALSE

The if statement will bot be performed a second time.

I don't want it to perform an else statement as soon as soon as L:SMK1 turns TRUE. Because then the smoke would get switched off again right away.

----

Instead, I use a second section for switching smoke OFF only,

(A:var) ! (L:SMK1) &&amp

this returns true if:

(A:var) = 0

then (A:var) ! = 1

And, only when (A:Var) ! =1 and (L:SMK1) =1 both TRUE

then the if statement gets performed:

IF--> 1 (>K:SMOKE_OFF) 0 (>L:SMK1)

Again, the smoke is switched off only once. After that is done LSMK1 is set to 0 again.

With L:SMK1 at 0, the total condition for switching off turns to FALSE. So the smoke does not get switched off again.

And, the smoke does not simply switch on right after L:SMK1 turns 1.

For the smoke to turn on the A:Var has to switch first as well.

So no more: ON ON ON ON ON ON ON ON ON ON ON ON ON ON ON ON

And no more: ON OFF ON OFF ON OFF ON OFF ON OFF ON OFF ON

Only: ON once, wait for Avar to cange, OFF once.....waiting for the A:var to change again... etc.

And the doors all open fine.

To be sure I pressed: Shift+E then 3

door 3 opened,

then pressed 2

door 2 opened,

pressed one, main door opened

pressed 3, door 3 closed again,

etc.

Proving: No more race condition.

Very happy!

----------

The total first section:

              (A:Var,bool) (L:SMK1) ! &&
              if{ 1 (>K:SMOKE_ON) 1 (>L:SMK1) }






             (A:var,bool) ! (L:SMK1) &&
               if{ 1 (>K:SMOKE_OFF) 0 (>L:SMK1) }

There are actually more then one A var involved. But the Boolean gave the issue that required doing this. So I just wrote one A:var down here.

Also, in the first section is a third element. That also switches the smoke off, it looks very similar to the second one, except that the A:var used in it is different.

I just realised, maybe L:SMK1 is not the best name for me to chose as L:variable.

I read that L:vars are global. meaning that if two gauges use the same L:var, then both of them affect the L:var's value. If both add 1 to the L:var, then it will not have value 1 as needed, but value will be 2.

In the other thread in the forum currently, tornadowilkes in this thread

https://www.flightsim.com/vbfs/showthread.php?294546-Independent-smoke-effects-for-each-engine

mentions using (L:SMK1) as well.

I guess I better choose a different name for my L:vars

Does anyone have a recommendation for choosing unique names?

Does anyone have a recommendation for choosing unique names?

You can actually use any name you wish. (L:Fred,bool) will work just the same as (L:SMK1,bool)... :)

I would suggest picking a name that bears some relationship to what your script is controlling. For the example I submitted, I choose to use (L:SMK1,bool) so it would match up with the commands (>K:SMOKE_ON) and (>K:SMOKE_OFF).

I also highly recommend that you get in the habit of using ",units" with your custom L:variables. The sim doesn't really care since it treats all custom L:vars as FLOAT64 type anyway, but it does help to keep the scripter reminded of what types he/she intends (bool, int, float, string, et cetera).

BTW, to save yourself a lot of extra typing, instead of using separate sections for each evaluation, just put them all in a single section. Bear in mind that using this FS9 schema, we can only have one section:

 (A:Var,bool) (L:SMK1,bool) ! and
 if{ 1 (>K:SMOKE_ON) 1 (>L:SMK1,bool) }


 (A:var,bool) ! (L:SMK1,bool) and
 if{ 1 (>K:SMOKE_OFF) 0 (>L:SMK1,bool) }

I don't really see the effect of the part.

I did start my gauge off with:

That was to slow it down.

But after fixing the problem with effect switching on all the time (or off), the slow frequency is not needed as much any more.

So I changed it to:

I never used an update line in my previous gauges.

(And this one works fine if I delete that line altogether also. (frequency is then 16 times per second loop I believe).

So I don't see a pressing reason to have an update line.

Or does have another effect, like causing a loop within the loping gauge?

---------

Btw, about the gauge getting very long. I managed to find a workaround for that too.

At that time I had split one if/els element into three elements for smoke.0:

element1 - If condition1, then switch on.

element2 - if condition2, then switch it off

element3 - if condition3, then switch it off also.

I just discovered the OR operator. || With that I combined element 2 and 3 to be:

if condition2 OR condition3 (AND SMK1=True) --> then switch off

It's working ok.

Total gauge started as 3 elements with if/els. (One element for each smoke.)

now it's 6 elements.

one to switch smoke.0 on

one to switch smoke.0 off

one to switch smoke.1 on

etc. 6 in total. Only if statements.

I only have at the top of the gauge, so I assume that means all the elements are in the same loop. Correct?

-----

I will try to think of some L:var names that are related to the function, but are still unique. Add a few random letters or numbers perhaps. Thanks. Oh, I'll start adding units to the L:vars.

I realise more and more how important it is for other variables as well.:)

Gauge code updates 18 times per second; if you don't want an update rate different from that you can delete the Update_Frequency line altogether. It's not needed unless you need a gauge to delay it's update rate (like when you were trying to use it to avoid flooding).

An Update section works the same as an Element/Select/Value section - it runs the code. To many coders this is a neater solution when you just need to run code because it clearly indicates that this section is only for running code. That leaves the Element sections for other things, like visible parts of your gauge. When you come back to the gauge it can make it easier to remember the logic you used. But if you like Element/Select/Value you can use that instead.

And as Bill states, there's no need to put each statement into its own Element section - combining all similar logic into one Element section shortens the gauge code and makes things easier to understand. I maintain separate Element sections only for code that has a different purpose from the other code, although that can also be done with comments within a single Update section.

Hope this helps,

That answers my question on update frequency. Thank you.

And also new info about the sections/elements. I will start experimenting. I do like the separate elements for clarity so far. But I can see your method has benefits too. Thanks.