
www.Usenet.com
| <-- __Chronological__ --> | <-- __Thread__ --> |
> Quick question, does the judge ever actually screw up orders, or is it > always the human that messes up? In a game I am playing one of the players > is claiming that the Judge screwed up his orders, and I want to know how > possible this is. I've never seen this. I assume you mean that the judge gives a unit a different order than the player sent, and not an adjudication issue. The exception here is that the judge will *always* interpret: fleet por-spa as fleet por-spa/nc mao-spa as mao-spa/nc [anything] s fleet por-spa as [anything] s fleet por-spa/nc [anything] s mao-spa as [anything] s mao-spa/nc fleet con-bul as fleet con-bul/ec [anything] s fleet con-bul as [anything] s fleet con-bul/ec Those are the only orders where the judge will "change" from what the player sent. It seems to me that the type of thing that may have happened to the player is that he sent in multiple order versions for the phase and there were delays that caused the orders to be processed by the judge out of order, or emails not received by the judge at all, or confirmations not received by the player. I've found in the last year that confirmations from judges on order sets are routinely delayed much longer than previously. In the past, I could get a confirmation within a few seconds of sending... it was that fast. Now, it is sometimes several minutes. And that is when my own ISP and the judge's communications and load are in good shape. I suspect it may be new spam and virus filters delaying things at many points. At any rate, a player should always be cautious if he does not get timely confirmations on his orders. This is not a big problem if he is not revising orders. In that case, one of three (more?) things is happening: 1) the judge is down, the orders will be processed when the judge comes back up, 2) the judge's email reception is down/degraded, the player might go late depending on how/when the problem is fixed, and whether the player decides to resend the same orders as he has not received a confirmation, 3) the judge got the email, and interpreted the orders, but the player did not get a confirmation through an email fault... the player might see results without getting a confirmation. If I don't get a confirmation from the judge on a single order set, I go back to my "sent" folder and scrutinize the orders I did send, and double check the expected judge interpretation to make sure all is well if the judge does process the order set ultimately. This is a good time to remember spain and bulgaria... and to double check slips of the mind on places like ven/vie and bur/ber. Things get much more complicated if one sends in an order set that is not confirmed, and then sees or decides that the orders submitted should be changed. Without the confirmations, the initial undesired order sets are potentially dynamite. In this case, the player should decide on his final orders, make sure they are perfect, and include a password change with the orders. If the final orders are confirmed by the judge, the player is in the clear. If and when the judge ever processes the initial undesired order sets, they will be ignored because of an incorrect signon. This is a great trick to use when the situation comes up. I read about it on r.g.d. some time ago (I think it was Rod Spade who posted it, but I'm am not sure). However, if the final order set with password change is not confirmed by the judge and there are one or more order versions issued by the player on the phase (confirmed or not), then the player still potentially has his problem. A good next step is to check to see if the judge is down (the openings list at the DipPouch is a good way to check). The judge may be marked there as down or the player can see if the last response the judge made to the DipPouch was old compared to the other responses from other judges. If the judge looks OK (though it may not be), a good next step for the player is to sign on to a freemail account and send a message to himself at his regular game email, to help determine whether the problem is on the incoming email end of things. Also, sending an email from the regular game email to the freemail account, can help determine whether the problem is on the outgoing mail delivery. If all looks well with the player's email behavior, the only other thing to do is to mail the GM and inform him of the intended final orders as a protective measure. This message should be sent directly to the GM and not through the press command (since the judge could be down), and it should ask the GM to confirm receipt. It may also be a good idea to send order intentions to one or more other neutral (and trusted) parties, particularly if the GM is known to have low quality email service. This way if the judge does not get all mails or processes them out of order, a good case can be made for rolling back the turn and adjudicating with the desired order set. Finally, mulitple order sets can cause a problem in a subsequent phase and the player should be aware of this if timely confirmations are not received. In particular, if the judge processes an order set, and issues results, and then processes another order set that was meant for the just processed phase but delayed somehow, the judge may establish an undesired order for the next phase. This could be for a retreat phase (if the order for the dislodged unit was different in the order sets) or for the next movement phase (if none of the players units moved on the just completed phase). In summary, the judge confirmations are key. If they do not arrive in timely fashion, the player should take steps to protect his interests and not be "victimized". If there are known or recent problems in getting confirmations from a judge, the player could anticipate the potential conflicts ahead of time: 1) double check orders before they are sent, 2) plan on sending only one version of orders for a phase whenever possible, 3) send a "set wait", planning to remove the wait when orders are confirmed and reviewed. Steve
| <-- __Chronological__ --> | <-- __Thread__ --> |