Changing alignment once per player when entering area?

Neverwinter Nights 1 Toolset, Scripting, NWNX
1

Hi, I’ve been building a module and am looking to make it so that should you enter a house that you are not supposed to enter (presumably for robbing purposes), your alignment would be sent down the evil and chaotic route, however I am a terrible scripter and while the internet has revealed how to change a character’s alignment, I can’t quite seem to figure out how to make it so their alignment doesn’t change every single time they enter the house

This is the rather simple script I’ve found:

void main()
{
object oPC = GetEnteringObject();
if(GetIsPC(oPC))
{
AdjustAlignment(oPC, ALIGNMENT_EVIL, 10, FALSE);
AdjustAlignment(oPC, ALIGNMENT_CHAOTIC, 10, FALSE);
}
}

Could someone help me in making it a one time penalty

2

Try with this and see if it works:

void main()
{
    object oPC = GetEnteringObject();
    if (GetIsPC(oPC) == FALSE) return;
    object oAREA = OBJECT_SELF;
    string sVAR = ObjectToString(oPC);
    if (GetLocalInt(oAREA, sVAR) == TRUE) return;
    AdjustAlignment(oPC, ALIGNMENT_EVIL, 10, FALSE);
    AdjustAlignment(oPC, ALIGNMENT_CHAOTIC, 10, FALSE);
    SetLocalInt(oAREA, sVAR, TRUE);
}
3

That worked perfectly, thank you very much

1 Like
4

@Clangeddin - Just out of curiosity, why are you setting the local integer on the area rather than the PC. Won’t a second PC overwrite the variable? Then if the first PC returns, the script will execute again. Would it not be better to set the local integer on each PC? Or am I missing something?

5

@Grymlorde

The second PC should not overwrite the variable, because it should be stored as a different variable.
What are the chances that two different PCs return the same sVAR from ObjectToString? I’d say zero.

From: ObjectToString | NWNWiki | Fandom

"The primary use of this command is for debugging, as it can distinguish objects that have data (e.g. names and tags) in common. In particular, it easily distinguishes formerly-valid objects (which have no data associated with them) from OBJECT_INVALID, a distinction that can be lost through other debugging methods. Another benefit of using this command is that there is always a non-empty string returned, which can provide some reassurance that a particular script has not gone completely haywire.

This command also has use as a means of generating local variable names that are unique to an object (presumably to an object other than the one on which the variable will be stored). This is one way, for example, to keep track of which player characters have accomplished certain tasks, particularly when that tracking is stored on the module object. "

I prefer to use the area because local vars persist better on them then on PC. PCs lose their local vars when they log off, this means that for multiplayer it wouldn’t for work very well.
I could have used the module instead I guess, in the end it’s about what has better persistance of local vars.

Another method could have been to create an item inside the inventory and store the variables there, for server vaults those persist too, but then you take away 1 inventory item slot and you have to check for full inventory on first trigger. If the inventory is full it could be theoretically bypassed.

6

Okay. Thanks for the explanation.

7

Neither is good for persistence. As soon as the server restarts, which is needed from time to time, area and module variables are lost too. As is the above won’t work well in a PW setting. Area in this case is a better choice than the module in case you use this mechanism more than once.

I use the skin as the PC storage item so it does not take up a slot. You do have to bypass ELC though so that’s a choice to make. Even if you don’t you probably have other things to persist so that item should be there long before the PC can fill his/her inventory.