phantomwhale
April 3rd, 2011, 14:12
I'm trying to fix up some bugs with Allies in Savage Worlds. In Savage Worlds, you can have NPCs (personalities, as they are called on the GUI) and these can be shared with the players.
They can also have their shortcuts dragged onto a character sheet list (called Allies), which gives the players a link to open up the NPC sheet, and view the NPC detail.
The bug I am facing is if a non-shared NPC is put on that list; the player will not be a "holder" of the NPC database nodes, and therefore attempts to open the NPC off the Ally list result in console errors. After trying some clever solutions that all don't quite work, my thoughts on a fix here are simply when a user logs in, add him as a holder to the NPC database node, and remove him when he logs out for cleanness.
But my question is really around a side-effect of this bug, which is on attempting to open the NPC via the shortcut link when the user has NO "holder" access to the data, it seems the user still manages to open the sheet, but all the NPC's attributes (dice fields) have been set to d4 (which is default for a blank field). What I am surprised by is that this changes the attributes on the server database as well ?!
I wasn't aware the client application sessions could alter the server database with being an owner (e.g. a holder, with the owner="true" flag), yet here without even being the holder, the player is able to change these attribute dice fields. Even when the NPCs are correctly shared, and open without error, I also note the players cannot modify the text or number fields on the shared sheet... but can still modify the dice fields - these modifications being replicated on the server ?!
Am I misunderstanding how the database update security model works ? Or is this a known "bug" at all ? This, it seems, will cause me problems even if I can manage to ensure all users have holder permissions to their character(s) allies, as I still don't want them able to adjust the allies core attributes !
Thanks,
Ben (-PW-)
They can also have their shortcuts dragged onto a character sheet list (called Allies), which gives the players a link to open up the NPC sheet, and view the NPC detail.
The bug I am facing is if a non-shared NPC is put on that list; the player will not be a "holder" of the NPC database nodes, and therefore attempts to open the NPC off the Ally list result in console errors. After trying some clever solutions that all don't quite work, my thoughts on a fix here are simply when a user logs in, add him as a holder to the NPC database node, and remove him when he logs out for cleanness.
But my question is really around a side-effect of this bug, which is on attempting to open the NPC via the shortcut link when the user has NO "holder" access to the data, it seems the user still manages to open the sheet, but all the NPC's attributes (dice fields) have been set to d4 (which is default for a blank field). What I am surprised by is that this changes the attributes on the server database as well ?!
I wasn't aware the client application sessions could alter the server database with being an owner (e.g. a holder, with the owner="true" flag), yet here without even being the holder, the player is able to change these attribute dice fields. Even when the NPCs are correctly shared, and open without error, I also note the players cannot modify the text or number fields on the shared sheet... but can still modify the dice fields - these modifications being replicated on the server ?!
Am I misunderstanding how the database update security model works ? Or is this a known "bug" at all ? This, it seems, will cause me problems even if I can manage to ensure all users have holder permissions to their character(s) allies, as I still don't want them able to adjust the allies core attributes !
Thanks,
Ben (-PW-)