Pathfinder Spell Database Library (UPDATED 19.0811.1)

Show off your RPG maps, campaigns, and tokens. Share your gaming experiences and stories under General Discussion and save this forum for things you've created that may help others run their own games. Use the subforums when appropriate.

Moderators: Azhrei, dorpond, trevor, Gamerdude

User avatar
Full Bleed
Demigod
Posts: 4444
Joined: Sun Feb 25, 2007 11:53 am
Location: MD
Contact:

Re: Pathfinder Spell Database Library (UPDATED 19.0729.2)

Post by Full Bleed »

aranginor wrote:
Tue Jul 30, 2019 3:42 pm
The 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?
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 6:55 pm
Also, 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.
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:

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 *wish* I'd of done this in the beginning of my framework design. I'd probably only have a few hidden props on a token and just about everything on their Lib token just to deal with concurrency issues.

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
I'd maybe offer GM's an option to set an alternative place to have player settings saved (like Table Name/Range Value or a Lib Token name/Property), but I'd make that a GM only setting, so only the GM would be writing to the Settings Table.
Maptool is the Millennium Falcon of VTT's -- "She may not look like much, but she's got it where it counts."

aranginor
Giant
Posts: 131
Joined: Fri Dec 05, 2008 2:32 pm

Re: Pathfinder Spell Database Library (UPDATED 19.0729.2)

Post by aranginor »

I was talking about just saving the settings in "All Players and Colors" as a sort of Theme.
I don't understand this. What is "All Players and Colors"? Is this a save location?

What I was thinking of was putting default font and colors in each of the themes we have created. Like in table positions 41=Frame, 42=Graphics,43 = Font, 44 = font color, 45 = link color, 46 = disabled color.
A player could select a theme that would update their personal settings for frames, graphics, font and colors. They could then adjust their personal settings to customize their own personal theme.
We could copy the players personal settings to a global area so other players could try out other customized themes, but where would I store them where concurrency won't be a problem?

But to address some of the concerns you have above (like issues with concurrency),
The problem I have with putting the settings on the tokens is that players will be required to have their token selected to open the library, or to click any link shared from the library. I could have it use the default theme if no token is selected, but I think that might frustrate players who don't get the theme they made because they forgot to click their token. The original design of this library was to have it work anywhere, anytime, token selected or not.

User avatar
Full Bleed
Demigod
Posts: 4444
Joined: Sun Feb 25, 2007 11:53 am
Location: MD
Contact:

Re: Pathfinder Spell Database Library (UPDATED 19.0729.2)

Post by Full Bleed »

