Definitions for the Player1-6 and Player1-6Fill object references

[Guest Modronic]

Hello,

It seems that the IESDP could use an improvement to descriptions of Player1-6 and Player1-6Fill. Currently at the top of the page for OBJECT.IDS (EE, BG2, BG1) it says "Static objects (e.g. Player1, Myself) are always bound (and in fact, they always return the same creature)". Down the pages, for Player1 it says either nothing or "Returns the player in the first portrait slot.", and for Player1Fill it's also "Returns the player in the first portrait slot." (no mention in BG1, I suppose it doesn't exist there).

I think it's the "down the pages" descriptions that need a change. From limited tests, PlayerX and PlayerXFill appear to have nothing to do with portraits, they're just references to party members independently from their portrait's position. The PlayerX references point to nothing until a character joins the party and refs with a lower X have already been assigned. Said differently, the character who joins gets the empty PlayerX reference with the lowest value, and keeps it until he leaves. Then whoever joins next takes the spot, unless a lower one has been freed as well.

PlayerXFill is reassigned every time the party changes. It takes the PlayerX list and basically compacts it to the left so there's no hole, i.e. if you have a party of 6 and kick out Player2, Player4 and Player5, then besides the unmovable Player1 remain Player3 and Player6. Player3 will be Player2Fill and Player6 will be Player3Fill.

When one new character joins, he'll get the Player2 reference since it's the lowest empty PlayerX, and the PlayerXFill will be recomputed: He'll be Player2Fill, and now Player3 will be Player3Fill and Player6 will be Player4Fill.

So yeah, it seems that these object references have nothing to do with portraits. Now how to word that in a concise and clear way for the IESDP... ^^

[lynx]

The way you describe PlayerXFill clearly matches the portraits, so your conclusion is a bit odd. I think the wording mentions portraits from reverse engineering and just looking at the great work being done on iwd2, you can see how these are tied together. Those two arrays correspond to both sets of objects and you can search for their use.

https://github.com/alexbatalov/iwd2-re/blob/main/src/CInfGame.h#L392-L393

[DavidW]

7 hours ago, lynx said:

The way you describe PlayerXFill clearly matches the portraits

Does it? Portraits can be rearranged freely, after all, without affecting the PlayerN and PlayerNFill objects (assuming the OP’s description is correct).

[lynx]

In that case no, which reminds me ees also have PartySlotN objects.

[Bubb]

This post might help. 

Edited March 19 by Bubb
Removed Embed

[Guest Modronic]

Quote

The way you describe PlayerXFill clearly matches the portraits

The list of portraits as seen in the UI is what I'm referring to. It has a programmatic existence as it defines the party "leader" and decides who stands where in party formations. This list is freely arrangeable but has no effect on the PlayerX list; to affect that one the party composition must change, i.e. someone must leave or join. Since the PlayerXFill list is constructed from the PlayerX list, it too has nothing to do with the ordering of portraits as seen in the UI.

By "PlayerXFill is reassigned every time the party changes." I meant the list is rebuilt from PlayerX every time someone leaves or joins. (Or possibly every time the PlayerX list is modified, if there are other obscure means to achieve that in game; but rearranging portraits is not one of them)

Note that asking a party member to leave and changing your mind when they come talking for a confirmation does change their PlayerX handle. e.g. the "kicked-out-but-oh-nah-you-can-stay Player4" will become Player2 if that reference is empty, and that'll leave the Player4 ref empty even if Player5 is assigned to another companion.

Also I've only tested BG2EE 2.6.6.0, I can't talk for any other game or edition and especially not for IWD2 which I've never played. ^^

 

Regarding IESDP wording, I'd reconsider using Player1 as an example at the top of the pages for OBJECT.IDS, and for PlayerX, I'd say something like "Returns the party member that was assigned this slot when joining the team. This has nothing to do with the order portraits are displayed in in the game interface. Upon joining, a new party member is assigned the lowest free PlayerX handle and keeps it until they leave.". For PlayerNFill I'd say: "Returns the party member with the Nth lowest PlayerX handle."

 

[Guest Modronic]

  

I didn't see Bubb's post. It does throw grease in the wheels with this:

Quote

Keldorn is gone, yet the [PlayerX] list does not shift to fill the gap, (until you save / reload).

It's true, reloading appears to apply PlayerXFill's "algorithm" to the PlayerX list (i.e. compacting). In other words, if the party is composed of only Player1, 3 and 6, and I save my game and reload, Player3 will now be Player2, and Player6 will now be Player3. Anyone that joins next will be Player4, whereas they'd have been Player2 if I didn't reload. So their kinda-permanent-until-departure PlayerX handle is not the same whether I reloaded or not before hiring!

Note: Reloading does not make the PlayerX handles follow portrait order. According to Bubb, PartySlotX is the list that follows portrait order: "If you actually want to target a specific portrait slot, use PartySlot[1-6]."

This makes it harder to write a concise explanation but I guess I'll try to fix the IESDP suggested language with that new info:

Player1 to Player6: "Up to six handles assigned to party members as they join or as a saved game is loaded. This has nothing to do with portrait order; use the PartySlot1-6 handles for that. When a companion joins the party, they get the lowest handle available, and keep it until they leave, at which point that handle will refer to nothing. If the game is saved and reloaded, companions with higher handles will be shifted down, maintaining order, so that there is no hole in the list of occupied handles."

Of course, use whatever wording you like, I'm just trying to save you time since I've been the one bringing it up.

[lynx]

Thanks all, I wrote it even more succinctly:

https://github.com/Gibberlings3/iesdp/commit/09092ac2c3dc37ba9c0f09b285d4cec0175153ac