bug, bad docs, or gotcha?
Author | Topic: bug, bad docs, or gotcha? |
---|---|
Shock Trooper
Member # 4180
|
written Thursday, April 15 2004 00:38
Profile
The docs for party_size() simply say "Returns the number of characters in the party." Based on that, and since I can't really be sure of how big a party was brought into my scenario, I've taken to doing something like this: However, say you have a 4-character party, but all of them except, say, character 2 is dead. In that case, party_size() returns 1 (when I expected 4, based on the docs). So my loop runs through once, with character 0, who is dead, and nothing happens. I suppose it's easy enough to work around by always doing: (Or at least I'm presuming char_ok() will return FALSE on a non-existant character... anyone know for sure?) -spyderbytes EDIT: typo in 2nd code block [ Thursday, April 15, 2004 00:42: Message edited by: spyderbytes ] -------------------- -spyderbytes Posts: 200 | Registered: Wednesday, March 31 2004 08:00 |
...b10010b...
Member # 869
|
written Thursday, April 15 2004 00:53
Profile
Homepage
I suspect the engine doesn't differentiate between a dead character and a nonexistent character as well as it should. BoE's didn't, which made the Kill Party node display some interesting behaviour. -------------------- The Empire Always Loses: This Time For Sure! Posts: 9973 | Registered: Saturday, March 30 2002 08:00 |
Shock Trooper
Member # 4180
|
written Thursday, April 15 2004 01:10
Profile
I may well just not be thinking of something, but I don't really see how the current behavior of party_size() would be more advantageous than the behavior I expected (that is, seems better to me to know total size of party, not just learn how many are alive and kicking). Not that we're talking a massive number of cycles either way, but I would think a single call to a party_size() (or equivalent that returned what I expected) would certainly incur less overhead than the unnecessary iterations through a loop (which is why I was querying party_size() in the first place :) ). -spyderbytes -------------------- -spyderbytes Posts: 200 | Registered: Wednesday, March 31 2004 08:00 |
Triad Mage
Member # 7
|
written Thursday, April 15 2004 01:13
Profile
Homepage
That's why I've avoided using calls to characters 0-3. There are enough group calls that accomplish what I want, and for the times there's not, I can use random_party_member() -------------------- "At times discretion should be thrown aside, and with the foolish we should play the fool." - Menander ==== Drakefyre's Demesne - Happy Happy Joy Joy Encyclopedia Ermariana - Trapped in the Closet ==== You can take my Mac when you pry my cold, dead fingers off the mouse! Posts: 9436 | Registered: Wednesday, September 19 2001 07:00 |
Shock Trooper
Member # 4180
|
written Thursday, April 15 2004 01:27
Profile
Agreed, Drakefyre. It's not that there are that many times I end up iterating the group (mostly when I'm just being fiddly about where they are for a cutscene and such--in a neat little row starting from a particular loc). I probably wouldn't have discovered this at all if I hadn't been working on a, well, I guess you'd call it a trap, that has some rather, well, I guess you'd call it odd, behavior. :D I was testing what happens if players are both stupid and unlucky, and all but one of the characters ended up dying... before the trap was going through a final iteration to turn the thumbscrews a bit more. :eek: :eek: I'm toning the worst case down a tad... -spyderbytes -------------------- -spyderbytes Posts: 200 | Registered: Wednesday, March 31 2004 08:00 |
Board Administrator
Member # 1
|
written Thursday, April 15 2004 12:00
Profile
Homepage
I updated the description of this call in the docs: short party_size() - Returns the number of living, present characters in the party. -------------------- Official Board Admin spidweb@spiderwebsoftware.com Posts: 960 | Registered: Tuesday, September 18 2001 07:00 |