Programmatically Setting the Holder Versus Sharing

[Minty23185Fresh]

Quite probably I am doing it incorrectly but I have noticed that sharing an NPC with a Druid character so that they can use it for Wild Shaping (5E) is a little tedious: drag an NPC out of and back into the library to create a copy, maybe rename it, maybe place it in a Group for better organization, then share the copy with the Druid's player. As part of my Druid Wild Shapes extension, I am shortcutting the process - a character's portrait drag to the NPC library to create a special Group, NPC drags into the special Group instantly create copies and set the holder/owner of the copy to the player.

Question: Are there pitfalls or ramifications that I should be aware of, in using DB.addHolder() instead of windowinstance.share() or its equivalent?

[Moon Wizard]

No, they are doing similar things in the background.

* windowinstance.share() is specifically setting the access to the underlying database node, then sending a request to open that window (class/datasource) on the player machine.
* DB.addHolder() is just setting access to the underlying database node.

So, the only difference is whether the window is also opened on the player side.

Regards,
JPG

[Minty23185Fresh]

Thank you Moon Wizard.
I noticed that, and didn’t want the pop up in the client. I didn’t set the “shared” icon, so I have that missing. But otherwise I think I’m good then. Thank you for the help.

I was worried about some sort of allowing access to proprietary/copyright info or something, that share might prevent but heavy-handed addHolder might ignore.