Some things I have learned about the event manager.

[trevor]

Sorry that this is in English only, I'd Google translate it, but I am sure the results would be less that satisfactory. Perhaps someone can translate it for me if you think it is worth sharing.

The event manager is a bit odd in the way that it works. So much so I thought I’d share some of my findings in case it might help other uses.

First, the whole application runs on kind of clock. (Though clock might simply mean cycle time.) From my experiment it appears that the simulation is advanced one “frame”, whatever that is, at which point a snap-shot of the current state seems to be used to test and run the events listed in the event manager.

I tested this by running two parallel events, one long, one short. Each one repeated 1000 times. Each event chain had an associated locomotive that ran down a track while the events were running. To my surprise, both trains always ended at almost exactly the same spot despite the difference in event commands.  When I timed the completion of the events I noticed it was pretty much 1000/(frame rate).


Second, the amount of stuff actively happening in events can slow down the frame rate. Since the events are run between each move of the simulation, if the amount of code running for an event is large, it can exceed the allotted time window for normal simulation. The frame rate will be reduced or trains may appear to hesitate.


Third, event conditions, both primary and secondary are always based on the state of the simulation at THE START of the event cycle. That is, if you test for a variable value or switch state, change that value and then try to use that new value in a subsequent TEST in the same event, the new value will NOT be used in the conditions logic. This one is a little irritating. If you want to use that new value in a test, you end up having to generate a new event which will be tested in a future event cycle.

Note on the latter, when you make changes, the underlying values ARE propagated down the event chain. For example you can increment a variable in one event condition and multiply that new value in the next and the final result of the variable will be as you expect. You just cannot test for that new value.
 

Finally, beware of races. Great care and forethought needs to be used when generating more complex event chains that can be started by more than one object on the layout. There is no built in method to propagate and maintain the underlying source of the event.  If event handlers for two objects toggle a variable, switch etc. handled by a different event, at or close to the same time, the results may not be as you expect. In some cases you need to resort to setting a different unique object and then activating a common handler that goes to look through a group of those objects for the one, or more, that is primed.

I hope this helps you. If I am mistaken on one or more points I am sure Neo will correct me.

 

Bearbeitet 5. Oktober 2016 von trevor

[Curt84328]

Interesting,  I found that the more events added to the EV, the slower it runs.  to preserve speed, I  grouped certain events into groups, and made them inactive until needed.   I have one event that activates the inactive groups,  the same event programs (If you want to call it that) two global variables and calls a common event that it had just activated to stop a locomotive for a railroad switch using the global variables just inserted into the program.  it then sets a timer, and you can then manually switch the railroad switch which uses a second routine to change the state of the signals.  the timer expires, deactivates the two groups, and resumes the locomotive speed. (It actually stops and starts all locomotives, so that the global variables do not get overwritten while in use)

 

Interessant fand ich, dass die mehrere Ereignisse in die EV hinzugefügt, desto langsamer betreibt. zu bewahren Geschwindigkeit, gruppiert ich bestimmte Ereignisse in Gruppen, und machte sie inaktiv, bis sie benötigt. Ich habe ein Ereignis, das die inaktiven Gruppen die gleichen Ereignisprogramme aktiviert (Wenn Sie es nennen wollen, dass) zwei globale Variablen und fordert eine gemeinsame Fall, dass es hatte gerade eine Lokomotive für eine Bahn-Schalter zu stoppen aktiviert, um die globalen Variablen nur eingefügt mit in das Programm. es setzt dann einen Timer, und Sie können dann auf die Bahn-Schalter manuell schalten, die eine zweite Routine verwendet den Zustand der Signale zu ändern. der Timer abgelaufen ist, deaktiviert die beiden Gruppen, und nimmt die Bewegungsgeschwindigkeit. (Er hält tatsächlich und startet alle Lokomotiven, so dass die globalen Variablen während der Benutzung nicht überschrieben)

Bearbeitet 5. Oktober 2016 von Curt84328

[Neo]

Hi Trevor,

your assumptions are right. Let me add some detailled explanations:

vor 17 Stunden schrieb trevor:

First, the whole application runs on kind of clock.

This is known as the game loop:

1. First, the studio collects all user input and processes it.
2. Then, it performs all internal updates, like moving a running train or forwarding an animation.
3. Then, the event manager processes any events occured during the last updates.
4. Finally, the current state is rendered to the screen.

After step 4, the studio starts again at step 1, and a new "frame" begins.

vor 17 Stunden schrieb trevor:

Second, the amount of stuff actively happening in events can slow down the frame rate.

This is an expected behavior. The more work the studio has to do, the more CPU power is needed. Future versions of the application will be optimized to continuously increase the efficiency of the event management.

vor 18 Stunden schrieb trevor:

Third, event conditions, both primary and secondary are always based on the state of the simulation at THE START of the event cycle.

This prevents dead-locks due to infinite loops. Imagine an action which triggers an event which executes an action which triggers the same event again (maybe implicit). That's why the event manager simply collects all actions and executes them once at the end of the frame. Events, triggered by the actions, are then processed in the next frame.

vor 18 Stunden schrieb trevor:

Finally, beware of races.

Race conditions cannot be solved by the event manager if the same event is triggered by two independent objects. This is a conceptional problem. Like in real, you have to make sure that two trains don't enter the same section by using a locking mechanism, for example signals.

Kind regards,

Neo

[trevor]

Cool just as my testing figured out...

I can understand the reason for the snapshot.. especially at the initial condition level, not so much at the other conditions level though.

Infinite loops are always a possibility either way... Have you ever written a handler called by a controller switch set and have the handler clear the switch when it's done, run it and realize you accidentally set the initial condition to ANY STATE... LOL...

Thank you for the task manager Bill Gates... LOL
 

Bearbeitet 7. Oktober 2016 von trevor