Une fenêtre de répartition est ouverte quand plusieurs
caractéristiques peuvent recevoir l'expérience. Sinon,
l'expérience est attribuée automatiquement.
L'expérience n'est plus ajoutée en Force si supérieure à Taille+4
- style en phase avec le système
- icones attaque/d6/soins pour le HUD
- tooltip plus détaillé pour le HUD
- icône et bouton pour déterminer les chiffres astraux (astrologie)
- tooltips pour les boutons archétype
- suppression de log sur chaque point de coeur
Bloquait les rencontres en TMR.
Quand un rollData ne contient pas les sous-noeuds pouvant être
utilisés par les ajustements possibles, le jet de dés était perdu.
Le calcul d'ajustements ajoute maintenant les noeuds use/ajustements
s'ils ne sont pas fournis, pour éviter le risque.
- Les suivants/compagnons/amoureux sont dans l'onglet description
- si acteurs "liés", ils peuvent avoir des points de coeur
- les jets de volonté peuvent être ajustés s'ils concernent un
compagnon pour lequel on a du coeur
- on peut ajouter des points de coeur (entre la gestion de Chateau
dormant par le gardien et le jet de repos si ce mode est utilisé)
- on peut retirer des points de coeur en perdant du moral (mêmes
conditions)
- on peut passer de tendres moments si les deux acteurs acceptent
- les tendre moments font jouer un jet de moral adapté
- on peut perdre un point de coeur suite à un tendre moment qui ne fait
pas gagner de moral
Simplification de code:
- des Méthodes simples sur une ligne
- utilisation de item.update au lieu de updateEmbeddedDocuments
quand possibe
- renommage des templates SubActeur
- déplacement de logs quand compétence non trouvée
- état général corrigé
- ajout de blessure, mise à jour endurance, ...
- calcul du malus d'état général
- ajustement des jets selon points de vie perdus
Sur Firefor, le onReady n'est jamais appelé, le système n'est alors
pas totalement initialisé, toute la partie calendrier n'est pas prête,
et donc les ajustement d'astrologie.
WARNING: Too many active WebGL contexts. Oldest context will be lost.
Semble lié à la destruction incorrecte de l'Application PIXI des TMR,
en cas de nombreuses ouvertures/fermetures
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, ...)
Le malus appliqué est maintenant correct.
Avant, le malus pouvait avoir une virgule, et donc être arrondi
dans le malus vraiment appliqué même si affiché correctement.
En cours de round en atteignant 2 points d'empoignade, on peut
uniquement entraîner au sol.
En fin de round, si la victime est immobilisée, on peut projeter, ou
faire perdre de l'endurance
Seul le propriétaire du défenseur peut effecuer les contres
d'empoignade ou tenter de se libérer.
Seul le propriétaire de l'empoigneur peut tenter d'empêcher
la libération du défenseur, de projeter au sol, ou de faire perdre
de l'endurance.
- les items d'empoignade sont ajoutés par le MJ
- les caractéristiques du défenseur sont utilisées pour la défense
- la difficulté d'attaque est imposée au défenseur
- les particulières sont en finesse (p133)
- gestion de la difficulté imposée sur la défense
- gestion des particulières en attaque considérées en finesse
- utilisation du rêve actuel pour les personnages
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.
Correction sur les achats: l'objet acheté vient forcément soit d'un
personnage-vendeur, soit des Items globaux.
Ne pas essayer d'acheter autrement car on aurait des données d'item
non structurées, et donc ça ne fonctionnerait pas.
la liste des types (pour aider à la saisie) est une idée mitigée
- ça évite les fautes d'orthographe dans les constantes de types
Mais:
- on peut oublier un type
- si le type n'est pas défini, il est undefined
(donc risques de regressions)
Saisie de tous les types du template.
Reprise du journal d'expérience pour:
- afficher ancienne/nouvelle valeur
- la valeur du changement
- si c'est manuel / automatique
- identifier les dépenses de stress
- identifier les augmentations de compétences
- les changements des compteurs
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)
Par exemple, la mise à jour de quantité d'herbe ne se faisait pas
dans les liste d'équipement des feuilles de conteneurs, lors d'une
fabrication de potion dans les items
