Avenger Posted August 27, 2009 Posted August 27, 2009 UseContainer() does the same with an actor's inventory as LeaveParty(). Testing: stack one or more plot critical in some of your partymembers inventory (don't equip it), then call UseContainer().
igi Posted August 28, 2009 Posted August 28, 2009 I'm guessing the critical items will be placed in the nearest (unlocked) container? If this is the case, your post also infers that LeaveParty() does this too (it's not specified in the IESDP atm).
Avenger Posted August 28, 2009 Author Posted August 28, 2009 That's a good question, i didn't test the code, just read it. I don't know where the items go, but they should be: 1. movable and critical (as in itm flags) 2. not undroppable (as in inventory flags) 3. not equipped (inv slot is between 15 and 33)
Avenger Posted August 28, 2009 Author Posted August 28, 2009 Meh, this was a fluke. What i reported was DropInventory() In any case, LeaveParty does call DropInventory(). I'll report back if i find what UseContainer() actually does! [edit] Ok, UseContainer and UseDoor crash because they never look for the target (container or door). It is highly likely these actions are called by the GUI and the target is already parsed for them.
Avenger Posted August 28, 2009 Author Posted August 28, 2009 Well, i knew it needs more testing The part about dropping only inventory and skipping critical items is controlled by flags. And those flags are set to 0 in DropInventory and LeaveParty too. So, they will simply drop all movable equipment, it seems. But i'm sure somewhere they use those flags... And back to LeaveParty: it drops the items only under rare circumstances, i don't even imagine why they needed it to do that. (The actor is technically dead but not frozen or petrified nor below -10 hp). Feel free to delete this thread
Taimon Posted August 28, 2009 Posted August 28, 2009 UseContainer() expects the (container) object id in int1, so I bet it's used internally.
fuzzie Posted August 29, 2009 Posted August 29, 2009 UseContainer() expects the (container) object id in int1, so I bet it's used internally. Any idea if the same applies to UseDoor? We steal two NIDSpecial actions right now for internal GemRB use so that the GUI can make "use container" and "use door" actions, would be nice if we could just use those two original ones!
Taimon Posted August 29, 2009 Posted August 29, 2009 Any idea if the same applies to UseDoor? Yes, the control flow is similar. (door object id in int1) Doesn't even check the object type to make sure it really is a door.
Recommended Posts
Archived
This topic is now archived and is closed to further replies.