aranginor wrote:
Tue Jul 30, 2019 8:50 pm
I was talking about just saving the settings in "All Players and Colors" as a sort of Theme.
I don't understand this. What is "All Players and Colors"? Is this a save location?
Under settings, there are subsections "All Players" and "Colors" that cover : Font, Frames, Graphics, Font Color, Link Color, & Disabled Color. Those settings make up the entire theme they are using.
What I was thinking of was putting default font and colors in each of the themes we have created. Like in table positions 41=Frame, 42=Graphics,43 = Font, 44 = font color, 45 = link color, 46 = disabled color.
A default that looks good would be nice (so you don't end up looking at a graphics set that doesn't work at all with a particular background, for example.) But, as you note below...
A player could select a theme that would update their personal settings for frames, graphics, font and colors. They could then adjust their personal settings to customize their own personal theme.
We could copy the players personal settings to a global area so other players could try out other customized themes, but where would I store them where concurrency won't be a problem?
It's a tough question. Any time you share a resource that multiple people can write to you risk having concurrency issues. Hence my use of lib shadow tokens where they're tied to one token that no one can even touch to trigger an Event (because it's on an inaccessible map.)
The problem I have with putting the settings on the tokens is that players will be required to have their token selected to open the library, or to click any link shared from the library. I could have it use the default theme if no token is selected, but I think that might frustrate players who don't get the theme they made because they forgot to click their token. The original design of this library was to have it work anywhere, anytime, token selected or not.
I actually haven't tested this on clients since I ran into the issue using it with impersonation earlier, but it might be nice to allow people to set up how they want to launch the library with an argument. Impersonated, selected, or player name. Every framework is different. When my players log in they get a welcome message that tells them to 1) Impersonate their Character 2) Launch their Character Sheet 3) Dock sheet to side of screen (only have to do this once now.) Everything they do comes through their Character Sheet. They have no other macros on their token and don't have access to campaign macros. But that's the way I do it... many do things very differently which makes all-in-one solutions more complicated. :/

I don't love the way impersonated works (mainly because I don't feel I have ways to assign and control it like other methods), but I've found that's the most bullet-proof way for many things. I know some would rather use player names, but I've done that in the past and someone inevitably logs in with a different name on occasion. "John" becomes "john" or "johnny" or "Jdog" one week... or someone logs in to use another's character that week... and then stuff tied to a particular player name breaks. Character names stay the same and impersonating a token ties the player to that token for the session and they never have to worry about having the token selected, etc. Heck, one friend built a few amazing frameworks in MT, and he was heavily vested in using token IDs... but then token ID's can "unexpectedly" change or get corrupted and things start breaking. In MT there are various ways to skin a cat... but, rarely a perfect way.
Maptool is the Millennium Falcon of VTT's -- "She may not look like much, but she's got it where it counts."

User avatar
Full Bleed
Demigod
Posts: 4444
Joined: Sun Feb 25, 2007 11:53 am
Location: MD
Contact:

Re: Pathfinder Spell Database Library (UPDATED 19.0729.2)

Post by Full Bleed »

The more I've been thinking about this, the more I feel that we're over-working the feature. ;) Various frameworks deal with these issues in various ways so getting the one perfect way for everyone is always going to be an issue. So you really have to think about how far you want to lean into that...


That said, I would do this to improve the feature:

1) Make it so "Font, Frames, Graphics, Font Color, Link Color, & Disabled Color" can be grouped and named into a "Theme." I would not drill down to the individual graphic set assets to create uber custom themes. Just keep it more basic.
2) Allow GM's to set a Default Theme.

Believe it or not, this will work for 99% of the groups out there. My players don't get to alter much about the way their character sheets look and the sky hasn't fallen! ;)

When introducing the feature to players, the GM can kind of show off the themes and then just go with consensus (or not.)


Optional 1 (Individual Settings)--

3) Disallow players write rights to the settings table. Provide them with only TWO setting options: Home and Theme Selection. When they change one of those require that they send the request via macrolink to the GM in chat: "XXXX requests you update their PFSpells settings." When the GM clicks the link, have it apply the change. I think that works because I really don't think this is going to happen much outside the first time some players set a Home or Select a Theme.
a) This would require two buttons in settings: "Preview Changes." and "Send Changes to GM." Preview would be session only so they could look at the various Themes without sending a setting change. Send Changes to GM would make those changes permanent for the player once the GM runs the macrolink. My guess is that the Preview option will probably be a significant speed improvement anyway since writing to tables is kind of slow.


Optional 2 (Custom Player Created Themes (and probably more work than it's worth))--

4) Allow the GM to assign authoring rights to only one player at a time.
b) This would require a third button: "Request Authoring Rights." If they have authoring rights, *then* give them access to the selected theme's: Font, Frames, Graphics, Font Color, Link Color, and Disabled Color. Let them play around with it, using the "Preview Changes" until they are ready to send changes to the GM. Once they send the changes to the GM, they lose authoring rights and the GM activates the macrolink to add the new theme to the settings table. Now others would be able to Preview it and select it.


