[N4] ORA sur zone de hack via répétiteurs

[marduck]

Non pas tout a fait.

Seul ton hacker utilise la zone du répétiteur. Donc c'est le seul qui a une ora valide. Les autres n'ont pas d'ora tant qu'ils ne sont pas la cible d'un hacking.

[sco]

Justement la FAQ 1.0 valide "l'exemple de la p61 !" où un Orco, qui n'a aucune raison d'avoir un ORA, en annonce quand même un (parce que c'est comme ça...)

Donc, l'ILO peut annoncer Reset sans même être visée (vive la FAQ -_-). S'il elle est effectivement visée par un prog, elle reset, sinon elle Idle.
Par contre, je ne suis pas sûr qu'elle soit obligée de l'annoncer. Elle peut attendre d'être attaquée pour réagir...

[Docteur Tank]

J'ai ce sujet en tête depuis la lecture de la N4 et ça me fait chier car cet exemple de la p.61 défonce le cœur du jeu (la mécanique d'annonce des oras) ... Je n'ai pas de plus value en terme de lecture et de compréhension par rapport à vous, je ne peux que vous encourager dans vos réflexions (et le lien à faire avec Corvus ?) Vivement qu'on ait une vrai réponse là dessus.

[Arhnayel]

L'ILO qui n'est pas hacker peut annoncer un ORA à la Phase 2. Cet ORA ne peut être que Reset (car ORA sur Zone de Piratage). Toutefois, cet ORA n'est pas encore valide : aucune des conditions de validité d'ORA n'est remplie (pour l'instant). Il n'est donc pas obligatoire d'annoncer cet ORA.

Si l'ILO non hacker n'annonce pas son ORA à la Phase 2 et se fait cibler par un programme de piratage à la Phase 3, elle devra annoncer son ORA à la phase 4. Là, l'ORA est valide et doit donc être annoncé.

Dans tous les cas, l'ILO hacker doit annoncer son ORA à la Phase 2 car il est valide : le hacker adverse vient de s'activer dans la Zone de Piratage de l'ILO. Cet ORA peut être Reset, ou un programme de piratage comme Carbonite, Oblivion, Trinity etc. Si l'ILO hacker n'annonce pas son ORA à la Phase 2, elle le perd. En effet, dès le moment où le hacker adverse s'est activé, l'ILO hacker adverse a eu un ORA valide : elle ne pouvait pas ne pas l'annoncer.

Dans ton exemple, ton hacker peut pirater l'ILO non hacker en opposition contre Reset, et se prendre du piratage par l'autre ILO, sans opposition.

La règle des ORAs :
- si une troupe a un ORA valide à la Phase 2, elle doit l'annoncer ;
- si une troupe a un ORA non valide à la Phase 2, elle peut l'annoncer, en estimant que cet ORA sera validé ultérieurement à la Phase 5 ou à la Phase 6.

Tout ORA annoncé et validé sera fait. Tout ORA annoncé et invalidé deviendra Idle.

Tout ORA qui aurait dû être annoncé en Phase 2 et ne l'a pas été (pour être annoncé en Phase 4 par exemple) est invalidé et devient Idle.

