More sizes for square grids would be useful

[xdy]

Is your feature request related to a problem? Please describe. My DM just asked if it was possible to have a 5x5 size token in MapTool (square grid).

Describe the solution you'd like I'd like to be able to select among a wider variety of token sizes on a square grid. 10x10 sounds like a reasonable maximum size (the current implementation is a hard-coded list read from an xml file.)

Describe alternatives you've considered

• Just Say No. But, he's my DM, there would probably be Consequences...
• Use free sizing and turn off snap to grid. Ok for a single token, but it gets tedious fast.
• Move token footprint handling from "comment out the irrelevant footprint-types in TokenFootprintCreator, run the class to print out what should be in squareGridFootPrints.xml, cut-and-paste the relevant bits to said file" to "having a gui kind of like Lights, Sight, etc."

Additional context I've added token sizes up to 10x10 on the branch I'll shortly mention in this issue, which covers what I need. Refactoring TokenFootPrints (perhaps along the lines of the above) sounds like it would be a good thing to do, but is way beyond the time I have available. Several of the sizes in the current squareGridFootprints.xml didn't exist in the TokenFootprintCreator (the ones smaller than Medium), so I added them while I was at it.

[JamzTheMan]

Seems like this should be a campaign property configuration. When playing a dnd game I would only want to see valid sizes but would also like to see other valid sizes when playing other systems.

[Phergus]

Probably.

[xdy]

Even the various d&d games have different opinions on what sizes exist and how they are shaped (compare 3.0 (rectangles) vs 3.5 (everything is a square) vs 4e (colossal+ almost exists) vs 5e.) For that matter the current token footprint sizes don't quite implement 5e either, the actual token sizes stop dropping after scale 0.5 (quite reasonably, Fine wouldn't be very easy to use at scale 0.125 :)

Perhaps leave squareGrid as is and add a new squareGridGeneric in which the sizes would all be named like '1x1 squares', '2x2 squares' etc? (With perhaps 0.75, 0.5 and 0.25 scales also added, as '0.75x075 squares', etc)?

[Azhrei]

If they were campaign properties, the creator could name them as they wish, but macros would need to be able to reference the 1x1 size as index 0 (perhaps?) with larger and smaller sizes being +1 and -1, respectively.

[JamzTheMan]

Good point @Azhrei re size index. We don't want to break existing frameworks that expect certain sizes at certain indexes.

What was required to make the change? Something more than editing squareGridFootprints.xml I surmise? If we get this into campaign properties then it can be part of the new game system defaults @Phergus put together.

[xdy]

For the change I made just editing the xml file would have sufficed, but I used the existing TokenFootprintCreator to do it (it prints out the contents of the xml file based on the hardcoding in said class.) Adding a new 'gridtype' seems fairly easy, i.e. I could probably do that as part of this issue. Changing to a campaign property is more than I could handle in a reasonable amount of time. As far as I can see from the code that would be a fairly large refactoring. (I just searched for 'footprint', most likely all those places wouldn't have to be touched, but, man, was that a lot of places. Some of it in fairly gnarly gui code. Well, gnarly to me anyway. :) Though I do agree (as I said in the alternatives section in the issue) that it would be a good idea to do it that way.

[Phergus]

@JamzTheMan @Azhrei The macro functions definitely have to be updated as they use the name of the size.

[Azhrei]

The macro functions definitely have to be updated as they use the name of the size.

Yeah, that was an unfortunate choice, but not insurmountable. We can allow strings to be used, in which case they are the size names, and we can add support for numbers. It doesn't break upward compatibility but allows size indexes to be used going forward. And eventually, when the size names become user-specified text strings, those strings will be usable as well.

It's all good. :)

[Phergus]

PR merged to new branch feature-token-footprint for possible further development.

Instead of hacking in clunky sizes that everyone on square grids has to use, the token footprints need to be moved to user-configurable campaign properties.