Train Hessitation On Event Firing

[trevor]

It seems to me that the simulation pauses whenever an event is triggered. For small events this is hardly noticeable, but those that have a more complex sequence of chained events this hesitation is extremely noticeable and almost nullified the usefulness of the application... Obviously it gets worse the bigger the layout and the more events that fire.

 

[Neo]

Hi Trevor,

can you provide a sample layout which shows this behavior? Events do not "pause" the simulation, but the bigger a layout is, the more CPU and GPU power is needed in order to achieve smooth animations.

Kind regards,

Neo

[Henry]

 

Hi Trevor,

you wrote (this is my translation for german readers)

Zitat

Es scheint mir, dass die Simulation pausiert, wenn ein Ereignis ausgelöst wird. Für kleinere Ereignisse ist dies kaum spürbar, aber diejenigen, die eine komplexe Folge von verketteten Ereignissen haben, ist diese Verzögerung  extrem auffällig , was fast die Nützlichkeit der Anwendung zunichte macht ... Natürlich ist es noch schlimmer, desto größer das Layout und die Ereignisse werden.

The event-controller is a simple list of upcoming and unordered events while the trains run around. Events are executed in linear order by a running train. You have no influence on the order

On the other hand the event-controller is a loop that runs permanently top-down in the background. It is a look-up chart too. You must fill your lookup table in the right order to get quick performance. You  will slowdown the EV when you try to process advanced ideas which are not supported.

The EV is NOT

• a script,
• supports only simple string-operations up to 58 chars in labels
• no procedures
• no functions
• no jump_to's
• no extra tables
• no arrays

it is just the Look up List and running permanently.

Please reduce your feature wishes to this simple fact and find new ways.

Deutsch:
Die Event-Controller ist eine einfache Liste der anstehenden und ungeordneten Ereignisse, während die Züge herumlaufen. Die Ereignisse werden in linearer Reihenfolge von einem fahrenden Zug ausgeführt. Wir haben keinen Einfluss auf die Reihenfolge .

Auf der anderen Seite ist eine die Ereinisverwaltung eine Schleife, die permanent von oben nach unten im Hintergrund läuft. Es ist ein Look-up Datei. Sie müssen Ihre Lookup-Tabelle so in der richtigen Reihenfolge anordnen, daß sie schnell ausgeführt werden. man Verlangsamt des EV, wenn man versucht, fortschrittliche Ideen zu verarbeiten, die nicht unterstützt werden.  

Die EV ist NICHT

• ein Skript,  
• Es werden nur einfache String-Operationen bis zu 58 Zeichen in Beschriftungen unterstützt  
• Keine Proceduren
• Keine Funktionen  
• Keine Sprungbefehle
• Keine zusätzlichen Tabellen  
• Keine Arrays  

Die EV ist nur eine Look up-Liste und läuft permanent im Hintergrund .
Bitte reduzieren Sie Ihre Funktions Wünsche auf diese einfache Tatsache, um neue Wege zu finden.

Regards,

Henry

[Curt84328]

perhaps to simplify,  setup your layout in sections and write the ev in sections/  have the sections deactivated most of the time and then when a train enters a section it first activates that section, and when the train leaves the section, it deactivates the section.

I have my layout on 4 different levels, and events for each level are in their own group.   When a train enters a level, it activates that level and the events are deactivated when the train leaves.  If you get too many events in the EV, it can run a bit slow. 

vielleicht zu vereinfachen, Setup Ihre Anlage in den Abschnitten und schreiben die ev in Abschnitte / haben die Abschnitte die meiste Zeit ausgeschaltet und dann, wenn ein Zug in einen Abschnitt gelangt es aktiviert zuerst diesen Abschnitt, und wenn der Zug den Abschnitt verlässt, schaltet es den Abschnitt .

Ich habe meiner Anlage auf 4 verschiedenen Ebenen und Veranstaltungen für jede Ebene sind in ihrer eigenen Gruppe. Wenn ein Zug eine Ebene eintritt, aktiviert es das Niveau und die Ereignisse deaktiviert werden, wenn der Zug geht. Wenn Sie zu viele Ereignisse in der EV bringen, kann es ein wenig langsam laufen.

[BahnLand]

Hallo Neo [english below],

