RPTools.net

EDIT: Updating thread title, because there's a really big bug in here with regard to token rotation. See second post.

EDIT THE SECOND: REMOVED THE BIG PLEASE MOVE

---------------------------------------------------------------

Currently maptools allows you to very slightly offset the image of a token from its base square/hex (less than one square/hex from its 'actual' location).

For multi-square and multi-hex creatures, some game systems are quite specific about where the figure should be rotated around (for example, in GURPS you use the hex the head is in. If the creature is big enough that its head is in multiple hexes, the GM has to pick one hex of the head and stick with it).

The current system of "offsetting" the image of the token from its actual position on the map sort-of works for "small" large tokens, but due to the limit of offsetting, it can't compensate enough for large tokens, and offsetting the image instead of changing the rotation point usually results in the token taking up the wrong number of hexes).

An option to change the axis around which the token rotates, setting it to be either in the center of a hex/square, or a intersection/corner between hexes/squares, should cover all the options for a given token for just about any system.

So while playing around with token sizes, I've discovered something that may actually count as a Bug but I'll start with posting it here until I get some more information.

In short, rotating a "Large" pre-sized token on a hex grid knocks the token off the grid.

Obviously there are six (or twelve) ways to orient a token on a hex grid, presuming you're aiming to align with vertexes and/or faces while rotating. For a 1 hex radius "Large" token, there are three alignments where it will match up exactly with the grid underneath it, if you rotate from the center (as per current mechanics - being able to pick a hex as the center of rotation will fix this and provide the full six).

However, only one of the three is actually ligning up properly. This may explain why I've been so confused when trying to pilot my oversized minotaur across the game maps.



Top left shows the token in the only "working" position.

Top right picture shows it rotated 120 clockwise. The mini creeps southwest about a third of a hex.

Bottom picture shows it rotated 270/-120 degrees. The mini creeps NORTHwest about two thirds of a hex. Information dot is in picture to show where I expected his head to end up.

If I keep rotating back to the "neutral" state of looking west, he pops back onto the grid again.

The bottom picture is especially bad, because now Maptools shows him as occupying 4 hexes, and moving the token precisely is VERY hard, as Maptools apparently thinks I'm clickig on another hex than the one I actualyl make contact with, and he flops around all over the place.

I'm pretty sure this is a bug - hexagonal minis shouldn't be wandering off the hexmap like this... but I figure I'd check and see if there's something I'm missing first.

This token has not been "nudged" to align to the grid, by the way.

I've attached the raw image to this post so you can experiment for yourself. I just drag-and-dropped it into maptools.

Note that if I can pick my own center of rotation, I would expect Mrugnak to rotate around his Head (that's where I'd pick) and he therefore could chose one of 6 orientations that would drop him on the grid.

Just saw this...

On the config panel you can make the token bleed outside it's cell. I suggest the following changes:

1) Have a small 5x5 pixel circle that defaults in the center of the square and is the token's rotation point. left clicking will move the token exactly the way it does now. right clicking will move the rotation point circle.

2) Have a reset rotation point button below that will reset the point

3) Have a reset token positioning button. Actually, we really need to have this there ASAP... I just opened a square token I frequently use to test the clicking and I'm having a really hard time getting it to line up back in the grid correctly

This would all be good, but they'd have to scale the "bleed" window to match the token scale - right now it's unusable with a sufficiently oversized token - if the head is four hexes away from the center of the token, it goes off the right side of the "bleed" window. That's a vital change, even if a new control is used to pick the rotation center, because if you DO have to nudge a big token (a Gargantuan dragon, for example) you have to do it blind.

Before you could do this properly there would also need to be a way to define which hexes are actually part of the token as well. Otherwise even if you have a rotation point you will find your token isn't really occupying the hexes you think it is, so you should probably add that to the request.

Do you mean bits of the token "bleeding" into non-occupied hexes? Like, bits sticking out over the base? Or do you mean "When rotated like X, it should occupy hexes abc"? The last part shouldn't need to be specified when Maptools rotates the token, it's actually sort of trying to do that now, only it is failing miserably due to rotating at the wrong place.

No I mean your token has an idea of what spaces it is taking up, and that may not agree with your picture in the first place. So if your image makes it look like its taking up an area such as


but maptools thinks its taking up an area like

No amount of fiddling with the rotation point will fix all the problems. And even if it looks right certain things like the distance or position functions will not give you the correct answers.

Hm. The graphical display on Maptools highlights "correctly" (well, correct for the cells it SHOWS being taken up, they're wrong, but that's from the rotation being wrong).

Does the back end not know what the front end is doing? That would explain the problem where I grab on one hex of a rotated token, but it moves according to something completely different.

Okay, I've moved this to the Bug Reports forum as your second post does have a confirmed "bug" (being able to resize the image beyond certain boundaries qualifies as something the user would probably expect).

OK, summing up problems with rotating multicell tokens on hex grids:

1) Token does not align even approximately with the grid for 3 out of 6 of the possible orientations (assuming vertex only or face only).

2) Token does basically allign correctly for TWO orientations, but "wanders" off the grid.

3) While rotated into any of these "wrong" rotations from 1 or 2, except the one that is 180 degrees from "correct", the token does not drag and drop properly, appearing to take a different cell from the one you click on as your point of clicking.

The attached image, upthread, is a good one to experiment with. I don't normally play with a base, but attaching the base to him made it quite obvious what the real problems were.

Dropping by to say that this is still an issue in 1.3.54; should I update the thread title to show the latest version that I'm seeing this in?


EDIT: part of the bug, IMO, is that on a hexagon based system, there should be six different facings available that result in the token sitting properly on a grid. With a large token, there's exactly ONE.

That's already there in the TokenFootprints.



Large (3-hex) tokens are defined as origin point plus the hex immediately below {0,1} and a hex to the right {1,0} on a Vertical hex grid. These and the huge footprint break on Horizontal Hex Grids. The problem appears to be one of consistency in handling what {0,1} means if you start on an even or odd row. On a Horizontal hex grid the 3-hex footprint always comes out as kind of the glider pattern in life. The 7-hex footprint is blob.

There are also rotational issues. Some systems using hex grids rotate the 3-hex beings around the common vertex. The systems I play rotate around a specific hex (for all critter footprints). The current rotation is around the center of the bounding box of the hexes.

Sorry I should of been more specific, I know of the TokenFootPrints class, what I was trying to say was their should be a way to take a token and in a nice gui click on the hexes, (or squares) to define the foot print of the token. This allows for greater flexibility for how tokens/objects are made up. This is not a 1.3 thing of course

Ahh. A gui for this would be spiffy.

Sorry to keep bumping this, but I'm still not sure on the etiquette - should I update the title to show that it's still an issue in the current build?