Bienvenue sur JeuxOnLine - MMO, MMORPG et MOBA !
Les sites de JeuxOnLine...
 

Panneau de contrôle

Recherche | Retour aux forums

JOL Archives

INFO: GetResRef, ouais bof

Par LeProctophantasmiste le 15/10/2002 à 16:29:07 (#2340233)

Pour ceux qui ont la version française, le patch 1.25 n'est pas encore sortit, mais ne saurait tarder, il introduit une nouvelle fonction, très attendue, GetResRef(oObject).

Seulement voilà:l

Qu'est-ce que cette ResRef à laquelle Bioware nous a donné accès? Il s'agit d'une nouvelle propriété des objets, introduite dans la version 1.25, qui enregistre la chaîne de caractère identifiant le blueprint à l'intérieur du module où l'objet a été créé .
Ceci est bien différent du fait de donner accès au blueprint lui-même.

En réalité GetResRef vous évite d'avoir à établir une correspondance entre tags et blueprint d'objets, sans pour autant affaiblir la fonction CreateObject. Et c'est à peu près tout. J'espère juste que l'on ne voit pas voir fleurir des scripts monstrueux à cause d'une annonce assez trompeuse de BIOWARE.

Quelques tests faits par moi ou par d'autre qui illustre cette différence:

1)

Ouvrir un module créé avec la version 1.24, rajouter un objet en lui donnant le blueprint "test".
créer un dispositif permettant d'avoir accès au ResRefs

par exemple un coffre avec ceci dans le OnDisturb:


void main()
{
object oItem = GetInventoryDisturbItem();
string sItem = GetResRef(oItem);
SendMessageToPC(GetLastDisturbed(),GetName(oItem) + " : " + sItem);
//CreateItemOnObject(sItem);

}


Tester les objets (items ou autres).

Résultat: Pour l'objet nouvellement créé on obtiendra bien le ResRef, en revanche pour les objets qui ont étés placés avec la version 1.24 (ou antérieure) du toolset, la ResRef sera vide.

2)
tester ceci:

void main()
{
string sResRef = "rappelezvouslobjetquenousvimescebeaumatindetesidoux";
object oItem = CreateObject(OBJECT_TYPE_CREATURE, sResRef, GetLocation(OBJECT_SELF));
SendMessageToPC(GetFirstPC(),"ResRef:"+GetResRef(oItem));
}


Comme "rappelezvouslobjetquenousvimescebeaumatindetesidoux" ne fait pas référence à une blueprint existante, ceci crée un blaireau. Jusque là tout est normal :D. Seulement voilà ce blaireau a pour ResRef: "rappelezvouslobj". Ce qui ne fait pourtant pas plus référence à un blueprint (si vous avez ce blueprint dans votre module, vous devriez revoir vos conventions de dénomination).

3) Deux modules version 1.25, le deuxième ayant le coffre susmentionné. Dans le premier créez une dague avec pour blueprint "testgetresref". Dans le deuxième la même chose mais avec une épée double. Créer une partie dans le premier module, prenez un exemplaire de cette nouvelle dague. Sauvegardez le personnage. Créez une partie dans le second module avec ce perso, prenez une épée double, et testez les deux objets. C'est là que les pbms commencent: tous deux ont pour "ResRef" "testgetresref".

Si vous décommentez la ligne CreateObject du petit script, et que vous ajoutez une dague venant du premier module dans le coffre du deuxième. La duplication créera... une épée double.

Donc prudence.

Par eMRaistlin le 15/10/2002 à 16:44:20 (#2340350)

Merci pour ces info ^^

Autre note :

le patch 1.25 US à été suivi par un patch non-officiel 1.26 distribué par bioware (!). Ce dernier patch etant non-teste, un patch 1.25 critique est accessible, et il devrait y avoir un release d'un patch 1.26 final ces jour-ci en US (ce jour ou demain, d'apres les bruits de couloirs...)

Pour la VF, faut attendre un chouilla... mais ca devrait permettre d'avoir un patch correct.