The above is a response to the various issues discussed regarding where individual settings can and should be saved across various frameworks and potential concurrency issues. I don't think it's ideal. In my framework saving player settings to a character's shadow Lib tokens would be best (where I already save character specific settings and only launch macros from character sheets.) In another's, it might be best to save to the character token or a unique player/character table, etc. I'm just spit-balling something that would be more universal.
Maptool is the Millennium Falcon of VTT's -- "She may not look like much, but she's got it where it counts."

aranginor
Giant
Posts: 131
Joined: Fri Dec 05, 2008 2:32 pm

Re: Pathfinder Spell Database Library (UPDATED 19.0729.2)

Post by aranginor »

I like your ideas. However, the only time I have a possible concurrency is when each player FIRST initializes their settings. Once their settings have been initialized there is no longer a possible concurrency.

The first line of the settings table is an array that contains global settings and player names. The position in the array determines which line of the table is read/written. So playerX always and only writes to table line 5 and playerY always and only writes to table line 6. This is how I reduced the concurrency.

I don't know about your players, but with mine, once I declare the server is up, they all start connecting at the same time. This is where my concurrency worry comes in. To offset this, what I will probably do is move the player setting initialization from onCampaingLoad to the first time they open the library. In the unlikely event that two or more players just happen to open the library for the FIRST time, the ones that get the concurrency error, can cancel the error and try again, since it is no longer in onCampaignLoad.

User avatar
Full Bleed
Demigod
Posts: 4444
Joined: Sun Feb 25, 2007 11:53 am
Location: MD
Contact:

Re: Pathfinder Spell Database Library (UPDATED 19.0729.2)

Post by Full Bleed »

aranginor wrote:
Wed Jul 31, 2019 9:32 am
I like your ideas. However, the only time I have a possible concurrency is when each player FIRST initializes their settings. Once their settings have been initialized there is no longer a possible concurrency.

The first line of the settings table is an array that contains global settings and player names. The position in the array determines which line of the table is read/written. So playerX always and only writes to table line 5 and playerY always and only writes to table line 6. This is how I reduced the concurrency.

I don't know about your players, but with mine, once I declare the server is up, they all start connecting at the same time. This is where my concurrency worry comes in. To offset this, what I will probably do is move the player setting initialization from onCampaingLoad to the first time they open the library. In the unlikely event that two or more players just happen to open the library for the FIRST time, the ones that get the concurrency error, can cancel the error and try again, since it is no longer in onCampaignLoad.
You could have a concurrency problem any time they edit their settings, too. So if I go, "Hey, got a new feature in PFSpells, you can set your Home landing spot." Then they all go in to do and it at the same time one, or two is likely to bounce off the other. Same with telling, "Hey there is a new PFSPells Theme, check it out!" But the worst case scenario is any time two or more would be working on customizing a new theme at the same time... every time they change something to see how it looks (new font or text color) it's writing their new settings to the table (i.e. hitting the table with a new write command.) Multiple players trying to save to the same table at the same times as they're rolling through the different setting options will likely be a problem... at least, it is on a token, so I assumed it will be on a table. I really have no idea if it will fail gracefully... But I'm pretty sure it will fail. Reduce the final save of a tinker session to the last step in the process (i.e. let them "View" changes before sending a save to the table) and you'd probably have an exponentially lower chance to collide, but you'd still have a chance any time more than one person has rights to edit the same thing and they're working on that thing at the same time.

If that wasn't likely a problem we wouldn't have opened this can of worms when you brought up your concerns with multiple people trying to write to the settings at the same time.
Maptool is the Millennium Falcon of VTT's -- "She may not look like much, but she's got it where it counts."

aranginor
Giant
Posts: 131
Joined: Fri Dec 05, 2008 2:32 pm

Re: Pathfinder Spell Database Library (UPDATED 19.0729.2)

Post by aranginor »

You mean to tell me when someone writes to a table, it locks the ENTIRE table? Not just the table line they are writing?

User avatar
Full Bleed
Demigod
Posts: 4444
Joined: Sun Feb 25, 2007 11:53 am
Location: MD
Contact:

