Jump to content

TakePartyItem() - BG


plainab

Recommended Posts

According to IESDP

This action takes a single instance of the specified item from the party (unless the item exists in a stack, in which case the entire stack is taken). The item is transferred to the inventory of the active creature. If there are multiple calls to TakePartyItem() in the same block, each with the same item specified, only one call will actually remove an item (on each execution of the block). Inventory slots are checked in the following order
It appears that it scans thru party members in order of Player1, Player2, Player3, Player4, Player5, Player6. Unlike the small chart in the entry on the IESDP page, it scans thru all slots not just the 16 inventory slots.

 

Reasoning: I had two copies of one item. One equipped via Sword Coast Keeper. The other gathered in game to turn in for a quest. The one taken was the equipped item on player1. player2 maintained ownership of the gathered item.

Link to comment

For BG2 variants:

before moving to player 2 & others, all item slots on player 1 are checked and then all containers are checked. Slots are checked in order as listed in the IDS file rather than on the creature file. However, there is a catch to removing items from the container. If there is another copy on another party member that copy is taken as well as the copy in the container. The dialog window will reflect this with two listings for "The party has lost an item"

 

Tests to prove: belt quest for Unshey in EasyTutu.

1 belt equipped on player 1. 1 belt in player 1 container. -- equipped belt is taken

1 belt in player 1 container. 1 belt in inventory slot 16 -- belt in inventory is taken

1 belt in player 1 container. 1 belt in player 2 inventory slot 1 -- belt in player 2's inventory is taken AND belt in player 1's container is taken

1 belt in player 1 container. 1 belt equipped on player 2. -- equipped belt is taken from player 2 AND belt in player 1's container is taken.

 

use shadow keeper to place 1 belt in helmet slot & 1 belt in amulet slot.

amulet is #1 entry in identifier list. helmet is #1 entry in cre file list. -- belt in amulet slot is taken

 

That said, unique quest items may be stored in containers with impunity however quest items that are generic or could have multiple copies at any one time in the player's inventory should be pulled out of any containers prior to turning in said quest.

Link to comment

So you say, TakePartyItem in BG2 is buggy, because it may take 2 items, one from inventory and one from container. If they are held by different PC's.

 

I tested this, and you are right. Original (patched) ToB: if an earlier player has the item in container, then both the item in the container and another item from another player will be taken.

I mainly used this script for testing (easier test without easytutu):

After 'B', put one belt into the bag and hand it over to player1.

Wait for the cat actually execute the action (takes quite some time).

 

 

IF
 HotKey(B)
THEN
 RESPONSE #100
   SetGlobal("take","global",1)
   CreateItem("belt04",1,0,0)  // ~Girdle of Piercing~
   CreateItem("bag04",1,0,0)  // ~Girdle of Piercing~
   CreateItem("belt04",1,0,0)  // ~Girdle of Piercing~
END

IF
 HotKey(D)
THEN
 RESPONSE #100
   SetGlobal("take","global",2)
   CreateCreatureObject("cat",Myself,0,0,0)  // ~Cat~
END

IF
 Global("take","global",2)
THEN
 RESPONSE #100
setglobal("take","global",0)
   ActionOverride("cat",TakePartyItem("belt04"))
END

 

 

Link to comment

BG2 -- additional notes.

Unlike as I thought after a brief test with BG, items are not taken in order of player 1, player 2, etc but in order of displayed portraits.

 

If player 2 is holding a container with whatever item and player 1 has the same item equipped or not. Player 1's item will be taken and the item in player 2's container remains untouched.

 

If more than 1 of the item is in the container only 1 is taken out.

 

If player 1 has multiple unique containers holding the same item, the container which is read first gets the item removed, the others are untouched.

 

If all 6 players each have a unique container holding the same item, the container from player 1 gets the item removed, the others are untouched.

 

If all 6 players each have a unique container holding the same item & any player besides player 1 also has the item in their inventory, the item from the one player's inventory is removed AND 1 item from the container on player 1.

 

Therefore it is safe to say that TakePartyItem() is coded to terminate when 1 item is taken from player inventory AND (not or) 1 item is taken from any containers

 

As long as any one party member has the same item in inventory as is in a container and said container is located on a party member above the one with the item in inventory then both the first item found in inventory AND first item found in container is taken.

 

As long as the inventory item is located before the item in the container then only the item in inventory is taken.

 

This suggests that the code for TakePartyItem() is instructed to terminate after the first item found in the inventory AND the first item found in a container. However the termination for finding in a container is incomplete and does not halt the entire process only the container searching.

Link to comment

order of searching party members for items is not important in my book. Just something i noticed, so I included it.

 

What is important is either searching all inventories sans containers before searching containers or telling the action to completely stop after finding the first item wherever that is located.

 

I have no clue how GemRB works. As far as I know it's a rebuild from the ground up to do what the original games do and then some.

Link to comment

Yes, it is a rebuild and as such, it is possible to tweak to work better than the original (we'll see if it is better than bgee).

At the moment, it works in reverse player order. For each player it first looks in the normal inventory, then it looks in the containers of the same inventory.

Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...