Par miriandel le 15/10/2002 à 17:02:32 (#2340459)

Juste une microspique précision... GetResrRef est une méthode, pas une propriété des objets, et elle n'enregistre rien du tout, elle renvoie l'identifiant unique du blueprint.

GetResRef fait bien ce que nous réclamions à corps et à cris depuis longtemps: donner la possibilité de créer un objet à partir de son identifiant unique, ce qui est extrêmement utile à tous les scripteurs qui attaquent les problèmes de manipulations d'inventaires (coffres, vendeurs, artisanat, ...).
La seule méthode qui existait auparavant était de faire correspondre le blueprint au tag, ce qui était fort contraignant et marquait des limites.

Donc en clair, si tu n'as jamais eu besoin de GetResRef, fais comme si elle n'existait pas, mais moi j'ai une librairie complète qui est écrite avec GetResRef depuis plus d'un mois, en attendant qu'ils l'implémentent :)

Donc, haut les coeurs :)

Par LeProctophantasmiste le 15/10/2002 à 17:24:09 (#2340597)

Euh Miriandel tu as lu mon post? et les tests que je me suis échiné a effectué :D . Non ce n'est pas une méthode -toutes les fonctions ne sont pas des méthodes, mais que sont les méthodes si ce ne sont des fonctions?. Je ne vois pas très bien ce que les méthodes ont à voir la dedans d'ailleurs , la programmation objet n'a pas inventé les adresses mémoires, et autant que je sache le premier compilateur objet n'était pas écrit en objet :). Non l'identifiant n'est pas unique , ce n'est pas une adresse mémoire, il peut même ne pas exister -voir mon commentaire sur les objets placés avec la version 1.24 -, j'ai horreur d'insister mais tu devrais lire mon post.
Cette fonction ne permet rien de plus que la convention de dénomination entre tags et blueprint, en fait BIOWARE a éliminé le besoin de cette convention en l'automatisant à travers une nouvelle propriété.
Si je ne te semble pas assez qualifié pour être écouté, va donc sur le forum officiel des scripts, tu y trouvera mon topic -Proctophantamist- datant d'hier, ainsi que d'autres interventions (une notamment dans les reports de bugs). Il se trouve que les tests précédents les miens étaient incomplet et conduisaient à une fausse conclusion, mais bon fait comme tu veux :p .

Sinon pour Althéa ça ne devrait pas changer grand chose puisque je pense que vous fonctionnez en serveur vault. Mais sur le principe ça n'apporte rien de plus qu'une l'automatisation de la convention déjà utilisée.

EDIT :
Pour être précis : à chaque instance d’objet est attachée une chaîne de caractère égale à :

1)la valeur de la chaîne identifiant le blueprint si l’instance a été créée dans le toolset (à) partir de la version 1.25, sinon = chaîne vide, i.e. la propriété n’existe pas) ceci passant sans contrôle d’un module à l’autre.
2)le paramètre passé à CreateObject() si l’instance a été créée par un script, quand bien même ce paramètre était n’importe quoi, voir l’histoire du blaireau.

C’est cela que récupère GetResRef().

Par Tyn' le 15/10/2002 à 18:02:49 (#2340834)

Question : recompiler totalement le module avec Aurora 1.25 ne rend-il pas compatible avec GetResRef tous les objets ?

