Coucou...
T!TER...
As-tu eu la curiosité de regarder mes messages sur le lien
vers wiwiland là...?
Car j'explique pourquoi on a besoin du GameMode...
De même, le rMarker est conservé, car on en a besoin pour gérer les compagnons, comme c'est fait sur le script du Gomorrah...
Plik a modifié le script du Gomorrah pour en faire un générique pour le présenter sur son site, il n'y a donc pas la gestion des compagnons... Du coup conserver le rMarker n'y est pas trop utile... Dans les faits, c'est utile si tu as besoin de gérer les compagnons...
Quant à la vérification de l'utilisateur de l'activateur, c'est utile...
Car le script du Gomorrah est appliqué sur une porte, que tout à chacun peut activer...
De même, les packages IA des PNJ (d'un mod par exemple) peuvent être foireux, et un PNJ pourra activer un activateur au hasard, se sont des choses qui arrivent...
Quand on commence à faire de la sécurité, on prend toujours les situations pire cas...
Plus accessoirement, ça permet dans notre cas aux compagnons des mods de suivre le PJ, puisque quand le joueur va utiliser la porte/ascenseur, le PNJ compagnon venant d'un mod va lui aussi activer cette porte...
Il faut bien le téléporter au niveau du joueur, histoire de s'assurer qu'il aille bien dans la même cellule...
Sinon, par rapport à ton optimisation...
Il ne faut pas se fier au nombre de lignes, comme chaque langage, ça dépend du compilateur qu'il y a derrière, pas forcément de l'écriture du code lui-même d'un point de vue algorithmique...
C'est assez courant que lorsque l'on essaie d’optimiser un code, et qu'on le fait en réduisant le plus possible les lignes, que le temps d'exécution s'en trouve rallongé, car les compilateurs ont leur propres routines d'optimisations pour optimiser les cas les plus courant... Écrire en version très raccourcie a tendance à nous faire sortir de ces cas courant, et donc les routines d'optimisation du compilateur ne s'appliquent plus...
Si tu veux faire dans la véritable optimisation, tu peux regarder
ici...
Pour illustrer mes histoires d'optimisation, cet exemple est parfait...
La seconde écriture est plus rapide... ça semble logique...
Pourtant, si on regarde su le wiki d'Oblivion,
ça dépend de la façon dont c'est écrit...
Incidemment, ton second script est "drastiquement" plus long à l'exécution que ton premier...
En effet, quand le jeu tombe sur un return, ceci provoque un point de sortie du script, le script reprend donc dès le début...
J'imagine que tu voulais utiliser ton return pour créer une boucle sur le bloc, c'est à priori logique* mais comme le return fait sortir du bloc courant en coupant tout, ça ne fonctionne pas...
Or dans ton premier script, tu fais le return dès le début, et comme expliqué
ici, le système de script va lire le script jusqu'au premier return (à priori il y en a automatiquement un à la fin de chaque script), même quand il ne l'exécute pas...
Il vaut donc mieux placer le return aussi haut que possible dans le script...
*C'est certes logique, mais dangereux...
Comme je l'ai dit sur Wiwiland, le bloc OnActivate n'est joué que sur une unique frame...
Si on fait une boucle dans un tel bloc, bonjour le freeze du jeu...
comme celui du GOMORRAH ou du LUCKY 38...
) connaît ce script et si il veut le faire passer se serai super cool 
). Pour cela, sélectionne chaque choix un par un, clique droit sur la liste en-dessous et créez une nouvelle condition.La fonction c'est IsInInterior, la variable c'est le nom de l'intérieur en question, "run on : subject", puis il faut mettre == 0. Concrètement, pour le bouton "1er étage", il faut mettre comme condition IsInInterior Etage1 == 0.
