Moving inventory items

[subtledoctor]

I am working on a mod that takes place at the end of BG1, and I need to make a scripted scene where Imoen leaves the party. That creates inventory issues. I am thinking of doing something like this:

1. Imoen says "I'm going to stay here for a while. You can use my equipment while I'm here - I won't need it."
2. And then terminate the dialogue, and set a variable, and then the area script recognizes that variable and opens the inventory screen
3. Once you close the inventory screen, after a couple seconds, Imoen leaves the party.

Is #2 possible?

(Realistically, this is how it should work when every NPC leaves the party. But i this case it is particularly important.)

Edited December 1 by subtledoctor

[lynx]

No, but DropInventory(). IWD2 also has TransferInventory(O:Source*,O:Target*), so you could move it to a container instead, but that's not present in any other engine.

[jmerry]

SoD already sends Imoen's stuff to a container ... how?

First, there's this block in the script for the BD0120 starting area:

IF
	Global("BD_TURNOFF_GEARSCRIPT","BD0120",0)  // Tomb Safehouse, First Floor
	Global("SOD_fromimport","global",1)
	Global("BD_Imoen_Items","GLOBAL",0)
	InPartyAllowDead("imoen")  // Imoen
THEN
	RESPONSE #100
		SetGlobal("BD_Imoen_Items","GLOBAL",1)
		ActionOverride("Imoen_import_eq",TakeCreatureItems("Imoen",ALL))  // Imoen
		SmallWait(1)
		ActionOverride("imoen",LeaveParty())
		ActionOverride("imoen",DestroySelf())
END

"Imoen_import_eq" is a hidden container. Not a creature at all. It doesn't need to be in order to be a valid object for the TakeCreatureItems command. So that block transfers Imoen's stuff to a container in the same area, and then gets rid of her. If she was in the party, anyway.

Second, there's a block in the area script for BD0103 in the Ducal Palace:

IF
	Global("BD_Imoen_Items","GLOBAL",1)
	GlobalLT("BD_PLOT","GLOBAL",51)
THEN
	RESPONSE #100
		SetGlobal("BD_Imoen_Items","GLOBAL",2)
		MoveContainerContents("BD0120*Imoen_import_eq","BD0103*Imoen_equipment")
END

That moves Imoen's stuff from the hidden container in BD0120 to a visible container in BD0103.

So, I'd recommend copying this solution. Create a hidden (disabled) container in the area you're using for your cutscene, have that container grab Imoen's stuff, then transfer that stuff to a container wherever you'd like the party to be able to pick that stuff up.

[subtledoctor]

Thanks. In this case, I am adding a quest between the end of BG1 and the transition to BG2. But for story reasons Imoen cannot be in the party during the quest. So the party will be in AR0108 (Ducal Palace, 1st floor). And since the transition has not happened, the upstairs room will be AR0110, not BD0103. I think most players will not think about going upstairs yet; the natural thing to do is to have the conversation, be given the quest, and go out and do the quest.

Maybe I can explicitly give Imoen residence upstairs in this dialogue (this is Liia recruiting Imoen to study with her... almost like Liia suspects something we don't ), and have her pointedly say the player can go upstairs and use what they want. And then do something like:

IF
	Global("D5_Imoen_Palace","GLOBAL",2)
	InPartyAllowDead("imoen")
THEN
	RESPONSE #100
		SetGlobal("D5_Imoen_Palace","GLOBAL",3)
		ActionOverride("AR0110*Container\ 4",TakeCreatureItems("Imoen",ALL))
		Wait(1)
		ActionOverride("imoen",LeaveParty())
END

Curious:

5 hours ago, jmerry said:

Create a hidden (disabled) container in the area you're using for your cutscene, have that container grab Imoen's stuff, then transfer that stuff to a container wherever you'd like the party to be able to pick that stuff up.

Any reason for the initial hidden container? Why not cut out the middle man and have the upstairs container grab her stuff, like in what I posted? Is it because it has to be in the current active area for the ActionOverride() to proceed?

EDIT - the containers in AR0110 have spaces in their names. E.g. "Container 4" and such. Is escaping the space as I did above the correct way to address that in the area script?

EDIT 2 - any idea how to remove the trap and lock from a single container? (Which has an annoying generic name like "Container 4")

Edited November 26 by subtledoctor

[jmerry]

34 minutes ago, subtledoctor said:

Is it because it has to be in the current active area for the ActionOverride() to proceed?

Presumably this. I haven't tested that, but the SoD designers must have done it that way for a reason...

36 minutes ago, subtledoctor said:

any idea how to remove the trap and lock from a single container? (Which has an annoying generic name like "Container 4")

Searching the WeiDU documentation ...

Spoiler

ALTER_AREA_CONTAINER: patch area containers, but not their contents. This is a PATCH function. All integer variables default to -1 and negative values result in no change to the corresponding field. In the case of flags, a value of 1 will set the flag and a value of 0 will unset it. All string variables except container_name default to the string "same", which results in no change to the corresponding field. The variable container_name is required.

INT_VAR coord_x to the new x coordinate.
INT_VAR coord_y to the new y coordinate.
INT_VAR container_type to the new type of the container.
INT_VAR trapped to whether the container should be trapped.
INT_VAR detected to whether the container trap should be detected.
INT_VAR launch_x to the new x coordinate of the launch point.
INT_VAR launch_y to the new y coordinate of the launch point.
INT_VAR bounding_left to the new value of the left edge of the bounding box. The vertices remain unchanged.
INT_VAR bounding_top to the new value of the top edge of the bounding box. The vertices remain unchanged.
INT_VAR bounding_right to the new value of the right edge of the bounding box. The vertices remain unchanged.
INT_VAR bounding_bottom to the new value of the bottom edge of the bounding box. The vertices remain unchanged.
INT_VAR range to the new trigger-range value.
INT_VAR lockpick_strref to the new strref of the lockpick string.
INT_VAR lock_difficulty to the new difficulty of the lock.
INT_VAR trap_detect to the new difficulty of trap detection.
INT_VAR trap_remove to the new difficulty of trap removal.
INT_VAR flag_locked to the new value of the flag known as locked (bit 0).
INT_VAR flag_mlocked to the new value of the flag known as magical lock (bit 2).
INT_VAR flag_resets to the new value of the flag known as trap resets (bit 3).
INT_VAR flag_disabled to the new value of the flag known as disabled (bit 5).
STR_VAR container_name to the name of the container to be patched. This variable is required.
STR_VAR container_script to the resref of the new container script.
STR_VAR container_key to the resref of the new container key.

 

There's a built-in function ALTER_AREA_CONTAINER. It uses the container name as the only match variable, and doesn't allow you to change the name - so you're stuck with that annoying generic name unless you get in the even more annoying low-level weeds. If anyone's written a more flexible version of the function, I'm not aware of it.