oddly enough, another constant query:

[Legacy_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 .
                     
                  

            

[Legacy_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 .
                     
                  

            

[Legacy_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 .
                     
                  

            

[Legacy_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.