Submitting orders ================= Orders should be sent to orders@.pbm.com. For instance, if you are in game 1 of Olympia, send orders to: orders@g1.pbm.com The Reply-To: header on turn reports is set to the correct orders, so using the "reply" feature of your mailer should send orders to the right place. The orders address is read by an automated daemon which scans the orders for syntax errors and queues them for your units. It will send a reply as soon as it receives mail from you, showing whether or not there were any errors with the orders it received. Orders must be of the following form: BEGIN player-number "password" . . EMAIL, LORE, PASSWORD commands . UNIT player-number . . commands for player entity: NAME, FORMAT or QUIT . UNIT unit-number . . commands for unit . UNIT unit-number . . commands for unit . END The Subject: line on your message is ignored. The BEGIN keyword tells the order scanner what your player number is. If you have not set a password, you do not need to supply one. The UNIT command replaces a set of orders for a unit. Any pending orders for the unit will be cleared, and the new orders sent in will queue up. Orders that are still executing for the unit will not be interrupted unless the first order queued is the STOP order (see below). Do not match an END for every UNIT command! There should only be one END, at the end of all of the UNIT sections. The Olympia order parser will not read beyond the END. For example, here is a set of orders for player Fate [812], who has two characters, Osswid [5499] and Candide [1269]: BEGIN 812 password sneaky UNIT 5499 explore move east explore study 120 UNIT 1269 move north stack 5499 END The parser tries to be as flexible as possible. It is case insensitive and is not strict about spaces on a line, so you may use indentation to make your orders more readable. Orders may be commented with the # character. Everything from a # to the end of the line will be ignored by the parser: move north # Head to Drassa to meet up with Osswid stack 5499 # stack with him No one will read the comments but you. Neither the GM nor the Olympia engine will try to interpret them for any reason. Note that arguments must be enclosed in quotes if they are more than one word: name "Osswid the Constructor" The acknowledgement will show any errors that occurred while the orders were being parsed, and list the current pending commands for all of your units. Interrupting orders ------------------- Suppose the turn report shows the following orders queued: unit 5499 # > study 160 (executing for three more days) recruit 10 explore Sending in new orders for this unit will not disturb the still-running study command unless the first order is STOP. For example: If this were sent in: unit 5499 move south This would be the result: unit 5499 # > study 160 (executing for three more days) move south To interrupt the study and get on with the move right away, instead send in: unit 5499 stop move south This will show: unit 5499 # > study 160 (executing for three more days) stop move south Note that the stop queues like any other order; it does not actually interrupt the executing command until the turn runs. This means that the stop itself can be replaced by sending in another set of orders later. Units not controlled by you (yet) --------------------------------- Orders may be sent in for units which are not yet under control, such as characters that you intend to BRIBE or TERRORIZE into switching to your faction. As soon as the unit comes under your control, the orders queued for it will begin to execute. Orders may also be sent in for new nobles which will be formed during the turn. First choose one of the possible unit numbers from the choices listed near the beginning of the turn report: The next five nobles formed will be: 5717 3215 4902 4489 5628 Supply one of these numbers as the first parameter to the FORM order: form 5628 "Feasel the Wicked" Then queue some orders for Feasel to execute as soon as he appears: unit 5628 unstack study 160 move out recruit ... Use the order template ---------------------- An order template listing all of the units for a player and showing any pending orders for those units, appears at the bottom of the turn sheet: Order template -------------- begin 812 # Master Bogomil's Family unit 2508 # Tudor # > make 74 (still executing) unit 2947 # Milo unit 4375 # Beorn # > move s (executing for one more day) pillage recruit unit 4763 # Sylvia unit 5977 # Drango # > collect 87 0 0 (still executing) sail e sail s fish explore unit 5418 # Comte de le Sang end Note that the layout of the order template matches the syntax the order scanner expects. Many players find it convenient to edit this template to add or change commands for their units. Mail everything from the "begin" to "end" (inclusive) to the order scanner. It is wise to save a copy of the orders you submit in case there are errors and they need to be resent. Be careful ---------- Beware of sending in different sets of orders too quickly. Sometimes messages sent within a short time of each other will arrive out of order. This can wreak havoc on your turn if the wrong orders arrive last. Compose your orders offline and review them before mailing. A simple typographical error in your orders could ruin your whole turn! Failed orders ------------- Commands that fail generally take zero time. For instance, if STUDY is issued for a skill which the location does not offer, it will fail immediately, and take zero time. The failed STUDY order will not take a week, and it will not count toward the diminishing study returns for the month. Production commands fail immediately if none of their input resources are available. For instance, RECRUIT in a location with no peasants will immediately fail, taking zero time. However, resources may sometimes become depleted while the command is being executed. In such cases, the command may fail even after it has spent some time executing. Player Entity ------------- Each Olympia player faction has a number. This number is represented by an entity in the game. However, unlike a character, this entity is mostly used as a place holder for the faction. No one can see the faction entity, and it can issue very few orders. For example, suppose player Fate [501] has one character Osswid [5499]. Fate does not exist in any location, so it does not receive a location report, and no one can see it. However, Osswid, being the player character for the faction, is sworn to Fate [501]. Fate may execute only a limited set of administrative orders. Characters, not factions, issue most orders. Do not try to FORM or RECRUIT with the player entity. For most turns, the player entity will have no orders queued for it. The orders a player entity may issue are: ADMIT FORMAT NAME QUIT Quitting -------- To drop out of the game, issue the QUIT order for your player entity. For instance, player 501 would quit by sending in the following orders: begin 812 password unit 812 # don't forget UNIT for the player unit! quit end No turn report will be sent for the turn in which a player quits. More examples ------------- You can replace orders for some units, but leave pending orders for other units alone, by only including UNIT sections for the ones you want to change. If you want to see what orders are queued, but not change anything send in begin 999 # whatever your player number is... end To change your email address, send in begin 999 email new@address.com # give your new address end As a security measure, the confirmation will be sent to both the new and old addresses. To change the name of your faction, issue the NAME order for the faction's player entity: begin 999 unit 999 name "Seekers of Fame and Power" ... Important: Don't forget the UNIT command for the player entity. Order of characters in a location --------------------------------- When a character enters a location, it is added to the end of the list of characters already there. The unit that has been in a location the longest will appear at the top of the list. If a character leaves a location and later returns, it will be put at the end of the list again. For example: Seen here: Candide [1269] Osswid [5499] Feasel the Wicked [1109] Candide has been here longest, followed by Osswid, then Feasel. If Candide were to leave and return, he would appear at the end of the list. If a character unstacks from beneath another unit, the character will appear just after the unit, rather than at the end of the list. For example: Seen here: Candide [1269], accompanied by: Osswid [5499] Feasel the Wicked [1109] Osswid is stacked beneath Candide. If Osswid unstacks, he will appear after Candide, not after Feasel: Seen here: Candide [1269] Osswid [5499] Feasel the Wicked [1109] Command priority ---------------- All orders have a priority of 0-4. Permission commands (ADMIT, HOSTILE, etc.) are priority 0. Zero time commands*, and WAIT, are priority 1. MOVE and FLY are priority 2. The SAIL command is priority 4. All other commands are priority 3. * A zero time command is an order which always takes zero time. This does not include an order which may sometimes take zero time. For instance, UNSTACK is always a zero time order. However, RECRUIT is not, even though RECRUIT may terminate immediately under some conditions. The order scheduler will first try to start all priority 1 orders. Only when no more priority 1 orders are ready to start will a priority 2 order be started. In other words, the order scheduler will not start an order at a higher priority when an order may be started at a lower priority. Orders at the same priority are resolved in location order. If two units in a location are both waiting to start a MOVE order, the first unit in the location will go first. How this is good ---------------- The above description of order priorities may seem complicated, but the intent is to let players ignore same-day synchronization issues in most cases. Rather that needing WAIT to guarantee that GIVE happens before MOVE, the lower priority of GIVE makes this happen naturally. For example, consider three units stacked together, top, mid and bot: top: move ec69 yew mid: unstack recruit bot: recruit These should be executed in the following order: mid: unstack # unstack is prio-1 top: move ec69 # move is prio-2 mid: recruit # recruit is prio-3 [top and bot arrive at ec69] top: yew # yew is prio-3 bot: recruit # recruit is prio-3 The UNSTACK happened first since it's a priority 1 command. The MOVE went second. When top and bot finished moving, there were only priority three commands left, so they ran in location order. Command precedence within a location ------------------------------------ Seen here: Candide [1269] Osswid [5499] Feasel the Wicked [1109] Order precedence within a location is an advantage for commands or skill uses which obtain resources from the location. For instance, if Candide and Osswid both attempted to harvest all of the lumber available in their location, Candide would have precedence, since his harvest order would finish before Osswid's, if they were started on the same day. At the same time... ------------------- No two things ever happen at exactly the same instant in Olympia. Someone always goes first. Suppose two characters were outside of a building (which nobody is inside), and both wanted to enter, to claim it: Seen here: Osswid [5499] Candide [1269] Inner locations: Hooting Own Inn [ep76], inn Both Osswid and Candid issue MOVE ep76 as their first order on day 1 of the month. What happens? Osswid's command begins before Candide's, since Osswid appears before Candid in the location list. Therefore, Osswid will enter the inn first. Order precedence between units in different provinces is undefined. Osswid ? Candide ------- 8 days -------- 8 days -------- city A city B city C If Osswid and Candide both leave for city B on the same day, we cannot predict who will get their first.