Aller au contenu

Photo

local variable on object fluctuating in value?


  • Veuillez vous connecter pour répondre
7 réponses à ce sujet

#1
kamal_

kamal_
  • Members
  • 5 260 messages
Perhaps someone can explain this:
3.bp.blogspot.com/-C6sLxtQD8C8/UQsngg2WymI/AAAAAAAABTE/-ivo31KamY0/s1600/local+variable+mystery.jpg

There is a local variable on a trigger (demarcated by the mushrooms). For testing, there is no way to set the local variable other than via conversation with the npc. The trigger itself has no scripts for it (heartbeat, onenter/exit etc). When initialized, the debug returns a string of 0, as expected. When told to set the value to 1, the value switches back and forth between 1 and 0. When told to set the value to 0, a string of 0 as expected. Back to 1 and it switches again. I tried storing the variable on a mushroom instead of the trigger and had the same result.

The following runs in the heartbeat of the npc to provide feedback on the value of the trigger's variable

    object oTrigger = GetObjectByTag(GetLocalString(OBJECT_SELF, "sPerception_trigger"));
    int nAllowedHere = GetLocalInt(oTrigger, "nPCAllowedHere");
    SendMessageToPC(GetFirstPC(), "Debug: Trigger's local variable is : " + IntToString(nAllowedHere));

When I use an OnEnter script on the trigger to provide debug text on the local variable, with the same debug code as above, it always returns correctly.

Modifié par kamal_, 01 février 2013 - 02:49 .


#2
Dann-J

Dann-J
  • Members
  • 3 161 messages
If oTrigger isn't being returned properly (resulting in an invalid object), then any local integer you try to read off it will return as zero. You can try adding an additional line that reports whether oTrigger is a valid object or not.

#3
Lugaid of the Red Stripes

Lugaid of the Red Stripes
  • Members
  • 955 messages
Could be there's another trigger somewhere with the same tag, and GetObjectByTag sometimes gets one, sometimes the other. Maybe there's three altogether, since you only get the right number 4 times out of 11.

GetNearestObjectByTag would eliminate triggers in other areas, setting the trigger as a local object on your NPC might help as well (in the same script that sets the variable). You could also run a loop to count the number of triggers, if you don't quite trust what you see in Area contents.

#4
painofdungeoneternal

painofdungeoneternal
  • Members
  • 1 799 messages
Where is the code that sets it? ( assume its one of the standard convo scripts provided ) What parameters are involved in the dialog, or where it's set? Can you send messages to getfirstpc to figure out what is going on inside that script?

#5
kamal_

kamal_
  • Members
  • 5 260 messages
Ok, looks like I've gotten it figured out after making a new module to test only this specific thing, and DannJ was as close to correct as could be given the information I provided was wrong (I was wrong about only having a single npc running the heartbeat). There were multiple npc's in the area running the debugging heartbeat script, however not all of them had the local string so I was getting invalid returns. I wish it would actually say "object invalid" instead of 0.

#6
painofdungeoneternal

painofdungeoneternal
  • Members
  • 1 799 messages
Use -1 for forced false. Seeing 0 indicates then no variable at all that way.

#7
Morbane

Morbane
  • Members
  • 1 883 messages
:crying:

Modifié par Morbane, 02 février 2013 - 09:48 .


#8
Dann-J

Dann-J
  • Members
  • 3 161 messages
Yes - it's annoying that invalid results can come back as zero integers, instead of -1 by default.

I'm using Hellfire's mounts in an upcoming module. Saving and reloading the game while mounted was causing everyone in the party to turn into dwarves. The OnEquip script for the 'riding cloak' was firing again when the game was reloaded, but because the current appearance type wasn't in the switch list (they were already mounted), the new appearance value wasn't being changed. I had initially defined the integer without a value (which is the same as zero), but zero is the appearance number for stout-folk, so the script was dwarf-a-fying everyone. Defining the integer variable initially as -1 (instead of simply defining it with no value), and aborting if less than zero, fixed the problem.