Roll20 uses cookies to improve your experience on our site. Cookies enable you to enjoy certain features, social sharing functionality, and tailor message and display ads to your interests on our site and others. They also help us understand how our site is being used. By continuing to use our site, you consent to our use of cookies. Update your cookie preferences .
×
Create a free account
This post has been closed. You can still view previous posts, but you can't post any new replies.

Measure While Moving

1340058513
Stephen Koontz
Forum Champion
Marketplace Creator
Sheet Author
API Scripter
Compendium Curator
There has to be a way to measure your token’s movement as you drag it. A setting that shows from it’s point of origin how far you’ve dragged it. Without a grid I can’t tell how many units “feet” the tokens are being moved. I’m just being dense and can’t figure it out. Any advice?
I'd like to know this as well. It would be really handy, especially if you could tie it in with a max movement stat associated with the token. This would be especially useful for some situations where grid movement causes more headaches than it solves.
1341246805
Stephen Koontz
Forum Champion
Marketplace Creator
Sheet Author
API Scripter
Compendium Curator
So, if there is no measure while moving has anyone figured out how to easily do movement without a grid? The measurement tool doesn't persist so you're left eyeballing your movements which isn't very practical.
I've found a couple of ways to get around this issue: 1. Turn on the "aura" of the token that is moving, and set its radius to the token's max movement stat. This makes it easy to see exactly where they can move to. 2. Create a special marker token and set its aura like above. Right click on it and select "To Back" (keep it underneath the other tokens.) Then you can place the marker directly under your character token and see exactly how far they can move. I agree with you, though. Displaying the distance as you drag a token would be very useful.
I believe that a feature like this one will be mainly useful just for RPG systems that favor straight movement, and maybe having no concern for facing. It's tricky to track a token hex/square grid movement if it moves, for instance, in an irregular or semicircular way, involving facing changes.
Maptool solved this problem by using waypoints. When moving the token, each time you click the spacebar, you create a waypoint that anchors the token path there. And you can make any number of waypoints.
1342775533
Gid
Roll20 Team
That feature in maptools was REALLY sweet. It made it really easy to keep count AND also kept track of your initial position in case you needed to start the move phase over.
Maptool solved this problem by using waypoints. When moving the token, each time you click the spacebar, you create a waypoint that anchors the token path there. And you can make any number of waypoints. Could right click work as well? Seems very natural.
Um, Fantasy Grounds also has waypoints. I wonder if MapTool's waypoints are able to cover not just the change in the movement path, but also "token rotation" or change of facing during the displacement. In any case, it would be nice to see "movement waypoints" in Roll20 as well.
Yup the waypoints feature in Fantasygrounds does an excellent job in allowing you to keep track how and where you move. Its especially handy if there are traps about that are set off half way through a move if the character stands on a particular square.
In Maptool, you can rotate the token while you are moving it, but I don't see what you mean by "change of facing during displacement". The move tool let you go from one point to another by following a path that is not straight, but it is one move, you see the "ghosted" path followed by the token with the distance visible; you have a "ghosted" token at the end of the path (rotated as you want) that you move; you hit "d" (for "drop") and the movement is finished and the token is on its new location, in its new orientation.
Perhaps Axel means that FG can include changes in facing as part of the movement system? Or maybe that it can limit movement (as in, if you've got a speed of 10, and you move 8, you only get to move 2 more before you can't move the token, and facing changes use up movement). I have no idea, personally - never could figure out how to use FG - but maybe that's it.
Ah yes, that could be it, but I don't know a VTT that compute movements costs. I am not sure that it would be very useful. After all, if you know that your move allowance is 10 and that the distance moved is 12, you know you are too far.
Actually Fantasy Grounds 2 waypoints can include any direction, but not facing changes (with this, I mean token rotation, Patric C.); on the other hand, according to what Patric said above, MapTool manages to include token rotation along with its move tool, displaying the "ghosted" rotated token at the end of the path: it looks like a cool feature for maps.
Ah yes, that could be it, but I don't know a VTT that compute movements costs. I am not sure that it would be very useful. Most RPGs simplify the movement rules to the point where computing movement costs isn't too important, but if you want to use a VTT for wargames, then it would definitely be useful. (And maybe if VTTs catch on enough, some RPGs will start implementing more realistic movement too.)
Most RPGs simplify the movement rules to the point where computing movement costs isn't too important, but if you want to use a VTT for wargames, then it would definitely be useful. But keep in mind that "most" doesn't mean "all of them", and that RPGs with more or less detailed movement rules are not wargames. So, at the present time, it would be certainly useful for some gaming groups a Roll20 able to keep track of movement costs.
That would open a can of worms, I think. Whilst it is easy to imagine waypoints to know the distance moved around an obstacle, computing movement costs implies having a way to set for each square (or hex) the cost of entering it. Not all squares are clear. And you would have to add costs for obstacles, which means that the cost of entering a square could be different depending on the side you move from. It would be quite cumbersome to setup a map this way. It seems easier to me to count squares and calculate movements costs on the spot.
I think that you are right, but however "computing moved squares-hexes" --disregarding the costs of specific obstacles, etc-- and adding just a basic waypoints feature with the ruler measurement and its customized units inside it, shouldn't be a problem. In other words: basically it could be a "waypoints feature" with the already existent ruler tool embedded into it for calculating the distance, instead of "computing token movement", which sounds much more complicated.
Yes, an hex counting mechanism seems more workable.
Yes a way to measure distance while moving a token is an absolute must, there are many games I would love to play using Roll20 (such as Malifaux) but it is such a hassle. I also think that we need a way to change the scale for these games, I was 1 unit (70x) to be 1 Inch, so that if my token can move 6 inches, the "ruler" while dragging the token reads out inches.
FWIW, speaking of scale, units and distances, I commented some current Roll20 "handicaps" in the "The updated Ruler Tool" thread: <a href="http://community.roll20.net/discussion/2136/the-updated-ruler-tool#Item_1" rel="nofollow">http://community.roll20.net/discussion/2136/the-updated-ruler-tool#Item_1</a>
Just adding my support to measured movement as well. From a usability standpoint, to toggle between movement and measurement using a toolbar button is a recurring cause for confusion. A keyboard shortcut for measurement is a must (currently Command+F brings up a drawing tool, I thought "Path" would refer to measurement!) In truth, people need to switch back and forth between measurement and movement in a much cleaner, faster way that is currently allowed. My suggestion: Click and Drag a Token leaves a measured Path. --- Space bar (or right click) drops waypoints. --- Escape key clears the path and returns token to the original position Shift Click and Drag anywhere on the map is a measurement tool. --- Space bar (or right click) drops waypoints. Shift Click and Drag from a token behaves as a measurement tool, but highlights the token. --- Releasing shift before releasing the mouse button moves the token to the mouse cursor position and treats it as though you have dragged the token to that point. --- Space bar (or right click) drops waypoints. --- Escape key clears the path and returns token to the original position (if shift released)
An alternate method of doing paths without waypoints is just to track which squares the tokens move through. My earlier suggestion was that tracking movement seems to go along with specific turns (because generally units get movement alotted each turn) and thus fits naturally into the turn/initiative window. I had a detailed (and I thought easy to use) suggestion for the user interface for that in the second half of this suggestion: <a href="http://community.roll20.net/discussion/2152/advanced-turn-order-options-locking-tracking#Item_1" rel="nofollow">http://community.roll20.net/discussion/2152/advanced-turn-order-options-locking-tracking#Item_1</a> But no-one seemed to like the idea. (Note that tracking movement could be used, and automatically reset, without using any of the locking features, and everyone could move in order or at the same time).
If I remember correctly, the problem with tracking automatically the movement points whilst moving, is that the system breaks down as soon as there are different costs for different types of squares and even for different types of obstacles between squares.
Arn't there a reasonably finite amount of systems to cover though? Most seem to use the "You have X points to move, moving in some squares uses more" system. Maybe I am just not remembering how DnD handles it, but we have a rather diverse set of dice systems in place, why not a diverse set of movement trackers?
The problem is not with the different rulesets, but with the fact that the system must know how much each square costs, if it must deduct the cost automatically. So each map must be prepared beforehand, with a cost associated with each square and with each square side (in case there is an obstacle between two squares). On a 20X20 squares map (small), that would mean entering, one way or another 400 values for the squares and 1600 values for the squares sides.
So then let the groups keep track of that, but an actual measurement while moving, one that Just measures the actual distance, would still be useful for many of us.
Also, why not treat the movement costs as an option layer to add to maps? It keeps the current system simple, with the ability to add a layer that you can then "Paint" movement costs onto. You just treat a given hex/square as a paint able pixel with a given default cost. This keeps things simple, while giving us a very powerful tool for quick calculations. Even simpler would be to have a "Show tokens last path" button/command/feature. Then the DM can just look at what they did at determine what the cost would be. The issue here is that you start getting into token movement control which the Dev.s have said they wanted to avoid (can't say I blame them either..).
Also, why not treat the movement costs as an option layer to add to maps? It keeps the current system simple, with the ability to add a layer that you can then "Paint" movement costs onto. You just treat a given hex/square as a paint able pixel with a given default cost. Doesn't take care of obstacles (a low wall for exemple) between squares, or of different costs in different directions (more move points costs to climb a hill than to go down), or of different modifiers for different characters (characters on foot, mounted or flying, for exemple, wouldn't pay the same move price and wouldn't be affected by the same modifiers). It would still be a lot of work for something that can be easily calculated during play and that would need calculating corrections anyway for different situations during play (flying characters for exemple).
My suggestion above just applied the standard square distance as cost (and highlighted when you moused over the unit in the turn menu) for every square you moved over. This is equivalent to no rough terrain, no extra cost for diagonal movement, a rough draft. When you clicked on the turn counters movement sum for this round, it toggled you into path editing mode... where left clicks increased the cost of a square (for rough terrain or diagonal movement) by the standard amount (adding it to the path if it was not before)... and right clicks subtracted the standard amount (fixing mistakes, teleporting, sliding, etc) possibly removing it from the path. That lets you touch up the autopath with just a few clicks, as long as your movement costs have simple granularity. 5ft, 5ft, 10ft, 5ft, 5ft = 30ft You don't have to prepare your map for any type of person that may walk over it, only when you suspect the person who actually walked over it may not be able to make the whole trip, you can check their path easily.
I think I can calculate that faster whilst moving than I can click it on an highlighted path (if it is expressed in simple units).
The point would be that as you drag the token in an L shape it automatically "paints" the path it follows and gives a rough estimate. Then if and only if you want to check the exact distance, you can do that, and be sure you did not miscount.
Just adding my support to measured movement as well. From a usability standpoint, to toggle between movement and measurement using a toolbar button is a recurring cause for confusion. A keyboard shortcut for measurement is a must (currently Command+F brings up a drawing tool, I thought "Path" would refer to measurement!) In truth, people need to switch back and forth between measurement and movement in a much cleaner, faster way that is currently allowed. My suggestion: Click and Drag a Token leaves a measured Path. --- Space bar (or right click) drops waypoints. --- Escape key clears the path and returns token to the original position Shift Click and Drag anywhere on the map is a measurement tool. --- Space bar (or right click) drops waypoints. Shift Click and Drag from a token behaves as a measurement tool, but highlights the token. --- Releasing shift before releasing the mouse button moves the token to the mouse cursor position and treats it as though you have dragged the token to that point. --- Space bar (or right click) drops waypoints. --- Escape key clears the path and returns token to the original position (if shift released) Yes. That is brilliant. There are only a couple hurdles left to clear before my group abandons MapTool and commits to roll20, and this is one of them. Essentially, "When measuring distance, the first diagonal counts as 1 square, the second counts as 2 squares, the third counts as 1, the fourth as 2, and so on." [d20 rules] It'd make combat that much easier, as manual calculation of movement is something we erased by adopting MapTool. If I remember correctly, the problem with tracking automatically the movement points whilst moving, is that the system breaks down as soon as there are different costs for different types of squares and even for different types of obstacles between squares. I don't think the OP wanted anything so granular. Difficult terrain or different movement types is something the GM has to handle manually. All we're really asking for is the square of the hypotenuse of a right triangle to NOT equal the square of its next longest side. Essentially, if two characters have to hit a switch across a room with an ogre in the middle, one character runs straight for the switch right past the ogre and another takes a wide swath avoiding the ogre, the guy risking getting crushed to goo should arrive at the switch before the character who respects the better part of valor.
Yeah, the diagonal measurement issue has been discussed. I believe a GM-defined option for "Manhattan" style (5-10-5) is in the works. If gets especially bad with things like dragons in 3.5/PF which can move some 40 squares in a round. With "4e" diagonals, that can be an extra hundred feet of movement along the diagonals — enough to make a serious difference.
Yeah, 4e would drive Pythagoras (more?) insane.
I recommended this a while ago (when Roll20 was first released, here: <a href="http://community.roll20.net/discussion/702/token-movement-distances" rel="nofollow">http://community.roll20.net/discussion/702/token-movement-distances</a>), and I still support it. Yeah, the diagonal measurement issue has been discussed. I believe a GM-defined option for "Manhattan" style (5-10-5) is in the works. 5-10-5 is not "Manhattan style;" in Manhattan style diagonal movement is impossible and thus you can only move right, up, right, up, etc. and all "diagonals" cost 2 squares. See Wiki: <a href="http://en.wikipedia.org/wiki/Taxicab_geometry" rel="nofollow">http://en.wikipedia.org/wiki/Taxicab_geometry</a>
Here is my 2 cents. While your left mouse button is set to select/move and right mouse button is set to pan. You press and hold Pan then while holding press and hold Select/move to engage the measure tool, then when you release the buttons you have access to your separate pan and select/move strait away.
Different kinds of grids are now supported! (4e, Manhattan, 5-10-5, and Perfect) That much closer to measure-on-movement.
For measure while moving, I think you could implement DM approved movement paths as well. Shift + drag would leave a greyed out token at the start point and then you would draw your movement path, using the space bar t create waypoints. The GM would then have the option to adjust or deny the move.
Thats a good idea Jonathan, it's very similar to the way Fantasy Grounds does it. I still think that this is all a must for Roll20.