deleted by uploader

[tiffy]

deleted

[KG_is_back]

in the schematic you've provided the situation is little different. Every time a trigger (from, whichever link) comes to the "combined output" string primitive, it sends backward trigger to all its input links which updates their values. In your case they reach multiplexer - which is either on and passes the trigger through as if it was just another "string" module or it is off in which case it is ignored as if empty string was connected.

So what actually happens is when first trigger is send from the timer to multiplexer 2 backward trigger is send to those 2 string inputs and the output of the multiplexer gets constructed from the inputs by their order (in this case 'John'+',') and the trigger is passed to the "combined output" as it arrives backward triggers are send from all input links all of them hitting turned off multiplexers which output empty strings. Again the value gets reconstructed by summing the inputs in the order they are connected ( in this case ''+'John,'+'').

When second trigger is send off the same happens at the multiplexer 1. (backward triggers are send and value gets reconstructed by summing the inputs in their order 'Steven'+')' ). then the trigger is send to "combined output" string. Old value is deleted and backward triggers are send. This time they found one multiplexer off (outputting empty string) and one turned on which also send backward triggers and reconstructs its output as 'John'+','. Then the value of "combined output" is recreated from the inputs by summing them in their order ( in this case ''+'John,'+'Steven)' )

So every trigger you send in preforms a separate process. If more triggers are send in, they simply be processed separately one after another.
note: trigger delay works in a way that input trigger gets finished and new output trigger (= new process) is created n-milliseconds later, so though this schematic is started by one trigger, actually 4 triggers are performed (one stated by user clicking the start button, and 3 that are created by timers in event delay modules).

So although the green trees of modules and links seem like a net that is "flowing" and interacting it is actually like a formula written into a calculator and every trigger is simply hitting [=]. If you send new triggers before the previous is finished it doesn't interact with the running process - it creates a processing queue.

[tester]

To make it short. From what I remember (Trog's stories on SM), and from what I could observe - triggers seem to have "hidden marks" on them, and they work in hierarchical way. When you use timer - you just generate trigger with "new marker" on it, thus - this one is no longer connected with the tree of "things to do". Timers (and some other actions, that generate "new" triggers) break the tree so to speak, and thus - sometimes triggers from order and sometimes from timers are faster (I saw this in action on my schematics too). If there are complex data retrievals - trigger order can produce pretty big delays across the schematic, even few seconds long.