How does EACH_PARTY_MEMBER work?

[Chaos Awakes]

How does the EACH_PARTY_MEMBER action work?

Do the party members have to be alive? If I have a party of four and three of them are dead, does the action only get triggered once, or four times? In other words, is it "party slots taken up" or "actual alive party members" that trigger the action?

[George Gilbert]

Currently only once (i.e. they have to be alive).

Now that you come to mention it though, unless anyone is currently using this action (which is unlikely as it was only included in V0.38), I think it would be better to change this behaviour and have 2 different actions

- EACH_PARTY_MEMBER (which would trigger 4 times)

and

- EACH_LIVING_PARTY_MEMBER (which would trigger once)

Any thoughts?

[Chaos Awakes]

I agree. My dungeon uses it as though they are alive, so that there are areas that you can only go into with 2 party members - or you have to sacrifice your party members to enter areas (evil laugh) and then resurrect them afterwards.

But adding the other action would also have it's uses.

[Lunever]

Considering that it will be probably soon possible in RTC to switch party members, replace dead ones with new ones etc... it might be wise to already also implement an EACH_DEAD_MEMBER too.

[George Gilbert]

My dungeon uses it as though they are alive, so that there are areas that you can only go into with 2 party members - or you have to sacrifice your party members to enter areas (evil laugh) and then resurrect them afterwards.

Oooh, evil.

I like it!

[Lunever]

I also had this idea about forced sacrifice and ressurrection (maybe a bit like Wismerhills initiation in Chronicles of the Dark Moon), but the problem is as far as I understand that ressurrection in an Altar of Vi would reduce the character's stats permanently and doing so repeatedly might get a bit out of hand. Is it possible for a diabolical dungeon designer to have a non-stat-crippling ressurection? That may be also very useful in regard to future party member swapping: If you tweak dungeon mechanics somehow to emulate 1 character leaving and another joining, like some kind of temporary NPC, by using a neutral monster to represent the new character and have the leaving character leaving by making the engine kill him and transport his bones back to his mirror, that character should be able to rejoin later with the same stats he had before, not with reduced stats. Once that retransfer to mirrors talked about in another thread would be implemented it would open up a lot of possibilities. Rejoining could be also easily done by some relay teleporting the bones to an invisible Altar of Vi etc..

[Chaos Awakes]

I second this, but I would also point out that the stat crippling feature is sort of part of the design in this particular instance.

For example, if there is a room that you cannot enter unless you kill one party member, and you know that when you ressurrect them they are going to take a hit, it becomes a dilemma for the player as to which member they want to kill. Do you kill the fighter and then have to fight in the room with magic and have your fighter come back less powerfull, or do you kill the wizard and fight with swords but have the wizard ressurrect with a hit? Dilemmas are good - they make the player think.

But having a "ressurrect without stat hit" option would be good too of course.

[Lunever]

Yes, I know! This may be very wicked if deliberately set up by the dungeon designer. But for this be deliberately, you'd need to have an option of doing it otherwise first. I don't say "let's all be happy and ressurrection be a picknick", but having an stat-conserving ressurrection as an OPTION would allow for a broad array of tweaking it for various purposes.

[Chaos Awakes]

That's why I said "But having a "ressurrect without stat hit" option would be good too of course".

You seem to think everyone is attacking you all the time for your suggestions Lunever.

[beowuuf]

We are *shhhhhhh*

You'll get your knife later

[George Gilbert]

There's a free one with every hundred posts...

<edit> ...yours is now on its way!

[Sophia]

Currently only once (i.e. they have to be alive).

Now that you come to mention it though, unless anyone is currently using this action (which is unlikely as it was only included in V0.38), I think it would be better to change this behaviour and have 2 different actions

- EACH_PARTY_MEMBER (which would trigger 4 times)

and

- EACH_LIVING_PARTY_MEMBER (which would trigger once)

Any thoughts?

Perhaps instead there should be one trigger to iterate over living member and one to iterate over dead members, thus, to combine the behavior, the designer simply needs to include one trigger of each type.

In general, I would propose to either not change EACH_PARTY_MEMBER's function or to remove/replace it entirely: having the same word do different things in different versions is what causes backward compatibility headaches.