Post reply

Warning: this topic has not been posted in for at least 120 days.
Unless you're sure you want to reply, please consider starting a new topic.
Name:
Email:
Subject:
Message icon:

Verification:
Type the letters shown in the picture
Listen to the letters / Request another image

Type the letters shown in the picture:
What color is grass?:
What is the seventh word in this sentence?:
What is five minus two (use the full word)?:

shortcuts: hit alt+s to submit/post or alt+p to preview


Topic Summary

Posted by: devSin
« on: November 20, 2011, 08:53:04 PM »

Heh heh. She said "shaft".
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.
Posted 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.
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.
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
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:
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?