Vfx eyes to waypoint

[Legacy_Builder_Anthony]

               Ok this creates a vfx glowing eyes to a waypoint i wana make sure its not searching the entire mod for the tag but i think thats done

Do you guys have any other suggestions for the script.I currently use it on headstones and it makes eyes on them because thats where i adjusted the waypoint to. 

void main()
{    object oPC = GetEnteringObject();
    if (!GetIsPC(oPC)) return;
    if (d4() == 3)
    {
        int i=0;
        object oTarget = GetNearestObjectByTag("wp_eyes", oPC, i);
        for( ; GetIsObjectValid(oTarget); i++)
        {   oTarget = GetNearestObjectByTag("wp_eyes", oPC, i);
            location lLocation = GetLocation(oTarget);
            ApplyEffectAtLocation(DURATION_TYPE_INSTANT,
                EffectVisualEffect(VFX_EYES_RED_FLAME_TROGLODYTE), lLocation);
        }
    }
}

               
               

               

                     Modifié par Builder_Anthony, 15 octobre 2011 - 05:49 .
                     
                  

            

[Legacy_Shadooow]

               It works? Afaik visual effect applied on waypoints wont show up.
               
               

               
            

[Legacy_Builder_Anthony]

               Ya it worked i seen it already or i put it on a invisable object but in my toolset i seen a waypoint taged eyes so i figured it was a waypoint.I see it though.
               
               

               

                     Modifié par Builder_Anthony, 15 octobre 2011 - 06:00 .
                     
                  

            

[Legacy_Shadooow]

               Ah yes, I didnt read code properly the actual effect is not played at WP but only at WPs location using ApplyEffectToLocation. This makes it undispellable, permanent and unaccesable. Not really best way I guess. Also this works only for one area. GetObjectByTag in module load would be definitely better if you uses these waypoints in different areas. I wouldnt worried about performance, unless your server is running on 386 you should not feel the difference.
               
               

               

                     Modifié par ShaDoOoW, 15 octobre 2011 - 06:11 .
                     
                  

            

[Legacy_Builder_Anthony]

               so its ok like the way it is?Its applied to a waypoint then?Im asking because the custom comuntiy content challenge is being sent in and its real close to the deadline.
               
               

               
            

[Legacy_Aradan Kir]

               My understanding of how NWN works (I think from a thread from some much more experienced scripters than I) is that NWN keeps an internal index of all tags used in the module, and when you use the function GetObjectByTag("xxx") it searches this index for "xxx" starting with the current area (ie the one the triggerer is in) and then going backwards through all areas by the reverse order in which they were added to the mod (ie newest areas are checkest first).

However, GetNearestObjectByTag("xxx") doesn't use this index, so is potentially slower to execute (as presumably it does a loop of all objects in the area and compares tags and distance from the target).  It also only checks tags in the current area.

So, depending on how exactly you want your script to run, it might be better to swap the functions used.

http://www.nwnlexico...bjectbytag.html
http://www.nwnlexico...bjectbytag.html
               
               

               
            

[Legacy_Lightfoot8]

               

aradankir wrote...

My understanding of how NWN works (I think from a thread from some much more experienced scripters than I) is that NWN keeps an internal index of all tags used in the module, and when you use the function GetObjectByTag("xxx") it searches this index for "xxx" starting with the current area (ie the one the triggerer is in) and then going backwards through all areas by the reverse order in which they were added to the mod (ie newest areas are checkest first).

However, GetNearestObjectByTag("xxx") doesn't use this index, so is potentially slower to execute (as presumably it does a loop of all objects in the area and compares tags and distance from the target).  It also only checks tags in the current area.

So, depending on how exactly you want your script to run, it might be better to swap the functions used.

http://www.nwnlexico...bjectbytag.html
http://www.nwnlexico...bjectbytag.html

You are incorrect. The GetObjectByTag function does not care what area you are in.   the tag at Index0 will always be the same reguardless of what area you are in.
               
               

               
            

[Legacy_Aradan Kir]

               

Lightfoot8 wrote...
You are incorrect. The GetObjectByTag function does not care what area you are in.   the tag at Index0 will always be the same reguardless of what area you are in.

Does this mean this bit of the Lexicon is incorrect? 

"Outside of the current area, the scan will begin starting with the last (most recent) area added to the module..."

And does it also mean that if you had this module setup:

Area 1 - added first
Area 2 - added next
Area 3 - added last

... with an item with identical tag in Areas 1,2 & 3, and the PC triggering the script being in Area 2, that the script using GetObjectByTag would return the objects in the order of Area 3 / Area 2 / Area 1, and not (as the Lexicon implies to me) Area 2 / Area 3 / Area 1?

And would GetNearestObjectByTag return the item in Area 2?
               
               

               

                     Modifié par aradankir, 16 octobre 2011 - 12:45 .
                     
                  

            

[Legacy_Shadooow]

               Nwn lexicon isnt really accurate at these things. But neverlethess OP doenst have to think hard about this, the current code is enough.
               
               

               
            

[Legacy_Lightfoot8]

               I do not see the lexicon being incorrect.   To fully quote the lexcon:
 
 The nNth parameter has been determined to return the nNth object with the specified sTag starting at position 0. Outside of the current area, the scan will begin starting with the last (most recent) area added to the module following this hierarchy:

I do not see, anywhere, that it states it begins in the current area.   I feel that you somehow read that into the statment when it was simply just not stated.   True they could have worded it better.  the "OutSide of the current area,"  is to denote that you can not use this function to get a tag in the area the script is running, without checting the area of the object vs. the area you are in.

Also keep in mind that the order the areas are added to the module is not necessarily the same order that the builder added the areas to the module.   It is the order the areas are loaded into the module when the game is loaded.  The order can be the same but it is not always the same.  

The order areas are loaded into the the module is alphebetical by the ResRef of the area.   The ResRef is created at the same time the area is created as the Name the area is given, as long as it is less then 16 characters long and is not a duplicateof another areas name.   if it is longer or a duplicate NWN creates a unique name for the ResRef.   it then names the area  [ResRef:] AreaDisplayName

So if you created an area and called it  "Inn" during creation, Not after creation,  the toolset would give it a ResRef of  "Inn" and the name of the Area would simply be "Inn".  If however, you then created a second area and called it "Inn" during creation.  The Tollset would give this area a ResRef of "Inn001"  and the Name entered into the name field would be "Inn001:Inn"  where the only text that you see displayed in game or the toolset is the name after the colon('> .  If you ever rename your area, the ResRef  remains unchainged and the display name is updated.  This is one of the main reasons that in order to inport an area from one module to another, it is best to make a copy the area so that you can control what the ResRef name is before inporting it into a new module.   because a lot of areas where created just using the standerd names generated by the toolset i.e: Area001, area002...  and then renamed later. 

Hmm,  most like more information then you wanted and off topic for this post, So I will quit rambling now.  
   
 
               
               

               
            

[Legacy_Aradan Kir]

               I did interpret "Outside of the current area, the scan will begin starting with the last (most recent) area added to the module following this hierarchy" as meaning it would start in the current area, and if not found there, would then go through the other areas in the stated order.

Thanks for the clarification '>
               
               

               

                     Modifié par aradankir, 16 octobre 2011 - 05:47 .
                     
                  

            

[Legacy_Builder_Anthony]

               Hmm intresting to know it loads areas first by the resref.Thanks everyone.