Kleine EV-Tipps

[Andy]

Hier sollten kleine Hinweise für Dinge, die in der EV nicht unbedingt intuitiv sind, angehängt werden, .

Groß/Kleinschreibung:
  Variablennamen ändern Ist derzeit leider nicht möglich. Gibt man jedoch eine Variable ein, deren Name bereits existiert, ändert aber an der Groß/Kleinschreibung etwas, wird diese Änderung übernommen (demzufolge auch in allen Ereugnissen). Das bedeutet auch, dass z.B. x und X nicht gleichzeitig existieren können.

EV-Änderungen setzen normalerweise nicht das Sternchen im Anlagennamen, d.h. verläßt man die Anlage nun ohne zu speichern, wird man nicht gefragt, ob man noch sichern will.

Nutzung von nicht existierenden (Objekt)variablen.
Es ist ggf. möglich in Ereignissen Variablennamen zu verwenden, die sich noch nicht in der Variablenliste befinden. Diese Variablen gelten als nicht existent und ihre Verwendung in Bedingungen wird eine Teilaussage als 'falsch' erzeugen. Sie werden auch nicht automatisch ins Leben gerufen, sondern müssen manuell über die Liste ins Leben gerufen werden.
Man kann diesen Effekt aber auch durchaus verwenden. Im nachfolgenden Beispiel 1 werden alle Loks außer Rangierloks an dem Stopgleis angehalten. Jetzt gibt es nicht so viele Rangierloks, und man gibt nur den Rangierloks die Objektvariable 'istRangierlok' und setzt den Wert auf 1.

Im Ereignis wird gefragt, ob Auslöselok.istRangierlok auf 1 steht, gibt bei der Rangierlok 'wahr', Negierung ist angeklickt, wird also zu 'falsch', die Lok stoppt nicht.
Die BR 118 besitzt die Objektvariable gar nicht. Die Abfrage findet keine Variable und setzt 'falsch', negiert wird das 'wahr', die Lok stoppt.
Nun Beispiel 2. Eine Alt-Copy des Beispiels kopiert Objektvariablen zum Glück mit! Die Loks sind also identisch.
Nur die Ereignisbedingung ist anders.
Sie läßt auf Anhieb das Gegenteil vermuten, denn wenn ich nur die Werte 0 und 1 für 'istRangierlok' verwende, prüfe auf 1 und negiere, erwarte ich das gleiche Resultat wie prüfe auf 0 ohne Negierung. Aber, die BR 118 hat die Objektvariable gar nicht, der Versuch der Prüfung wird mit 'falsch' bewertet, und damit nun auch der komplette Ausdruck. Die Lok stoppt nicht! Keine hält hier!
Obwohl man hier auch mit der alternativen Aktion hätte arbeiten können, zeigt das Beispiel auch schön auf, wie eine Negation auf einer Einzelbedingung brauchbar ist.
Und man spart sich einiges an Tipperei bei der Erstellung von Objektvariablen.

 

objektvariable.mbp

Bearbeitet 7. Oktober 2018 von Andy

[Andy]

EV vs. herkömmlicher Programmlinearität:

Manchmal bringen kleine Beispiele Licht ins Dunkel.
Das folgende Beispiel zeigt auf, dass man in der EV gelegentlich etwas umdenken muß:

Wird der Kippschalter betätigt, wird eine Variable check auf 1 gesetzt.
Im nächsten Ereignis wird darauf reagiert, dass check auf 1 gesetzt wird. Die Aktion ist: check auf 0 setzen.
Der 'normale' Programmierer erwartet nun in einem linearen Programmverlauf, dass check nicht mehr 1 sein kann.

Das dritte Ereignis reagiert nun doch noch mal auf das Setzen check auf 1. Und siehe da, die Testvariable test wird wirklich auf 1 geschaltet. Es ist eingetreten!

