How do holders work in different types of nodes?

[SilentRuin]

Why does the following code always return {} - an empty array. I can edit my db.xml and see holders all over the charsheet's and combat tracker entries but can never get them. Only thing that seems to work is getOwner() but in a lot of those cases it will always be the host.



local aHolders = node.getHolders();
Debug.console(aHolders);


I note that addHolder() will only work if set to true on a CT node but will work with false if set on a reference (like sharing an NPC to a player).

Why? How do holders work - can someone explain it to me? Using them with references works no problems - but charsheets and combat tracker are weird in how they limit or ignore them.

[Moon Wizard]

Some details that might help:
* If the node is set to Public, then holders will be empty, and the public flag will be set.
* If the node is not public, then one or more holders can be assigned to a node.
* The owner of the node is separate, but is always a holder if not public.
* Only the GM can change the public/owner/holder state.
* Any nodes that are public, or which are owned/held by a particular user, will be sent to the player client and part of the player-side database.
* Otherwise, nodes, which are not public and which the user is not a owner/holder, will be deleted from the player client, and will not exist in the player-side database.

These features are used in multiple places in the standard FG ruleset code, so they appear to be working as expected.

Regards,
JPG

[SilentRuin]

Some details that might help:
* If the node is set to Public, then holders will be empty, and the public flag will be set.
* If the node is not public, then one or more holders can be assigned to a node.
* The owner of the node is separate, but is always a holder if not public.
* Only the GM can change the public/owner/holder state.
* Any nodes that are public, or which are owned/held by a particular user, will be sent to the player client and part of the player-side database.
* Otherwise, nodes, which are not public and which the user is not a owner/holder, will be deleted from the player client, and will not exist in the player-side database.

These features are used in multiple places in the standard FG ruleset code, so they appear to be working as expected.

Regards,
JPG

It's the public flag stopping me from seeing any holders. Apparently all the NPC's have it set? Or so my db.xml is showing.

In fact, I can't determine how when you drop an NPC onto a player (to supposedly give him control of it) how that is being done. I assumed it was by assigning them as a holder - but evidently not. How is that being done?

[Moon Wizard]

I ran into this exact situation when looking at some changes I wanted to make; but haven't figured out how I'm going to solve yet.

Basically, all combat tracker data (including NPCs) are all public data. This is necessary in order to provide the right information to the player combat tracker; and support combat automation. When you drag and drop a record to a player PC portrait, you are asking FG to "Share" the window. This will add the player as a holder if they aren't already; but for CT NPC records, they are already public, so no access changes are needed. Then, there is a "share" network message sent that forces the player client to open the shared window; which is what you are seeing when a GM shares an CT NPC record with a player. The reason why players can not see the full CT NPC records during the normal course of play without the sharing is because the player CT does not offer a link to do so. However, the data is already there for other reasons.

Regards,
JPG

[SilentRuin]

I ran into this exact situation when looking at some changes I wanted to make; but haven't figured out how I'm going to solve yet.

Basically, all combat tracker data (including NPCs) are all public data. This is necessary in order to provide the right information to the player combat tracker; and support combat automation. When you drag and drop a record to a player PC portrait, you are asking FG to "Share" the window. This will add the player as a holder if they aren't already; but for CT NPC records, they are already public, so no access changes are needed. Then, there is a "share" network message sent that forces the player client to open the shared window; which is what you are seeing when a GM shares an CT NPC record with a player. The reason why players can not see the full CT NPC records during the normal course of play without the sharing is because the player CT does not offer a link to do so. However, the data is already there for other reasons.

Regards,
JPG

I've solved this for NPC's I create in my extension by insuring having a CT node DB node added that I can extract the original owner from. This allows me to then - say during end turn or a number of other things I need it for in my extension - to extract the owner directly from the CT node and do operations with it.

Its simple, but the only way I've found to make it work for me. Otherwise, end turn and other things required for PC's playing an NPC will not work for the reasons you've stated. I also end up addHolder() to the NPC source link used to create this (so it is shared) and then unshare it when the NPC is removed. Preserving as best I can the NPC can only be seen by those who have legitimate access. Obviously this can be a rabbit hole if you think to hard about it - but I'm a simple person with simple plans so it works for me :)

If you solve it before I'm done with this let me know and I will abandon my end turn solution which only works for NPC's I've created anyway.

[Moon Wizard]

You'll probably get yours done before me. A lot of my ruleset coding is on the back burner as I am bug gatherer, tester, and backup dev for FGU as well.

Regards,
JPG

[SilentRuin]

You'll probably get yours done before me. A lot of my ruleset coding is on the back burner as I am bug gatherer, tester, and backup dev for FGU as well.

Regards,
JPG

Feels like every time I solve one problem I hit another - then it breaks something then I rewrite whole sections and .... one step forward... two steps back :)

But sometimes I get a bunch of steps so that's progress I suppose.