En fait, les règles de déroute il faut les appliquer bêtement sans chercher à comprendre ou interpréter. Après, c'est beaucoup plus simple.
Une chose qui m'a aidé c'est que chaque déroute doit se gérer en deux temps:- tu détermines quels sont les buts de déroute valides et tu en choisis un
- tu implémentes la déroute vers ce but
J'ai regardé sur le site "Texas ASL", il y a une Rout Flowchart (qui fait quand même 6 pages, avec 26 footnotes - c'est dire si c'est un mécanisme simple). Et il indique un "surrender check" (le moment où on regarde si on se rend ou pas), mais il le met
avant le moment où on décide d'une destination de déroute.
Or précisément, dans la situation que je décrivais, il faut avoir déterminé les options de déroute pour s'apercevoir que la seule possibilité implique Interdiction/Low Crawl, et que donc on est en Surrender.
C'est un peu ça que je reproche aux règles telles qu'elles sont écrites: je ne demande pas un flowchart complet, mais une description claire des étapes, ça serait quand même drôlement bien.
J'ai même consulté ma terreur, l'ASOP (terreur, parce que vraiment, c'est écrit trop petit, et il a fallu que j'aille la chercher parmi mon bordel), et en dehors de dire que les Disrupted risquent de se rendre au
début de la RtPh, elle ne précise pas l'ordre des opérations dans la RtPh d'une unité.
Résultat, j'ai l'impression que la Rout Flowchart est incorrecte sur ce point: on ne détermine la reddition (hors Disrupted) qu'une fois que la destination est décidée? Sinon, comment on fait pour déterminer que l'unité est "unable to rout away or only able to rout while being subject to Interdiction or resorting to Low Crawl"?