Dann prüfen wir nochmal die tatsächlichen Verhältnisse mit einem vierten Ereignis:
Nochmal reagieren wir auf das Setzen von check auf 1 und fragen in der Bedingung nun, ob check nun 0 ist. Ist es nicht! Die Aktion, das Setzen von test2 auf 1 wird nicht ausgeführt!

Das heißt:
Wie immer ich auch Variablen in einem Zyklus der Ereignis-Abarbeitung beeinflusse, die Änderung wird erst nach der Abarbeitung aller Ereignisse vollzogen.
Wie sich das nun auswirkt, wenn man Variablen innerhalb eines Zyklus mehrfach verändert, mag man selber mal testen.

Grüße Andy

 

variablencheck.mbp

[BahnLand]

Hallo Andy,

in Deinem Beispiel gibt es 3 Ereignisdefinitionen ("reset check", "check2" und "check3"), die sich alle auf dasselbe Ereignis (nämlich "Variable check bekommt den Wert 1 zugewiesen") beziehen. Damit wird die Bearbeitung aller 3 Ereignisdefinitonen angestoßen, sobald das besagte Ereignis eintritt.

In der Ereignisdefinition gibt es nun 3 Möglichkeiten, eine Aktion(sfolge) anzustoßen, nämlich bedingungslos (wenn keine Bedingungen formuliert wurden), wenn eine vorliegende Bedingung(smenge) erfüllt ist, oder wenn diese nicht erfüllt ist. Diese Bedingung (falls vorhanden) bezieht sich genau auf den Auslösezeitpunkt, muss also geprüft werden, bevor irgendwelche Aktionen aufgrund dieses Ereignisses in Gang gesetzt werden und möglicherweise den Zustand zum Zeitpunkt des Ereignisses verändern. Deshalb werden diese Bedingungen für alle durch dieses Ereignis ausgelösten Definitionen geprüft, bevor irgendeine Aktion aus diesen Definitionen angestoßen wird.

Damit ist im vorliegenden Beispiel von vorherein klar, warum die Aktion zu Ereignisdefinition "check2" ausgeführt wird und jene zu Ereignisdefinition "check3" nicht.

Erst bei der Ausführung der in den Ereignisdefinitionen hinterlegten Aktionen spielt die Reihenfolge der Ereignisdefinitionen in der Ereignisverwaltung eine Rolle. Denn würde man beispielsweise in Definiton "check2" die Variable check mit 2 multiplizieren und in Definiton "check3" 2 hinzuaddieren, käme bei umgekehrter Reihenfolge der angestoßenen Aktionen ein anderes Ergebnis heraus. Hier ist sichergestellt, dass die Ausführung der Aktionen in jener Reihenfolge geschieht, in der die betroffenen Definitionen in der Ereignisverewaltung hinterlegt sind.

Übrigens:
Besitzt die Variable check vor dem Umlegen des Schalters bereits den Wert 1, tritt das Ereignis "Variable check bekommt den Wert 1 zugewiesen" trotzdem ein. Die genannten Aktionen würden also in dieser Situation genauso ausgeführt. Dies ist ein signifikanter Unterschied zu den Ereignissen "Weiche schaltet auf Stellung x" und "Signal schaltet auf Begriff y". Besitzt die Weiche nämlich bereits die Stellung x oder zeigt das Signal bereits den Begriff y an, führt das Zuweisen ("Umschalten") der der Weiche oder des Signals auf diese Position eben nicht zur Auslösung dieser Ereignisse.. 

Viele Grüße
BahnLand

[ademes]

Hi Andy and Bahnland,

Starting from the sample given by Andy, I try to understand the logic behind.  So I change the logic of the events in order to reflect exactly what I want, expressed in the diagram furnished here below.  And the result is trully not understandable.

In fact, the EV cycle reacts exactly as if the content of the variable VAR1 does'nt matter.  This is very strange.

