33 réponses à ce sujet

[AndarianTD]

Failed.Bard wrote...

It's generally not a good practice to define a variable within a while or for loop, it can cause oddities in behaviour. The variables at the start should likely look something like...:

There's no problem with defining variables within a while or for loop. I do it in NWSCRIPT all the time. All you have to do is make sure that a variable declared within the scope of the loop (the curly braces) is initialized properly and used exclusively within that scope -- especially if it's hiding a variable with the same name at a higher scope.

Modifié par AndarianTD, 10 mai 2012 - 11:43 .

[henesua]

 

Leurnid wrote...

GetLocalObject is freaking me out... the beginning and the end of that I get, but the GetLocalObject... can you store an object in an object!?!?

as Andarian said, its a pointer to an object. With lighting I often have more than one object to get the effect. In order to keep track of them, I reference them on each other. Thats what "PAIRED" is all about. This enables me to destroy both objects in a pair. One of those objects was a flame placeable (which could not receive the light visualeffect), the other was a placeable light. The "LIGHT_OBJECT" is the object which players interact with to produce the light. Since it is not destroyed, I track state (On versus Off) on that object.


 

Leurnid wrote... 
*EDIT*  
And why do so many people use 'NW_L_AMION' for state tracking? I haven't seen anything official regarding it, but it is a fairly common thing.

The reason why I am using it: I started with the standard On/Off script that bioware provides for placeables, and never changed the label they used for this state tracking variable. It probably doesn't matter, but I chose to keep it because I didn't know if any other scripts used the same label. And once I started using it, I included it in my own scripts which do look at placeable state. And so... now I am locked into using it, unless I find/replace all these references throughout my scripts. It doesn't seem worth it to me to do so.

[Leurnid]

henesua wrote...

 

Leurnid wrote...

GetLocalObject is freaking me out... the beginning and the end of that I get, but the GetLocalObject... can you store an object in an object!?!?

as Andarian said, its a pointer to an object. With lighting I often have more than one object to get the effect. In order to keep track of them, I reference them on each other. Thats what "PAIRED" is all about. This enables me to destroy both objects in a pair. One of those objects was a flame placeable (which could not receive the light visualeffect), the other was a placeable light. The "LIGHT_OBJECT" is the object which players interact with to produce the light. Since it is not destroyed, I track state (On versus Off) on that object.

So do you store that locally on an object as a string var then, but pull it up as an object (by tag I assume)... I have been attempting to do the same thing using locally stored strings, getting those, and getting the objects by tag using those strings... it sounds like GetLocalObject could save me some lines of potential error and waste.

Leurnid wrote... 
*EDIT*  
And why do so many people use 'NW_L_AMION' for state tracking? I haven't seen anything official regarding it, but it is a fairly common thing.

The reason why I am using it: I started with the standard On/Off script that bioware provides for placeables, and never changed the label they used for this state tracking variable. It probably doesn't matter, but I chose to keep it because I didn't know if any other scripts used the same label. And once I started using it, I included it in my own scripts which do look at placeable state. And so... now I am locked into using it, unless I find/replace all these references throughout my scripts. It doesn't seem worth it to me to do so.

Because it had the NW_ prefix, I had hoped it was used someplace officially at some point... I have noticed that a lot people name their local  vars with CAPS_LIKE_A_CONSTANT, for some reason, it bugs me, but I suspect now, based on that answer, the reason for that too is because of a convention started by the folks at Bioware... Is there anything to be said for or against the practice?

Modifié par Leurnid, 10 mai 2012 - 04:43 .

[eeriegeek]

The use of ALL_CAPS for constant definition is just a convention, but it wasn't started by Bioware. It dates at least back to its use as a convention when defining constants for C preprocessor macros.

[Leurnid]

eeriegeek wrote...

The use of ALL_CAPS for constant definition is just a convention, but it wasn't started by Bioware. It dates at least back to its use as a convention when defining constants for C preprocessor macros.

I'm sorry, I must have misspoke... I meant that I see a lot people use local variables stored with an all cap string, as if they were constants.

[meaglyn]

Leurnid wrote...

henesua wrote...

 

Leurnid wrote...

GetLocalObject is freaking me out... the beginning and the end of that I get, but the GetLocalObject... can you store an object in an object!?!?

as Andarian said, its a pointer to an object. With lighting I often have more than one object to get the effect. In order to keep track of them, I reference them on each other. Thats what "PAIRED" is all about. This enables me to destroy both objects in a pair. One of those objects was a flame placeable (which could not receive the light visualeffect), the other was a placeable light. The "LIGHT_OBJECT" is the object which players interact with to produce the light. Since it is not destroyed, I track state (On versus Off) on that object.

So do you store that locally on an object as a string var then, but pull it up as an object (by tag I assume)... I have been attempting to do the same thing using locally stored strings, getting those, and getting the objects by tag using those strings... it sounds like GetLocalObject could save me some lines of potential error and waste.

No, you use SetLocalObject to store the object.

Modifié par meaglyn, 10 mai 2012 - 08:23 .

[henesua]

Leurnid wrote...
GetLocalObject is freaking me out... the beginning and the end of that I get, but the GetLocalObject... can you store an object in an object!?!?
...

So do you store that locally on an object as a string var then, but pull it up as an object (by tag I assume)...

Check these out:

SetLocalObject

GetLocalObject

Leurnid wrote... 
And why do so many people use 'NW_L_AMION' for state tracking? I haven't seen anything official regarding it, but it is a fairly common thing.
...

Because it had the NW_ prefix, I had hoped it was used someplace officially at some point... I have noticed that a lot people name their local  vars with CAPS_LIKE_A_CONSTANT, for some reason, it bugs me, but I suspect now, based on that answer, the reason for that too is because of a convention started by the folks at Bioware... Is there anything to be said for or against the practice?

Since Bioware and others I have worked behind followed the all caps convention in NWN, I generally follow it.
For local variables in most systems in my mod I use all caps.
For the AID system local variables I use all lower case

My problem however is inconsistency. I have incorporated a great number of systems and developed my own. Each of these started out with slightly different conventions. If this was a team project I would have taken the time to define some conventions and rewritten the code to follow the conventions.

It hasnt been worth it to bother however. For the most part I follow existing conventions to minimize the number of exceptions I have to wrap by mind around.

Modifié par henesua, 10 mai 2012 - 08:56 .

[Leurnid]

So: objects can only be stored locally by scripts, and then retrieved via scripts... I assume that this is more precise than using object tags, because it stores precisely that object, regardless of how many other objects it may share a tag with?

The utility of this (beyond possible precision) is eluding me at the moment. Are there things one is capable of doing only with defined local objects, or with far less effort?

Modifié par Leurnid, 10 mai 2012 - 09:50 .

[henesua]

If an object is destroyed, the pointer to the object is no longer valid. Its thus typically good practice to include garbage collection. DeleteLocalObject is the third function you will want to take advantage of.

As to utility... its just another tool for you to take advantage of.