arcenild a écrit :J'ai une question somme toute technique, un détail, y a t-il une variable globale qui me permette de faire un test de présence ou non (un peu à la façon Giskard pour savoir si le mod est présent dans le jeu PC)?
C'est aussi l'une des techniques qu'utilise COBL écrit par Wrye... Étant donné que le mod est en ses ressources techniquement autonome, sauf pour Ilav, c'est une chose qui ne m'a pas du tout effleurée l'esprit durant la conception de "Cavernes Mirifiques", bien que j'y utilise tout de même une variable globale tel un drapeau sur son statut d'activation. Ce n'est pas le cas de DDND (POTND en anglais), où je n'utilise aucune variable globale: la quête démarre, puis suite à la quête, on choisit le moment de l'arrêt du mod via une sélection du menu de dialogue avec Titus Cubitus, c'est tout. Ce mod n'amène aucun effet technique permanent ni ne dépend de la présence d'aucune ressource du jeux (outre celles d'origine gardées intact et référées directement telle une chaise une pomme ou un sort), en dehors d'Ilav. Il ajoute ses propres objets à Tamriel ainsi qu'une nouvelle guilde (qui sera plus élaborée dans "Cavernes Mirifiques"). De fait, j'avais prévu une variable globale d'état lors des premiers coups de claviers sur ce mod, nommée
fjGlobalPOTND et que tu pourras voir dans le CS, mais je ne l'utilise pas. Pas encore...
Tout d'abord mon approche conceptuelle concernant les PNJ, puis ensuite quelques notes techniques relatives au Mod DDND.
À PROPOS DE PNJ ET DE COMPATIBILITÉ
Je vais même plus loin et plus simple avec CM (Cavernes Mirifiques): détecter la présence de Ilav et de tout autre PNJ impliqué qui est lié au produit de base de Bethesda, puis soit y greffer au démarrage du mod les AI et objets particuliers (étape d'initialisation), soit "cloner" le PNJ dans la cellule en cas d'absence (étape de détection, préalable à l'étape d'initialisation) - j'y bouge une copie de Ilav, qui a été ajoutée par le CS dans une cellule tampon (inaccessible dans le jeux, seulement le CS). Cette technique n'est pas utilisée dans Dévôt des Neuf Divins, mais elle est généralisée dans le mod CM, c'est la cellule nommée "
fjPCMBufferCell". Ainsi, peu importe si un autre mod enlève ou modifie quelque PNJ, ou encore si ce dernier se fait tuer lors d'un contexte différent du jeux: on est certain que le "bon" Ilav apparaîtra en temps opportun, par design. Bien entendu, cela pourrait ne pas faire de sens si la trame du jeux, via un autre mod, fait tuer ou disparaître son "âme" de Tamriel alors que ce n'est pas dans l'histoire fournie par Bethesda, mais bon ça je n'y pourrai jamais rien
...
Outre ce fait que dans DDND je ne clone pas Ilav, le principe de conception visé dans "Cavernes Mirifiques", pour tout PNJ devant avoir des comportements temporaires, est ainsi: les packages particuliers au PNJ que l'on manipule (en l'occurrence Ilav), sont ajoutés via scripts lors de l'accès à la cellule par le joueur (actuellement ils sont ajoutés dans le CS, l'ID du PNJ est
IlavDralgoner). Et ceci, seulement si le mod est actif, c'est-à dire suite à la discussion avec Savlian Matius aux portes de Kvatch (ou encore si Kvatch fut déjà libéré dans une partie sauvegardée), et non suite au chargement du mod parmi les autres plugins du jeux lors du démarrage (via le menu principal concernant les "plugins"). Quand les packages d'AI sont ajoutés dynamiquement via script, le moteur fait en sorte d'en prioriser le rendu sur la suite de la liste associée au AI du PNJ dans le CS, que ce soit "vanille" ou d'un autre mod. Et aussi de le "décharger" de la liste automatiquement à la fin du rendu, laissant intact le PNJ initial, peu importe d'où il provienne. S'il existe toujours dans Tamriel... Car s'il n'y est plus, alors un clone y est "téléporté" lors de du premier accès à la cellule qui correspond au contexte de démarrage du mod:mrgreen. Les conflits potentiels entre les PNJ du mod et ceux des autres mods, ou entre les différents status que peut prendre un PNJ dans le jeux et son déroulement (vivant, mort ou "ailleurs"), se retrouvent ainsi minimisés, et vice-versa en toute convivialité
- Note: Comme je le mentionnais, ce qui précède n'est pas totalement assumé dans Dévôt des Neuf Divins, car les seuls mods qui modifient Ilav sont Kvatch Rebuilt et Aftermath: je préfère me concentrer sur son mod parent (CM) pour le développement, au lieu de me préoccuper de mettre continuellement à jour DDND (ce qui serait une demande ridicule à faire aux utilisateurs d'un si petit mod). Bref: aucun problème avec le premier (Rebuilt), quant au second (Aftermath), bien qu'il ne soit plus disponible pour téléchargement, si on l'a déjà dans son jeux il suffit de charger DDND après lui (plus bas dans la liste de chargement d'OBMM).
Un radar.... La technique (utilisée dans DDND et dans CM): un script attaché à un "activateur" statique, par exemple un élément de terrain ou de décors, qui telle une machine de Turing en ce qui concerne les différents états du jeux, va continuellement sonder la cellule, et seulement lorsqu'elle cette dernière est active (c'est à dire lorsque le joueur s'y trouve). Un peu comme un script de quête, mais pour une cellule donnée: dont l'exécution est localisé dans l'espace, en plus des éventuelles conditions sur les divers états du déroulement du jeux, tel le ferait un script de quête (pour clore la comparaison, le "stop/startQuest" se produirait à chaque arrivée/départ du joueur dans la cellule de l'"activateur", le joueur étant ici l'Oracle de Turing). Et ceci seulement si le mod est actif: c'est-à-dire entre le moment de son démarrage, après avoir accepté d'aider Savlian Matius à libérer Kvatch ou au chargement du jeux sauvegardé alors que Kvatch est déjà libre, et le moment de son arrêt, option de dialogue avec Titus (topic
fjTitusStopQuest: "I think I know enough, let's move on"). Ainsi, selon les états du mod, et plus globalement du jeux, il est possible de contrôler parfaitement les AI d'un PNJ d'origine sans avoir à en modifier l'objet de base. Note que la manipulation d'AI est implantée dans COM, mais pas dans DDND: pour ce dernier il ne s'agit que d'une vérification d'étape de quête afin de faire un EVP sur la liste d'AI associée au PNJ de base (dont les packages sont rendus selon les conditions associées dans le CS).
NOTES CONCERNANT L'ÉDITION VIA LE CS:
- tu constateras que tous les ID d'objet tels les spells, les armures, enchantements, mobiliers, noms des scripts, des quêtes etc., tous commencent par la chaîne "fj", les rendant plus accessibles et repérables dans le CS (pour Cavernes Mirifiques, ce sera "fjPCM"), et il en va de même pour les noms de variables globales qui commencent par "fjGlobal" (DDND) ou "fjPCMGlobal" (COM);
- la quête principale se nomme fjPriestOfTheNineQuest, le script de quête qui y est attaché se nomme "fjProvostOfTheNineQuestSCR";
- dans le script de quête nommé "fjProvostOfTheNineQuestSCR", il apparait un message de test message "In dialog menu mode...",4, tu peux mettre la ligne de code correspondante en commentaire ou la supprimer du script;
- le PNJ de base utilisé pour Titus Cubitus est identifié par fjPriestOfTheNine;
- quelques objets propres à ce mod et définis dans la fenêtre des objets (Armor et Spell), sont inutilisés... Un léger oubli de ma part, tu peus les effacer si tu veux mais ça n'enlève ni n'ajoute rien au mod car ils ne sont pas utilisés (je les avais intégrés pour mes tests de texture et de meshes), notamment:
- Armor / fjActorCrusaderBootsP;
- Armor / fjActorCrusaderGauntletsP;
- Armor / fjActorCrusaderGreavesP.
- Spell / fjPantsOnFire
- Spell / fjShaderTest
- Spell / fjSoulCapture
Voilà, "petit détail" est devenu grand!
... Bonne continuation, et n'hésite pas à me contacter pour toute question.