Le joueur réactif doit donc estimer si les conditions de validité d'un ORA sont remplies dès la Phase 2, sans rien mesurer ni vérifier, sauf lignes de vue. S'il estime avoir un ORA déjà valide - et dont la validité sera confirmée à la Phase 5 ou 6 - il doit l'annoncer. S'il estime ne pas avoir d'ORA déjà valide, il peut toutefois l'annoncer (mais n'est pas obligé). Cependant, s'il se trompe dans cette estimation et ne déclare pas son ORA à la Phase 2 pour le déclarer à la Phase 4, et qu'à la Phase 5 ou 6 quand les vérifications sont faites, il s'avère que l'ORA était valide dès la Phase 2, le joueur réactif perd l'ORA de sa troupe... qui finit par faire Idle.

Cette règle, un peu bancale, a pour objectif d'éviter des situations comme celle-ci (exemple de Mattbab, et la FAQ va dans ce sens un peu plus loin) :

- le joueur actif active plusieurs figurines (ordre coordonné, Fireteam...) dont un killer hacker avec Stealth et une figurine sans Stealth ;

- les deux figurines se trouvent dans la Zone de Piratage d'un hacker du joueur réactif à l'issue de la premier compétence déclarée : celui-ci a donc un ORA qu'il doit annoncer obligatoirement à cause de la figurine sans Stealth. Cet ORA est, pour l'instant, uniquement valide contre la figurine sans Stealth. Si le hacker réactif déclarait son ORA contre cette figurine sans Stealth, le killer hacker avec Stealth pourrait l'attaquer sans opposition possible ! Donc, pour éviter ça, il est accordé au hacker réactif de déclarer son ORA contre le killer hacker avec Stealth dès la Phase 2 (Phase où son ORA est obligatoirement déclaré à cause de la figurine non Stealth, je le rappelle) même si pas encore valide puisque la cible de cet ORA utilise Stealth et n'a pas encore attaqué le hacker réactif. Ceci est confirmé dans la FAQ.

Ainsi, lorsque le killer hacker attaque le hacker réactif, les jets se feront en opposition, et le joueur réactif n'a pas été "piégé".

Des liens :
https://forum.corvusbelli.com/threads/faq-1-0-invalid-aro-declaration-p-61-and-p-21.39016/#post-387430
Et :
http://www.bureau-aegis.org/forum/index.php?topic=15955.msg200225#msg200225

[Ayadan]

Je me permets de déterrer le sujet car j'ai l'impression que pour la page 61, vous avez manqué un détail dans l'illustration. Il y a un répétiteur déployable sur le sommet du bâtiment que câline le KoJ et le M-Drone possède lui aussi un Répétiteur. C'est donc normal que les deux PanOs aient des ORA lorsque le Shrouded fait Idle (et ici, il n'utilise pas sa furtivité, sinon ce serait précisé).

Donc pour moi, ce qu'il se passe sur cette page est assez limpide.

[sco]

Le KoJ n'a pas de compétence ou équipement pour agir via un répétiteur => il ne peut pas avoir d'ORA "normalement". Il n'aurait dû avoir un ORA que s'il avait été ciblé par une attaque de hacking.

Mais selon CB on peut annoncer un ORA comme ça, tant que les conditions sont vérifiables à la résolution de l'ordre.

[Aelune]

C'est pas tout à fait le cas à l'heure actuelle, Hellois et Ian ont fait une demande sur FB auprès de la communauté pour savoir ce qu'ils préféraient mais il était pointé que actuellement on était bien sur une déclaration d'ora qui devait être valide dès le début et pas hypothétique

[mike brant]

"Il n'aurait dû avoir un ORA que s'il avait été ciblé par une attaque de hacking."

non règle reset:
"Troopers can only Reset if at least one of these is true:

They are the Active Trooper.
In the Reactive Turn, they have a valid ARO, or are targeted by a Hacking Program or other Comms Attack."

Tu es dans la zone de piratage d'un hacker qui peu te hacker via un programme donc ton ARO reset est valide donc tu peux declarer reset. Moi je le comprend comme ça.

[sco]

on va pas recommencer ^^'

"In the Reactive Turn, they have a valid ARO,"
p21 ORA
"◼ An enemy Trooper activates within its Line of Fire (LoF)." => Non
"◼ An enemy Trooper activates within its Zone of Control (ZoC)." => Non
"◼ It has a Special Skill, weapon, or piece of Equipment allowing it to react to enemy actions without LoF." => l'orco n'a rien pour agir sans LdV
"◼ It is affected by a Template Weapon, or is the target of a Hacking Program or other Comms Attack." => Non
Donc pas d'ORA valide

"or are targeted by a Hacking Program or other Comms Attack." L'Orc n'est pas ciblé par une attaque puisque le hacker fait idle donc Non.

Les règles ne permettent pas à l'Orco d'avoir un ORA valide.
Mais selon CB, on peut annoncer un ordre invalide tant qu'il devient valide à la résolution de l'ordre (cf.p21 5.)...
Et je me demande pourquoi il faut alors vérifier les LdV à la déclaration des ORA (cf.p21 2.) ^^'

Donc ce n'est pas parce que c'est hacker "pouvant attaquer" qui s'active qui permet d'annoncer un reset mais n'importe quelle activation. C'est juste que ça devient Idle s'il n'y a pas d'attaque de hacking.

[Docteur Tank]

Grande nouvelle : la FAQ 1,1 rajoute enfin l'errata qu'il manquait à la page 60. Et l'exemple a été réécrit en spécifiant qu'ici on ne prenait pas en compte stealth
Il aura fallu attendre quelques mois mais on y est ! J'espère que la VF intègrera cette errata !

(PAGE 60) HACKING AREA AND AROS
Enemies entering or acting inside the Hacking
Area of a Hacker while remaining outside that
Hacker's LoF and ZoC can be reacted to with
Hacking Programs or with Reset.

Players can check the Hacking Area.
Measurements must always be made from the
Active Trooper and their Repeaters, checking a
maximum of 8 inches from any point along their
path. If there are Reactive Troopers or Game
Elements within the Hacking Area of the Active
Trooper, they can declare an ARO (See Order
Expenditure Sequence, page 21).

(PAGE 61) EXAMPLE OF HACKING AREA AND
AROS THROUGH A REPEATER

In this example, Stealth is not being used.

During his Active Turn, the Shrouded Hacker
decides to declare Idle as the first Short Skill of
the Order. As shown in the picture, he is outside
his enemies LoF and ZoC, but since he is a Hacker,
he can use the Deployable Repeater, and the MDrone Trooper (who carries the Repeater piece of
Equipment), to increase his Hacking Area, allowing
him to act from his current position.
As the Shrouded Hacker is inside the Orc Hacker's
Hacking Area, the Orc Hacker declares an ARO.
The Orc Hacker declares Oblivion.
The second Skill of the Shrouded Hacker is
Carbonite, dividing his B2 between the Knight of
Justice and the Orc Hacker.
The Knight of Justice has now been targeted by a
Hacking Program, given she an ARO, and she
declare Reset.
The following Face to Face Rolls occur:
• Reset by the Knight of Justice vs Carbonite
from the Shrouded.
o No Modifiers (MOD).
• Oblivion from the Orc Hacker vs Carbonite
from the Shrouded.
o Orc Hacker MODs:
▪ 3 Firewall MOD for using
an Enemy Repeater.
o Shrouded MODs:
▪ If a Saving Roll is required,
the Attack Damage of
Oblivion will suffer a -3
MOD from the Firewall.

[Shoany]

On revient donc bien a la règle qui à toujours été.
Les Ora déclarées doivent être possibles pour être déclaré, et donc non juste hypothétique.

Après ça permet donc de créer des pièges.

Par contre dans le cas particulier des zone de hack via répétiteur, les troupes non hacker peuvent/doivent déclarer leur reset dès qu'il sont dans la zone de hack.

Ils ont coupés la poire en deux en somme