stimmt es, dass Ereignis-Definitionen, die zu einer Gruppe zusammengefasst sind, komplett ignoriert werden, wenn die Gruppe insgesamt deaktiviert ist, oder werden diese Ereignis-Definitionen trotzdem  durchlaufen, aber eben nicht ausgeführt. Mit anderen Worten: Führt die Deaktivierung ganzer Ereignisgruppen (sofern sie eine gewisse Größe besitzen) tatsächlich zu einer Beschleunigung der Ereignis-Verarbeitung und damit auch des kompletten Betriebsablaufs?

Viele Grüße
BahnLand


Is it true, that event definitions, which are grouped, get completely ignored, when the event group is deactivated in whole? Or get these event definitions scanned anyway, but not executed? In other words: Does the deactivation of larger event groups really leed to a speedup of the event handling and therefore also affects to the whole operating sequence?

[trevor]

14 hours ago, Neo said:

Hi Trevor,

can you provide a sample layout which shows this behavior? Events do not "pause" the simulation, but the bigger a layout is, the more CPU and GPU power is needed in order to achieve smooth animations.

Kind regards,

Neo

Here is the test layout I am working on.

I am trying to build an automated sectioned layout with section controllers and train controllers. Only one train can own a section and enter / occupy it at any given time. A timer is used to sequence the navigation events in each controller. I make quite heavy use of pointers attached to objects to reference other objects so that the event handlers can be easily duplicated as I add more sections and trains. I am also using controller switches to trigger events since I need the Trigger properties attached to those. (Using simple Variables does not allow me that luxury)

Performance is pretty bad. Navigation requests can take more than 1/4 sec which Is a problem since that's longer than the navigation timer window allotted to each train. Granted I am doing quite a lot in those windows, but really.... it should not take that long to check that 20 or so tracks are clear and toggle a few controllers. I suspect the performance delay has to do with all the string lookups.

I am a professional software developer, writing software that processes and searches through tens of thousands of records. If my code took 1/4s to sort through <100 I'd be out of a job. Perhaps I can give you some pointers. I'd love to talk to you guys 1 on 1.

If you watch the trains they do not run smoothly but hesitate at regular intervals.
BTW My system is top of the line with medium graphics capability, Frame rate on that layout is 50FPS so that should not be causing the hesitation.

 

 

Test21.mbp

Bearbeitet 27. September 2016 von trevor

[trevor]

13 hours ago, Henry said:

The event-controller is a simple list of upcoming and unordered events while the trains run around. Events are executed in linear order by a running train. You have no influence on the order

On the other hand the event-controller is a loop that runs permanently top-down in the background. It is a look-up chart too. You must fill your lookup table in the right order.

Hi Henry,

Thanks for that explanation and doing the translations.

So what you are saying is, it is NOT REALLY an event handler but a state monitoring sequence.

I had already determined that handlers triggered by the same event were executed in top down order in the EV but had no idea it was checking states of all of them and not EVENT driven as the name implies. I will take that into consideration.

It also appears to take a "Snapshot" of the layout state before running the events. A change made in one event may not be detected in the conditions of the next one in sequence. The latter makes creating an ELSE event problematic.

Even with all that, it is still horribly slow though.

[Neo]

Hi Trevor,

thank you for the sample, I can reproduce the "jittering" of the trains, although your layout is rather small (I get > 60 FPS). I will profile the EV to detect any performance issues and will let you know.

vor 4 Minuten schrieb trevor:

On the other hand the event-controller is a loop that runs permanently top-down in the background.

This is only true for timers. For all other triggers, they get only fired when the event is triggered. The application does not check every trigger at every frame.

vor 3 Stunden schrieb BahnLand:

Is it true, that event definitions, which are grouped, get completely ignored, when the event group is deactivated in whole?

Yes. When an event is incoming, all triggers are immediately skipped if their parent group is disabled.

Kind regards,

Neo

[Neo]

Hi Trevor,

I've analyzed your layout and have found the source of the problems. You have a lot of object accesses by name, which is not yet fully optimized. I will publish a software update in the next days which will improve the behavior.

Kind regards,

Neo

[trevor]

1 hour ago, Neo said:

Hi Trevor,

I've analyzed your layout and have found the source of the problems. You have a lot of object accesses by name, which is not yet fully optimized. I will publish a software update in the next days which will improve the behavior.

Kind regards,

Neo

Sweet

I figured that was probably related. Not sure what you wrote this in. I strongly recommend dictionary objects or using routines that play the higher-lower game for looking up sorted lists of text. If you are using simple for I = 1 to ubound, it is horribly inefficient. OF course dictionaries wont help much unless u force folks to use unique names. 

[Neo]

Hi Trevor,

the problem was fixed in the latest beta version.

Kind regards,

Neo