- Warning: This section covers FAQ for Mafia and is transcluded in the Guide to Hosting Please don't make changes unless you wish these changes to be included in that guide!
Whenever the host lets all actions happen at the same time and chooses a certain set of rules to treat collisions (such as cycles) and determine which action goes through first, a precedence-based order (OOP) is implicitly used. In layman's terms: "All actions happen unless acted upon".
The precedence-based universe states that all actions happen more or less simultaneously and the night-post is in whatever order the host wants it. This non-linear timeline can cause apparent paradoxes such as the player dying in the first action shown in the night post had the role that killed someone else as the last action shown in the same night post.
The policy adopted on mOs and which is favored by a lot of hosts is the same-time aspect of the universe. But instead of solving collisions on a case-by-case basis (which may lead to inconsistencies when dealing with loops of mutually exclusive actions), the concept of precedence should be used to make it completely deterministic, with explicit public rules on detecting and solving collisions.
A side-effect of the same-time model is the fact that kills are by definition non-blocking. In this model, the kill can never block anyone because it will happen at the same time as the target acts. The only thing that can block someone is the block.
Order of precedence
The order of precedence comes in play when a collision is detected by the host regarding two or more actions which cannot happen at the same time. The most common type of collisions where precedence is used are cycles (informally called loops) where a set of actions starts from an initial player targeting another and loops back to someone targeting the initial player (e.g. A targets B who targets C who targets A). In this case, the precedence order states which action goes first (to break the loop).
Example 1: Host's OOP: Trap > Save > Kill. Action submitted in the same night: *A wants to kill B *B wants to trap C *C wants to save B
These actions cause a 2-loop which (treated as a collision) is bound to be solved by precedence. So B traps C (trap > save), no save occurs as C is trapped and outside the loop, A kills B.
Example 2: Host's OOP: Trap > Save > Kill. Action submitted in the same night: *A wants to kill B *B wants to trap C *C wants to save A
These actions cause a 3-loop which (treated as a collision) is bound to be solved by precedence. So B traps C stopping the save and A kills B (this time, as part of the loop).
Some hosts treat only people directly targeting each other (2-loops) as the only type of collisions bound to be evaluated by the order of precedence (e.g. GMaster479). So in example 2, since there are no 2-loops, all actions happen.
Example 3: Host's OOP: Redirect > Trap > Kill. Action submitted in the same night: *A wants to trap B *B wants to kill C *C wants to redirect B to A
These actions cause a 2-loop between B and C with A's action interfering with B's. The approach of the precedence rules is to break the loop first (Redirect > Kill), allowing C to redirect B to A, then the remaining actions form another 2-loop:
*A wants to trap B *B was redirected and wants to kill A
Precedence is again used to break the loop (Trap > Kill) allowing A's action to go through, trapping B and thus stopping the kill.
Exceptions to the OOP
The order of precedence allows exceptions, for example:
- If the NK can't be blocked or redirected, then the host typically adds that phrase to the rules, while still allowing other actions (such as save or spy) to be blocked or redirected.
- If the RID Kill is also a blocking action, then the host typically adds that phrase to the rules, while still considering NKs to be non-blocking actions.