Hello,

En parcourant le chapitre sur la Matrice, j'ai noté quelques questions en même temps que je 'bossais' sur les actes élémentaires du Decker (ici). Si vous avez déjà les réponses, je suis preneur.

Le mec qui a toujours plein de questions a écrit:

1 - Attribut mental et configuration du PAN des copains par le decker
Contexte : Page 238, il est écrit que l'indice d'attribut du propriétaire est à utiliser lorsqu'un test de défense requiert un attribut mental.
Question : Si le decker configure le PAN de ses camarades, cela aurait-il du sens d'utiliser l'indice d'attribut du decker plutôt que du propriétaire ? (cela me semblerait logique sauf à dire que c'est l'utilisation qu'en fait le propriétaire qui ouvre les failles ensuite... mais bon sur du cyberware...)


2 - Persistance des marks
Contexte : Pages 231, 233, 238, 241 il est clairement expliqué que si l'appareil marké reboote ou si le decker subit une convergence, alors les marks sont effacées.
Question : Cela semble sous-entendu mais jamais écrit, les marks du decker qui reboote hors convergence (celui qui a posé, pas celui qui est marké) sont-elles bien effacées avec ce reboot (ou persistent-elles) ? 


3 - Reconnaissance de l'auteur de marks
Contexte : Page 242, il est explicité qu'on ne peut reconnaître (au sens distinguer l'auteur) des marks observées que s'on a déjà marké le persona qui a posé ces marks.
Question : A votre avis, faut-il avoir marké le persona en question durant sa session en cours ou n'importe quand ? (les deux réponses me semblent se défendre...)


4 - Distinction des marks lors d'une perception matricielle
Contexte : Pages 237 et 242, il est explicité qu'on obtient le nombre de marks sur une icône sans savoir les propriétaires (sauf cas cité en question 2).
Question : A votre avis, obtient-on quand même le nombre de marks par propriétaire (même sans connaître leur nom) ou juste un total ? (j'aurais tendance à séparer par propriétaire car le look matriciel diffère, mais bon...)


5 - Cas où Contrôler un appareil devient une action de Corruption
Contexte : Pages 239 et 240, il est expliqué que Contrôler un appareil devient une action de Corruption (avec impact SS et tutti quanti) lorsqu'elle est limitée par l'attribut Corruption... et que c'est le cas lorsque l'action demandée à l'appareil n'est pas soumise à un test (et uniquement dans ce cas).
Question : Quelle est la logique qui sous-tend ce raisonnement ? Je ne vois en effet pas pourquoi éjecter un chargeur est plus Corruption-like que tirer une rafale... j'aurais plutôt imaginer un cas où on n'est pas propriétaire / autorisé sur l'appareil, par exemple.

Si vous êtes chauds suite aux premières questions faciles, j'enchaîne avec ma vraie question...

Toujours le même mec, en encore plus casse-pieds a écrit:

6 - Cohérence des attributs utilisés dans les tests matriciels
Contexte : Le chapitre de la Matrice donne tous les tests à faire, un par un, pour réaliser ou résister lors des actions matricielles...
Question : Quelle est la cohérence retenue par les auteurs pour décider des attributs sur chacun de ces tests ? Au départ je pensais avoir au moins trouvé qu'Intuition résistait contre Corruption et Volonté contre Attaque (en plus ça me semblait avoir du sens !)... mais ce n'est finalement pas systématique.

Cette question 6 est clé pour moi, car elle conditionne la facilité pour le MJ et le decker de se rappeler quelques principes clés (facilement applicables en partie) plutôt que d'apprendre (ou imprimer) tous les tests un par un... et ralentir tout le monde en jeu. So, please help.


Merci par avance pour chacune de vos réponses.

NB : les références sont toutes issues du pdf v0 de SR5 (FR)

Dernière modification par Ultyme (01/08/2014 21:55:38)