RPTools
[Feature]: Configure token size categories
Describe the Problem
MapTool has no functionality enabling a GM to customise or configure token size categories.
- currently token size names for a square/iso grid are seemingly named after D&D 3.0 sizes, gridless uses numbers, and hex uses a fraction or a name. Ref: https://wiki.rptools.info/index.php/token_Size
- game systems are likely to use different size names or have a different number of size categories entirely but MapTool does not support size customisation leading to a disconnect between MapTool sizes and the games system sizes.
The Solution you'd like
(In priority order 1= highest, 4=lowest)
- Similar to other items under Campaign Properties, as a GM I'd like to be able to manually configure, save, export, and import token sizes to suit my game system of choice, such as the ability to:
- add new sizes, e.g. adding a grid/iso size 'Big' with a scale of 1.5 between 'Medium' and 'Large'
- rename a size rather than being forced to use numbers (gridless), D&D 3.0 size names (grid/iso), or a mixture of fractions/names (hex) in both MapTool GUI and MT Script.
- set a display name to be shown in the MapTool token context menu size item (if different to the size name)
- remove/hide redundant sizes so they do not show under the MapTool token context menu size item
- change a size scale, e.g. Colossal from 1.0 (6x6) to 1.0 (8x8), or Fine from 0.5 to 0.25
- delete sizes
-
Adding campaign size categories, names, display name, values to
getInfo("campaign")results for each grid type. -
When importing predefined Campaign Properties (e.g. Dungeons and Dragons: 5th Edition), set the sizes correctly for that system.
-
MT Script functions to support automating relevant features above in point 1.
Alternatives that you've considered.
- Having some data mapping residing somewhere in the campaign file that can translate the game system size into MapTool size, but then the sizes show in the MapTool GUI still use MapTool sizes.
Additional Context
D&D 3.0 came out in 2000, so MapTool needs to get with the times and size up supporting sizes from other games systems! e.g.
I started experimenting with something myself, but lack of GUI skills meant it didn't go far. I'd like to add Lancer to the list as an odd Hex Size setup. Lancer Sizes
I expect you're planning to build a new grid configuration in your onCampaignLoad macro(s), since you requested macro functions to make these changes... How do you expect to propagate your changes such that other oCL macros that run before (or after) yours know that you're going to be changing the grid configuration?
I started experimenting with something myself, but lack of GUI skills meant it didn't go far. I'd like to add Lancer to the list as an odd Hex Size setup. Lancer Sizes
Yep, I do see a need to cater for non-standard token shapes, another example being rectangular tokens on a square grid such as a 1x2 Medium Mount size category (or do I recall seeing a lib somewhere which can do something already?).
Whether non-standard token shapes are best served under this request or as a future consideration to follow on from it, someone more in the know can decide as there are probably a whole heap of implications with non-standard token shapes (moving, turning, facing, images, auras, topology, etc...) which may vary depending on the grid.
I expect you're planning to build a new grid configuration in your
onCampaignLoadmacro(s), since you requested macro functions to make these changes... How do you expect to propagate your changes such that other oCL macros that run before (or after) yours know that you're going to be changing the grid configuration?
Good question, and I do not know! Other than providing wiki guidance/hazard warnings, sounds like such related MT Script functions would be more problematic than they are worth so could be dropped from this request. t.b.h. they were included more for completeness.
I've reordered the points in the original request to be in priority order from my perspective, No. 1 being able to add/edit the size categories manually.
Yep, I do see a need to cater for non-standard token shapes, another example being rectangular tokens on a square grid such as a 1x2 Medium Mount size category (or do I recall seeing a lib somewhere which can do something already?).
Whether non-standard token shapes are best served under this request or as a future consideration to follow on from it, someone more in the know can decide as there are probably a whole heap of implications with non-standard token shapes (moving, turning, facing, images, auras, topology, etc...) which may vary depending on the grid.
If this does end up with non-standard token sizes being on the table (now or later), I'd throw in template shapes as ones to add as well, as I'd imagine that would help drawings be able to be manipulated in the future.
As a suggestion on the token size changes via script maybe conflicting with other add-ons use of a specific size or something: Namespaces
The MapTool namespace is read only via macros, and is where use of the campaign properties manual configuration goes. All other setting of size data must be assigned to a specific namespace, where any reading of a size defaults to the MapTool namespace if none is defined. Add-ons that have strict requirements about some size definition can ensure their data remains unchanged, while still giving freedom to addons that want to setup their own definitions.
This does lead to complications with the edit token gui - maybe link a token property type to a namespace - or have the size namespace as a second drop down?
@ColdAnkles I'll hava a bash at a GUI if you can get reading and writing shape definition back-end stuff sorted.
@bubblobill - I started on some basic campaign-property-ifying of token footprints. I'm exploring parts of the codebase I'm fairly unfamiliar with, so would appreciate any feedback. I'm not happy with the loading of the defaults being part of Grid.getFootprints() at this point, but also think maybe useful as fallback?
https://github.com/ColdAnkles/maptool/commit/a995252a96a13f574877f94309bab7dbb8ea9e26
It really annoys me that I cannot get footprints without a grid (for populating selection lists) so create a function to fetch all the footprints for all the grid types. Footprints have a name and a localised name, modify the class to include a system/preferred/user/whatever name as well. This gets us away from the D&D paradigm and also opens the door to having different footprints included in the "import a system" button. Consider also how you intend to manage Gridless. The GUI I'm doing won't be able to do them but I figure using SVG, token VB or drawing tools to define them are suitable starting points. Think beyond campaign properties. People will want to be able to change them as a MT preference for default values.
Haven't put much thought into gridless as of yet, but here's what I've done so far: https://github.com/RPTools/maptool/compare/develop...ColdAnkles:maptool:token-footprint-properties
Getting grid footprints for all grids is now Map<String, List<TokenFootprint>> campaignFootprints = MapTool.getCampaign().getCampaignProperties().getGridFootprints();