simplification des tests de droits pour savoir si on transmet
l'appel de méthode à un MJ connecté.
De manière générale, si on est le owner: pas besoin d'appel remote.
Donc si MJ pas besoin.
Si on a un appel remote, seul un MJ le traite.
Calcul automatique des informations dérivées:
- vie max
- endurance max
- bonus dommages
Ces informations ne peuvent plus être saisies.
L'endurance max des animaux est vie+constitution.
Les entités non-incarnées n'ont pas de +dom
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
Lors d'une partie, la feuille d'un personnage a été bloquée.
Après debug, il semble que l'objet a eu le flag estContenu=true
sans être contenu.
En regardant le json, il semble que des Item "objet" se sont retrouvés
avec un champ "contenu", et que l'arbre des contenant a été cassé.
Du coup: l'ajout dans un conteneur est maintenant "sécurisé" pour
éviter l'accident. si on essaie d'ajouter dans un Item non conteneur,
on positionne estContenu à false, et on corrige si possible le "contenu"
de la cible, qui ne devrait pas être là.
Dans certains cas mal identifiés, on pouvait avoir un problème de droits
sur l'acteur, quand plusieurs joueurs accédaient en même temps à
l'équipement porté par une mule, par exemple
Le contexte des constructeurs est partagé entre Actor et Items,
il faut donc enlever l'indicateur qui sert au choix de la bonne
classe dérivée, sans quoi certains objets/acteurs peuvent être
créés en utilisant le type de base, ce qui empêche d'ouvrir
certains items d'acteurs après avoir redémarré le monde
Par exemple, après ajout d'une blessure et redémarrage, il était
impossible de réouvrir la feuille du personnage blessé.
Correction de l'erreur qui était affichée chez les joueurs lors de
hooks utilisés pour effectuer des modifications sur des
documents:
- ChatMessage, ajout de flags pour l'heure
- Item au sein d'un Actor pour mettre à jour certains éléments
- remplacement des données/JSON dans le html par des Flags sur
le ChatMessage
- extraction de la gestion des infos de ventes pour rassembler la
génération du ChatMessage
- on ne perd plus la quantité ou le vendeur
- attention au mergeObject: il modifie le premier parametre, ce
qui modifiait parfois l'acteur (!!!) et toujours la quantité de
l'objet du vendeur lors de la création de l'objet de l'acheteur!
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
- 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
- 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)
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.
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)
- Séparation des timestamp / calendrier
Les poisons/maladies/souffles/queues/rencontres/signes peuvent
être temporaires.
- Ajout de champs pour stocker les timestamps de début et fin
- définition de la durée (selon les items)
- extraction des classes spécialisées des items
- initialisation des dates de début/fin des effets temporaires à
l'ajout d'un item temporel
- préparation de la suppression automatique
- Fix de mauvaise présentations sur les dialog d'astrologie
et d'édition du calendrier
