RPTools
[Feature]: Drawing and Template Improvements
Is your feature request related to a problem? Please describe. Drawings and templates cannot be easily manipulated once drawn, whether by moving them around on the map or by macros. Currently, the only way to get the ID of a drawing is via the Draw Explorer interface, so it is difficult to use macros to affect them. Even if that were possible, what can be done with those drawings is currently very limited.
Describe the solution you'd like I would like for drawings to be objects that can be interacted with similar to a token. This would be especially useful for templates that show area of effect, allowing players to create an appropriately-sized area and move it around to see how many targets they can affect, rather than having to redraw the template each time.
If possible, it might be useful for AoE templates to enable 'scrolling' through them to rotate them, especially for shapes like cones and lines.
More powerful usages of the drawings would require increased macro support via:
- Addition of drawings to the getTokens() function, or a getDrawings() function to allow for collection of drawing IDs outside of Draw Explorer.
- A getLastDrawing() function, which might be useful for tracking AoEs since they are often used
- A createTemplate() function that could make templates based on defined parameters - could return the ID of the created drawing as well for use in macro. createTemplate() and not createDrawing() because I have no idea how you could possibly replicate everything a drawing does in a macro.
- A copyDrawing() or moveDrawing() function that works similarly to copy/moveToken()
- A getTokensOverDrawing() (idk maybe needs a better name) function that returns all token IDs contained within a drawing to identify targets affected by an AoE
- There are probably more things that could be done with this (e.g. changing the size/color of templates) but I admittedly don't use drawings excessively for much at this stage
Proposed macro flow for the above in action:
- Player casts an AoE spell that creates an AoE template (either with createTemplate(), moveDrawing(), or copyDrawing())
- Player moves the newly created/moved template into position underneath enemies
- Second macro applies damage to targets within the AoE using getTokensOverDrawing()
Alternative to the above using getLastDrawing():
- Player casts AoE spell
- Player makes a drawing
- Second macro applies damage to targets within the AoE using getTokensOverDrawing(getLastDrawing())
Describe alternatives you've considered
As far as I'm aware, there is no alternative option for physically moving the drawings. There is a possible alternative for the functionality of grabbing tokens within a certain AoE using current functionality, though - it could be partially simulated using a token with an aura. However, auras do not have the same capability for creating shapes (e.g. lines, freeform wall templates) and are more cumbersome if an effect is centered at the intersection of 4 grid squares as opposed to on a single grid square.
This would be especially useful for templates that show area of effect, allowing players to create an appropriately-sized area and move it around to see how many targets they can affect, rather than having to redraw the template each time.
I was thinking of this usecase as well for templates.. It would be so handy to have the ability to create them then move and rotate them after the fact. I found myself redrawing templates from scratch a couple times in one of my most recent battles that I ran. Another interesting usecase is for persiting spells such as Cloudkill where you need to move the AoE at a later time:
The fog moves 10 feet away from you at the start of each of your turns, rolling along the surface of the ground. The vapors, being heavier than air, sink to the lowest level of the land, even pouring down openings.
Good point about the moving AoEs! One thing that I hadn't mentioned in the original post is that this would be great for targeting for persistent effects - even if they don't move like Cloudkill. Just having a template on the board that you can check if a token is on top of would make targeting for persistent effects (Wall of Fire, Moonbeam, etc.) much more user friendly - and you can't just use the initial targets since creatures could be moving into and out of those areas at any time.
Housekeeping! #4111 #1276
I think those issues bring up separate concerns, so I don't know if they should necessarily be pruned.
Yeah my bad for the lack of clarity.. By housekeeping I just wanted them to relate in some way since they were all discussed in the discord, and they all are relate to the template system.
Love that all of the issues (this and the two linked via housekeeping) might all be considered together. IMHO a solution that solves all three and more would be fantastic and very much appreciated!
I recently had a play with Foundry VTT and it does this very nicely. I would be in favour of implementing a very similar system. A glimpse at that system can be seen in this brief video: https://www.youtube.com/watch?v=l112GeL-S1E
Main features are:
- The template has a start point which is interacted with in a similar way to a token. It can be dragged to an alternate location, double-clicked to open a settings menu, and deleted. The settings allow for fine-tuning such as adjustment of cone template angle (which would resolve issue #4111 )
- A cone template can be adjusted on the fly by SHIFT-scroll to change the angle by 45 degrees, or CTRL-scroll to change the angle by a smaller amount (I'm guessing 5 degrees).
- The template type can be adjusted, so even if you started with a cone you could change your mind and make it a circle etc. Multiple cone types might be able to be implemented, solving issue #1276 .
For bonus points, it'd be lovely if the template texture could be an animated image for those that want bling. Something like: https://www.youtube.com/watch?v=ktVyp6sJUXw
I am looking to work on some new template/drawing functions, which considered along with all the other PRs linked above hopefully may close this request.
What you've done looks amazing, and I can't wait to use it when I'm back from my hiatus of programming + running games! It definitely covers most everything in the realm of non-macro interaction with templates. There are a couple things that may be missing, though, or I'm just not seeing where you've mentioned them.
One would be the ability to rotate templates after being drawn - it looks like CTRL/SHIFT + scroll are open to being used. This would be different from the default rotation of tokens and drawings as the shape would need to be changed when rotating some templates, particularly cones and lines.
Another, which may be slightly out of scope, would be the addition of a cone template that supports the 5e version (I don't think this was explicitly part of this issue, but had been discussed).
As for closing this issue, there's some macro interactivity stuff that doesn't seem covered by your PRs, but I haven't been keeping track of the shape() functions - not sure if that stuff has been included there? But as for what you've done with the current PR, I'd just hope that drawings/templates will be able to support that kind of macro functionality in the future.
@Pmofmalasia thanks! In response:
rotate templates after being drawn
From 1.19, this is handled via #5731 where with the new TemplatePointerTool being active and on selected templates:
- Mouse
DRAG+CTRLallows resizing of templates after they have been drawn and for cones this will also allow changing the rotation/direction. This replicates the behavior when drawing original cone templates. - Mouse
DRAG+ALTwill move the "path vertex" which will change line rotation/direction.
Saying this, it may be a 'nice to have' to be able to rotate the cone without changing the radius. If you have not already, maybe download and take the nightly build for a spin! Let me know of any usability or testing feedback?
addition of a cone template that supports the 5e version
IMO new templates are out of scope of this request, 5E cone templates having been already requested elsewhere.
macro interactivity
I was not specific in my last post, but my intention is to cover those bits off in the next bit of development I said I would be working on (i.e. createTemplate, copyDrawing, moveDrawing, tokensOverTemplate functions).
Just checked it out - feels very nice to use! Didn't realize that the bit about changing lines/cones was already in there. The only thing that feels odd to me is the distinction between DRAG + CTRL and DRAG + ALT for lines. Though it seems like that's a result of the two-step method of drawing lines. Probably out of scope for this request, but it makes me wonder why two steps are required for lines in the first place? It's always confused me why they need two clicks when I could just do the first click out to the distance I want, but I'm sure there's a reason for it.
I do agree that having the ability to rotate a cone without changing the size would be nice to have, though - I plan on generating templates via macro and then having players reposition them, so I can foresee my players trying to rotate a cone, changing the size, and then forgetting what the original size was.
Another approach to the above use case could be a setting to "lock" the sizes of templates so they can't be changed, just moved or rotated. I'm not sure if that's really feasible to do via UI, but I could see it being an option in a createTemplate() macro.
And gotcha, didn't realize the macro stuff was yet to come - looking forward to it!
Being able to lock a template's dimensions does seem fairly important.
And, though I haven't tested this yet, I hope that manipulating templates and drawings ends up aligning with how we will one day be able to manipulate "shapes" of *BL once @kwvanderlinde 's new *BL is extended to that.
but it makes me wonder why two steps are required for lines in the first place? It's always confused me why they need two clicks when I could just do the first click out to the distance I want, but I'm sure there's a reason for it.
I believe it's for line spell effects and such that have a fixed distance. The two-step process lets you first pick a target, then set the distance as required by the rules.
How would people want to use a new moveDrawings() function?
- To a specific x & y co-ordinate?
- Shunt by an x and/or y amount?
- To/from different maps?
- Something else?
Where x or y could be: cell reference, the map pixels reference (i.e. based on grid size), or distance per cell reference (e.g. 5 feet). Templates would seemingly use cells or distance more than map pixels (and would have to be rounded to the nearest cell).
How would people want to use a new tokensOverTemplate() function?
- List tokenIds with a footprint completely over the template?
- List tokenIds with a footprint partially over the template?
- Something else
I'm honestly not sure what would be best for drawings as most of what I'd plan to use is with templates, so I'll defer to others there. For templates, if possible it would probably be best to have options for tolerance of inclusion/exclusion, maybe using parameters similar to canSeeToken(). For example, default to requiring all of the token ("TOP_LEFT", "BOTTOM_LEFT", "TOP_RIGHT", "BOTTOM_RIGHT", "CENTER") in the template, but have an option to include the token if X number of the above options are included (e.g. if X = 2, it would not be included if only a corner overlaps the template, but would be included if a corner + the center or more are included).
I think the amount that people consider "over" the template would vary depending on system and/or GM, so having some flexibility is probably best.
Thanks. Yeah, I did take a look at canSeeToken() and have based getTokensOverDrawing() on it, however I felt the 5 token location points were not granular enough for this purpose. WIP is that a token footprint bounds (or image bounds for non-snap-to-grid tokens) is broken down into 100 squares and compared to the drawable area, which then provides an approximate % drawing/template overlap. e.g.
and
N.B. the Dragon tokens shown in the above two images are Snap to Grid, the Eagle tokens are not.
Also shown above is a new a getSelectedDrawings() function which works with the new in 1.19 DrawingPointerTool and TemplatePointerTool to expose respective selected drawings/templates to macros.
That sounds even better! I just went with canSeeToken() for something pre-existing, but a percentage of the token would be a nice level of granularity.
Separately, it seems that the output is an array of objects with the tokens as the keys and the percentage covered as the value? On the scripting side I think it would be easier to set a threshold and only output tokens above that threshold as an array of tokenIDs, rather than filtering it later.
Alternatively, could set a threshold in the function and keep the output format as is in case people need the percentage - perhaps this is useful outside of the binary in/not in the template in some systems? Using json.fields on the output wouldn't be as much of a pain on the scripting side as filtering it.