Oz Flyer wrote:I think it would be best as an option.
If not then use the actual values as each event in the sequence is run.
That way if event 2 needs to use a value from event 1 it will have the updated value.
Having said that there would need to be a way to have a time delay so the the data from event 1 is fully updated.
That is literally not possible. Because one of the key features of SPAD.neXt is, that everything is asynchronous. SPAD.neXt does simply not know
when and if a data change is completed.
How do events work:
First of all a SPAD.neXt event is
always triggered by an external event. This can either be a hardware device (Switch turned to on) or a data value, which is used in a condition, changes. You can picture the "Switched on"-Event as an invisible "if SwitchVariable equals 1"-Condition.
1. At this moment in time, nothing is evaluated. SPAD.neXt just recognizes "it changed".
2. SPAD.neXt will tell all programmed events that use that changed data: "Hey you need to evaluate your conditions".
3. The events evaluate their condition in the priority order. They will use the values that are current, when the evaluation takes place. SPAD.neXt Events bound to different triggers will evaluate parallel. (e.g. 2 different Script-Events using SIMCONNECT:HEADING LOCK DIR, will execute at the same time, not in sequence!)
(for a general sequence of what is happening see this:
http://www.spadnext.com/wiki/manual:events_execution )
4. If now any of the actions changes SIMCONNECT:HEADING LOCK DIR, all starts from the beginning as soon as the change arrives at SPAD.neXt.. So changing SIMCONNECT:HEADING LOCK DIR will do
* SPAD.neXt sends new value to FSX. (SPAD.neXt will internally
still work with the old value!)
* FSX updates SIMCONNECT:HEADING LOCK DIR
* FSX send update of SIMCONNECT:HEADING LOCK DIR to SPAD.neXt
* SPAD.neXt recognized change of SIMCONNECT:HEADING LOCK DIR and starts at 1. again
Btw this explains, why sometimes the Multipanel shows something different than the aircraft: SPAD.neXt did not get the value change for any reason.
All but LOCAL will always make the roundtrip through the simulation. Using this approach SPAD.neXt ensures it's not working with invalid/outdated/different data.
To have something like "wait until the change is done" local variables can be used. As the change of the local variable and the data change from the sim will both trigger the event.
So actions with a condition
if LOCAL:DoThis == 1 AND SIMCONNECT:HEADING LOCK DIR > 100
will only be executed if DOthis and SIMCONNECT:HEADING LOCK DIR match the values, but will be evaluated every time any of those two changes.
Due to the nature of the asynchronous execution, it might happen that one programmed action sequence is executing while another is not, because the condition-trigger changed meanwhile. Instead of changing the time when the conditions is evaluated, i might decide to introduce "subevents" that will be executed if their main event triggered.
A good example is the new LOCAL:SPAD_AIRCRAFTCHANGED data value. If you monitor this, you will see it always has the value "1" as soon as a simulation is connected. Nevertheless actions bound to it will be executed if the aircraft changes, because SPAD.neXt will just set it to 1 again (no change in value, but as stated above (1.) , SPAD.neXt does not care).
Constraint:
All external data values have an epsilon. SPAD.neXt will only trigger the "it changed" if the new value and the "last changed trigger value" differ more than this epsilon. This is simply to spare CPU. Some values (e.g. the fuel capacity or RPM) change 60 times a second with a difference of like 0.000000000001 gallon. To evaluate all conditions 60 times a second would mean to have a 8-Core 200GhZ Cpu just for SPAD.neXt. To prevent this, "it changed" is only triggered if the fuel capacity changed since the last trigger by at least 0.01 gallons.
Big wall of text, but it hope it explains understandable how events work.
but think that you might want it to be an option depending on what your working with and attempting to do.