Par LeProctophantasmiste le 15/10/2002 à 18:40:02 (#2341059)

Non, j'ai essayé mais ce n'est manifestement pas à la compilation que la propriété est affectée.
Ca c'est l'autre aspect du pbm, comment faire passer un module 1.24 à la version 1.25 du point de vue de cette propriété. Je n'ai pas trouvé de solution simple (si vous en avez une je suis preneur:)). Un script peut être écrit si une convention tag/blueprint a été respecté jusque là. . A vrai dire j'ai le squelette d'un script qui fait cela pour les PJs: substituer certains objets à d'autres, y compris s'ils sont équipés, et qui marche de façon à peu près satisfaisante (j'arrive pas toujours à remettre tous les objets si l'inventaire était plein au départ, si vous en connaissez un qui marche...) le problème c'est qu'il utilise GetReRef :bouffon: .

Par Tyn' le 15/10/2002 à 18:59:23 (#2341130)

Ca pue le bug. Vivement la release note 1.26 finale.

Re: INFO: GetResRef, ouais bof

Par Gargantuel le 15/10/2002 à 19:18:17 (#2341235)

Merci pour tes tests et tes infos.

Provient du message de LeProctophantasmiste
Résultat: Pour l'objet nouvellement créé on obtiendra bien le ResRef, en revanche pour les objets qui ont étés placés avec la version 1.24 (ou antérieure) du toolset, la ResRef sera vide.

Ouch !
J'en connais qui vont avoir mal en regardant leur belle liste d'objets placés à gauche de l'écran :(

Par Tyn' le 15/10/2002 à 19:25:26 (#2341281)

*Pense à Ambrosia*

Paix à leur Âme :D

Par LeProctophantasmiste le 15/10/2002 à 19:35:34 (#2341347)

Ca pue le bug. Vivement la release note 1.26 finale.


Je ne pense pas que ce soit ton cas, mais juste pour d'autres personnes qui liraient ce thread, il ne faut pas trop attendre du patch 1.26 non plus. Le principe de GetResRef ne changera pas sauf miracle, les limitations sont inhérentes à l'approche, et cela reviendrait à tout refaire (s'ils ne l'ont pas fait le premier coup il y a probablement une raison).
Ceci dit pour les ResRefs vides je suis assez de ton avis. Bioware pourrait nous donner un truc pour faire la mise à jour automatiquement, ce ne devrait pas être très compliqué de leur côté (mais je peux me tromper :)). Je ne pense pas qu'ils l'incluent dans la phase de compilation par défaut étant donné que déjà sans cela elle est assez lourde, et sur le principe ça reviendrait à écraser une mouche avec une masse d'arme, mais comme option ou à part pourquoi pas? Il faudrait peut-être leur demander gentiment :)

Par Tyn' le 15/10/2002 à 19:39:27 (#2341376)

Tout est parametrable en compilation. Et effectivement, je parle des resrefs vide en tant que bug, pas du fonctionnement de GetResRef.. Bien que celui-ci soit assez douteux :doute: Surtout qu'ils sont stupides, le resref c'est un champ tout simple dans l'UTI, pourquoi ils s'emmerdent avec des allocations en objet plutot que de charger les resrefs dans tous les UTI au chargement ? Pour pas qu'ils soyent plus long de 2,5sec ?

Par LeProctophantasmiste le 15/10/2002 à 20:01:32 (#2341492)

Bon alors là je suis un peu perdu, je vous assure que je n'ai pas inventé les resrefs vides:) (je ne suis d'ailleurs pas le seul à avoir fait cette observation), ceci dit, par hazard, je viens de me rendre compte qu'un objet placé avec 1.24 me renvoyait une ResRef, donc d'une façon ou d'une autre il y a eu mise à jour, j'ai du planté mon test "post-recompilation" quelque part, peut-être ai-je pris l'objet dans l'inventaire du PC, va savoir... Désolé donc, mais faites quand même le test de votre côté.

Par Tyn' le 15/10/2002 à 20:17:44 (#2341595)

Ahh ! Tu me rassures :)

Tu m'excuseras, mais je préfère largement que ça soit qui fasse une erreur que BioWare :p J'ai eut l'occasion de bosser sur deux jeux, l'un programmés avec le petit orteil du pied gauche par une amibe tetraplégique (A savoir : T4C :p) et l'autre pas dutout prévu pour l'édition à la base (A savoir : Fallout 2 :p), et autant te dire que c'est aut'chose plus lourd :D

Bon, on dit merciii Bioware ! MAIS ON VEUT LE MEME EN VF TOUT DE SUIIIIIIIIIIIIIITE !!! :ange:

Par miriandel le 16/10/2002 à 0:46:40 (#2343049)

Dis Procto... tu n'as guère de raison de prendre ombrage d'une précision mineure que j'ai apportée à ton commentaire, si tu veux appeler loup un chien, pour moi c'est bon, hein ? :D

Quant à dire que le blueprintresref n'est pas unique... il est unique, c'est d'ailleurs bien là son intérêt.

Je n'aurais même pas répondu si je n'avais lu ça, et surtout que tu présentes GetResRef comme une "annonce trompeuse".
C'est de ma faute, pardonne-moi, je me range toujours du côté de l'opprimé quand on attaque injustement des confrères :)

Toujours est-il que GetResRef nous permet à présent bien plus de souplesse dans la gestion des objets, raison pour laquelle je faisais partie de ceux qui le réclamaient.

Alors tu me casses pas mes jouets, hein ? :rasta:

euh ? en clair ?

Par Le Hamster le 16/10/2002 à 10:40:12 (#2344224)

Pardonnez le misérable adepte que je suis mais, en clair ? ça veut dire quoi

"J'en connais qui vont faire une drôle de tête en voyant la liste vide des objets à gauche ?"

hein ?

C'est quoi qui va réellement se passer avec cette fameuse 1.25 ?

hein ?

Je transpire d'angoisse déjà !!


Hein ?

Dites !

Bises

Par LeProctophantasmiste le 16/10/2002 à 13:37:00 (#2345351)

Hamster il n'y a pas de bug à proprement parlé, rien de ce qui marchait avant n'est cassé à cause de cela, si problème il y a c'est pour l'utilisation de la fonction GetResRef elle même.

Miriandel excuse moi, il semble y avoir eu une incompréhension. Tu parlais bien d'une correction microscopique, mais la suite de ton post me faisait plutôt pensé à "t'as rien compris", et c'est à ce qui m'apparaissait comme de l'ironie que je réagissais.
Quant à mon commentaire sur BIOWARE, je ne voulais pas dire qu'il nous ai trompé sciemment, juste que certaines personnes qui sont nouvellement arrivée au scripts, pourrait croire détenir là un identifiant véritable de tout objet, ce n'est pas tout à fait vrai.

Bon je vais arrêter là les justifications et autre tentatives de clarifications psychologiques, étant donné que cela n'intéresse personne, même pas moi :).
Donc passons l'éponge, et parlons du sujet en question.

De mon deuxième post:
"Non l'identifiant n'est pas unique" évidemment ça c'est faux, tout objet a une unique ResRef (si on admet qu'une ResRef vide en est une). Ce que je voulais dire c'est que l' "identifiant" -ce que l'on obtient avec la fonction GetResRef- n'est pas univoque, qu'il ne désigne pas un unique "type" d'objet, ce qui est plutôt embêtant pour un identifiant. C'est ce que je croyais que tu contestais dans ta réponse, désolé donc si je t'ai mal compris.

Tout objet a un blueprint (on peut le supposer en tout cas pour les objets apportés par les PJs), et deux objets différents ne peuvent avoir le même blueprint, ce que je conteste c'est que GetResRef donne "accès" (d'une façon ou d'une autre) aux blueprints, il donne accès à une copie de la chaîne de caractère identifiant le blueprint d'un objet à l'intérieur du module ou cet objet a été créé. L'existence (!=") et l'univocité ne sont garanties que tant que l'on fonctionne en vase clos. La preuve? Je ne peux que redonner un exemple du premier post:

Deux modules version 1.25, le deuxième ayant le coffre susmentionné. Dans le premier créez une dague avec pour blueprint "testgetresref". Dans le deuxième la même chose mais avec une épée double. Créer une partie dans le premier module, prenez un exemplaire de cette nouvelle dague. Sauvegardez le personnage. Créez une partie dans le second module avec ce perso, prenez une épée double, et testez les deux objets. C'est là que les pbms commencent: tous deux ont pour "ResRef" "testgetresref".


Pour ce qui est de l'existence, prend un vieux perso (pour moi celui avec lequel j'ai fait la campagne officielle), et test son équipement, tu obtiendra " pour toutes les ResRef.

Je ne dis pas que cette fonction ne serve à rien, je compte bien m'en servir. Ceci dit si tu me trouves un exemple ou cela permet de faire quelque chose de plus qu'une convention de dénomination tag/blueprint, je serais très surpris, étant donné que sur le principe c'est exactement la même chose. Je crois bien que c'est tout ce que j'ai jamais dit.

JOL Archives 1.0.1
@ JOL / JeuxOnLine