Le perfectionnisme me tuera!
Au fil de mes 2 934 646 aller-retours entre Seyda Nihyn et l'antre des fées, j'ai constaté (ou crois avoir constaté) les deux choses suivantes qu'il me semble utile de signaler (si toutefois je n'enfonce pas des portail ouverts!^^)
1) "setHealth" commandé depuis le script d'une créature sur elle-même ne fonctionne correctement que dans une frame dédiée, avec de préférence quelques autres frames de distance avec des frames où s'effectuent des tests et majs de stats (en tout cas dans des scripts complexes ; j'ai passé pratiquement une nuit 1/2 à ce que Galia se l'applique correctement).
2) Le message d'erreur "compiled script not saved" peut être le signe d'une extermination complète de l'esp, dans certaines circonstances.
Comme d'hab avec le tesc ce n'est pas systématique, mais j'ai déjà fait ce constat plusieurs fois.
Ce coup-ci j'ai identifié, je crois, un type d'erreur qui explose l'esp sous ce message:
placer une globale en argument d'une fonction.
La cirrhose sur le gâteux, c'est qu'une locale pas déclarée est identifiée comme une globale lorsqu'elle est ainsi placée.
Dans ce cas, à la tentative de sauvegarde du script on a le message "only local variables are allowed ligne xxx", + "compiled script not saved".
Même si l'on effectue la correction qui permet de sauvegarder apparemment correctement le script, l'esp est mort si on le sauvegarde.
C'est en tout cas ce qui m'est arrivé la nuit dernière.
Bref oublier une déclaration de variable peut être encore plus grave qu'oublier une déclaration d'impots.
==>
quand on a "compiled script not saved", si l'on n'est pas certain qu'il ne s'applique qu'à un erreur "légère", il vaut mieux fermer le tesc sans rien sauvegarder et le réouvrir si l'on veut être sûr de conserver un esp viable.
1
Deux "tips"
Débuté par
alliop
, 25 juil. 2009 - 23:12
25 réponses à ce sujet
#1
alliop
Renaissance de l'art magique.
Posté 25 juillet 2009 - 23:12
"Bienvenue à toi, lent homme lié, poussif tresseur des vitesses."
Alain Damasio
#2
lnari
Chocapic Cortexicus
Posté 25 juillet 2009 - 23:42
En quoi l'.esp est il "mort" ? Il n'y a pas moyen de l'ouvrir avec le TESAME pour supprimer entièrement le script problématique, et garder le reste, par exemple ?
Ca fait mal.
Ca fait mal.
Rahj Sagas, module de quêtes Morrowind, et la Chaîne Youtube pour quelques trailers.
#3
alliop
Renaissance de l'art magique.
Posté 26 juillet 2009 - 02:45
Merci de ta réponse. 
Avec le TESAME, je ne sais pas, je n'ai pas essayé. Je ne pourrai pas ce coup-ci, l'esp incriminé est à la poubelle.
Ce genre de crash ne me cause pas trop de soucis : je travaille par couches, en créant un nouveau double de l'esp pour chaque nouvelle série de modifs, donc en cas de crash j'ai toujours un backup dont je refais un double neuf et y recopie les nouveautés (corrigées!^^) depuis l'ancien.
*************
Je tiens à vous faire partager ma joie de la découverte d'une nouvelle curiosité touristique :
Lançant un global "RG_sGlobal_Fam_Fee" par la console et voulant y mettre à jour une variable nommée "blocage" à la valeur 6, je tape donc "set RG_sGlobal_Fam_Fee.blocage to 6" (manip déjà exécutée mille fois sans problème, faite cette fois-ci après l'unique modif d'une valeur de timer dans ledit script, qui en a pourtant vu d'autres, et sur une partie neuve), et j'obtiens.....
un éblouissement blanc de l'écran tandis qu'une save automatique s'exécute, et le message d'erreur suivant :
N'est-ce pas splendide? On n'arrête pas le progrès.
J'abandonne pour cette nuit, je vais vomir si je continue. Les familiers seront un peu en retard (ils ne sont plus à ça près) ou pas aussi "parfaits" que je le souhaite.
Avec le TESAME, je ne sais pas, je n'ai pas essayé. Je ne pourrai pas ce coup-ci, l'esp incriminé est à la poubelle.
Ce genre de crash ne me cause pas trop de soucis : je travaille par couches, en créant un nouveau double de l'esp pour chaque nouvelle série de modifs, donc en cas de crash j'ai toujours un backup dont je refais un double neuf et y recopie les nouveautés (corrigées!^^) depuis l'ancien.
*************
Je tiens à vous faire partager ma joie de la découverte d'une nouvelle curiosité touristique :
Lançant un global "RG_sGlobal_Fam_Fee" par la console et voulant y mettre à jour une variable nommée "blocage" à la valeur 6, je tape donc "set RG_sGlobal_Fam_Fee.blocage to 6" (manip déjà exécutée mille fois sans problème, faite cette fois-ci après l'unique modif d'une valeur de timer dans ledit script, qui en a pourtant vu d'autres, et sur une partie neuve), et j'obtiens.....
un éblouissement blanc de l'écran tandis qu'une save automatique s'exécute, et le message d'erreur suivant :
"tesc" dit :
Unable to find faction id '6' in sys window compile & run
J'abandonne pour cette nuit, je vais vomir si je continue. Les familiers seront un peu en retard (ils ne sont plus à ça près) ou pas aussi "parfaits" que je le souhaite.
Modifié par alliop, 26 juillet 2009 - 02:46.
"Bienvenue à toi, lent homme lié, poussif tresseur des vitesses."
Alain Damasio
#4
Finraïl
Modèle de wiwilandais nanotechnologique
Posté 26 juillet 2009 - 08:37
alliop, le 26.07.2009 à 03:44, dit :
"tesc" dit :
Unable to find faction id '6' in sys window compile & run
J'avoue que celle-là, elle vraiment superbe !
Not Quite Dead, le 22.06.2006 à 19:42, dit :
[...]un changement avatarien, même infime, est PAS BIEN et nuisible [...]
Fervent Partisan de l'Immuabilité Avatarienne.
#5
Shadow she-wolf
Le katana de la GBT
Posté 26 juillet 2009 - 08:43
alliop, le 26.07.2009 à 00:11, dit :
1) "setHealth" commandé depuis le script d'une créature sur elle-même ne fonctionne correctement que dans une frame dédiée, avec de préférence quelques autres frames de distance avec des frames où s'effectuent des tests et majs de stats (en tout cas dans des scripts complexes ; j'ai passé pratiquement une nuit 1/2 à ce que Galia se l'applique correctement).
Je ne suis pas sûre que se soit la même chose, surtout avec le mot "frame" dont je ne vois pas ce qu'il fait dans un script...(si on peut m'expliquer...)
Mais sur obli, il y a des pnjs totalement isolé dans un cell intérieure qui doivent faire des patrouilles.
Chacun porte un script tout simple:
Begin OnPackageDone X;lorsque le package IA X se termine Evp; permet de recharger la liste des packages pour choisir le suivant End Begin OnPackageDone Y Evp End
Et ainsi de suite...
Le truc, c'est que ce script ne fonctionne pas correctement (par exemple un pnj reste immobile au lieu de patrouiller) si on applique pas un "bloc de sécurité" en tout début de script comme ceci :
Begin GameMode If GetInSameCell Player != 1 Return EndIf EndJe suppose qu'en extérieur, il serait plus judicieux d'utiliser la fonction GetDistance Player plutôt...
Le script devant mal s'exécuter si l'acteur n'est pas chargé.
Par ailleurs, si on a un script sans le premier "bloc de sécurité" (et qui donc bug) et qu'on le rajoute en cours de partie, le script ne fonctionne quand même pas correctement.
#6
Kafou
Le canari a bouffé le rominet !
Posté 26 juillet 2009 - 11:31
Citation
placer une globale en argument d'une fonction.
(...)
"compiled script not saved"
(...)
"compiled script not saved"
Citation
"set RG_sGlobal_Fam_Fee.blocage to 6"
set "RG_sGlobal_Fam_Fee".blocage to 6
Les guillemets évitent plein de problèmes, notamment le "bug de l'underscore en début d'ID" contre lequel tout le monde met en garde mais que je n'ai jamais rencontré dans la GPL, qui utilise pourtant des underscores partout. J'ai appris plus tard que c'était grâce aux fameux guillemets.
Citation
je travaille par couches, en créant un nouveau double de l'esp pour chaque nouvelle série de modifs, donc en cas de crash j'ai toujours un backup dont je refais un double neuf et y recopie les nouveautés (corrigées!^^) depuis l'ancien.
Citation
Je ne suis pas sûre que se soit la même chose, surtout avec le mot "frame" dont je ne vois pas ce qu'il fait dans un script...(si on peut m'expliquer...)
You look like you need a monkey!
Attention : perfectionniste paresseux.
Attention : perfectionniste paresseux.
#7
Shadow she-wolf
Le katana de la GBT
Posté 26 juillet 2009 - 11:34
Kafou, le 26.07.2009 à 12:30, dit :
Une frame c'est une image à l'écran. Pour chaque frame, chaque script chargé est exécuté exactement une fois.
Bah oui, pour moi c'était ça aussi.
Mais quand je lis "frame dédiée" et "frame de distance", j'ai un peu du mal à faire le lien.
#8
Kafou
Le canari a bouffé le rominet !
Posté 26 juillet 2009 - 11:38
Shadow she-wolf, le 26.07.2009 à 12:33, dit :
Mais quand je lis "frame dédiée" et "frame de distance", j'ai un peu du mal à faire le lien.
Frame de distance, ça sous-entend que tu ajoutes plus d'une frame de décalage entre cette instruction et les précédente/suivante, mais je doute que ça soit utile.
You look like you need a monkey!
Attention : perfectionniste paresseux.
Attention : perfectionniste paresseux.
#9
elendell
Mécano Dell'Arte
Posté 26 juillet 2009 - 11:50
Hello,
Pour le "SetHealth", je n'ai jamais rencontré ce problème mais je ne suis pas sûr de l'avoir déjà utilisée et comme souvent pour les bugs, ça doit dépendre de plusieurs facteurs.
Par contre, j'ai déjà eu droit 2 ou 3 fois à des "esp" à jeter après un "compiled script not saved" et j'ai tendance maintenant à faire comme toi : Si j'ai fait peu de modifications depuis ma dernières sauvegarde, je jette et recommence.
Une fois, j'avais fait beaucoup de modifications sans sauvegarder et j'ai récupéré "l'esp" en supprimant complètement le script->sauvegarde->recharge et nouvelle écriture du script. Réécrire le script sans l'avoir complètement supprimé ne suffisait pas (même s'il se compilait correctement).
C'est vrai qu'elle est belle. Il faudrait faire un recueil de tous les messages hallucinants que ce farceur de Tescs nous envoie pour pimenter nos "scriptages" monotones. 
Je pense qu'alliop voulait dire qu'il ne doit y avoir aucune autre instruction prévue durant la frame où s'exécute le "setHealth" (+ des frames à vide). Par exemple, au lieu de faire ceci :
EDIT :
Même si l'objet est par exemple en mouvement ?
Pour le "SetHealth", je n'ai jamais rencontré ce problème mais je ne suis pas sûr de l'avoir déjà utilisée et comme souvent pour les bugs, ça doit dépendre de plusieurs facteurs.
Par contre, j'ai déjà eu droit 2 ou 3 fois à des "esp" à jeter après un "compiled script not saved" et j'ai tendance maintenant à faire comme toi : Si j'ai fait peu de modifications depuis ma dernières sauvegarde, je jette et recommence.
Une fois, j'avais fait beaucoup de modifications sans sauvegarder et j'ai récupéré "l'esp" en supprimant complètement le script->sauvegarde->recharge et nouvelle écriture du script. Réécrire le script sans l'avoir complètement supprimé ne suffisait pas (même s'il se compilait correctement).
Finraïl, le 26.07.2009 à 09:36, dit :
J'avoue que celle-là, elle vraiment superbe !
Shadow she-wolf, le 26.07.2009 à 09:42, dit :
Je ne suis pas sûre que se soit la même chose, surtout avec le mot "frame" dont je ne vois pas ce qu'il fait dans un script...(si on peut m'expliquer...)
if ( frame == 1 ) instruction A SetHealth 60 instruction C endifIl devrait faire ça :
set frame to frame + 1 if ( frame == 1 ) instruction A elseif ( frame == 5 ) SetHealth 60 elseif ( frame == 9 ) instruction C endif
EDIT :
Kafou, le 26.07.2009 à 12:37, dit :
par contre je tiens à préciser qu'on peut très bien faire Disable et SetDelete dans une même frame sans le moindre problème.
#10
Kafou
Le canari a bouffé le rominet !
Posté 26 juillet 2009 - 11:58
elendell, le 26.07.2009 à 12:49, dit :
Qu'est-ce que tu appelles en mouvement ?
Les Move/Rotate, font partie des fonctions modifiant les caractéristiques de l'objet donc incompatibles avec SetDelete dans la même frame a priori (s'il y a un problème avec le mouvement, c'est SetDelete tout seul qui le cause et non la combinaison Disable/SetDelete).
Quant au déplacement dû à l'IA, je supprime tous les jours des créatures avec Disable/SetDelete et je n'ai jamais eu de problèmes
Ceci dit, j'ai jamais essayé de faire SetDelete sans Disable (encore un automatisme probablement inutile).
You look like you need a monkey!
Attention : perfectionniste paresseux.
Attention : perfectionniste paresseux.
#11
elendell
Mécano Dell'Arte
Posté 26 juillet 2009 - 12:20
Oui, par mouvement je voulais dire tel que Move/Rotate.
Je me suis toujours fié à cette phrase du MSfD : "SetDelete plantera Morrowind si une autre fonction s’exécute sur l’objet dans la même
frame."
Donc, quand je suis sûr qu'aucune autre fonction ne risque de s'appliquer sur l'objet dans la même frame, j'utilise "SetDelete" sans "Disable" et dans le cas contraire, je la fait précéder de "Disable" avec un écart de 2 ou 3 frames.
Je me suis toujours fié à cette phrase du MSfD : "SetDelete plantera Morrowind si une autre fonction s’exécute sur l’objet dans la même
frame."
Donc, quand je suis sûr qu'aucune autre fonction ne risque de s'appliquer sur l'objet dans la même frame, j'utilise "SetDelete" sans "Disable" et dans le cas contraire, je la fait précéder de "Disable" avec un écart de 2 ou 3 frames.
#12
Kafou
Le canari a bouffé le rominet !
Posté 26 juillet 2009 - 12:59
elendell, le 26.07.2009 à 13:19, dit :
Oui, par mouvement je voulais dire tel que Move/Rotate.
Citation
"SetDelete plantera Morrowind si une autre fonction s’exécute sur l’objet dans la même frame."
Citation
Donc, quand je suis sûr qu'aucune autre fonction ne risque de s'appliquer sur l'objet dans la même frame, j'utilise "SetDelete" sans "Disable" et dans le cas contraire, je la fait précéder de "Disable" avec un écart de 2 ou 3 frames.
Par contre le Disable sert seulement à faire disparaître visuellement l'objet hein.
Et merci de confirmer qu'un SetDelete sans Disable ça marche
You look like you need a monkey!
Attention : perfectionniste paresseux.
Attention : perfectionniste paresseux.
#13
elendell
Mécano Dell'Arte
Posté 26 juillet 2009 - 14:22
Kafou, le 26.07.2009 à 13:58, dit :
En théorie, une seule frame d'écart suffit...
).Kafou, le 26.07.2009 à 13:58, dit :
Par contre le Disable sert seulement à faire disparaître visuellement l'objet hein.
J'ai tendance à faire des messages à rallonge par souci de précision et j'essaye donc de m'en empêcher.
C'est pour ça que je n'ai pas parlé de "GetDisabled->Return" de la frame suivante qui empêche ensuite l'application d'une fonction modificatrice dans la même frame que le "SetDelete". Mais on peut également se passer de "Disable" bien sûr.
#14
alliop
Renaissance de l'art magique.
Posté 26 juillet 2009 - 18:43
Hello.
J'espère que vous n'avez pas loupé la messe, je crois que pour cet outil on a vraiment besoin de Sa Grâce (ALMSIVI c'est des amateurs!).
@Shadow : voilà, c'est exactement comme ils disent.
[édité]Sauf que :
... est une simplification un peu abusive.
Ce qui est exécuté "exactement une fois", ce n'est pas "chaque script chargé", mais les instructions de chaque script entre le "begin" et le "end", une ligne après l'autre et dans l'ordre, depuis le premier script jusqu'au dernier et exactement dans leur ordre successif dans le tesc (ordre alphabétique). Donc ce qui est exécuté ce sont les instructions depuis le "begin" du premier script commençant par "A" jusqu'au "end" du dernier script commençant par "z".
Dans le cas d'un script construit sur plusieurs frames avec une variable d'état (genre "if state == 0 / set state to 1"), ce n'est donc pas "le script chargé" qui sera exécutée, mais seulement ses instructions concernées par la valeur de "state" en cours.
L'"image à l'écran" n'est que le résultat visible pour nous de ce qu'est "une frame" : une frame est en réalité une unité de temps : ça représente le temps qu'il faut pour effectuer l'ensemble des calculs nécessaires à afficher une image (une fraction de mouvement), effectivement, et à exécuter toutes les instructions de tous les scripts l'une après l'autre.
C'est pour ça qu'on parle de "frames par secondes" et que ça peut varier ; idéalement, cette unité doit tendre à une durée nulle ("une image" instantanée donnant un "framerate" infini), mais plus il y a d'instructions à exécuter dans cette unité de temps plus elle a tendance à gonfler et donc moins l'U.C. peut en caser dans une seconde, c'est pour ça que l'on constate des "chutes de fps", ou de "framerate" qui veut dire la même chose. Bien sûr plus l'U.C. est puissante plus cette unité de temps est raccourcie. En tout cas la vitesse d'affichage à l'écran ne fait que traduire la vitesse de calcul de l'ensemble des instructions concernant toutes les dimensions du jeu, image, mouvement, gameplay...
Et c'est pourquoi on peut avoir intéret à répartir un script sur plusieurs frames au moyen d'une variable d'état pour alléger chacune d'entre elles et donc minimiser l'impact des instructions de ce script sur les fps.
C'est aussi ce qui doit être utilisé lorsque deux instructions ne peuvent pas être correctement exécutées dans le même "instant" -la même frame- (lorsque l'une doit être achevée avant de pouvoir être testée par l'autre et doit prendre un certain temps pour ça ; c'est l'hypothèse dont on parle là).
Il est donc parfaitement correct et parfaitement clair de parler de "frame dédiée" à une fonction et d'un "écart de distance" entre des blocs d'instructions dans un script (d'accord, en réalité c'est un écart de temps).
C'est bien ce que lit Ellendel.
Voilà, Shadow, l'explication détaillée que tu demandais, désolé mais il y a des choses qu'on ne peut pas vraiment exposer correctement en sms.
@K. & E. : ok; merci, je note pour "SetDelete" ; j'ai tendance à prendre des précautions infinies avec plein de trucs dont celui là, je place toujours un disable + au moins 2 frames avant un setDelete.
Autre cas académique de plantage avec setDelete : quand il est exécuté sur un objet ayant démarré un global qui n'est pas encore stopé lors de la commande (je dis ça pour ne pas être en reste, tout le monde est au courant je suppose ^^).
Essaie de mettre plutôt :
set "RG_sGlobal_Fam_Fee".blocage to 6
Bah oui, bien sûr! les " " sont pour la citation en texte dans le post; à la console je tape :
Comme tu dis Kfou les guillemets ne sont vraiment utiles que quand une ID commence par un underscore, je n'ai jamais eu de problèmes non plus avec l'esp base de nova-magica, sauf un : je n'ai jamais réussi à commander à distance des majs de variables par "_blablaScript".variable.
A propos de SetHealth, voilà l'extrait concerné :
° version qui ne marche pas :
Le "setHealth" est juste après le renseignement "mise à jour des attributs proprement dits", mais j'ai essayé de le placer à d'autres endroits dans la frame, ça ne marche pas non plus.
° Version qui fonctionne :
le SetHealt est juste après le framecount, il est effectué à 10 frames de distance des tests et majs des autres attributs
Autre curiosité :
Je n'ai jamais réussi à obtenir un résultat correct de ce calcul
Bhé non, ça donne 0.25
Par contre :
....
Pour la "faction ID 6", ça ne concernait qu'un esp. Transféré sur une autre install de Morrow sur une autre bécanne, il ne m'a pas refait tout à fait la même mais sa soeur : au chargement de la save il m'annonce :
J'ai donc jeté l'esp et recommencé (ce n'était que 2 scripts à copier/coller).
Je préfère faire ainsi que de tenter des réparations. Au moins je suis absolument certain que c'est propre, en tout cas que s'il y a des erreurs elles ne sont que d'une seule source, mes possibles erreurs de manips d'un outil de nettoyage ne risquant pas de s'y ajouter, même si cet outil est fiable à 100%.
J'espère que vous n'avez pas loupé la messe, je crois que pour cet outil on a vraiment besoin de Sa Grâce (ALMSIVI c'est des amateurs!).
@Shadow : voilà, c'est exactement comme ils disent.
[édité]Sauf que :
Kafou dit :
Une frame c'est une image à l'écran. Pour chaque frame, chaque script chargé est exécuté exactement une fois.
Ce qui est exécuté "exactement une fois", ce n'est pas "chaque script chargé", mais les instructions de chaque script entre le "begin" et le "end", une ligne après l'autre et dans l'ordre, depuis le premier script jusqu'au dernier et exactement dans leur ordre successif dans le tesc (ordre alphabétique). Donc ce qui est exécuté ce sont les instructions depuis le "begin" du premier script commençant par "A" jusqu'au "end" du dernier script commençant par "z".
Dans le cas d'un script construit sur plusieurs frames avec une variable d'état (genre "if state == 0 / set state to 1"), ce n'est donc pas "le script chargé" qui sera exécutée, mais seulement ses instructions concernées par la valeur de "state" en cours.
L'"image à l'écran" n'est que le résultat visible pour nous de ce qu'est "une frame" : une frame est en réalité une unité de temps : ça représente le temps qu'il faut pour effectuer l'ensemble des calculs nécessaires à afficher une image (une fraction de mouvement), effectivement, et à exécuter toutes les instructions de tous les scripts l'une après l'autre.
C'est pour ça qu'on parle de "frames par secondes" et que ça peut varier ; idéalement, cette unité doit tendre à une durée nulle ("une image" instantanée donnant un "framerate" infini), mais plus il y a d'instructions à exécuter dans cette unité de temps plus elle a tendance à gonfler et donc moins l'U.C. peut en caser dans une seconde, c'est pour ça que l'on constate des "chutes de fps", ou de "framerate" qui veut dire la même chose. Bien sûr plus l'U.C. est puissante plus cette unité de temps est raccourcie. En tout cas la vitesse d'affichage à l'écran ne fait que traduire la vitesse de calcul de l'ensemble des instructions concernant toutes les dimensions du jeu, image, mouvement, gameplay...
Et c'est pourquoi on peut avoir intéret à répartir un script sur plusieurs frames au moyen d'une variable d'état pour alléger chacune d'entre elles et donc minimiser l'impact des instructions de ce script sur les fps.
C'est aussi ce qui doit être utilisé lorsque deux instructions ne peuvent pas être correctement exécutées dans le même "instant" -la même frame- (lorsque l'une doit être achevée avant de pouvoir être testée par l'autre et doit prendre un certain temps pour ça ; c'est l'hypothèse dont on parle là).
Il est donc parfaitement correct et parfaitement clair de parler de "frame dédiée" à une fonction et d'un "écart de distance" entre des blocs d'instructions dans un script (d'accord, en réalité c'est un écart de temps).
C'est bien ce que lit Ellendel.
Voilà, Shadow, l'explication détaillée que tu demandais, désolé mais il y a des choses qu'on ne peut pas vraiment exposer correctement en sms.
@K. & E. : ok; merci, je note pour "SetDelete" ; j'ai tendance à prendre des précautions infinies avec plein de trucs dont celui là, je place toujours un disable + au moins 2 frames avant un setDelete.
Autre cas académique de plantage avec setDelete : quand il est exécuté sur un objet ayant démarré un global qui n'est pas encore stopé lors de la commande (je dis ça pour ne pas être en reste, tout le monde est au courant je suppose ^^).
Citation
Citation
"set RG_sGlobal_Fam_Fee.blocage to 6"
Essaie de mettre plutôt :
set "RG_sGlobal_Fam_Fee".blocage to 6
set RG_sGlobal_Fam_Fee.blocage to 6
Comme tu dis Kfou les guillemets ne sont vraiment utiles que quand une ID commence par un underscore, je n'ai jamais eu de problèmes non plus avec l'esp base de nova-magica, sauf un : je n'ai jamais réussi à commander à distance des majs de variables par "_blablaScript".variable.
set "_script".variable to X; n'a jamais fonctionné pour moi set script.variable to X; a toujours fonctionné à tous les coups(maintenant je n'utilise pratiquement plus ni unerscores devant, ni guillemets, ni vurgules, nulle part)
A propos de SetHealth, voilà l'extrait concerné :
° version qui ne marche pas :
Le "setHealth" est juste après le renseignement "mise à jour des attributs proprement dits", mais j'ai essayé de le placer à d'autres endroits dans la frame, ça ne marche pas non plus.
Spoiler
° Version qui fonctionne :
le SetHealt est juste après le framecount, il est effectué à 10 frames de distance des tests et majs des autres attributs
Spoiler
Autre curiosité :
Je n'ai jamais réussi à obtenir un résultat correct de ce calcul
; Globale vaut 0.25 set LocaleA to (-1 * Globale ) set LocaleB to ( 1.25 + LocaleA )Ca devait donner +1, n'est-ce pas?
Bhé non, ça donne 0.25
Par contre :
set localeB to ( Globale - 1.25 )me donne bien -1
....
Pour la "faction ID 6", ça ne concernait qu'un esp. Transféré sur une autre install de Morrow sur une autre bécanne, il ne m'a pas refait tout à fait la même mais sa soeur : au chargement de la save il m'annonce :
"tesc" dit :
Unable to find faction ID "" in script [un script tout à fait différent pas modifié du tout dans cet esp!!!!]
Je préfère faire ainsi que de tenter des réparations. Au moins je suis absolument certain que c'est propre, en tout cas que s'il y a des erreurs elles ne sont que d'une seule source, mes possibles erreurs de manips d'un outil de nettoyage ne risquant pas de s'y ajouter, même si cet outil est fiable à 100%.
Modifié par alliop, 26 juillet 2009 - 18:44.
"Bienvenue à toi, lent homme lié, poussif tresseur des vitesses."
Alain Damasio
#15
Kafou
Le canari a bouffé le rominet !
Posté 26 juillet 2009 - 20:24
alliop, le 26.07.2009 à 19:42, dit :
Ce qui est exécuté "exactement une fois", ce n'est pas "chaque script chargé", mais les instructions de chaque script entre le "begin" et le "end", une ligne après l'autre et dans l'ordre, depuis le premier script jusqu'au dernier et exactement dans leur ordre successif dans le tesc (ordre alphabétique). Donc ce qui est exécuté ce sont les instructions depuis le "begin" du premier script commençant par "A" jusqu'au "end" du dernier script commençant par "z".
Par contre, les scripts ne s'exécutent pas dans l'ordre alphabétique. Si par script tu crées un objet auquel est associé un autre script (quel qu'il soit) son script sera exécuté lors de la même frame quoi qu'il arrive, et même si son nom se classe avant dans l'ordre alphabétique. A partir de ce fait (et puis aussi parce que c'est encore ce qu'il y a de plus simple à programmer), j'ai supposé que les scripts s'exécutaient simplement dans l'ordre dans lequel les objets auxquels ils sont attachés apparaissent dans la cellule (et donc dans l'esp, pour les objets non créés par script). Pour les globaux, je sais pas !
Citation
Et c'est pourquoi on peut avoir intéret à répartir un script sur plusieurs frames au moyen d'une variable d'état pour alléger chacune d'entre elles et donc minimiser l'impact des instructions de ce script sur les fps.
Citation
Bah oui, bien sûr! les " " sont pour la citation en texte dans le post; à la console je tape :
set RG_sGlobal_Fam_Fee.blocage to 6
Je disais qu'il ne coûtait rien de rajouter des guillemets pour éviter des problèmes à la con.Citation
Autre curiosité :
Je n'ai jamais réussi à obtenir un résultat correct de ce calcul
Bhé non, ça donne 0.25
Je n'ai jamais réussi à obtenir un résultat correct de ce calcul
; Globale vaut 0.25 set LocaleA to (-1 * Globale ) set LocaleB to ( 1.25 + LocaleA )Ca devait donner +1, n'est-ce pas?
Bhé non, ça donne 0.25
set LocaleA to ( (-1) * Globale )Ou encore mieux, un bon vieux zéro :
set LocaleA to ( 0 - Globale )
You look like you need a monkey!
Attention : perfectionniste paresseux.
Attention : perfectionniste paresseux.
#16
alliop
Renaissance de l'art magique.
Posté 26 juillet 2009 - 23:52
Ok, ok, je ne cherchais pas à te contredire, je ne trouvais pas ta définition "fausse" bien sûr (me permettrais pas, j'ai pas vraiment les moyens!^^), mais un peu sommaire pour répondre à la question de Shadow, qui semblait ne pas savoir qu'un même script peut être exécuté sur plusieurs frames. C'est quand même important de le comprendre, c'est une fonction assez basique.
Soit, mais c'est plus précisément "exécuter les instructions d'un script faites pour être exécutées dans cette frame là", alors que d'autres dans le même script peuvent être exécutées dans plusieurs frames suivantes, c'est ça que je veux préciser à Shadow parce que c'est de ça qu'on parle et qu'elle ne percutait pas.
Je retiens ce que tu dis, qu'il vaut mieux exécuter un maximum de calculs dans une frame que les répartir. C'est vrai que j'ai tendance à faire l'inverse... mais j'utilise souvent des fonctions lourdes (cf tous les "set[stat]" ci-dessus), et je crains qu'une seule frame en pic de performance puisse geler le jeu dans certaines circonstances, par exemple en situation de combat avec des animations de sorts.
J'ai souvent constaté le phénomène, justement en cumulant une exécution peu légère en une frame et des effets de sorts un tant soit peu massifs (par ex les effets cumulés d'un sort combiné ; c'est flagrant dans les "invocations perverties", qui cumulent des calculs et majs de stats et des placement d'activators explosant des sorts combinés).
Que les scripts s'exécutent dans l'ordre alphabétiques, je le tiens de Nenphea et je l'ai également lu quelque part, genre le forum de Yaccobi, un post de Galsiah ou de Timeslip (je sais plus), et c'est constatable dans GCD (Ascension).
C'est vrai que les scripts d'objets créés font exception, de même que les scripts startés.
C'est d'ailleurs sans doute la raison pour laquelle on a constaté que "un startscript lançant un global fait exécuter une seconde fois les globaux déjà exécutés dans la même frame" : c'est sans doute les globaux placés après le script starté dans la chaine alphabétique, qui sont rééxécutés après celui-ci si son start est placé plus bas.
Euh... je suis clair? ... si le script global "Zigouigoui" starte le script global "Abération", tous les globaux de la liste vont être exécutés une seconde fois dans la même frame, mais pas si c'est "Abération" qui starte "Zigouigoui". Faudrait tester ça mais je prends les paris (c'est sans doute pour ça que certains d'entre nous en font l'expérience alors que d'autres n'ont pas le problème... ça dépend des IDs).
OOOOOOOOK! Merci à toi! (Mais pour le coup j'ai lâché l'affaire, me suis trop cassé les dents là dessus, j'ai la migraine, l'impression de trimer dans un camp sibérien et plus de modder pour le plaisir -si ça n'inclut pas le mien, alors où va-t-on???!!^^.... je verrai ça un jour en y revenant, si ce jour arrive).
Citation
en fait là tu viens de définir ce que signifie "exécuter un script une fois"
Je retiens ce que tu dis, qu'il vaut mieux exécuter un maximum de calculs dans une frame que les répartir. C'est vrai que j'ai tendance à faire l'inverse... mais j'utilise souvent des fonctions lourdes (cf tous les "set[stat]" ci-dessus), et je crains qu'une seule frame en pic de performance puisse geler le jeu dans certaines circonstances, par exemple en situation de combat avec des animations de sorts.
J'ai souvent constaté le phénomène, justement en cumulant une exécution peu légère en une frame et des effets de sorts un tant soit peu massifs (par ex les effets cumulés d'un sort combiné ; c'est flagrant dans les "invocations perverties", qui cumulent des calculs et majs de stats et des placement d'activators explosant des sorts combinés).
Que les scripts s'exécutent dans l'ordre alphabétiques, je le tiens de Nenphea et je l'ai également lu quelque part, genre le forum de Yaccobi, un post de Galsiah ou de Timeslip (je sais plus), et c'est constatable dans GCD (Ascension).
C'est vrai que les scripts d'objets créés font exception, de même que les scripts startés.
C'est d'ailleurs sans doute la raison pour laquelle on a constaté que "un startscript lançant un global fait exécuter une seconde fois les globaux déjà exécutés dans la même frame" : c'est sans doute les globaux placés après le script starté dans la chaine alphabétique, qui sont rééxécutés après celui-ci si son start est placé plus bas.
Euh... je suis clair? ... si le script global "Zigouigoui" starte le script global "Abération", tous les globaux de la liste vont être exécutés une seconde fois dans la même frame, mais pas si c'est "Abération" qui starte "Zigouigoui". Faudrait tester ça mais je prends les paris (c'est sans doute pour ça que certains d'entre nous en font l'expérience alors que d'autres n'ont pas le problème... ça dépend des IDs).
Citation
Les opérateurs unaires (le "moins" de -1) son souvent mal compilés. Pour éviter ça : parenthèses ! Ce qui donne (pas testé, mais ça devrait être bon) :
set LocaleA to ( (-1) * Globale )Ou encore mieux, un bon vieux zéro :
set LocaleA to ( 0 - Globale )
OOOOOOOOK! Merci à toi! (Mais pour le coup j'ai lâché l'affaire, me suis trop cassé les dents là dessus, j'ai la migraine, l'impression de trimer dans un camp sibérien et plus de modder pour le plaisir -si ça n'inclut pas le mien, alors où va-t-on???!!^^.... je verrai ça un jour en y revenant, si ce jour arrive).
"Bienvenue à toi, lent homme lié, poussif tresseur des vitesses."
Alain Damasio
#17
Kafou
Le canari a bouffé le rominet !
Posté 27 juillet 2009 - 08:59
Citation
Soit, mais c'est plus précisément "exécuter les instructions d'un script faites pour être exécutées dans cette frame là", alors que d'autres dans le même script peuvent être exécutées dans plusieurs frames suivantes, c'est ça que je veux préciser à Shadow parce que c'est de ça qu'on parle et qu'elle ne percutait pas.
Citation
J'ai souvent constaté le phénomène, justement en cumulant une exécution peu légère en une frame et des effets de sorts un tant soit peu massifs (par ex les effets cumulés d'un sort combiné ; c'est flagrant dans les "invocations perverties", qui cumulent des calculs et majs de stats et des placement d'activators explosant des sorts combinés).
Citation
C'est vrai que les scripts d'objets créés font exception, de même que les scripts startés.
C'est clair que ma constatation n'a été faite qu'avec les objets créés... mais en fait, quand je crée des objets, que je sauvegarde le jeu (et donc -> rajoute les objets dans la cellule via le fichier .ess qui n'est autre qu'un plugin de plugin), quand je charge cette partie les scripts s'exécutent toujours dans le même ordre. Donc j'aurais tendance à penser que ce que tu dis n'es valable que pour les scripts globaux.
Citation
C'est d'ailleurs sans doute la raison pour laquelle on a constaté que "un startscript lançant un global fait exécuter une seconde fois les globaux déjà exécutés dans la même frame" : c'est sans doute les globaux placés après le script starté dans la chaine alphabétique, qui sont rééxécutés après celui-ci si son start est placé plus bas.
).Citation
définir ce que signifie
You look like you need a monkey!
Attention : perfectionniste paresseux.
Attention : perfectionniste paresseux.
#18
Shadow she-wolf
Le katana de la GBT
Posté 27 juillet 2009 - 09:43
Kafou, le 27.07.2009 à 09:58, dit :
Citation
Soit, mais c'est plus précisément "exécuter les instructions d'un script faites pour être exécutées dans cette frame là", alors que d'autres dans le même script peuvent être exécutées dans plusieurs frames suivantes, c'est ça que je veux préciser à Shadow parce que c'est de ça qu'on parle et qu'elle ne percutait pas.
Et il vaut mieux pour faire un pno.
Alliop, c'était essentiellement un problème de vocabulaire que j'avais, j'ai tout appris sur le tas, pas dans les tuto, alors le vocabulaire à tendance à m'échapper...
Mais maintenant je sais, merci à vous.
#19
alliop
Renaissance de l'art magique.
Posté 27 juillet 2009 - 12:26
@ Shadow : t'inquiète, j'apprends moi aussi surtout "sur le tas" en pondant des centaines de kilomètres de scripting foireux avant quelques dizaines tournent, ce qui me conduit souvent à aller farfouiller des tutos et des forums.
@Kfou : je suis globalement ravi que tu insistes sur le fait que les scripts en eux mêmes n'ont que peu d'incidence sur le framerate, on a eu tendance à me reprocher beaucoup d'user de globaux à tire-larigo, et j'ai toujours opposé le même constat que toi : ça ne coûte pas grand chose -mais pas tt à fait rien non plus au cumul-. C'est flagrant avec Ascension, qui initialise son incroyable usine atomique en quelques frames qu'on ne sent absolument pas passer -mais GCD est époustoufliquement magistralement construit et écrit, faut dire-.
On ne sent pas passer non plus ses calculs de majs de niveaux de talents, qui ne sont pas des scripts "simples", quand ils s'effectuent "normalement" c a dire un par un de temps en temps ; par contre avec "incantation", où les calculs de 6 majs de niveaux "simultanés" (c'est à dire immédiatement successifs dans la même frame) sont effectués par GCD (pour conclure qu'ils ne doivent pas être appliqués seulement si ces augmentations de niveaux viennent d'effets de "malédictions", sinon GCD n'assimile pas un saut de plusieurs niveaux et meurt sur le coup), on sent très très nettement un accrochage sur une frame.
C'est cette frame là qu'il faut craindre lorsqu'elle a lieu durant des effets 3D massifs, qui sont les trucs les plus lourds comme effectivement tu le signales. D'accord ce n'est pas le script en lui même, c'est le cumul ; que les effets 3D viennent de scripts moddés qui les convoquent ou de scripts moteurs (effets de sorts par ex), c'est kif kif.
Mais de toute façon un "effet 3D", "convoqué par script" ou pas, n'est jamais qu'un script très lourd quelque part dans le moteur : ta constatation de la "légèreté des scripts" signifie simplement que nous n'écrivons en général pas des scripts aussi lourds que ceux qui gèrent les particules, les nifs, leurs anims, et leurs texturations... mais parfois la goutte d'eau peut faire déborder le vase, il peut y avoir des scripts moddés relativement moins légers que la moyenne et/ou mal écrits.
Le problème dans ce cas vient de la création multiple d'objets 3D dans une même frame : il faut que le jeu charge les modèles correspondants. Ce n'est pas le script lui-même qui fait geler le jeu. Et effectivement, créer un objet fait partie des fonctions lourdes à ne pas exécuter par dizaines dans une même frame ! (sauf s'ils n'ont pas d'existence 3D, c'est typiquement mon cas quand je crée mes activators temporaires qui ont un EditorMarker.nif... et qui ne font pas exploser de sort ! ils servent juste de support pour des scripts ayant besoin de coordonnées 3D en paramètre)
Oui. Quelques précisions : c'est bien un EditorMarker que j'utilise, et il n'y en a qu'un seul. Effectivement ce n'est pas le script ni cette création d'objet mais ses effets : placé lors d'une invocation, l'activateur caste un "humanoïde frénétique" de zone 500, tandis que le PCCrime level est porté à 100 : à Seyda par ex, toute la population attaque l'invoc et PJ (joyeux bordel!) ; avec bloodmoon + Nova (qui booste la magicka de tous les pnjs), ça devient une combat de mages généralisé, les "vents brisants" fusent dans tous les sens... et là dessus il arrive que la créature invoquée soit atteinte d'une crise de "corruption", qui a pour effet de la remplacer par une créature de Dagoth tandis qu'elle même se trouve projetée en l'air et voit son scaleratio "fondre" de 1 à 0.2 en deux secondes avant d'être disabled/deleted.
Bref ça te donne complètement raison : il y a là le pataquès d'un cumul d'effets lourds qui apporte une période glaciaire totale une fois sur trois. Mais je gage que si Ascension est installé sans le patch de Finraïl et que le joueur se met en incantation justement à ce moment là (ce qui est plus que probable), ce n'est plus "une fois sur trois" mais "à tous les coups" ^^.
Faut être aussi attentifs aux dosages qu'un parfumeur, quoi.
Je ne sais pas. Je pense que la "simultanéïté" n'existe pas, en réalité, si? Un ordi ne traite jamais exactement "simultanément" plusieurs lignes de commande, n'est-ce pas? C'est en réalité une succession d'instructions par micro-secondes. Soit le moteur de Morrow traite les scripts entiers l'un après l'autre soit il intercale leurs lignes en alternant sa lecture des scripts, mais il doit forcément y avoir un ordre, même si c'est "le même script en 100 exemplaire" : dans ce cas ce sont 100 références d'un même objet qui ont en réalité chacune une ID dédiée d'instance (0000000, 0000001, etc....) et il doit donc déterminer son ordre de lecture selon ces IDs (d'où probablement les merdes qu'on peut avoir lorsqu'on essaye d'agir de l'extérieur sur une instance différente de la première, même si celle-ci est disabled dans une autre cell -en tout cas avec le TESC2, pas avec le 3 qui est quand même nettement plus évolué, mieux fini, et permet d'identifier les instances , comme de différencier la valeur de base d'un talent sous un modificateur même si celui-ci n'est pas une "malédiction"! etc...^^-).
Je suppose donc que si l'ordre alphabétique est valable pour les globaux, il l'est aussi pour les locaux, la "simultanéïté" ne consistant jamais qu'à "traiter dans la même frame" (d'où le "poids" quand il y a beaucoup d'instructions).
Si un objet portant un script "Marcel" débarque dans le jeu après l'exécution des scripts "Robert", en toute logique son script devrait s'exécuter dans la frame suivante, que les locaux et les globaux soient traités dans des procédures différentes ou non. Mais ma foi tu me dis l'inverse, je te crois... alors la question reste ouverte : quel est l'ordre d'exécution des locaux?
Que les globaux startés puissent relancer l'exécution des autres dans la même frame (c'est aussi dans le MFSD) et pas les locaux, bah ça peut n'être qu'une curiosité touristique supplémentaire du tesc2, qui n'est pas à ça près.
Franchement je ne sais pas, en tout cas on ne peut pas constater ce genre de trucs "de visu", on n'a pas le regard assez pointu pour identifier chaque frame (sauf en diaporama lorsque le moteur exécute trop de commandes par frames pour pouvoir satisfaire tous les clients!! ^^).
@Kfou : je suis globalement ravi que tu insistes sur le fait que les scripts en eux mêmes n'ont que peu d'incidence sur le framerate, on a eu tendance à me reprocher beaucoup d'user de globaux à tire-larigo, et j'ai toujours opposé le même constat que toi : ça ne coûte pas grand chose -mais pas tt à fait rien non plus au cumul-. C'est flagrant avec Ascension, qui initialise son incroyable usine atomique en quelques frames qu'on ne sent absolument pas passer -mais GCD est époustoufliquement magistralement construit et écrit, faut dire-.
On ne sent pas passer non plus ses calculs de majs de niveaux de talents, qui ne sont pas des scripts "simples", quand ils s'effectuent "normalement" c a dire un par un de temps en temps ; par contre avec "incantation", où les calculs de 6 majs de niveaux "simultanés" (c'est à dire immédiatement successifs dans la même frame) sont effectués par GCD (pour conclure qu'ils ne doivent pas être appliqués seulement si ces augmentations de niveaux viennent d'effets de "malédictions", sinon GCD n'assimile pas un saut de plusieurs niveaux et meurt sur le coup), on sent très très nettement un accrochage sur une frame.
C'est cette frame là qu'il faut craindre lorsqu'elle a lieu durant des effets 3D massifs, qui sont les trucs les plus lourds comme effectivement tu le signales. D'accord ce n'est pas le script en lui même, c'est le cumul ; que les effets 3D viennent de scripts moddés qui les convoquent ou de scripts moteurs (effets de sorts par ex), c'est kif kif.
Mais de toute façon un "effet 3D", "convoqué par script" ou pas, n'est jamais qu'un script très lourd quelque part dans le moteur : ta constatation de la "légèreté des scripts" signifie simplement que nous n'écrivons en général pas des scripts aussi lourds que ceux qui gèrent les particules, les nifs, leurs anims, et leurs texturations... mais parfois la goutte d'eau peut faire déborder le vase, il peut y avoir des scripts moddés relativement moins légers que la moyenne et/ou mal écrits.
Kafou, le 27.07.2009 à 09:58, dit :
Citation
J'ai souvent constaté le phénomène, justement en cumulant une exécution peu légère en une frame et des effets de sorts un tant soit peu massifs (par ex les effets cumulés d'un sort combiné ; c'est flagrant dans les "invocations perverties", qui cumulent des calculs et majs de stats et des placement d'activators explosant des sorts combinés).
Bref ça te donne complètement raison : il y a là le pataquès d'un cumul d'effets lourds qui apporte une période glaciaire totale une fois sur trois. Mais je gage que si Ascension est installé sans le patch de Finraïl et que le joueur se met en incantation justement à ce moment là (ce qui est plus que probable), ce n'est plus "une fois sur trois" mais "à tous les coups" ^^.
Faut être aussi attentifs aux dosages qu'un parfumeur, quoi.
Citation
Tous les scripts "d'objets" ? (locaux quoi) Ou bien juste ceux des objets créés ? Et quid du cas où il y a plusieurs fois le même script ?
Je suppose donc que si l'ordre alphabétique est valable pour les globaux, il l'est aussi pour les locaux, la "simultanéïté" ne consistant jamais qu'à "traiter dans la même frame" (d'où le "poids" quand il y a beaucoup d'instructions).
Si un objet portant un script "Marcel" débarque dans le jeu après l'exécution des scripts "Robert", en toute logique son script devrait s'exécuter dans la frame suivante, que les locaux et les globaux soient traités dans des procédures différentes ou non. Mais ma foi tu me dis l'inverse, je te crois... alors la question reste ouverte : quel est l'ordre d'exécution des locaux?
Que les globaux startés puissent relancer l'exécution des autres dans la même frame (c'est aussi dans le MFSD) et pas les locaux, bah ça peut n'être qu'une curiosité touristique supplémentaire du tesc2, qui n'est pas à ça près.
Franchement je ne sais pas, en tout cas on ne peut pas constater ce genre de trucs "de visu", on n'a pas le regard assez pointu pour identifier chaque frame (sauf en diaporama lorsque le moteur exécute trop de commandes par frames pour pouvoir satisfaire tous les clients!! ^^).
"Bienvenue à toi, lent homme lié, poussif tresseur des vitesses."
Alain Damasio
#20
Kafou
Le canari a bouffé le rominet !
Posté 27 juillet 2009 - 13:29
alliop, le 27.07.2009 à 13:25, dit :
nous n'écrivons en général pas des scripts aussi lourds que ceux qui gèrent les particules, les nifs, leurs anims, et leurs texturations...
Le code qui gère ce que tu cites est compilé dans Morrowind.exe, sous forme d'instructions directement compréhensibles par ton processeur : contrairement aux scripts qu'on utilise pour modder, rien n'est interprété. La liberté de programmation est bien plus grande, et l'exécution bien plus rapide (à ceci près que chez Bethesda on code avec les pieds). D'autant plus qu'un paquet de tout ça est effectué directement dans la carte graphique.
Ce que je citais pour la création d'objets c'est surtout le chargement : il y a un accès disque pour obtenir les nouvelles données à afficher, puisque celles-ci n'ont pas été chargées quand tu es entré dans la cellule courante. Et un disque dur, c'est lent. Et il faut interpréter le fichier .nif pour obtenir des données affichables sur la carte graphique. Etc.
Citation
Je ne sais pas. Je pense que la "simultanéïté" n'existe pas, en réalité, si? Un ordi ne traite jamais exactement "simultanément" plusieurs lignes de commande, n'est-ce pas?
).Citation
Soit le moteur de Morrow traite les scripts entiers l'un après l'autre soit il intercale leurs lignes en alternant sa lecture des scripts, mais il doit forcément y avoir un ordre,
Il faudrait tester plus en profondeur.
Citation
Franchement je ne sais pas, en tout cas on ne peut pas constater ce genre de trucs "de visu", on n'a pas le regard assez pointu pour identifier chaque frame (sauf en diaporama lorsque le moteur exécute trop de commandes par frames pour pouvoir satisfaire tous les clients!! ^^).
You look like you need a monkey!
Attention : perfectionniste paresseux.
Attention : perfectionniste paresseux.
#21
elendell
Mécano Dell'Arte
Posté 27 juillet 2009 - 16:59
Hello !
Comme ce sont des particularités qui peuvent avoir des conséquences, j'ai voulu les vérifier. Pour l'ordre de lecture des globaux, il faut apporter une précision importante : Les globaux ne sont pas lus par ordre alphabétique mais dans l'ordre de leurs lancements.
Tant que le joueur ne quitte pas sa partie, le jeu sait dans quel ordre ils ont été lancés et continue à les traiter dans cet ordre.
Par contre, lors d'une sauvegarde le jeu note quels scripts sont actifs mais pas dans quel ordre ils ont été lancés. Donc, quand on recharge cette sauvegarde, il les relance par ordre alphabétique (par défaut).
On se retrouve donc lors d'un chargement avec tous les scripts traités à chaque frame dans leur nouvel ordre de lancement, qui est l'ordre alphabétique par défaut. Mais les suivants ne seront pas lus par ordre alphabétique puisque le jeu traite les scripts suivant leur ordre de lancement. Les nouveaux scripts lancés en cours de jeu ne se retrouveront donc insérés dans l'ordre alphabétique des précédents que lorsque le joueur rechargera une nouvelle sauvegarde.
Pour la deuxième proposition : "un startscript lançant un global fait exécuter une seconde fois les globaux déjà exécutés dans la même frame", je ne suis pas parvenu à le vérifier. J'ai utilisé plusieurs scripts mais les derniers essayés sont les suivants :
J'ai essayé dans tous les ordres de lecture, et avant ou après recharge. Si j'ai bien compris l'idée émise, quand tous les scripts sauf "Aberation" sont actifs et que je fais "set Go to 1", je devrais avoir les conséquences suivantes :
- "AAAA" met "Frame" à 1
- "Kafou" met "Execution" à 1 car "Frame" est à 1
- "Zigouigoui" lance "Aberation" car "Frame" est à 1
Ce qui aurait pour résultat (selon ton idée) de faire à nouveau exécuter dans la même frame tous les scripts (et uniquement ceux-là) qui se situent alphabétiquement après "Aberation" :
- "AAAA" laisse "Frame" à 1 puisqu'on est toujours dans la même frame est qu'il n'est pas concerné
- "Kafou" est concerné et devrait donc mettre "Execution" à 2 car "Frame" est toujours à 1
Là encore, il doit y avoir d'autres conditions car dans mes essais, "Execution" est toujours à 1 et jamais à 2.
Note : J'ai également essayé de lancer "Aberation" manuellement pour l'enregistrer comme actif dans la sauvegarde et qu'il soit relancé ensuite dans l'ordre alphabétique mais le deuxième "StartScript" fait par "Zigouigoui" après recharge, n'a pas eu l'effet recherché non plus.
Peux-tu m'indiquer à quelle page c'est indiqué pour que j'essaye d'approfondir le sujet ?
alliop, le 27.07.2009 à 00:51, dit :
Que les scripts s'exécutent dans l'ordre alphabétiques, je le tiens de Nenphea et je l'ai également lu quelque part, genre le forum de Yaccobi, un post de Galsiah ou de Timeslip (je sais plus), et c'est constatable dans GCD (Ascension).
... on a constaté que "un startscript lançant un global fait exécuter une seconde fois les globaux déjà exécutés dans la même frame" : c'est sans doute les globaux placés après le script starté dans la chaine alphabétique, qui sont rééxécutés après celui-ci si son start est placé plus bas.
Euh... je suis clair? ... si le script global "Zigouigoui" starte le script global "Abération", tous les globaux de la liste vont être exécutés une seconde fois dans la même frame, mais pas si c'est "Abération" qui starte "Zigouigoui".
... on a constaté que "un startscript lançant un global fait exécuter une seconde fois les globaux déjà exécutés dans la même frame" : c'est sans doute les globaux placés après le script starté dans la chaine alphabétique, qui sont rééxécutés après celui-ci si son start est placé plus bas.
Euh... je suis clair? ... si le script global "Zigouigoui" starte le script global "Abération", tous les globaux de la liste vont être exécutés une seconde fois dans la même frame, mais pas si c'est "Abération" qui starte "Zigouigoui".
Comme ce sont des particularités qui peuvent avoir des conséquences, j'ai voulu les vérifier. Pour l'ordre de lecture des globaux, il faut apporter une précision importante : Les globaux ne sont pas lus par ordre alphabétique mais dans l'ordre de leurs lancements.
Tant que le joueur ne quitte pas sa partie, le jeu sait dans quel ordre ils ont été lancés et continue à les traiter dans cet ordre.
Par contre, lors d'une sauvegarde le jeu note quels scripts sont actifs mais pas dans quel ordre ils ont été lancés. Donc, quand on recharge cette sauvegarde, il les relance par ordre alphabétique (par défaut).
On se retrouve donc lors d'un chargement avec tous les scripts traités à chaque frame dans leur nouvel ordre de lancement, qui est l'ordre alphabétique par défaut. Mais les suivants ne seront pas lus par ordre alphabétique puisque le jeu traite les scripts suivant leur ordre de lancement. Les nouveaux scripts lancés en cours de jeu ne se retrouveront donc insérés dans l'ordre alphabétique des précédents que lorsque le joueur rechargera une nouvelle sauvegarde.
Pour la deuxième proposition : "un startscript lançant un global fait exécuter une seconde fois les globaux déjà exécutés dans la même frame", je ne suis pas parvenu à le vérifier. J'ai utilisé plusieurs scripts mais les derniers essayés sont les suivants :
Spoiler
J'ai essayé dans tous les ordres de lecture, et avant ou après recharge. Si j'ai bien compris l'idée émise, quand tous les scripts sauf "Aberation" sont actifs et que je fais "set Go to 1", je devrais avoir les conséquences suivantes :
- "AAAA" met "Frame" à 1
- "Kafou" met "Execution" à 1 car "Frame" est à 1
- "Zigouigoui" lance "Aberation" car "Frame" est à 1
Ce qui aurait pour résultat (selon ton idée) de faire à nouveau exécuter dans la même frame tous les scripts (et uniquement ceux-là) qui se situent alphabétiquement après "Aberation" :
- "AAAA" laisse "Frame" à 1 puisqu'on est toujours dans la même frame est qu'il n'est pas concerné
- "Kafou" est concerné et devrait donc mettre "Execution" à 2 car "Frame" est toujours à 1
Là encore, il doit y avoir d'autres conditions car dans mes essais, "Execution" est toujours à 1 et jamais à 2.
Note : J'ai également essayé de lancer "Aberation" manuellement pour l'enregistrer comme actif dans la sauvegarde et qu'il soit relancé ensuite dans l'ordre alphabétique mais le deuxième "StartScript" fait par "Zigouigoui" après recharge, n'a pas eu l'effet recherché non plus.
alliop dit :
Que les globaux startés puissent relancer l'exécution des autres dans la même frame (c'est aussi dans le MFSD) et pas les locaux
#22
alliop
Renaissance de l'art magique.
Posté 27 juillet 2009 - 17:45
[oups, erreur de clavier, ça a posté en pleine rédaction!!]
Re-jour
Merci et bravo, Elendell! (Voilà le genre de chose que j'ai rarement le courage de faire!^^).
@Kafou : oui oui je sais bien que le moteur n'est pas programmé avec le tesc mais plutôt avec les pieds : sises scripts le programme étaient correctement écrits, performants, légers, ça se saurait! Et que les scripts en tesc-langage doivent être interprétés va plutôt dans mon sens : cet interpré(ta?)teur doit aussi avoir son coût en ressources et s'il était optimisé, ou ne serait-ce que correct, on aurait sans doute moins de problèmes du genre "mauvaise compilation des opérateurs unaires" etc...
Quand à la CG, c'est aussi une petite puce qui lit desscripts programmes et a sa mémoire dédiée, donc ça revient toujours à un rapport de la puissance de traitement et du coût des exécutions.
En effet je n'avais pas tenu compte des accès disques! Ca oui, ça fait une sûre différence.
La référence est dans le MFSD9, page 153 du PDF
Il n'y a ni mention d'origine de test ni aucune autre indication...
L'exhumation de cette citation est due à Nerwall. Nous en avions discuté sur le forum MR, j'avais fait quelques tests (mais avec un algo que je ne pense pas adéquat), je n'étais pas parvenu à le vérifier non plus, et j'avais conclu que c'est plutôt faux.
Mais Nerwal semblait imputer pas mal de problèmes de Nova à cette affirmation, en tout cas il en émettait l'hypothèse.
Comme il s'agissait de startscripts effectués depuis des greetings, je pense pour ma part que le problème venait plutôt de là : certaines fonctions appelées depuis les dialogues ont parfois tendance à se répéter il me semble! (par ex je pense que le problème de redoublement d'instance du familier au drop de l'item vient de là : dans Nova-base le "placeAt" est effectué par le résult de dialogue lui même -EDIT : oups je dis une connerie monstre, alors que je viens de passer une semaine justement sur tout ça!! ... le placement de l'item n'est pas fait par un dialogue, mais dans la même frame que le "if (onPCDrop)"... c'était plutôt ça, la cause du redoublement....-).
Voili voilou
RE-Edit :
Voilà la citation du commentaire de Nerwal sur le forum MR, je ne résiste pas à vous la ressortir :
... où l'on reconnait le plus authentique style Normand du néo-classicisme flamboyant!!! ^^
[re-re-Edit] :
Merci Kafou pour les précisions de vocabulaire ci-dessous, en effet j'en ai bien besoin en la matière! (vais pas flooder pour ça)
Re-jour
Merci et bravo, Elendell! (Voilà le genre de chose que j'ai rarement le courage de faire!^^).
@Kafou : oui oui je sais bien que le moteur n'est pas programmé avec le tesc mais plutôt avec les pieds : si
Quand à la CG, c'est aussi une petite puce qui lit des
En effet je n'avais pas tenu compte des accès disques! Ca oui, ça fait une sûre différence.
La référence est dans le MFSD9, page 153 du PDF
MFSD9 dit :
Warning: When you use startscript, all the scripts that have been run before you called
startscript will be re-run, so scripts could be run more than once in the same frame.
startscript will be re-run, so scripts could be run more than once in the same frame.
L'exhumation de cette citation est due à Nerwall. Nous en avions discuté sur le forum MR, j'avais fait quelques tests (mais avec un algo que je ne pense pas adéquat), je n'étais pas parvenu à le vérifier non plus, et j'avais conclu que c'est plutôt faux.
Mais Nerwal semblait imputer pas mal de problèmes de Nova à cette affirmation, en tout cas il en émettait l'hypothèse.
Comme il s'agissait de startscripts effectués depuis des greetings, je pense pour ma part que le problème venait plutôt de là : certaines fonctions appelées depuis les dialogues ont parfois tendance à se répéter il me semble! (par ex je pense que le problème de redoublement d'instance du familier au drop de l'item vient de là : dans Nova-base le "placeAt" est effectué par le résult de dialogue lui même -EDIT : oups je dis une connerie monstre, alors que je viens de passer une semaine justement sur tout ça!! ... le placement de l'item n'est pas fait par un dialogue, mais dans la même frame que le "if (onPCDrop)"... c'était plutôt ça, la cause du redoublement....-).
Voili voilou
RE-Edit :
Voilà la citation du commentaire de Nerwal sur le forum MR, je ne résiste pas à vous la ressortir :
Nerwal dit :
Comme ça a été rajouté dans la 9e édition ce serait étonnant que ce soit faux, mais ce serait encore plus étonnant que ce soit vrai
[re-re-Edit] :
Merci Kafou pour les précisions de vocabulaire ci-dessous, en effet j'en ai bien besoin en la matière! (vais pas flooder pour ça)
Modifié par alliop, 27 juillet 2009 - 18:24.
"Bienvenue à toi, lent homme lié, poussif tresseur des vitesses."
Alain Damasio
#23
Kafou
Le canari a bouffé le rominet !
Posté 27 juillet 2009 - 18:12
alliop, le 27.07.2009 à 18:44, dit :
@Kafou : oui oui je sais bien que le moteur n'est pas programmé avec le tesc, mais bon si ses scripts étaient correctement écrits ça se saurait,
(...)
Quand à la CG, c'est aussi une petite puce qui lit des scripts et a sa mémoire dédiée, donc ça revient toujours à un rapport de la puissance de traitement et du coût des exécutions.
(...)
Quand à la CG, c'est aussi une petite puce qui lit des scripts et a sa mémoire dédiée, donc ça revient toujours à un rapport de la puissance de traitement et du coût des exécutions.
Merci elendell pour les tests. Si jamais tu as le courage de faire de même avec les scripts locaux et placeitem, surtout ne te retiens pas...
You look like you need a monkey!
Attention : perfectionniste paresseux.
Attention : perfectionniste paresseux.
#24
alliop
Renaissance de l'art magique.
Posté 27 juillet 2009 - 18:45
Outre les remierciements pour le vocabulaire (déjà faits en édit ci-dessus), tant pi je reposte quand même pour préciser ceci : le redoublement de placements d'items commandés par des résults de dialogues a été pleinement vérifié dans les corrections entre la Nova bêta et la Nova ici en dl :
Au "Marais de la sorcière", en fonction de certaines options de dialogues, une hutte doit prendre feu, et pour celà des objets "flammes" sont placés sur son toit.
Tant que c'était commandé par un script en résult, on n'arrivait à rien de correct car les objets se dédoublaient ou n'étaient carrément pas placés du tout (probablement à cause d'une démultiplication de placement supérieure à 2* et buguant carrément l'exécution). On n'a résolu le problème qu'en ayant recours à un global (par contre je ne sais plus si je l'ai starté depuis le résult ou depuis la mise à jour d'une variable sur un activateur extérieur sous "menumode/return" -ce que je ferais maintenant à coup sûr-).
Je sais bien que les scripts en résults sont censés ne s'exécuter qu'une seule fois, mais il semble donc qu'il y ait exception pour certaines fonctions. En tout cas on n'a jamais réussi, ni Nerwal ni moi, à réussir cet effet par le résult (donc pas non plus avec un "if (doonce)...".
Au "Marais de la sorcière", en fonction de certaines options de dialogues, une hutte doit prendre feu, et pour celà des objets "flammes" sont placés sur son toit.
Tant que c'était commandé par un script en résult, on n'arrivait à rien de correct car les objets se dédoublaient ou n'étaient carrément pas placés du tout (probablement à cause d'une démultiplication de placement supérieure à 2* et buguant carrément l'exécution). On n'a résolu le problème qu'en ayant recours à un global (par contre je ne sais plus si je l'ai starté depuis le résult ou depuis la mise à jour d'une variable sur un activateur extérieur sous "menumode/return" -ce que je ferais maintenant à coup sûr-).
Je sais bien que les scripts en résults sont censés ne s'exécuter qu'une seule fois, mais il semble donc qu'il y ait exception pour certaines fonctions. En tout cas on n'a jamais réussi, ni Nerwal ni moi, à réussir cet effet par le résult (donc pas non plus avec un "if (doonce)...".
"Bienvenue à toi, lent homme lié, poussif tresseur des vitesses."
Alain Damasio
#25
elendell
Mécano Dell'Arte
Posté 27 juillet 2009 - 22:30
Kafou, le 27.07.2009 à 19:11, dit :
Si jamais tu as le courage de faire de même avec les scripts locaux et placeitem, surtout ne te retiens pas...
Mais à tout hasard, qu'est-ce qu'il faudrait savoir pour "PlaceItem" ?
0 utilisateur(s) li(sen)t ce sujet
0 membre(s), 0 invité(s), 0 utilisateur(s) anonyme(s)
