Les messages dans les TMRs sont envoyés au GM
Simplification des messages de tchat liés à un actor: on peut
utiliser les Owners (car les GMs sont owner).
Au lieu de passer le name de l'Actor (qui peut être incorrect si deux
actors ont le même, mais pas les mêmes propriétaires), on passe
directement l'actor pour déterminer mles destinataires de messages
Quand mergeObject est utilisé pour retourner une valeur, faire très
attention à ne pas passer un Item/Actor, ou une de ses sous parties
en premier paramètre sans préciser l'option { inplace: false }
Sinon, le premier paramètre subit une mutation!
Lorsque l'option d'encaisser les dommages était contrôlée
par le MJ, les données envoyées par les joueurs ne correspondaient
pas aux paramètres de la méthode à exécuter par le MJ.
De plus, l'envoi de l'attacker (Actor) était reçu comme un Object,
donc inutilisable en tant qu'Actor.
Jusque là, le 20 indiquait la mort, mais ne diminuait pas la vie
en dessous de - SConst
Désormais:
- la vie passe à -SConst - 1 sur 20 au jet de vie
- Le message indique que le personnage est mort si sa vie est
inférieure à -SConst
- le jet de vie n'est pas fait si le personnage est déjà mort
Les messages de tour sont séparés en deux:
- un message pour tout le monde disant de qui c'est le tour
- un message pour les propriétaires du token pour les informations
de santé (jets de vie à faire, ...)
Seul les propriétaires peuvent déclencher les jets de vie
- gestion des armes à 1/2 mains depuis les armes / le combat
- gestion correcte des compétences d'attaques de créatures
- message pour les macros de compétence d'arme
L'utilisation de la méthode clone() pôur cloner la compétence
supprime l'id de la compétence, du coup l'update pour y
ajouter de l'expérience ne marchait plus et bloquait la suite de la
résolution (pas de messages dans le tchat, ...)
Les créatures peuvent avoir des compétences d'armes (lancer,
mêlée, tir, armes naturelles), de parade, de possession, et générales.
Les initiatives sont cohérentes. Les possessions sont en phase 10
d'initiative.
Déplacement dans le module empoignade du message et de
la vérification d'empoignade en cours.
Le message est donc centralisé (possible de le modifier une fois pour
toutes les utilisations)
Utilisation de itemTypes plutôt que de méthode listItems ou de
filtrer les items par type.
Potentiellement, itemTypes peut être précalculé par Foundry
C'est aussi un peu plus lisibles (conditions du filter moins longues,
et le filtrage par type est mis en avant en premier)
* ajout d'une option pour activer la validation par le MJ
* lors d'un jet d'encaissement, une fenêtre s'ouvre chez le MJ
avec le résultat d'encaissement
* le MJ peut changer le jet d'encaissement
* si le MJ annule, l'encaissement n'a pas lieu
* Attention, si plusieurs MJ, un seul doit valider, sinon
encaissements multiples
