18 réponses à ce sujet

[Proleric]

According to the Lexicon,

"Setting strings on objects just created can fail to work. Use ActionDoCommand(void) to set a string on a newly created object. This bug appears in all of the SetLocal* functions"

On a quick search, I can't find much discussion of this issue.

So far, I haven't been able to reproduce the problem.

Perhaps it was fixed?

Or perhaps a misconception? My understanding is that OnSpawn fires after the CreateObject script has finished, so it can explicitly change variables set in the latter, but that's a feature, not a bug.

Can anyone confirm?

[henesua]

I've not encountered this problem and I set locals on newly created objects all the time.

[Lightfoot8]

I do not think it is a problem.   i also do not know if it ever was a problem.   

Funny thing is I have heard more about problems with actions not working on "not full created objects" 

[Proleric]

...Funny thing is I have heard more about problems with actions not working on "not full created objects"

I'd offer a similar hypothesis for that. An action issued in the CreateObject script will be cancelled by WalkWayPoints() in the OnSpawn script, if my understanding is correct, i.e. the spawn event occurs after the create script has finished.

If I don't hear anything to the contrary, I'll try to get access to the Lexicon and deprecate the bug report to the talk page, with a link on the main page.

[FunkySwerve]

Never had an issue with it. Pretty sure our random loot system would crash to the ground if it were true, too, since we use a ton of variables while we're hot-swapping item properties, to store item prop information in variable form on the newly-created item. In fact, come to think of it, our banking system wouldn't work either. We recreate from resref including Unique ID variables and a bunch of others. Definitely not true, to the best of my knowledge.

 

Thanks to Proleric for helping to maintain the Lexicon. There's at least one thing every month or two I see on there that is just plain wrong or out-of-date, and it's nice to see someone taking the initiative to fix it.

 

Funky

[WhiZard]

The lexicon has many false positives.  Since it has only in the past few years become editable, many folk with the knowledge of the false positives have just ignored the information and moved on.  One of the most widely discussed false positives (that still has not been removed) is the bug report for the Random() command.  I tend to limit my editing on the Lexicon, so I won't have too much direct influence on two sources of community reference (NWNWiki being the other).  But if there were a group of people willing to test out the false positives, I would be willing to assist.

[Pstemarie]

I have never had an issue with storing variables on a newly created object - with one exception. I did have an issue some time back with an earlier project storing variables on newly summoned creatures. I had to use a DelayCommand() function call and ExecuteScript() to skirt the issue.  

[Baaleos]

I've had issues mainly around SetName on objects after they are spawned.

 

Eg: If their toolset name is 

planar_cre_min  (not just their resref, but also their firstname)

 

When I spawn them, and then do SetName(oMin,"Planar Fire Minion");

 

Sometimes, if there is alot going on in the area, the SetName doesnt appear to take effect from the clients point of view.

Eg: the creature, or object remains named planar_cre_min

[Shadooow]

I've had issues mainly around SetName on objects after they are spawned.

 

Eg: If their toolset name is 

planar_cre_min  (not just their resref, but also their firstname)

 

When I spawn them, and then do SetName(oMin,"Planar Fire Minion");

 

Sometimes, if there is alot going on in the area, the SetName doesnt appear to take effect from the clients point of view.

Eg: the creature, or object remains named planar_cre_min

hmm yea but I think that this is a client bug, try what returns GetName, I bet it will be the newer name...

 

though it has probably no meaning of what is the cause

[WhiZard]

I have never had an issue with storing variables on a newly created object - with one exception. I did have an issue some time back with an earlier project storing variables on newly summoned creatures. I had to use a DelayCommand() function call and ExecuteScript() to skirt the issue.  

 

Yes, summoning with an animation delay actually performs a double creation.  That is the OnSpawn script fires twice for the same creature, once at the point of summoning and next at the point of appearing.  Not sure what is going on with the creature as far as being able to be edited in between those two OnSpawn events.

[FunkySwerve]

The lexicon has many false positives.  Since it has only in the past few years become editable, many folk with the knowledge of the false positives have just ignored the information and moved on.  One of the most widely discussed false positives (that still has not been removed) is the bug report for the Random() command.  I tend to limit my editing on the Lexicon, so I won't have too much direct influence on two sources of community reference (NWNWiki being the other).  But if there were a group of people willing to test out the false positives, I would be willing to assist.

This sounds great, and I would volunteer if I had a little free time. I would like to suggest, though, that if people do wind up doing this, that they post the code they use to test and/or demonstrate bugs. Making, in essence, the bug reporting/debunking, 'open source'.

 

Funky

[Squatting Monk]

Making corrections or bug reports open is an excellent idea. I encourage anyone who wants to help with this to either discuss the issue on the talk page of the function in question or here on the forums. We have a citation extension on the Lexicon to allow reference links a la the other wiki which helps with this.

[Lightfoot8]

I've had issues mainly around SetName on objects after they are spawned.
 
Eg: If their toolset name is 
planar_cre_min  (not just their resref, but also their firstname)
 
When I spawn them, and then do SetName(oMin,"Planar Fire Minion");
 
Sometimes, if there is alot going on in the area, the SetName doesnt appear to take effect from the clients point of view.
Eg: the creature, or object remains named planar_cre_min

 
 

hmm yea but I think that this is a client bug, try what returns GetName, I bet it will be the newer name...
 
though it has probably no meaning of what is the cause

 
 
I ran across this one when I was using the DMFI rename widget. It is a client bug similar to the bug with static objects. Just like when you destroy a static object and it will stay visible to the PC until they leave the rendering range and return. SetName works about the same way with the players client. The object will have to leave the PCs rendering area and reenter of the new name to be seen.

[FunkySwerve]

FWIW, we avoid some rendering issues by doing an incredibly brief (0.1f) polymorph effect. Would probably work to correct the name of a creature, though I haven't tested. Doubtful, on the placeable, but probably still worth testisng. Applying cutscene invis and removing it did not resolve the rendering issue we were trying to correct, which was basically just that some player clients could not always see some creatures in a large spawn. Our !render command applies a very fast poly to all of them, to force the client to re-render.

 

Funky

[ShadowM]

I found also if you change appearance of a creature the size information is not updated either, so I do a wrapper like funky that polymorph them real quick. Have you tried a reset name then do the rename and see if that update the naming. I think I did that for my durability system of items, do not know if that will work with creatures or placables.

[WhiZard]

Ahh, yes, size modification.  The good old days of using a double axe with a tower shield.  Sounds more impressive than it actually is...

[Proleric]

...It is a client bug similar to the bug with static objects. Just like when you destroy a static object and it will stay visible to the PC until they leave the rendering range and return...

Drifting slightly off topic, I'd thought static objects had to be... well, static? In the past, I recall client crashes that went away when I realised I was unintentionally deleting a static placeable. If there's a way to do that reliably (even if it involves re-entering the area) I'd love to know; the problem with dynamic objects is, of course, that they don't render at a distance.

[FunkySwerve]

From my limited recollection, the only way to Get a static object is to have spawned it in a script. It IS possible to create and destroy them, still, I think, in that fashion. In that way, a spawned-in 'static' place isn't a true static place - it's not baked into the tiles. Other than that situation, I THINK all the Get-ing functions ignore statics completely. I don't recall any issues with doing that causing crashing, however.

 

Funky

[Proleric]

I updated the Lexicon entry for the SetLocal... functions and CreateObject.