Re: Pathfinder Spell Database Library (UPDATED 19.0729.2)

Post by Full Bleed »

Requests for image navigation table on the home page:

1) Remove all padding.
2) Make row one a single cell. It's impacting my ability to place a smaller graphic in the second column of Row 2.
3) Center images horizontally and vertically within the cells (right now I think it's centered and top justified.)
Maptool is the Millennium Falcon of VTT's -- "She may not look like much, but she's got it where it counts."

User avatar
Full Bleed
Demigod
Posts: 4444
Joined: Sun Feb 25, 2007 11:53 am
Location: MD
Contact:

Re: Pathfinder Spell Database Library (UPDATED 19.0729.2)

Post by Full Bleed »

aranginor wrote:
Wed Jul 31, 2019 10:44 am
You mean to tell me when someone writes to a table, it locks the ENTIRE table? Not just the table line they are writing?
That's my assumption because that's the way tokens work. You write to a single property and the whole token is written. Two people can't write to the same token by writing to two different properties and be safe. One will "win".

Keep in mind that tables used to be really, well, "limited" (compared to how they are now.) But in 1.4.0.1 we got a whole slew of new table functions that lets us start using them like databases. But that doesn't mean that they were designed from the ground up to actually be databases. Before that version of MT it would have been nearly impossible to do with tables what you're doing now (which is why you may have noticed that both Alias and I have spoken about previously using tokens as databases for our spells.)

Take a look here: viewtopic.php?p=262789#p262789

So, I can't say for *certain* that it won't work. But my money is on it being a problem. I'll try to open two clients locally and do two saves and see what happens....
Last edited by Full Bleed on Wed Jul 31, 2019 11:27 am, edited 2 times in total.
Maptool is the Millennium Falcon of VTT's -- "She may not look like much, but she's got it where it counts."

aranginor
Giant
Posts: 131
Joined: Fri Dec 05, 2008 2:32 pm

Re: Pathfinder Spell Database Library (UPDATED 19.0729.2)

Post by aranginor »

If that is true, that multiple writes to the same table, but different lined still causes concurrency, then I will just go to one table per player and avoid the problem completely and not have to do a bunch of workarounds.

I will need an image from you, like the others I use for tables, that says PLAYER. I have already added Player Maintenance so GMs can clean up old players or players who like to connect with different names.

User avatar
Full Bleed
Demigod
Posts: 4444
Joined: Sun Feb 25, 2007 11:53 am
Location: MD
Contact:

Re: Pathfinder Spell Database Library (UPDATED 19.0729.2)

Post by Full Bleed »

aranginor wrote:
Wed Jul 31, 2019 11:22 am
If that is true, that multiple writes to the same table, but different lined still causes concurrency, then I will just go to one table per player and avoid the problem completely and not have to do a bunch of workarounds.

I will need an image from you, like the others I use for tables, that says PLAYER. I have already added Player Maintenance so GMs can clean up old players or players who like to connect with different names.
Moving some edits from above since we were cross-posting:

Ok, was setting up to try and test table concurrency and ran into a problem where I could not get into settings on the player client. When I clicked on the settings gear it threw a "Macro-defined error: GM Only" error.

And, unrelated, when clicking on schools on spell lists I got: Unknown JSON type "" in function "json.contains".

When the ability for players to get into settings is fixed I'll try and do some concurrency testing to see what happens before you go ahead with creating player tables.
Maptool is the Millennium Falcon of VTT's -- "She may not look like much, but she's got it where it counts."

aranginor
Giant
Posts: 131
Joined: Fri Dec 05, 2008 2:32 pm

Re: Pathfinder Spell Database Library (UPDATED 19.0729.2)

Post by aranginor »

Going to put the test file right here. Not all new features are completely done, but you can test what you need to. After you are done, I will delete,
Attachments
LibPFSpells.rptok
(157.3 KiB) Downloaded 16 times

User avatar
Full Bleed
Demigod
Posts: 4444
Joined: Sun Feb 25, 2007 11:53 am
Location: MD
Contact:

Re: Pathfinder Spell Database Library (UPDATED 19.0729.2)

Post by Full Bleed »

aranginor wrote:
Wed Jul 31, 2019 12:07 pm
Going to put the test file right here. Not all new features are completely done, but you can test what you need to. After you are done, I will delete,
Yeah, don't really need to. I went ahead and tried running a simplified version of my "Add New Graphix" macro where it would just add 50 new entries (500-550 for one client 600-650 for the other) and it has failed pretty badly. The client to run the macro first seemed to get through at normal speed (the macro button raised, but the end chat message did not come through), the second which started a couple seconds later took much longer to run and has completely bogged down the server... seemingly, wiping out everything that the first client did to the table and then crawling through it's own execution adding entries in to 600-650 range (taking 5-10 minutes and counting to do it)... when it finally finished, both chat messages came through indicating that they'd finished, and it turns out that the only one that stuck was the first one (which looked wiped out while the second was adding.)

I know that's not the sort of hit this library would be doing, but it shows that two writes close together is not likely to play nicely.

Now I'm wondering if MT is really even friendly to writing to two separate tables at the same time... will check that next after my Server gets out of the molasses it appears stuck in...

Ok, just ran a test where I ran the macro to add only 10 spots to two *separate* tables at the same time (to see if having separate Player tables that were being hit simultaneously would be an issue.) I ran the macros a few seconds apart. It pegged my computer's CPU to 100% for about 3 minutes... and took about 4 minutes total before I got the execution chat broadcast that it was done. Only the first macro worked. The second was ignored. Moral of the story is that MT doesn't want you writing to two tables at the same time.

If you want the path of least resistance I suggest you put the individual settings on an owned token. If players want to use their custom settings and not the GM set default, I think they can be bothered to select their token and fire off the PF Spells macro.
Maptool is the Millennium Falcon of VTT's -- "She may not look like much, but she's got it where it counts."

aranginor
Giant
Posts: 131
Joined: Fri Dec 05, 2008 2:32 pm

Re: Pathfinder Spell Database Library (UPDATED 19.0729.2)

Post by aranginor »

Your numbers sounded off, so I did my own test. Holy crap! You were right. I simply ran the increaseImages macro (your macro, my version). On the server it took 15 seconds. On the client, it took almost 4 minutes. WOW!!!

My next test was to do 230 table updates. The server took 5 seconds, the client took 1 minute.

My next test was to do a single table update. The server was instant, the client took 8-10 seconds.

So every time a player, including GM, updates a table, that is the communications back log that is created.

Morale of the story: tables are great for reading, not so much for writing.

Working on token settings with a backup default if a token is not selected.

User avatar
Full Bleed
Demigod
Posts: 4444
Joined: Sun Feb 25, 2007 11:53 am
Location: MD
Contact:

Re: Pathfinder Spell Database Library (UPDATED 19.0729.2)

Post by Full Bleed »

aranginor wrote:
Wed Jul 31, 2019 2:01 pm
Your numbers sounded off, so I did my own test. Holy crap! You were right. I simply ran the increaseImages macro (your macro, my version). On the server it took 15 seconds. On the client, it took almost 4 minutes. WOW!!!
Heh, it sounds like you did Server/Client tests. That's not half as bad as doing Server/Client/Client tests. ;) That is, have two *clients* try to write to 1 table or even 2 different tables at the same time. It darn near implodes (check your task manager during the whole thing)... and, worse, the second client's write attempt will outright fail whether they're writing to the same table or not (after taking forever to do it.)

I don't want to be too critical of MT for this though since this is not what its tables were ever built for. These newer functions opened up some doors, but the limitations have to be respected.
Maptool is the Millennium Falcon of VTT's -- "She may not look like much, but she's got it where it counts."

Post Reply

Return to “User Creations”