Order of Operations

Within a turn, most properties and verbs take place exactly once. Conditions process when the game checks for what objects have a rule, which is usually right before it uses it.

They process in the following order:

* domovement(). For each movement stage, it adds all the entries to a list then iterates through said list. Each unit that moves is assigned a number of movements. It moves through all units in that list exactly once, then deletes the entries with 0 moves remaining and keeps going until it's done moving. Note that it completely finishes moving for a particular move stage before checking which units are in the next, so conditions reparse in between.
	+ (same step, added to list in this order)
		- and  do their rotations before any movement actually occurs, and also before the turnaround check. (The chill rotation occurs if the object has at least one chill.)
			* (The random direction of empty for other cases is set later in the turn, but only if it hasn't been set yet. This doesn't impact anything.)
		- An object will only not turn around on walls if the first action added to list is auto (the object is auto but not move).
	+ , , ,  (in this order, as separate steps)
	+ main movement
		- An object can only move in one direction per move stage (except the wall turnarounds from move/etc); if it would get shifted in multiple directions, the first shift to apply will set its direction and future shifts to apply in that turn will only increment the amount of movements. (the same applies to fear)
* (rule parsing)
* and object transformations via  and . While they are checked in the same step, REVERT takes priority over the others while **X IS ALL** takes the lowest priority.
* (rule parsing)
* moveblock()
	+ (but tele is really weird and no one really knows how it works)
	+ additional direction change
* Object deletion due to the stack limit (only 6 copies of an object can exist on a tile at once. The object with latest priority gets deleted)
* fallblock() - , in that order
* (rule parsing)
* statusblock() - This also gets called whenever a new object is created, but only applies to that object in that case. Here, it applies to every object. (It is also called at the start of turn, but the turning doesn't activate there.)
	+ ( is checked here, for any call to statusblock)
	+ (unless it's empty/outer level, which aren't cached)
	+ (unless it's empty/outer level, which aren't cached)
* fallblock() for the second time
* (rule parsing)
* levelblock(). All actions are only done with the outerlevel at this point. These are done in the order the rules are parsed, though it will do all actions with EMPTY (except ) before checking with nonempty objects.
	+ There's also a few other weird cases, such as if level is you and x is win and end the win will always process first.
	+ is checked here.
	+ If you are in the world "baba" and the level "305level" (that is, Gallery), it also checks for  at this point.
* block(). Deletion occurs after each step that removes objects, but all objects destroyed in the same step are destroyed simultaneously.
	+ If you are in the world "museum",  is checked here.
	+ (collision check; movement check occurs on movement)
	+ (collision check; movement check occurs on movement)
	+ Colors, other visual properties and visual aspects of non-visual properties.
	+ , ,  (ran in this order; deletes from bonus don't occur until after)
	+ Delete out of bounds units
	+ CRASH
* (rule parsing)

## Movement check response properties

Before first parsing, the game checks for collisions after every movement step in the following order.

* are checked simultaneously
* are checked.
* for pushed/pulled objects
* for pushed/pulled objects
* Passive

## Other considerations

* is checked after every standard destruction, no matter whether the destruction is checked on collision or overlap. In addition, conditions on these rules are rechecked at the time of destruction, even if multiple destructions occur in the same turn.

## Object Priority

Within an individual action, there is sometimes something that it must be resolved as one object having gone "first" over another object, such as when two objects try to push the same object from different directions.

The game stores objects as a single list, and objects earlier in the list get processed first. Additionally, the game places all objects it is about to perform an action with in a separate list, which is done in the order the rules are processed (with different objects affected by the same rule being added to the list in the expected order).

When (re)starting a level, objects are ordered in the list by placement: columns from left to right, from top to bottom within each column. If multiple objects are in the same tile, it places lower layer objects first.

New objects that are created are added to the end of the object list in the order they were created. This includes when the object is removed by any method, then the turn is undone. (If multiple objects are removed at once, they are readded in the reverse order they were removed.)

The following things rely on priority:

* Pushing, pulling, or swapping the same object with more than one object in the same move tick
* Opening a stack of objects
* Rules with level
* Following two equidistant objects
* Two stacked shift objects' preliminary turning
* Objects that are fall and stop, or more and stop
* Make text with stacked objects
* 6 stack cap with objects facing different directions
* Some weird rule parsing behaviours, especially with letters