2.3.3 Exit Priorities

In our discussion of the environment tree, it was noted that the server searches up the environment tree for commands matching users' input. If more than one command with the same name is found, the server must resolve which command to execute. This is determined by the `priority' of the exits, and the order of the search path. Both are affected by the system parameter compatible_priorities.

Wizards can set Mucker bits on exits as well as on programs and players. An exit with a higher Mucker bit runs at higher priority than an exit with a lower Mucker bit, or one with no Mucker bit.

For example, suppose a MUCK has a global exit named `bank' linked to a program that gives players 100 pennies, and a player has an exit in his room named `bank' linked to a program that gives players 500 pennies. If neither exit has a Mucker bit set, both are considered `Priority 0' (zero). The first exit found in the search path would be executed: a player standing in the room with the `local' exit would receive 500 pennies; elsewhere, the global `bank' command would run, and the player would receive 100 pennies.

However, if a wizard set the global `bank' exit M1, the global exit would now have higher priority. Even in the room with the `local' exit, typing `bank' would execute the global exit, and players would receive 100 pennies.

As indicated, if there are two exits with the same name and the same priority, the server executes the first exit found. But the order of the search path changes depending on whether the system parameter compatible_priorities is set to `no' or `yes'. (Wizards may set system parameters with the @tune command.)

If compatible_priorities is set to `no', all non-prioritied exits (i.e., exits with no Mucker bit set) are considered `priority 0', and the server uses the following search order:

1. On the room the player is located in
2. On objects the player's inventory
3. On objects in the room's inventory
4. On the player
5. Environment rooms containing the present room, beginning with the `closest' room... the room furthest from room #0
6. Room #0
7. The server

If compatible_priorities is set to `yes', all non-prioritied exits are considered `priority 1', and the server uses the following search order:

1. On the room the player is located in
2. On the player
3. Environment rooms containing the present room, beginning with the `closest' room... the room furthest from room #0
4. Room #0
5. Objects in the player's inventory
6. Objects in the room's inventory
7. The server

In our example, the wizard had just set the global `bank' exit M1, so it had a higher priority than the local M0 exit. If the wizard then did @tune compatible_priorities = yes, both exits would now be considered `priority 1': the global is priority 1 because it is set M1, and the local is considered priority 1 because the system parameter is set to run all unprioritied exits at priority 1. The search order for players and inventories has changed, but in both cases the local room is checked before the global parent #0. So, now the local exit would run when player's type `bank' in the room with the local exit. If the wizard then set the global exit M2, it would again have higher priority than the local exit, and would run regardless of where a player is standing when typing `bank'.

If you have difficulty getting a local or personal exit to run in preference to a global of the same name, contact a wizard and discuss modifying priorities, either by raising your exit's priority, or by changing the system parameter.