Pocket Plane Group

Miscellany, Inc. => Infinity Engine Modding Q&A => Topic started by: cmorgan on June 16, 2011, 11:20:07 AM

Title: Logic Grids for InParty() !InParty() Question
Post by: cmorgan on June 16, 2011, 11:20:07 AM

OK, I thought I knew m stuff, but I don't. I have a decently logical block that should work out fine, but is running into NVROLs in the field.

I am pretty sure that InParty(object) sets up so that you can only have mapping of pc/npc objects like this:
Player1
+ Player2
+ Player3
Player2 leaves, and Player3 now becomes Player2

so I set up logic grids like this:

Code: [Select]

IF ~~ THEN BEGIN X#KAQUREWARDParty
  SAY @45
  IF ~InParty(Player1) InParty(Player2) InParty(Player3) InParty(Player4) InParty(Player5) InParty(Player6)~ THEN DO ~EraseJournalEntry(@33) EraseJournalEntry(@44) GiveGoldForce(75) JoinParty()~ JOURNAL @35 EXIT
  IF ~InParty(Player1) InParty(Player2) InParty(Player3) InParty(Player4) InParty(Player5) !InParty(Player6)~ THEN DO ~EraseJournalEntry(@33) EraseJournalEntry(@44) GiveGoldForce(60) JoinParty()~ JOURNAL @35 EXIT
  IF ~InParty(Player1) InParty(Player2) InParty(Player3) InParty(Player4) !InParty(Player5) !InParty(Player6)~ THEN DO ~EraseJournalEntry(@33) EraseJournalEntry(@44) GiveGoldForce(45) JoinParty()~ JOURNAL @35 EXIT
  IF ~InParty(Player1) InParty(Player2) InParty(Player3) !InParty(Player4) !InParty(Player5) !InParty(Player6)~ THEN DO ~EraseJournalEntry(@33) EraseJournalEntry(@44) GiveGoldForce(30) JoinParty()~ JOURNAL @35 EXIT
  IF ~InParty(Player1) InParty(Player2) !InParty(Player3) !InParty(Player4) !InParty(Player5) !InParty(Player6)~ THEN DO ~EraseJournalEntry(@33) EraseJournalEntry(@44) GiveGoldForce(15) JoinParty()~ JOURNAL @35 EXIT
  IF ~InParty(Player1) !InParty(Player2) !InParty(Player3) !InParty(Player4) !InParty(Player5) !InParty(Player6)~ THEN DO ~EraseJournalEntry(@33) EraseJournalEntry(@44) GiveGoldForce(15) JoinParty()~ JOURNAL @35 EXIT
END

But I have reports showing (and in at least one case I was able to replicate) NVROL (which if the logic is correct, should never be possible).

I have fixed it by using NumInParty() calls, but the problem is that I use this kind of logic in several places in AranW, and I'd like to find out where I have gone wrong. Ideas?

Title: Re: Logic Grids for InParty() !InParty() Question
Post by: Miloch on July 05, 2011, 07:39:13 PM

Surely, NumInParty() is the simpler solution anyway? What is NVROL?

Title: Re: Logic Grids for InParty() !InParty() Question
Post by: cmorgan on July 05, 2011, 09:43:53 PM

I think the NumInParty() is the best bet.

NVROL = No Valid Replies Or Links

Title: Re: Logic Grids for InParty() !InParty() Question
Post by: devSin on July 06, 2011, 12:27:51 AM

InParty() is not true for deaders, so you may want NumInPartyAlive(), I think it was (unless you wanted dead chars too).

I don't believe you ever want to rely on PlayerN like that. Don't expect it to correspond to the visible party order or current party makeup. I don't recall the specifics, but it doesn't always make sense.

Title: Re: Logic Grids for InParty() !InParty() Question
Post by: GeN1e on July 07, 2011, 11:02:24 PM

Quote

Player1
+ Player2
+ Player3
Player2 leaves, and Player3 now becomes Player2

Not always. You know that players are displayed in order in loading menu, right? Now, if I dismiss Player2 and shortly after recruit the replacement, then the latter will take former Player2's place in order.

As a wild guess, maybe the order is re-organized at the save-load point? I know for a fact that some things do change on that verge - e.g. a simulacrum with parameter2=0 suffers deathvar change to NONE, as I've discovered when trying to solve one issue.

Title: Re: Logic Grids for InParty() !InParty() Question
Post by: cmorgan on July 08, 2011, 08:46:04 AM

Great info - and it looks like the takeaway is "don't rely on Player{23456} this way - instead, use NumInPartyAlive()."

Player1 most likely remains static, regardless of circumstance, but a safer long-term (GemRB, etc.) usage might be Protagonist, just in case.

Player{2345} is still very useful for checking for specific things, where a reply or scripting is just checking each slot for a potential condition

~InPartyAllowDead(Player2) StateCheck(Player2,STATE_DEAD)~ THEN REPLY ~[PC] You do know <PLAYER2> is dead, right? I think that takes priority over some silly talk about how you feel about me.~

~InPartyAllowDead(Player3) StateCheck(Player3,STATE_DEAD)~ THEN REPLY ~[PC] You do know <PLAYER3> is dead, right? I think that takes priority over some silly talk about how you feel about me.~

etc. (Amber has great examples of this).  But as far as using this kind of thing to make sure only one result comes up; nope. Can't use it.

Title: Logic Grids for InParty InParty Que
Post by: belkiska on November 13, 2011, 11:45:19 AM

i have both of them. the cam shaft sensor looks good its way down by the cam gear, and not any that are marked in your photo.??

Title: Re: Logic Grids for InParty() !InParty() Question
Post by: Miloch on November 20, 2011, 08:19:09 PM

Spam patrol seems a bit lax lately :(.

Title: Re: Logic Grids for InParty() !InParty() Question
Post by: devSin on November 20, 2011, 08:53:04 PM

Heh heh. She said "shaft".