FEC ordering of Zero Time Events: Difference between revisions
Jump to navigation
Jump to search
m (1 revision(s)) |
No edit summary |
||
| Line 12: | Line 12: | ||
This starts to bring order into the otherwise murky world<br /> of zero time events. You still must not depend on the order of BCs being<br /> processed, unblocks and moves being performed etc.<br /> </font> | This starts to bring order into the otherwise murky world<br /> of zero time events. You still must not depend on the order of BCs being<br /> processed, unblocks and moves being performed etc.<br /> </font> | ||
---- | ---- | ||
[[Category:Event | |||
<font size="2">idkbase note 18</font> | |||
[[Category:Event]] | |||
[[Category:FEC]] | |||
[[Category:Zero Time]] | [[Category:Zero Time]] | ||
[[Category:Broadcast]] | [[Category:Broadcast]] | ||
[[Category:Unblocking]] | [[Category:Unblocking]] | ||
[[Category:Runtime Engine]] | [[Category:Runtime Engine]] | ||
Revision as of 02:30, 12 January 2008
The FEC orders zero time (immediate events) as follows
- Broadcasts have top priority (including item and system info BCs)
- Moves and Unblocks
- Clock resetting/restart
- Button clicks during animation
- Other events (0 delays etc)
The idea is to process as many activities as possible (eg: handling BCs)
before making move and unblock decisions based on the side effects due
to attribute/table changes.
This starts to bring order into the otherwise murky world
of zero time events. You still must not depend on the order of BCs being
processed, unblocks and moves being performed etc.
idkbase note 18