Sal*Perie De Création Kit ! L'Heure Est Grave
#1
Posté 06 février 2013 - 00:42
Bethesda se fiche vraiment de notre poire !!
Comme vous le savez, on a un lot de bugs étranges avec le PNOS, en particulier le PNODG.
Sérana qui ne suit pas et d'autres joyeusetés par exemple...
Quand je regardais pourquoi dans le CK, je ne voyais rien d'anormal..sauf que je regardais sans charger le PNOS..(quel idiot)
En l'occurence , après avoir ressortit l'artillerie lourde (l'activation des traces de notification de papyrus) on s'est rendut compte que sur certaines quêtes modifiées par le PNODG pour des raisons TYPOGRAPHIQUES (rien a voir donc avec des corrections de bugs a proprement parler ni meme de scripts) nous avons tres exactement perdu la MOITIE DES VALEURS ATTRIBUEES AUX ALIAS de certains scripts des dites quêtes
Parmis lesquelles ont trouve des quetes... qui font partie de la main quest de DG
Nico, qui travaille sur le correctif Heartfire me confirme que le problème vient bien du Création Kit car il la lui même rencontré pendant le développment. iL me reste a lui demander des détails...
Alors maintenant que l'on a trouvé pourquoi, il nous reste à faire la liste des quêtes impactées et à proposer un nouvel esp.
Il devrait arriver cette semaine, le plus tot possible...
Nous nous excusons pour la gêne occasionnée . C'est vraiment horrible et nous en somme très peinés .
Il ya fort à parier que malheureusement , malgré le correctif corrigé ( ) il faudrat recommencer les quêtes impactées ou les finir à coup de console mais nous seront là pour assurer le suivit.
Allez y, préparez les jets de tomates et de fruits pourrits, nous sommes parés.
Punaise, pnoteur, c'est un métier. Nom de dieu
#3
Posté 06 février 2013 - 01:15
Shéogorath - Prince de la folie
Vrai Grand Moddeur et FPIA à ses heures...#4
Posté 06 février 2013 - 03:50
En fait je pige pas comment vous avez perdu des données...
En tout cas bon courage pour la réparation.
#5
Posté 06 février 2013 - 11:22
Même tard,
Restera ouvert.
#6
Posté 06 février 2013 - 12:00
Quand à savoir ce qui est touché, je pense au correctif Dawnguard seulement. Il faut dire que je n'ai regarde que ce correctif pour le moment
Les quêtes impactées sont :
DLC1dunRedwaterDenQST
DLC1VQ02
DLC1VQ05
DLC1VQ07
DLC1VQ08
DLC1VQSaint (pas sur pour celle là, il était tard hier soir)
On notera que cela concerne entre autre la quête ou l'on doit escorter Sérana au chateau pour la première fois, et aussi la quête dans le Cairn de l'ame (cela expliquerait peut etre l'immortalité de la bestiole?) : deux bug reportés ici-même.
Bon, j'y retourne
#7
Posté 06 février 2013 - 12:20
#8
Posté 06 février 2013 - 13:15
Bonne chance et bon courage.
#9
Posté 06 février 2013 - 14:01
Warwolf, le 06 février 2013 - 12:20, dit :
Ce n'est pas comme si les bugs des DLC étaient aussi nombreux que pour le jeu vanilla.
EldradNerevar, le 06 février 2013 - 13:15, dit :
Citation
Avec l'esp corrigé, j'ai quand meme le bug de Sérana.
Pour les quetes ultérieures j'ai un peu plus d'espoir mais bon..
#10
Posté 06 février 2013 - 18:29
En gros quand on fait un mod qui touche aux quêtes existantes, il faut faire attention aux alias qui peuvent être modifiés sans raison.
Déja quand modifiant les propriétés des scripts certaine propriétés peuvent bugguer, va vraiment falloir faire attention lorsque l'on va modder.
#11
Posté 06 février 2013 - 19:50
En développant le PNO Dawnguard il m'est arrivé de corriger des erreurs de typo (traduction, grammaire, orthographe, formulation de la langue... bref, du texte exclusivement) dans des textes de quest stages ou quest objectives. Le CK a donc créé un record lié à la quête modifiée dans l'esp de notre correctif, mais le fourbe a eu la mauvaise idée de vider la moitié des properties associées aux scripts de la quête sans prévenir... Et en jeu Papyrus crache des logs d'erreur car forcément les scripts font du coup appel à des properties qui sont vides !
Si j'affirme que c'est un bug du CK c'est parce que j'ai eu le problème en développant le correctif Hearthfire (pas encore rendu public à ce jour). J'ai bêtement et péniblement cherché d'où pouvaient venir toutes ces erreurs dans mes scripts jusqu'à ce que j'aille par hasard faire un tour dans les properties qui leur étaient associées et que je me rende compte que la moitié étaient vides (sur des scripts de quête vanilla). Je cherchais l'erreur dans les scripts alors qu'elle était dans l'esp qui ne remplissait plus les properties fautives...
C'est également ce qui est arrivé sur le PNO Dawnguard, et pour que cela arrive 2 fois ça ne peut pas être un accident.
Le message est donc très clair pour tous les moddeurs: si jamais vous touchez à une quête vanilla pensez à vérifier l'état des properties associées à ses scripts. Le problème ne se pose pas si vous créez une quête de toutes pièces : en effet, normalement vous allez remplir vous même vos properties...
On travaille dur pour vous proposer un correctif aussi vite que possible.
#12
Posté 06 février 2013 - 21:40
#15
Posté 07 février 2013 - 13:54
bon, je télécharge tous sa de nouveau.
#16
Posté 07 février 2013 - 14:26
Shéogorath - Prince de la folie
Vrai Grand Moddeur et FPIA à ses heures...#17
Posté 08 février 2013 - 19:38
Pierre Deproges
#18
Posté 08 février 2013 - 20:39
#19
Posté 09 février 2013 - 01:43
Shéogorath - Prince de la folie
Vrai Grand Moddeur et FPIA à ses heures...#20
Posté 09 février 2013 - 02:30
Toutes les infos sur le format de données des scripts compilés est expliqué ici.
Non, les scripts (en tant que ressources externalisées) peuvent être parfaitement corrects mais incapables de s'exécuter correctement en jeu si les properties qu'ils utilisent sont mal remplies (et ça c'est stocké dans l'esp).
Ce bug m'est arrivé deux fois et maintenant je m'en méfie comme de la peste. D'ailleurs on a la solution pour s'affranchir quasi totalement de ce risque en ce qui concerne les DLC. Par contre pour le jeu de base on ne peut pas (en raison de restrictions d'authentifcication des fichiers par Steam).
#21
Posté 29 avril 2013 - 23:16
Quête : DA03 (un Daedra pour ami). Entre la quête dans le jeu vanilla et la quête modifiée dans Dawnguard ce sont les properties AchievementsQuest, BarbasMovetoMarker, EndTopic et SummonFX qui ont purement et simplement disparu !!!!
Si vous avez commencé une partie avec Dawnguard activé dès le départ et que vous êtes bloqué(e)s dans la quête daedrique de Clavicus Vile, ne cherchez plus le coupable !
Bug corrigé dans l'UDGP 1.2.2, et par voie de conséquence dans le PNOS 1.3.2a actuel.
#22 Invité_kaos_sita
Posté 03 mai 2013 - 19:36
Actuellement dans la traduction d'un mod lourdement scripté nomme Retour à Helgen par Giskard et j'ai effectivement quelques scripts à traduire.
Je dispose évidemment des sources et ce bug m'inquète quand même pas mal.
Donc j'aimerai savoir s'il y a une possibilité d'être touché par ce bug pour une traduction qui se rapproche sur le plan technnique d'une correction des fautes.
PS : Merci pour la nouvelle version du PNOS !
#23
Posté 03 mai 2013 - 21:56
Une traduction peut s'effectuer sans le CK depuis déjà quelques mois. La méthode la plus sûre est de délocaliser le mod avec TES5Edit afin d'obtenir un brelan de fichiers strings. Ensuite tout le travail se fait exclusivement sur ces fichiers strings. On ne touche absolument plus à l'esp, ce qui évite justement de faire apparaître ou d'aggraver le problème dont ce topic fait l'objet.
L'ensemble du travail s'effectue partiellement à la main et partiellement de manière automatisée avec au choix :
TESVTranslator (envers qui j'ai une assez grande confiance, le plus abouti mais le plus complexe, et dont j'ai eu beaucoup de MP avec l'auteur)
STREdit (je m'en suis très peu servi et quelques problèmes ont été reportés pour du texte contenant des alias)
ESP-ESMTranslation (que je n'ai absolument jamais testé)
#24 Invité_kaos_sita
Posté 04 mai 2013 - 07:16
En tout cas il est incapable de charger le contenu du script.
Sinon j'évite le CK comme la peste car pas très confiance.
Mais je pense éventuellement utiliser des strings car cela permet de ne pas rajouter de bugs ce qui peut-être une bonne chose.
#25
Posté 04 mai 2013 - 11:38
L'outil se charge de verrouiller les chaines impropres à la traduction, toutefois, il est recommandé malgres tout connaitre un peu le papyrus (comme dans le cas où on traduit des sources), car il y a la possibilité de consulter le log de décompilation afin de verifier l'usage qui est fait des chaines à traduire.
Cependant, Il y a certaines restrictions incontournables.
Si une même chaine est utilisée à la fois pour une notification et un parametre interne au script (var, STATE, function ect...) il ne sera pas possible de la traduire, car les PEX utilise une table de chaines partagée.
Je sais comment ajouter des chaines dans la table pour ce genre de cas , mais je ne suis pas sur d'integrer la possibilité, car cela nécessiterait trop de manipulation "à risque" pour l'utilisateur.
Nico coiN, le 03 mai 2013 - 21:56, dit :
Ce qui provoquait les corruptions, notamment dans le cas de SSLocalizer/tesvSnip, a été clairement identifié, et on sait aujourd'hui eviter ces problemes.
(pour faire simple il y en avait 3: mauvaise compression Zlib, export de STRING incomplet/flag de localisation erroné, mauvaise gestion des chaines vides)
Par ailleurs, Bethesda ayant officiellement arreté le dev de Skyrim, il n'y aura vraissemblablement plus de nouveaux types de Record /field a gerer. On peut considerer aujourd'hui que les choses sont durablement stables. (en attendant un tes6/fallout)
Modifié par McGuffin, 04 mai 2013 - 13:20.
Aussi étiqueté avec Désastre, Bugs, Crash, PNOS, PNODG
0 utilisateur(s) li(sen)t ce sujet
0 membre(s), 0 invité(s), 0 utilisateur(s) anonyme(s)