Database ownership question

[Bidmaron]

Database node ownership is apparently important in FG. I don't understand who owns the nodes of a character sheet during a game. If it is the GM, how does the player edit his own sheet? (this obviously works, but how?) If it is the player, how does the GM and the combat tracker and all do the editing it does (hit points, etc)?

On a related note, (I can't test this by connecting to myself, as the database resides on the computer and isn't representative of how things work during a remote connection) what happens if a player attempts to edit the character sheet of another player?

[Trenloe]

Database node ownership is apparently important in FG. I don't understand who owns the nodes of a character sheet during a game. If it is the GM, how does the player edit his own sheet? (this obviously works, but how?) If it is the player, how does the GM and the combat tracker and all do the editing it does (hit points, etc)?
The GM always has full access to the database. Player's can own database nodes and can edit the node they own through the <holder> tag with owner=true. See some info about holder here: https://www.fantasygrounds.com/refdoc/DB.xcp#addHolder Open up a campaign db.xml file where a player has selected a charsheet and you will see the <holder name="Player" owner="true" /> line just after the <id-xxxxx> tag.

During a game players can initiate changes to database nodes they don't own, but this has to be handled by the GM - so the OOB (out of bounds) message process is used - where the player passes info to the GM and the GM processes the info.

A good example of this is the initiative rolling mechanism in 3.5e - the player rolls the initiative but the init resolver triggers an OOB message OOB_MSGTYPE_APPLYINIT which contains the relevant source node info and roll result so that the GM can apply the result to the database in the OOB handler handleApplyInit using DB.setValue(ActorManager.getCTNode(rSource), "initresult", "number", nTotal); This can be seen in scripts\manager_action_init.lua.

It is well worth spending time to understand the OOB process - it can be a ruleset modifiers saviour a few times! :)



On a related note, (I can't test this by connecting to myself, as the database resides on the computer and isn't representative of how things work during a remote connection) what happens if a player attempts to edit the character sheet of another player?
Yes you can test this using a localhost connection - the player instance does not access the database in the campaign folder - it gets access to the database through the info the GM passes over. This is the same as how a remote player would get access to the database.

[Bidmaron]

I remember a post recently by JPG cautioning against opening multiple instances on localhost, as it can corrupt the database. That tells me that something isn't done the same for localhost as for remote connection. Actually, it was you that made the comment (https://www.fantasygrounds.com/forums/showthread.php?20115-Slash-Vote-Issues-With-Multiple-LocalHost-Connections&p=164385&highlight=localhost#post164385). Guess the issue is the cache not the actual database. Just got that confused.

[Moon Wizard]

You don't want to run more than one host and one client on a machine. It's not specifically disallowed, but it can cause issues.

Multiple hosts will end up overwriting each other when saving data to disk, and may run into file conflicts when FG is saving data files which could cause problems.

Multiple clients will end up overwriting the cache files or having file conflicts when saving data. That is, if they are connected to the same campaign.

Regards,
JPG

[Bidmaron]

Thanks for clearing that up, JPG.