If I understood correctly what you said, the "Ereignisdefinition" as you call it is executed (checked, validated,...) first and the actions are executed a the event moment.  In this case, at "Ereignisdefinition" time, VAR1 contains 1; however, the Check2 event is executed while the condition isn't met.  How is this possible?

I now hope to get a full description of that logic, because otherwise, I don't see how to build easily and correctly my layout.

Many thanks in advance

André

logic2.mbp

[Andy]

Here's one more and hopefully this time you get it:

I added a second variable A, which gets incremented in both events check2/3 and the value is shown on the right side in Label1/2.
Now, again, see what happens, READ LINE FOR LINE SLOWLY!

The switch sets V = 1 (there's a special appendix in the end about it, just assume now, the event VAR gets set happened!)

now the 1st pass, calculating the logic:
reset check: variable gets set and is 1 -> TRUE
check2  variable gets set, but is not >5  -> FALSE
check3  variable gets set, and is 1 -> TRUE

NOW THE 2nd pass performing the actions:
reset check is true, ACTION:  var gets +5 and is 6 now!    my new one: A get +1, is 1 now, shown here
check2 is false - NO ACTION!!!
check3 is true - ACTION, Label4 gets the text NO, Label6 gets the value of var, which is in fact 6 now.    my new one: A gets +2, is 2 now, shown here
FOR THAT CYCLE WE ARE THROUGH NOW!

So far - so good. And why do get Label3 and 5 texts now at all?
I marked one thing bold. This one sets variable A again now, so in the next EV cycle this has an effect too.
Again the first pass:
reset check, variable got set, but is not 1 anymore -> FALSE
check2: variable got set and is now >5 -> TRUE
check3: variable got set but is not 1 -> FALSE

and again pass2 for the actions:
reset check: false, nothing happens
check2 is true: ACTION! Label3 gets text YES, and Label5 shows the value of A,  my new one: A gets +1, is 3 now and that is shown here
check3 is false: no action!

because var didn't get set anymore now, nothing happens anymore. system is stable.

The problem with your flowchart is: it is not splitted in two passes. The theme here is EV vs. 'normal' program linearity. And there's simply a difference. I had to learn that too!
Don't ask me for reasons, I didn't made that - but why the heck is it so hard to understand those two passes? It's more that a 'normal' programmer is not really willing to accept that. But believe me - once you jump over the fence, you can live with that.

So - after you did understand it now, you surely will understand too, that in fact one more EV-cycle is needed: for the beginning switch! it sets VAR to 1. But in that cycle all other events will be given a FALSE in the first pass, because on 'incoming' var wasn't changed, so no action will be launched. So my explanations happen truly in the next cylce, when the setting of var is on the event-list.
Last thing to know is: Event and total logic result of its conditions are combined in the first pass!

regards
  Andy

logic2a.mbp

[BahnLand]

Hello @ademes,

@Andy has described the senario quite correctly. So, I can only provide another kind of explanation for this scenario:

Look at your event definition:

1.   Ereignis:  bascule
       Auslöser:  Schalter wird betätigt   Schalter='Kippschalter'  Position='Jede Position'
       Aktion:      Variable setzen            Name='VAR1'  Wert='1'  
    
2.   Ereignis:  reset check
       Auslöser:  Variable wird gesetzt    Name='VAR1'  Wert='1'  
       Aktion:      Variable setzen             Name='VAR1'  Wert='+5'  
    
3.   Ereignis:  check2
       Auslöser:  Variable wird gesetzt    Name='VAR1'  Wert='>5'  
       Aktion:      Beschriftung setzen      Beschriftung='Label3'  Text='YES'  
       Aktion:      Beschriftung setzen      Beschriftung='Label5'  Text='$VAR1'  
    
4.   Ereignis:  check3
       Auslöser:  Variable wird gesetzt    Name='VAR1'  Wert='1'  
       Aktion:      Beschriftung setzen      Beschriftung='Label4'  Text='NO'
       Aktion:      Beschriftung setzen      Beschriftung='Label6'  Text='$VAR1'  

The 1st action ist to set the variable "VAR1" exlicitly to "1". By this action, both event definitions "reset check" and "check3" will be triggered in the order of their occurence within the event definition list. This will be done before the actions of all these event definitions will be executed. When the event definition "reset check" is executed, the variable "VAR1" will be added by "5", which causes the trigger of the event defiition "check2" and its execution after the hnadling of the event "VAR1 set to 1" is completed. Therefore, the full action scenanerio will be solved in the following order:

1. Set VAR1 explicitly to "1"
   ------------------------------------------------------------------------------------------------------------------------------------------------
2. Event definition "reset check" will be triggered includuing the condition check
   [check2 will not be triggered]
3. Event definition "check3" will be triggered including the condition check
4. Action of event definition "reset check" will be solved because the condition check of step 2 was true
   Variable VAR1 is set to "6"
5. Actions of event definition "check3" will be solved because the condition check of step 3 was true
   Set "Label4" to "NO" and "Label6" to current value of "VAR1", which is now "6"
   -------------------------------------------------------------------------------------------------------------------------------------------------
6. Event definition "check2" will be triggered because "VAR1" was set higher than "5" within step 4 (including the condition check)
7. Actions of event definition "check2"  will be solved because the condition check of step 6 was true
   Set "Label3" to "YES" and "Label5" to current value of "VAR1", which is still "6"

Steps 2-5 describe the handling of the event "VAR1 set to 1".
Steps 6-7 describe the handling of the event "VAR1 set to >5".

This is exactly the behavior that you see when testing "logic2.mbp".

Please notice, that all occuring events are solved one after the other, but event definitions belonging to the same event occurence will be handled together in the following manner: At first the conditions of all triggered event definitions are checked to decide which actions of them should be executed. After the condition check for all triggered event definitions is completed, all actions which are decided to be solved are executed. These actions are executed in the order of the event definitions in the event definition list and there in the order of their own occurence in the corresponding event definition.

While one event is handled, other events occured in the meantime are delayed until the current event handling is completed. This explains, why the event definitions "reset check" and "check3" are handled together, but the event definition "check2" caused by the action of event definition "rest check" will be delayed until the handling of the event definitions "reset check" and "check3" is completed.

Many greetings
BahnLand

[Andy]

Another interesting thing is the is, that there is still a difference between the 'cycles' and the 'ticks' that you get from the event-com-port. Here's the log:

TICK: 0.000               <-  Tick is the time in secs where you get a 'receive'
210;Kippschalter;0;   <-- the switch, first number is the event code, 210 is switch switching
60;VAR1;1;                <- code 60 stands for Variable set
TICK: 0.016
60;VAR1;6;
60;A;1;
TICK: 0.031
60;A;2;
60;A;3;                         <- very very interesting that you get this in the same tick as the last one! Didn't expect that.
                                         But this maybe just depends on how much time is left in the tick frame,
                                         because it's even possible that things come a tick later that belong together.
                                         But it is also possible, that this cycle was continued immediately because the EV caused an internal event (setting of variable),
                                         which doesn't come from the layout. However, the sequence itself isn't disturbed by that.
(btw - When a text gets set, there is no event notification. Some things are missing, like setting a speed or a noise too.)

regards
  Andy
 

[ademes]

Hi Andy and Bahnland,

Thank you both for all axplanations you gave.  And be sure that I understand your logic (=3d logic) even if I cannot imagine the reason for solving the event's triggers, behalve to avoid infinitive loops (something that I know as I worked as programmer ans project leader since 1968).

But the problem remains!  Look again to the small diagram I send to you : the purpose was to print either YES, either NO depending on the value of VAR1.  Due to your logic, both are printed, which is wrong.  In addition, as demonstrate by Andy, the sequence for the execution of the event is not as foreseen (= wat you see).  Remember the general informatica rule WYSIWYG (what you see is wat you get); instead of behing 1,2,3, the event sequence is now 1,3,2. and that is not what I've expected.

This logic of 3d involves a lot of consequences as, for example (not exhaustive list):

- if I create a variable in an event, I'm not sure that it will be present when I will test it later in the sequence
- if a variable vary due to some manipulations, the result may be totally different than expected (my case)
- If I use the variables _Trigger1 or _Trigger2, an I sure that their value will be exactly what I expect at the correct moment?
- etc..

Finally, no matter what the logic is as long as all users are aware of it as it isexplained in the Wiki; but it is not the case currently.

So, my final question : do you think that it is possible to optimize the event list?  I mean not duplicating the events or the variables.

Thank you again

Regards

André

[Andy]

Hi André,
be assured, that's all a question of practising!
But first - you have to have another design!
Your flowchart can't be reflected the way you did - i.e. var1 gets set two times, so any request if var1 > 5 gets in fact passed two times. see it?
Event handling is, as if a lot of users access the same site. Lots of things happen simultaneously. Whatever goes linear now, has somehow to be capsuled.
In a machine you use 'step chains' for that, and so is my sample. It is like you number the different elements of your flowchart and then program the path through it.
Please be aware, that I use the alternate action too. (if condition is not fullfilled - you can select that in the action part of an event!)
There would even be a little more effort needed to make the sample safe, right now very fast switching would always set step=1 again, interrupting the chain and restarting.
Do you get the idea?

regards
  Andy

logic2b.mbp

Result of BahnLand's XML-Processor:

Projekt:   Logic2b
Gruppe:    Ereignisse {
  Ereignis:  bascule
    Auslöser:  Switch gets toggled                                    Switch='Kippschalter'  Position='Any position'  
    Aktion:    Set variable                                           Name='VAR1'  Value='1'  
    Aktion:    Set variable                                           Name='step'  Value='1'  
 
  Ereignis:  step1
    Auslöser:  Variable is changed                                    Name='step'  Value='1'  
    Bedingung: Variable has the value                                 Name='VAR1'  Value='1'  Negate='0'  
    Aktion:    Set variable                                           Name='step'  Value='+1'  
      Sonst:   (Bedingung nicht erfüllt)
    Aktion:    Set caption                                            Caption='Label A1'  Text='???'  
 
  Ereignis:  step2
    Auslöser:  Variable is changed                                    Name='step'  Value='2'  
    Aktion:    Set variable                                           Name='VAR1'  Value='+5'  
    Aktion:    Set variable                                           Name='step'  Value='+1'  
 
  Ereignis:  step3
    Auslöser:  Variable is changed                                    Name='step'  Value='3'  
    Bedingung: Variable has the value                                 Name='VAR1'  Value='>5'  Negate='0'  
    Aktion:    Set caption                                            Caption='Label A1'  Text='YES'  
      Sonst:   (Bedingung nicht erfüllt)
    Aktion:    Set caption                                            Caption='Label A1'  Text='NO'  
}
 
Variable:  step                                                  '0'
Variable:  VAR1                                                  '0'
 
*** Ende ***

@BahnLand: schönes halb und halb deutsch/englisch aber man sieht, was gemeint ist.

Bearbeitet 31. März 2019 von Andy

[ademes]

Andy,

As I already said : when the internal logic is defined and well known, there should be no real problem to adapt.

We are currently exchanging information concerning one solely case.  That's OK and I thank you for that.  But now I would like to know if other problems may arise.  And how to solve them.

In other words, it should be great to create a kind of addendum to the Wiki to explain to everybody the real rules governing the event resolutions.  Maybe with some additional tricks.  Espescially in relation with the development of the next version of 3d; if I understood well, there will be some possibilities to develop kind of programming as part of the events.  What will be the exact relation between these part of coded lines and the internal logic of 3d?  That's what one need to know, in my opinion.

What do you think about that?  What will be the next step?  These are the questions, now.

Regards

André

[Andy]

Hi André,
naturally, some more things came up over time. There are lots of thoughts about smooth event sharing. Lately this thread was of interest regarding how much events can be handled safe with no negative effects for the graphic. One result of the thread was: better don't switch too much lights at the same moment, use very small delays.
Another thing is about splitting tracks/streets in lots of small pieces to handle curves in rising zones. If you make too short pieces, enter track events could be lost if the vehicle is too fast. And it really costs performance if you got too much objects of a certain type when you use the trigger-trick.
Neo knows about that and we're in good hope, that there will be options in the new version that will solve the one or other critical situation.
So about collecting this special stuff: there are plans that we will also have a user-wiki with the new version. Let's wait for that.
So far (at least in the forum) only very few people come to those critical situations at all. Writing about without being asked causes heavy flaming from the i-dont-like-variables-fraction... The most innovative EV-using layouts are probably those of BahnLand and fzonk, but perhaps the most creative ones are those of koriander - who is still programming 'old-style': If you're in trouble with the EV again, BahnLand, fzonk and me (at least) will help for sure.

regards
  Andy

[BahnLand]

Hallo Andy,

vor 18 Stunden schrieb Andy:

schönes halb und halb deutsch/englisch aber man sieht, was gemeint ist.

ja, vielleicht hätte ich vor dem Erzeugen der XML-Datei das Programm auf "Englisch" umstellen sollen. Aber daran ahtte ich leider nicht gedacht (man wird eben älter ).

Viele Grüße
BahnLand

[Andy]

Geht mir doch auch so. Ich hätte MBS schon vor Einbau des 'Kippschalters' auf englisch umstellen sollen, dann hätte der auch anders geheißen.
Ich hab's dann vor Abspeichern der EV gemacht, um mal zu sehen, was dabei herauskommt und das ist doch okay. Der Exporter ist zumindest nicht hängengeblieben.
Vielleicht können wir André ja dazu bekommen, an einer französischen MBS-Version mitzuhelfen. In der Liste der verfügbaren Sprachen ist gewiß noch ein wenig Platz.
Aber dann muß der Exporter nochmal kräftig auf Unicode-Zeichen abgeklopft werden. Ich bin Dir jedenfalls unendlich dankbar für die Strukturklammern!

beste Grüße
  Andy

[ademes]

Hi Andy and Bahnland,

Up to a few days, I was thinking that MBS is a pluging.  But during our exchanges you speak about MBS-version.  Is MBS integreted into standard 3D?

I have no problem to translate the Wiki into french, if this is helpfull.  And the english version contains currently some sentenses that aren't in good english.
Example :
     So instead of a concrete specify locomotive speed, also the name of a variable can be set to give the 3D model railway club takes the actual speed of the variable.
should be
     So instead of specifying a specific locomotive speed, the name of a variable can also be set, whereby the 3D model train studio takes the actual speed from the variable.

Regards

André

[Andy]

funny, MBS is just short for ModellBahnStudio, that's the german title of that what you call Standard-3D

[Andy]

Hallo @BahnLand,

ich habe den Problemfall doch isolieren und in ein Beispiel packen können.
Er widerspricht den Erkenntnissen, die wir gesammelt und oben erklärt haben und bereitet einiges an Kopfzerbrechen, wie's denn nun wirklich ist.

Wenn Du den Kippschalter umlegst, läuft alles wie erwartet. Die Schleife über alle Schritte (bis auf den ersten) wird fünfmal durchlaufen.
Tauscht man aber die Reihenfolge der in der EV mit Zeile 1 und Zeile 2 bezeichneten Ereignisse, wird styp nicht mehr auf 1 gesetzt. Es kommt zum sofortigen Ende.
Eigentlich wäre zu erwarten gewesen, dass es nichts ausmacht, diese Zeilen zu tauschen - und doch...

Gruß
  Andy

 

ev extrem.mbp

[BahnLand]

Hallo Andy,

ich habe Dein Beispiel etwas "aufgebohrt", um eventuell etwas mehr Informationen zu bekommen.

ev extrem 2.mbp

Bekannt ist ja, dass dann, wenn mehrere Ereignisse durch den selben Auslöser aktiviert werdren, zuerst alls Ereignisse (einschließlich der Bedingungen) ausgewertet und dann in einem zweiten Durchlauf alle nun tatsächlich auszuführenden Aktionen dieser Ereignisse abgearbeitet werden - und zwar immer in der Reihenfolge, in der die Ereignisdefinitionen in der EV angeordnet sind.

Dieses Vorgehen trifft in Deinem Beispiel sowohl für die Gruppe der Ereignisse "Zeile 1 ..." + "Zeile 2 ..." als auch für die Gruppe der Ereignisse "checken#2 ..." (styp0 und styp 1) zu. Ich sehe nun bei einer Vertauschung der Ereigisdefinitionen "Zeile 1 ..." und "Zeile 2 ...", dass bei der Aktionen-Verarbeitung just zu dem Zeitpunkt, wo die Aktion von "Zeile 2 ..." schon abgearbeitet ist, die Bearbeitung der Aktionen von "Zeile 1 ..." aber noch aussteht, die Ereignisse "checken#2 ..." - ausgelöst durch das Setzen der Variable "pstep#checke"n auf "2" - bereits die Auswertung der Bedingungen durchlaufen, bevor die Verarbeitung der Aktionen von "Zeile 1 ..." (insbesondere das Setzen der Variable "Knoten.styp" auf "1" abgeschlossen ist. Daher wird anschließend das Ereignis "checken#2 styp=1" ignoriert und das Ereignis "checken#2 styp=0" ausgeführt.

Dies entspricht nun genau dem sichtbaren Ablauf der Demo, wenn die Ereignisdefinition "Zeile 2 ..." der Ereignisdefinition "Zeile 1 ..." vorangestellt wurde.

Ich hätte eigentlich erwartet, dass zunächst bei allen Ereignisdefinitionen, die durch ein Ereignis ausgelöst wurden, beide Durchläufe (zuerst der Check aller Bedingungen und dann die Abarbeitung aller Aktionen) komplett abgeschlossen werden, bevor die Bearbeitung des nächsten ausgelösten Ereignisses beginnt. Dies scheint leider nicht so zu sein, wodurch sich Ereignis-Auswertungen zu verschiedenen Auslösern zeitlich gegenseitig überlappen können.

Ich glaube, dass sich @Neo dieses Problem mal anschauen sollte, da ich mir nicht vorstellen kann, dass dies so gewollt ist.

Viele Grüße
BahnLand

[Neo]

Hallo,

vor 35 Minuten schrieb BahnLand:

komplett abgeschlossen werden, bevor die Bearbeitung des nächsten ausgelösten Ereignisses beginnt

nein, das ist nicht der Fall. Wenn eine Aktion ein neues Ereignis auslöst, wird dieses sofort verarbeitet/geprüft. Die neuen Aktionen werden dann an die noch anstehenden Aktionen angefügt. Dieses Verhalten ändert sich in V5, wo Aktionen sofort ausgelöst werden, wenn Ereignisse eintreten.

Viele Grüße,

Neo

[Andy]

Ah ja,
das erklärt dann auch, dass in dem älteren Beispiel ( hier ) das letzte Event nicht erst im nächsten Zyklus erscheint, wie eigentlich zu vermuten stand.
Nun denn. Derart komplexe Dinge werden hier wohl bis V5 nicht mehr auftauchen. Und wenn, sind wir drauf vorbereitet und haben was zum Puzzeln.

Gruß
  Andy