Posted by: devSin
« on: November 20, 2011, 08:53:04 PM »Heh heh. She said "shaft".
Inconveniencing the Infinity Engine since 2001.
News:
Monitor PPG forums with XML/RSS browsers! Copy and paste this link into My Yahoo, Firefox, or another RSS browser!
Posted by: Miloch
« on: November 20, 2011, 08:19:09 PM »Spam patrol seems a bit lax lately 
.
.Posted 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.??
Posted 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.
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.
Posted by: GeN1e
« on: July 07, 2011, 11:02:24 PM »Quote
Player1Not 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.
+ Player2
+ Player3
Player2 leaves, and Player3 now becomes Player2
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.
Posted 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.
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.
Posted by: cmorgan
« on: July 05, 2011, 09:43:53 PM »I think the NumInParty() is the best bet.
NVROL = No Valid Replies Or Links
NVROL = No Valid Replies Or Links
Posted by: Miloch
« on: July 05, 2011, 07:39:13 PM »Surely, NumInParty() is the simpler solution anyway? What is NVROL?
Posted 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:
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?
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?