Open Jonny134 opened 5 months ago
I struggle to think of the use case for this one. These clocks are global, meaning it is shown to all players. Player specific clocks are sometimes called for in some games (like healing clocks in blades in the dark) but those are usually handled by the system's actor sheets. At best I can think of a @ProgressClock custom text enricher so that a clock can be embedded into a description, but even this is scary without some way to clean it up.
I came here to suggest this same thing. It's a quick and easy way for players to keep track of things that take time without making the DM do it. For instance, I have a player that crafts potions and potions take a certain number of days to brew and they have set things up to craft multiple potions via several stations they have set up. Having the ability to create their own private clocks would make it so they could easily just tick the clocks for their potions.
I struggle to think of the use case for this one. These clocks are global, meaning it is shown to all players. Player specific clocks are sometimes called for in some games (like healing clocks in blades in the dark) but those are usually handled by the system's actor sheets. At best I can think of a @ProgressClock custom text enricher so that a clock can be embedded into a description, but even this is scary without some way to clean it up.
If only the players woud be able to modify the colocks... I would be satisfyed. They dont have to create it, or own them. Just let them modify them. Then everyone could track their own progress, and resources with clocks. This alone, would EXPAND the usability of the module by 50%.
I thought about it, and unfortunately I can't agree. The purpose of this module is for the gamemaster to dynamically create progress trackers during play (for narrative first games that are run fast and loose). While long term project clocks are a thing, this module is ill suited towards doing that, and I'm still struggling to think of a solution. Because of the global nature of the clocks, it is even less suited to do clocks that only pertain to a single player (even healing clocks in bitd). The crafting example listed ticks both boxes.
Does Kasper satisfy your use case better? I haven't tried it yet.
@CarlosFdez Do you mind if I create a clone of this repository and create my own module and add the functionality I want and re-release it under a new module name for those that want the functionality? Of course, all credit for the original work would go to you and this module.
Built a working version of the above mentioned. I don't intend to release it publicly without @CarlosFdez 's permission as much of the code is theirs, however, I've made some substantial changes. They're listed as follows
To help visualize the changes, here are some screenshots
GM Screen with 3 active tickers.
Player's Screen
As you can see, the GM's private ticker is not displayed at all for the player. The GM's secret ticker is displayed with an unknown name. And the public is displayed normally. You can also see, players' individual tickers do not display on the GM's screen to avoid clutter.
A final thing of note, if either list (player or GM) of tickers is empty, that section is entirely omitted from the display to reduce clutter.
Built a working version of the above mentioned. I don't intend to release it publicly without @CarlosFdez 's permission as much of the code is theirs, however, I've made some substantial changes. They're listed as follows
- Clocks are referred to as "Tickers" in my version to differentiate the modules more easily.
- The vertical position of the tickers is now a client-side setting allowing users to decide for themselves if they want tickers at the top or bottom of the screen.
- The offset of the tickers is now a client-side setting to allow users to customize the positioning of the tickers for themselves.
- There are now two separate lists of tickers for players; One list contains the players' personal tickers. These tickers are private to the players. The other list is the GM list where the players can see all non-private tickers made by the GM.
- Added a "Cyclical" option when creating/editing tickers that allows them to go from max -> 0 and 0 -> max with a single click.
- Added a "Hide Name" option. This allows the GM to create a public ticker but prevent players from seeing the name. (Good when you want the players to know there is a time crunch or something is coming without them knowing what).
To help visualize the changes, here are some screenshots GM Screen with 3 active tickers.
Player's Screen
As you can see, the GM's private ticker is not displayed at all for the player. The GM's secret ticker is displayed with an unknown name. And the public is displayed normally. You can also see, players' individual tickers do not display on the GM's screen to avoid clutter.
A final thing of note, if either list (player or GM) of tickers is empty, that section is entirely omitted from the display to reduce clutter.
May I also use your version? Im asking for private use only... please.
I thought about it, and unfortunately I can't agree. The purpose of this module is for the gamemaster to dynamically create progress trackers during play (for narrative first games that are run fast and loose). While long term project clocks are a thing, this module is ill suited towards doing that, and I'm still struggling to think of a solution. Because of the global nature of the clocks, it is even less suited to do clocks that only pertain to a single player (even healing clocks in bitd). The crafting example listed ticks both boxes.
Does Kasper satisfy your use case better? I haven't tried it yet.
No, not really, Unfortunateley...
Built a working version of the above mentioned. I don't intend to release it publicly without @CarlosFdez 's permission as much of the code is theirs, however, I've made some substantial changes. They're listed as follows
- Clocks are referred to as "Tickers" in my version to differentiate the modules more easily.
- The vertical position of the tickers is now a client-side setting allowing users to decide for themselves if they want tickers at the top or bottom of the screen.
- The offset of the tickers is now a client-side setting to allow users to customize the positioning of the tickers for themselves.
- There are now two separate lists of tickers for players; One list contains the players' personal tickers. These tickers are private to the players. The other list is the GM list where the players can see all non-private tickers made by the GM.
- Added a "Cyclical" option when creating/editing tickers that allows them to go from max -> 0 and 0 -> max with a single click.
- Added a "Hide Name" option. This allows the GM to create a public ticker but prevent players from seeing the name. (Good when you want the players to know there is a time crunch or something is coming without them knowing what).
To help visualize the changes, here are some screenshots GM Screen with 3 active tickers.
Player's Screen
As you can see, the GM's private ticker is not displayed at all for the player. The GM's secret ticker is displayed with an unknown name. And the public is displayed normally. You can also see, players' individual tickers do not display on the GM's screen to avoid clutter. A final thing of note, if either list (player or GM) of tickers is empty, that section is entirely omitted from the display to reduce clutter.
May I also use your version? Im asking for private use only... please.
As much as I would love to do this, I will not step on the original module author's toes out of respect to all of the hard work they put in. If and when I get a positive response from them, I'll be sure make it available though!
Built a working version of the above mentioned. I don't intend to release it publicly without @CarlosFdez 's permission as much of the code is theirs, however, I've made some substantial changes. They're listed as follows
- Clocks are referred to as "Tickers" in my version to differentiate the modules more easily.
- The vertical position of the tickers is now a client-side setting allowing users to decide for themselves if they want tickers at the top or bottom of the screen.
- The offset of the tickers is now a client-side setting to allow users to customize the positioning of the tickers for themselves.
- There are now two separate lists of tickers for players; One list contains the players' personal tickers. These tickers are private to the players. The other list is the GM list where the players can see all non-private tickers made by the GM.
- Added a "Cyclical" option when creating/editing tickers that allows them to go from max -> 0 and 0 -> max with a single click.
- Added a "Hide Name" option. This allows the GM to create a public ticker but prevent players from seeing the name. (Good when you want the players to know there is a time crunch or something is coming without them knowing what).
To help visualize the changes, here are some screenshots GM Screen with 3 active tickers.
Player's Screen
As you can see, the GM's private ticker is not displayed at all for the player. The GM's secret ticker is displayed with an unknown name. And the public is displayed normally. You can also see, players' individual tickers do not display on the GM's screen to avoid clutter. A final thing of note, if either list (player or GM) of tickers is empty, that section is entirely omitted from the display to reduce clutter.
May I also use your version? Im asking for private use only... please.
As much as I would love to do this, I will not step on the original module author's toes out of respect to all of the hard work they put in. If and when I get a positive response from them, I'll be sure make it available though!
Sure, @CarlosFdez please grant me your approval. Thank you in advance
The license allows for it, go right ahead.
I like the little headers. That might be a way to separate by group to create "pages" of the stuff, especially with regards to long term clocks. I'd need a way to handle a "collapsed" group though. I'll probably think on it in more detail if I ever get around to running or playing ICON. I'll eventually add recurring clocks (what you call cyclical) as well. I'll have to think about hiding the name.
Given the GM can't see player clocks, I assume you implemented it via a client setting? That works, but I get the feeling GMs may want to verify them. What I had in mind (were I to implement, I actually did consider it) was socket messages sent to the GM to have the GM perform the updates in the player's stead. Another idea I had was to create a journal page sub type (https://foundryvtt.com/article/module-sub-types/) and store them there instead.
- The vertical position of the tickers is now a client-side setting allowing users to decide for themselves if they want tickers at the top or bottom of the screen.
- The offset of the tickers is now a client-side setting to allow users to customize the positioning of the tickers for themselves.
The reason they're world settings is for module/system compatibility reasons, to maintain being "system agnostic". If it was for prettiness, I'd likely aim for a drag/drop solution.
I know Jonny plays D&D5e (DM is a term owned by WOTC), but I don't know what LadyDefile plays. Just in case, the purpose of the module is to implement this https://bladesinthedark.com/progress-clocks. The closest comparison in a game like D&D would be a skill challenge, and in pf2e the closest comparison would be victory points (and the research/stealth/inflitration/etc subsystems). In Forged in the Dark games, players are aware of the odds and consequences before they roll, so nothing is ever hidden.
At the time this module was created, a progress clock was created as a custom actor sheet. Improvising a "chase" event that ticks to 4 by creating a new actor, changing the sheet type, customizing it, then dropping it onto the sheet was way too cumbersome. Those approaches work fine for Long-Term Project clocks (aka crafting) though, so I focused solely on the other types.
Making the dialog bigger runs counter to my original goal. I added support for the enter key just now to mitigate, but I have to evaluate every single feature to avoid bloat. Sections are a nice idea on a way to avoid that.
The license allows for it, go right ahead.
I like the little headers. That might be a way to separate by group to create "pages" of the stuff, especially with regards to long term clocks. I'd need a way to handle a "collapsed" group though. I'll probably think on it in more detail if I ever get around to running or playing ICON. I'll eventually add recurring clocks (what you call cyclical) as well. I'll have to think about hiding the name.
Given the GM can't see player clocks, I assume you implemented it via a client setting? That works, but I get the feeling GMs may want to verify them. What I had in mind (were I to implement, I actually did consider it) was socket messages sent to the GM to have the GM perform the updates in the player's stead. Another idea I had was to create a journal page sub type (https://foundryvtt.com/article/module-sub-types/) and store them there instead.
- The vertical position of the tickers is now a client-side setting allowing users to decide for themselves if they want tickers at the top or bottom of the screen.
- The offset of the tickers is now a client-side setting to allow users to customize the positioning of the tickers for themselves.
The reason they're world settings is for module/system compatibility reasons, to maintain being "system agnostic". If it was for prettiness, I'd likely aim for a drag/drop solution.
Awesome, glad to hear it.
I like the idea of creating a collapsed group option for a little bit of organization/clutter control.
The clocks are handled with GM Proxy through socketlib so they're still global objects. I went that route so if I decided to later on I could add functionality for the GM to see the clocks somehow (Probably collapsed groups).
Do the settings being world scope vs client scoped really affect the system? I had no idea it would do that. That's something that probably needs tested with my version then. It works in dnd5e 3.x at least (That's what I tested in).
The essence of what I did was split the activeClocks
setting into two settings gmTickers
and userTickers
then modified each of the database functions to do a if ( !game.user.isGM )
check. If the user is a GM, works as before but routes stuff into gmTickers. If not a GM, it routes it through the socket then the socket handler routes it through the database with a flag set saying that it was a user request to create the clock.
Initially, I tried keeping them all in activeClocks
but then I had trouble keeping the sort functionality, well, functional. By splitting them apart it made it a lot easier to retain the drag/sort function.
I went with "cyclical" instead of "recurring" or "repeating" because it can cycle in both directions (max to zero or zero to max).
This module's approach might be significantly better suited towards handling long term clocks, rather than the quick spawn/despawn ones this one does: https://github.com/BluSunrize/fvtt-clockworks
I prefer recurring because it better announces its intent (its for recurring obstacles/threats) and fits better with the module's goals (its not a D20 system module....its not meant for it). That said, its probably not a problem if they all cycle without a setting. I'll think about it, that's where I'm currently leaning right now. (EDIT: done, not released yet)
Glad to hear you went with the proxy approach. The functionality you described sounded like you went with separate GM/Player settings (with the player rendering both). Yeah, the ability to add functionality was what I was worried about.
As for world vs client setting, its not that the system fails, its that those settings exist to avoid conflicts of visual space. PF2e puts something in that area at the top. Ripper's Taskbar module and tokenbar puts something at the bottom. Some other module might put something at the top. Those settings were added after I got complaints of module incompatibility. Having every user work around the modules instead of the GM doing it for all is an extra step. If it becomes a user setting, it should be drag/drop.
I prefer recurring because it better announces its intent (its for recurring obstacles/threats) and fits better with the module's goals (its not a D20 system module....its not meant for it). That said, its probably not a problem if they're all recurring even without a setting. I'll think about it, that's where I'm currently leaning right now.
Glad to hear you went with the proxy approach. The functionality you described sounded like you went with separate GM/Player settings (with the player rendering both). Yeah, the ability to add functionality was what I was worried about.
As for world vs client setting, its not that the system fails, its that those settings exist to avoid conflicts of visual space. PF2e puts something in that area at the top. Ripper's Taskbar module and tokenbar puts something at the bottom. Some other module might put something at the top. Those settings were added after I got complaints of module incompatibility. Having every user work around the modules instead of the GM doing it for all is an extra step. If it becomes a user setting, it should be drag/drop.
I can see how the overlapping UI elements could get annoying pretty quick. I don't use any modules that populate the same area so I haven't seen the issue myself but it sounds like it may be worth reverting? We'll have to see how it goes.
https://github.com/CarlosFdez/global-progress-clocks/issues/4 was the reason it was added 😠. It wouldn't exist otherwise. Drag Drop would be like how Times Up (or was it combat timer?) does it, where the entire thing is a mini-window you can reposition.
@CarlosFdez I like your thought on the recurring timers just being how they work rather than an option. One less box for people to tick. Might make "Private" and "Hide Name" be a "Privacy" option where the DM can choose "Public", "Private", "Hide Name" One option that can just be set how they want it. More potential privacy modes in the future that way, too.
@Jonny134 You can find my version of the module here: https://github.com/LadyDefile/simple-tickers
I like the little headers. That might be a way to separate by group to create "pages" of the stuff, especially with regards to long term clocks. I'd need a way to handle a "collapsed" group though. I'll probably think on it in more detail if I ever get around to running or playing ICON. I'll eventually add recurring clocks (what you call cyclical) as well. I'll have to think about hiding the name.
Given the GM can't see player clocks, I assume you implemented it via a client setting? That works, but I get the feeling GMs may want to verify them. What I had in mind (were I to implement, I actually did consider it) was socket messages sent to the GM to have the GM perform the updates in the player's stead. Another idea I had was to create a journal page sub
Actually I play my own coustom system. I need the colocks so players can track a resource, and i want to see when they do. You see my system in in beta at the moment... and I want to see if they are doing it right.
I want to avoid a situation, where players seemingly agree with a rule.
But then they just ignore it, or foget about it.
And then they wonder why their haracters dont work.
Plus momentum point is the hear of my system so it would be nice if everyone would know how the others are doing.
I know Jonny plays D&D5e (DM is a term owned by WOTC), but I don't know what LadyDefile plays. Just in case, the purpose of the module is to implement this https://bladesinthedark.com/progress-clocks. The closest comparison in a game like D&D would be a skill challenge, and in pf2e the closest comparison would be victory points (and the research/stealth/inflitration/etc subsystems). In Forged in the Dark games, players are aware of the odds and consequences before they roll, so nothing is ever hidden.
At the time this module was created, a progress clock was created as a custom actor sheet. Improvising a "chase" event that ticks to 4 by creating a new actor, changing the sheet type, customizing it, then dropping it onto the sheet was way too cumbersome. Those approaches work fine for Long-Term Project clocks (aka crafting) though, so I focused solely on the other types.
Making the dialog bigger runs counter to my original goal. I added support for the enter key just now to mitigate, but I have to evaluate every single feature to avoid bloat. Sections are a nice idea on a way to avoid that.
"At the time this module was created, a progress clock was created as a custom actor sheet. Improvising a "chase" event that ticks to 4 by creating a new actor, changing the sheet type, customizing it, then dropping it onto the sheet was way too cumbersome. Those approaches work fine for Long-Term Project clocks (aka crafting) though, so I focused solely on the other types."
We were useing that back in the day, and I must say for my group they did not work, not even form long ter project. We keept the clocks on a separate tab. But players had projects like "become famous" and they wanted to work thowards these goals during session. i know that originally it was meant to be a downtime activity, but we wanted to use the colocks as reminders that float in front of they player face to keep them in focus. That did not work. With your module. it did.
I prefer recurring because it better announces its intent (its for recurring obstacles/threats) and fits better with the module's goals (its not a D20 system module....its not meant for it). That said, its probably not a problem if they all cycle without a setting. I'll think about it, that's where I'm currently leaning right now. (EDIT: done, not released yet)
Glad to hear you went with the proxy approach. The functionality you described sounded like you went with separate GM/Player settings (with the player rendering both). Yeah, the ability to add functionality was what I was worried about.
As for world vs client setting, its not that the system fails, its that those settings exist to avoid conflicts of visual space. PF2e puts something in that area at the top. Ripper's Taskbar module and tokenbar puts something at the bottom. Some other module might put something at the top. Those settings were added after I got complaints of module incompatibility. Having every user work around the modules instead of the GM doing it for all is an extra step. If it becomes a user setting, it should be drag/drop.
I agree
@Jonny134 You can find my version of the module here: https://github.com/LadyDefile/simple-tickers
Thank you my Lady :)
@Jonny134 You can find my version of the module here: https://github.com/LadyDefile/simple-tickers
I really like it, but it would be really nice if the Gm would see the players clocks or even better if the players could change the privacy settings of their clocks.
@Jonny134 You can find my version of the module here: https://github.com/LadyDefile/simple-tickers
I really like it, but it would be really nice if the Gm would see the players clocks or even better if the players could change the privacy settings of their clocks.
This is a topic for the Simple-Tickers github now. I don't want to keep pinging this one for problems/suggestions with my module. I'm working at the player clocks being able to be public but I'm trying to decide the best way to display them.
@Jonny134 You can find my version of the module here: https://github.com/LadyDefile/simple-tickers
I really like it, but it would be really nice if the Gm would see the players clocks or even better if the players could change the privacy settings of their clocks.
This is a topic for the Simple-Tickers github now. I don't want to keep pinging this one for problems/suggestions with my module. I'm working at the player clocks being able to be public but I'm trying to decide the best way to display them.
I move it there. Thanks
Allow players to create, modify and own clocks.
Thank you.