Salut à tous,
Je ne comprends pas l'exemple de hack via répétiteurs de la page 61 de la N4.
1. Le Hacker shrouded déclare idle.
2. Les deux pano en zone de hack (via répétiteurs) déclarent leurs ORA : Pourquoi ? Ils ne sont pas en lof, ni dans la zdc du hacker, ni ne sont pour l'instant ciblés par une attaque de hack.
3. Le hacker shrounded déclare son hack sur ses deux cibles... Pour moi les ORA devraient se faire maintenant.
Aidez-moi !
Je pense qu'il est sous-entendu que dans l'exemple et dans ta demande, la troupe active, en l'occurrence le Shrouded hacker, possède "stealth". (Sinon il n'y aurait pas de question... ?)
Et dans la définition de Stealth sur le pdf de la N4 :
Citation► If the user declares a Short Movement Skill or Cautious Movement within the
Zone of Control of one or more enemies and stays outside their LoF, he does not
grant AROs to those enemies.
Bien que "idle" étant un ordre court de mouvement, l'encadré du stealth ne parle que de "ligne de vue/Line of Fire", alors il me semble que stealth ne vaut rien sous une zone de hacking.
En conséquence, puisque le shrouded est hackable, il me parait logique que dans l'exemple les hackers Pano
puissent doivent réagir après le premier ordre court du shrouded.
Encadré complet de STEALTH :
[spoiler]
CitationSTEALTH
AUTOMATIC SKILL
CC Special Skill, Optional.
REQUIREMENTS
► The user of this Special Skill must be in his Active Turn.
EFFECTS
► The user can declare Cautious Movement inside the Zone of Control of enemy
Models and Markers.
► If the user declares a Short Movement Skill or Cautious Movement within the
Zone of Control of one or more enemies and stays outside their LoF, he does not
grant AROs to those enemies.
► However, if the second Short Skill of the Order is any non-Movement Skill, then
those enemies can react normally in ARO.
► If the Movement of the Trooper with Stealth ends in Silhouette contact with an
enemy who had no LoF against them and declares any non-Movement Short
Skill, then the enemy can only declare CC Attack, Dodge, Reset, or those Skills
that can be used in Engaged state.
► This CC Special Skill can be declared without being in Silhouette contact with
an enemy.
IMPORTANT
Stealth is not effective against Deployable Weapons, or against Troopers with
the Sixth Sense Special Skill.
[/spoiler]
Je ne pensais même pas au stealth ! Mais je crois que j'ai la réponse : c'est grâce aux répétiteurs que les hackers pano peuvent réagir à l'ordre court "idle" du shrouded, c'est bien ça ? Car il est dans leur zone de hack, ils peuvent donc réagir en ORA à la première compétence courte. C'est ça ?
Ah oui, un répétiteur étend la zone de hacking de tous les hackers de l'équipe. Je supposais que dans l'exemple le shrouded était dans la zone de hacking.
Il me semble que dans ce cas, en N3, avec Stealth, il n'aurait pas été possible aux hackers de réagir. (à confirmer apr desplus calés que moi)
Citation de: Mayel le 03 Octobre 2020 à 12:56:03
Il me semble que dans ce cas, en N3, avec Stealth, il n'aurait pas été possible aux hackers de réagir. (à confirmer apr desplus calés que moi)
Pour moi on peut toujours éviter les ORA de hacking avec stealth (sinon ce serait inutile sur les HI JSA). Il est bien précisé que stealth est optionnel, dans l'exemple je pense que le shrouded utilise volontairement idle sans stealth pour pouvoir adapter sa deuxième compétence.
Citation de: Mayel le 03 Octobre 2020 à 12:56:03
Pour moi on peut toujours éviter les ORA de hacking avec stealth
Qu'est-ce qui te fait dire ça dans les règles ?
la règle stealth parle uniquement de la zone de contrôle d'un ennemi ou d'un marqueur, et la zone de hacking est distincte dela zone decontrôle dans les règles.
CitationThe user can declare Cautious Movement inside the Zone of Control of enemy
Models and Markers.
Et une situation sans répétiteur, un stealth hackable qui se faufile dans la ZoC d'un hacker, peut se faire hacker en ORA mais rien d'autre, puisqu'il est aussi dans la zone de hacking.
Concernant l'exemple p.61 :
Stealth n'a rien à voir dans l'exemple de la page 61 - la compétence n'y est d'ailleurs pas mentionnée. Il faut donc abstraction du fait que le Shrouded dispose de cette compétence pour cet exemple.
Le Shrouded s'active et déclare Idle. Les deux figurines PanO étant dans la zone de piratage du Shrouded (étendue par les répétiteurs), elles sont visiblement considérées "comme étant dans sa zone de contrôle". Elles doivent donc déclarer leurs ORAs. L'Orc étant un Hacker, il peut tenter un programme contre le Shrouded, mais il passe par le répétiteur adverse et subit donc les malus d'un firewall (-3 VOL, -3 DMG). Le Knight of Justice n'étant pas Hacker, il déclare tout simplement Reset (sans malus). Le Shrouded peut ensuite déclarer sa seconde compétence (ici, Carbonite).
Concernant Stealth :
Stealth permet à une figurine piratable de ne pas générer d'ORA de piratage en passant dans la zone de contrôle d'une figurine ou d'un marqueur, à l'exception des Armes Déployables (Deployable Weapons) comme les mines, CrazyKolas et autres. Un répétiteur de position n'est pas une Arme Déployable mais un Équipement Déployable (Comms Equipment, Deployable). Une figurine avec Stealth n'est donc pas repérée par un répétiteur de position, et ne génère pas d'ORA de piratage (sauf si le Hacker possède Sixième Sens) tant qu'elle n'effectue que des Actions Courtes de Mouvement ou des Mouvements Prudents (oui, je préfère dire Action Courte que Compétence Courte).
Citation de: Arhnayel le 03 Octobre 2020 à 17:30:42
Concernant l'exemple p.61 :
Stealth n'a rien à voir dans l'exemple de la page 61 - la compétence n'y est d'ailleurs pas mentionnée. Il faut donc abstraction du fait que le Shrouded dispose de cette compétence pour cet exemple.
Le Shrouded s'active et déclare Idle. Les deux figurines PanO étant dans la zone de piratage du Shrouded (étendue par les répétiteurs), elles sont visiblement considérées "comme étant dans sa zone de contrôle". Elles doivent donc déclarer leurs ORAs. L'Orc étant un Hacker, il peut tenter un programme contre le Shrouded, mais il passe par le répétiteur adverse et subit donc les malus d'un firewall (-3 VOL, -3 DMG). Le Knight of Justice n'étant pas Hacker, il déclare tout simplement Reset (sans malus). Le Shrouded peut ensuite déclarer sa seconde compétence (ici, Carbonite).
Merci pour la clarification de l'exemple p. 61. On est ok que cette situation ne se rapproche d'aucune règle explicitée ? Pourquoi est-ce qu'on considère que le shrouded serait dans la zone de contrôle des deux panos ? C'est via les répétiteurs je suppose ?
CitationPourquoi est-ce qu'on considère que le shrouded serait dans la zone de contrôle des deux panos ? C'est via les répétiteurs je suppose ?
C'est ce que l'exemple sous-entend.
Avis perso :Que le Shrouded soit considéré dans la zone de piratage de l'Orc Hacker me semble tout à fait normal : c'est un Hacker, il peut utiliser le répétiteur adverse pour défoncer les Hackers d'en face. Cela est clairement dit dans la règle page 60.
Pour le Knight of Justice, je trouve ça curieux (il n'est pas mentionné Hacker), mais l'exemple sous-entend qu'on considère le Shrouded comme étant dans la zone de contrôle du PanO...
Peut-être que l'exemple contient une coquille, peut-être pas. En attendant un errata/une réponse de CB, il va falloir considérer que l'exemple vaut loi. D'ailleurs, une partie du texte de la règle du répétiteur manque page 60.
Merci pour la clarification, j'étais un peu à côté.
C'est effectivement un peu contre-intuitif puisque la future cible n'a aucune idée de ce qui va lui arriver puisqu'elle n'a pas d'aire de hacking et donc de "ressent" rien au travers d'un répétiteur. Je pense qu'elle doit déclarer un ORA en tant que cible potentielle.
Et si dans ce même exemple, le shrouded était toujours en marqueur camo. Doit-on alors annoncer qu'il s'agit d'un hacker là-dessous pour que l'ILO réactive et dans son aire de hacking déclare son ORA ?
Pour moi cet exemple est une erreur : à la lecture des règles je ne vois pas pkoi les deux Panis pourraient avoir une ora sur une compétence courte hors lof hors zdc et qui ne les cible pas... Soient ils erratent l'exemple soit fait modifier les règles d'ora.
Ou alors le répétiteur est un vrai cas particulier et ils doivent l'expliciter.
Tout de même, est-on bien sûr que Stealth en N4 peut prévenir d'un ORA de hacking ?
Pour répondre oui, il faudrait faire un amalgame entre zone de contrôle et zone de hacking. Or les règles ne le font pas au moment d'expliquer la zone de hacking. Et un répétiteur ne compte clairement pas comme l'extension d'une zone de contrôle. Et la définition de stealth ne parle que de Line of Fire et Zone of Control.
Et c'est important car cette règle ne concerne pas que les ILOS Stealth, maintenant que Spotlight est un ORA.
Dans l'ordre :
CitationC'est effectivement un peu contre-intuitif puisque la future cible n'a aucune idée de ce qui va lui arriver puisqu'elle n'a pas d'aire de hacking et donc de "ressent" rien au travers d'un répétiteur. Je pense qu'elle doit déclarer un ORA en tant que cible potentielle.
Tous les Hackers ont une zone de piratage composée de :
- leur zone de contrôle propre ;
- les zones de contrôles des troupes alliées avec l'équipement Répétiteur (exemple : un Moran, un Iguana, un Zond...) ;
- les zones de contrôles des Répétiteurs de Position déployés par des alliés.
En plus de cela, si le Hacker se trouve dans la zone de contrôle d'un Répétiteur ou Répétiteur de Position enemi, le Hacker peut cibler n'importe quel Hacker adverse. Il se prend toutefois les malus du firewall. Ceci est indiqué page 60.
Conséquence : l'Orc Hacker reçoit une ORA quand le Shrouded s'active, puisque l'Orc se trouve dans la zone de contrôle d'un DCD Répétiteur adverse (allié du Shrouded). Ceci est clair et logique.
Pour le Knight of Justice, c'est moins clair... il n'est pas mentionné Hacker mais doit quand même faire son ORA car il se trouve dans la zone de contrôle d'un Répétiteur de Position adverse, donc il est potentiellement une cible de la seconde action du Shrouded (je pense qu'il devrait déclarer son ORA de Reset une fois que le Shrouded déclare son programme Carbonite et le cible, mais ce n'est visiblement pas le cas dans l'exemple. C'est contre-intuitif, je suis d'accord, et ce sera peut-être erraté plus tard).
CitationEt si dans ce même exemple, le shrouded était toujours en marqueur camo. Doit-on alors annoncer qu'il s'agit d'un hacker là-dessous pour que l'ILO réactive et dans son aire de hacking déclare son ORA ?
Là, non. Contre un marqueur Camo, les troupes peuvent déclarer qu'elles retardent leurs ORA jusqu'à la déclaration de la seconde action du pion camo. Toutefois, si celui-ci ne se révèle pas, les ORA sont perdues... (page 91).
CitationPour moi cet exemple est une erreur : à la lecture des règles je ne vois pas pkoi les deux Panis pourraient avoir une ora sur une compétence courte hors lof hors zdc et qui ne les cible pas... Soient ils erratent l'exemple soit fait modifier les règles d'ora.
Ou alors le répétiteur est un vrai cas particulier et ils doivent l'expliciter.
Pour l'Orc Hacker, c'est au contraire tout à fait normal (j'ai déjà expliqué plus haut).
Pour le Knight of Justice, l'exemple semble curieux, mais...
CitationTout de même, est-on bien sûr que Stealth en N4 peut prévenir d'un ORA de hacking ?
Oui. Page 113 : "If the users declares a Short Movement Skill or Cautious Movement within the Zone of Control of one or more enemies and stays outside their LoF, he does not grant AROs to those enemies." (J'ai ajouté la couleur.)
Et, page 151 : "Enemy. Game elements that belong to the opposing player's Army List or to any of their teammates if the game is played in pairs or groups."
Un Répétiteur de Position posé par l'adversaire est un élément de jeu appartenant à l'adversaire (c'est indiqué dans la colonne précédente "Deployable Equipment"). Une figurine avec Répétiteur est, sans aucune contestation possible, un élément de jeu appartenant à l'adversaire. Même motif, même punition, donc une figurine avec Stealth ne génère pas d'ORA si elle passe dans la zone de contrôle d'une figurine ou d'un pion adverse, tant qu'elle ne fait que déclare des Actions Courtes de Mouvement ou des Mouvements Prudents et qu'elle reste en dehors de toute LoF.
Citation de: Arhnayel le 03 Octobre 2020 à 19:28:37
Dans l'ordre :
CitationC'est effectivement un peu contre-intuitif puisque la future cible n'a aucune idée de ce qui va lui arriver puisqu'elle n'a pas d'aire de hacking et donc de "ressent" rien au travers d'un répétiteur. Je pense qu'elle doit déclarer un ORA en tant que cible potentielle.
Tous les Hackers ont une zone de piratage composée de :
- leur zone de contrôle propre ;
- les zones de contrôles des troupes alliées avec l'équipement Répétiteur (exemple : un Moran, un Iguana, un Zond...) ;
- les zones de contrôles des Répétiteurs de Position déployés par des alliés.
En plus de cela, si le Hacker se trouve dans la zone de contrôle d'un Répétiteur ou Répétiteur de Position enemi, le Hacker peut cibler n'importe quel Hacker adverse. Il se prend toutefois les malus du firewall. Ceci est indiqué page 60.
Conséquence : l'Orc Hacker reçoit une ORA quand le Shrouded s'active, puisque l'Orc se trouve dans la zone de contrôle d'un DCD Répétiteur adverse (allié du Shrouded). Ceci est clair et logique.
Hum, je ne partage pas ton avis, enfin je n'arrive pas à trouver la règle qui explique cet exemple.
La page 21 qui explique les ORA dit qu'on peut faire une ORA quand on est dans la zdc d'une figurine qui agit, et non dans la zone de hack d'une figurine... Ici l'orc est dans la zone de hack du shrouded mais non dans sa zdc. Les deux ne sont pas synonymes pour ce qui est des ORA.
Enfin comme tu le dis l'exemple prévaut... C'est juste que pour moi il entre en contradiction avec la rédaction des règles.
EDIT : cette histoire me tracasse je suis allé jeter un coup d'œil sur le forum ENG. J'ai trouvé deux topics dont celui-ci : https://forum.corvusbelli.com/threads/do-hackers-get-an-aro-when.37912/
Tout est dans la description des hacking device page 60 : "They act in the user's hacking zone" sous entendu pour le déclenchement des ORA également. Mais bon, comme disent les gens en anglais si tu fais une lecture "RAW" tu n'aurais pas le droit de faire d'ORA... Bon c'est mal expliqué quand même je trouve.
J'avais buggé sur cet exemple et les ora en zone de hacking.
Il manque quelque chose aux règles permettant les ora en zone de hacking.
edit : et comme est écrit la furtivité, elle ne marche que dans les ZC. Comme on a perdu la notion de 'zone de hacking = zone de contrôle du hacker', elle ne fonctionne pas dans les zones de hacking.
Par contre, si elle entre dans la ZC du hacker => plus d'ORA...
Ca sent le bon vieux temps des FAQ ;D
Citationedit : et comme est écrit la furtivité, elle ne marche que dans les ZC. Comme on a perdu la notion de 'zone de hacking = zone de contrôle du hacker', elle ne fonctionne pas dans les zones de hacking.
Par contre, si elle entre dans la ZC du hacker => plus d'ORA...
C'est bien comme ça que je le comprends. Sauf que lorsqu'il rentre dans la ZC du hacker ça n'est pas plus d'ORA : c'est pas d'ORA de ZC, mais des ORA de ZH.
Pour moi tout ceci est logique à la lecture des règles, même si c'est dur pour certains profils.
Il était précisé dans la FAQ de la N3 que une figurine avec "stealth" qui passe en zone de hacking ne génère pas d'ORA.
issue de la FAQ p. 7
(If two or more hackable troops, one with Stealth and the other without Stealth, were activated simultaneously within Hacking Area, could I declare Hacking against the troops with Stealth?No, you can only ARO against the troop without Stealth. This does not prevent you from declaring Change Facing or Reset.)
https://assets.infinitythegame.net/downloads/faqs/en/v2.0/faqs.pdf
Il semble que la FAQ ne fait pas différence entre zone de contrôle et zone de hacking car la même question est posée plus loin avec la "Zone de contrôle".
En pratique on le joue comme ça depuis des années en tournoi (stealth empêche le hacking en zone de contrôle / zone de hacking).
C'est clairement l'intention des auteurs que les ORA de zone de hacking soient assimilées aux ORA de zone de contrôle. Je pense qu'ils n'avaient pas perçu que la subtilité pouvait avoir son importance. Pour ça que je trouve que stealth est une règle de merde qui devrait dégager ...
Mise à jour de ma réponse :
https://forum.corvusbelli.com/threads/stealth-and-repeaters.38048/#post-368666
Stealth ne permet pas d'échapper à des ORA de piratage quand la figurine avec Stealth passe dans la ZoC d'un Répétiteur.
La FAQ étant arrivée, nous avons la réponse officielle à cette question, qui tranche en faveur de Stealth :
CitationDoes Stealth work against Reactive Troopers outside Zone of Control?
Yes. Stealth applies to Reactive Troopers who do not have Line of Fire to them, including Hackers who are outside their Zone of Control and do not have Line of Fire.
Une figurine utilisant Stealth et passant dans la zone de piratage - mais pas la zone de contrôle - du hacker adverse ne lui donne aucun ORA (sauf s'il utilise une compétence pour laquelle Stealth ne fonctionne pas, ou s'il passe en ligne de vue du Hacker).
Exemples avec un Moine Shaolin (qui possède Stealth), un Moran répétiteur et Jazz :a) Si un Moine Shaolin déclare "mouvement" dans la zone de contrôle d'un Moran, Jazz ne peut pas déclarer Spotlight sur ce mouvement. Si le Moine ne fait que des mouvements, Jazz n'aura aucun ORA...
b) Cependant, si le Moine déclare une compétence pour laquelle Stealth ne s'applique pas (BS attack, CC attack, Dodge etc.), Jazz obtient un ORA de piratage.
c) Si le Moine décide de ne pas utiliser Stealth sur son mouvement, Jazz a un ORA.
Exemples avec un Ninja camouflé (qui possède Stealth), un Moran répétiteur et Jazz :a) Si un Ninja camouflé déclare "mouvement" dans la zone de contrôle d'un Moran, Jazz ne peut pas déclarer Spotlight sur ce mouvement. Si le Ninja ne fait que des mouvements, Jazz n'aura aucun ORA...
b) Cependant, si le Ninja déclare une compétence le révélant et pour laquelle Stealth ne s'applique pas (BS attack, CC attack, Dodge etc.), Jazz obtient un ORA de piratage.
c) Si le Ninja décide de ne pas utiliser Stealth sur son mouvement, Jazz a un ORA qui ne peut être que Reset. Toutefois, Jazz peut décider de retarder son ORA en attendant la seconde compétence du Ninja, car celui-ci est actuellement un pion camouflé (et on peut toujours retarder son ORA contre un jeton camouflé).
Enfin, Stealth ne s'applique toujours pas contre les équipements déployés (Mines, CK etc.), ni contre les figurines possédant Sixth Sense. Si Jazz est dans une Fireteam de 4 membres, elle gagne Sixth Sense et peut donc avoir des ORA de piratage contre des figurines avec Stealth passant dans sa zone de piratage (et hors ligne de vue / zone de contrôle de Jazz elle-même).
Bref, pour arrêter une HI avec Stealth, il faut la forcer à déclarer d'autres compétences que des mouvements lorsqu'elle est dans la zone de piratage, afin que les hackers gagnent des ORAs contre elle :)
En espérant que cela aide tous les hackers de la Sphère !
Petite question :
J'ai posé sur la table un répétiteur, plusieurs troupes adverses (une ILO non hacker et un hacker) sont couvertes par la zone de contrôle de ce répétiteur.
J'active un de mes hacker (tout seul dans ma ZD) : les troupes adverses sous mon répétiteur doivent déclarer leur ORA.
-Cet ORA doit être forcément Reset pour l'ILO (qui n'est pas hacker).
-Cet ORA peut être Reset ou un programme de piratage avec le type "ORA" pour son copain le hacker.
Ensuite, si en deuxième partie d'ordre, je choisis de cibler l'ILO sous le répétiteur, le hacker à côté peut se retrouver à exécuter un programme de piratage en ORA et sans opposition (avec un Firewall-3).
Et c'est idem durant cet ordre avec tous les autres répétiteurs que j'aurai posé sur la tablesi il y a des hackers dedans.
C'est bien comme ça que ça se passe ?
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.
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...
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.
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
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.
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.
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
"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.
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.
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 !
Citation(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.
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