For now I'd keep players out of the image table and only allow them to select a graphics set rather than mix and match assets. I was talking about just saving the settings in "All Players and Colors" as a sort of Theme. That way they'll come up with the basic stuff that they like together.aranginor wrote: ↑Tue Jul 30, 2019 3:42 pmThe players already have the ability to play with things. They can choose their own frames, graphic set, font, font color, link color and disabled color. These could be auto populated or overwritten by choosing a theme and then allowing further customization which is saved by player. I could add the ability for one player to clone the "theme" settings from another player.
The biggest problem I see is that players will not be able to customize graphics, since by default, they do not have access to the pf.spells.images table. I could allow access to the table with an option, which would be off by default. Since there is no way to test if a table entry has an image, trying to get the image from a table entry that has no image causes an error. Allowing players to edit this table could cause the library to stop working. This is why I have put a warning on the increaseImages macro you sent me.
Maybe set it up where they can choose, from predefined themes, which graphics they want from each theme. So they could choose the title from one theme, bloodlines from another, domains from another and so on. These settings would be saved to the player and then clone-able.
What do you think?
This is going to get a bit into framework design... But to address some of the concerns you have above (like issues with concurrency), in my frame work, every player token has a property called "Library". In that property is the name of a Lib token specifically for that token (usually like Lib:John). And, yes, on their lib token (I call it a shadow token) I have a property called "Settings" where I store a few Character Sheet settings (I use a string list.) That way I use getLibProperty(propName, Library) to pull things from their Lib token instead of their tokens. I even have a UDF that will work with NPC and PC tokens:aranginor wrote: ↑Tue Jul 30, 2019 6:55 pmAlso, I have been thinking about what would happen when multiple players connect at the same time. They could all be trying to write to the settings table at the same time. I separated each player into their own table entry to reduce the problem, but it could still happen especially when two or more players connect at the same time and create their initial settings.
I am thinking of creating a table per player or token to hold their settings. I may do token instead of player because if a player has more than one token they may want their wizard to open to the wizard page and their cleric to open to the cleric page.
Actually I am thinking I may move my framework to this idea. The first line of each player or token settings table will contain an array with settings names with their indexes corresponding to their table position, similar to how I am handling pf.spells.settings now. Or something like that. I have to think about it because sometimes we have a token with more than one owner or a single player with multiple tokens.
getProp("propertyName")
Code: Select all
[h: propName = arg(0)]
[h, if(getPropertyType() == "NPC"), CODE:
{
[h: propValue = getProperty(propName)]
};
{
[h: propValue = getLibProperty(propName, Library)]
}
]
[r: propValue]
I do also give each player a table named after themselves ("PC-CharacterName"). *But* I only use that to store images custom to their character (different token images and portraits, etc.)
That said, I wouldn't want to break *this* drop-in by making users go through a bunch of steps to get it working. And it's best to keep the number of tables down. We're up to 3 with 1 dynamically created. One of the beauties of this drop-in is how easy it is to get it working.
So, if you want to put in an optional way to let the GM determine where a Player's settings are saved I think that would be great. But forcing people to create shadow tokens or unique player tables will start to complicate things unnecessarily. However, your issue of worrying about them trying to save to the Setting table at the same time is a real one, so I'd default to a hidden property on the player token for their PFS settings for now:
Code: Select all
hid.PFSpells.Settings