Rulers using non-4e math

Is it possible to have the ruler calculate distances by an accurate method instead of the 4e approximation?

Hi Adam Please define what an " accurate " method would be, because just because it's proper in your system, it may not be right in half a dozen others. There's also a number of similar discussions going on. I'd encourage you to lend your voice to one of them, since higher voted threads are more likely to rise in the priority list. <a href="http://community.roll20.net/discussion/comment/4231" rel="nofollow">http://community.roll20.net/discussion/comment/4231</a> <a href="http://community.roll20.net/discussion/comment/3278" rel="nofollow">http://community.roll20.net/discussion/comment/3278</a> <a href="http://community.roll20.net/discussion/comment/2974" rel="nofollow">http://community.roll20.net/discussion/comment/2974</a> <a href="http://community.roll20.net/discussion/comment/3482" rel="nofollow">http://community.roll20.net/discussion/comment/3482</a> <a href="http://community.roll20.net/discussion/672" rel="nofollow">http://community.roll20.net/discussion/672</a> <a href="http://community.roll20.net/discussion/comment/2643" rel="nofollow">http://community.roll20.net/discussion/comment/2643</a>

is the OP basically asking for the true measurement by way of Pythagoras Theorem? A^2 + B^2 = C^2 instead of 3e/4e counting diagonals as 1.5 squares (so 2 squares going at 45 degree costs 3 squares of movement) Or consider Frag, the SJG game where distance is counted by right-angle movement, even on diagonals.

What Janx said exactly.

Yeah, that would be useful. Most of my players are math or science graduates, and they can get pretty crazy with the math. Calculating range, blast radius, falling speeds, terminal velocity... Having it be a bit more "mathematically correct" would be nice.

using real physics could make the game really complicated really fast. approximations are easy.

And if you use the grid you are using approximation. The character is within a 5 feet (or another size) square. On the left? On the right? You have an approximation of several feet to begin with; so calculating a move to the inch is just false precision. The result is "you moved 121.321 inches, more or less 2 feet". If your players are science graduates, they should know that this is bad science.

We aren't all using a grid, and sure as hell aren't all using a scale of five feet to the inch. Besides, in the case of a target that is, say, twelve squares to the right and five squares towards the top of the screen it is not a matter of calculating to the inch, it is a matter of the approximation being wrong by a whole five feet .

Which is, at best, the approximation due to the size of the square (or the size of the token you are using). There is no use to be more precise than your margin of error. And by the way, there is no inch here. And I don't use 5 feet per square. I have problems to understand your need to precision. What do you use as move or distances unit? edit: and also which rules do you use that have a granularity needing that kind of precision?

And what if I'm not using a square or a token? What if I have a map of the Empire of Jehannum and I want to measure the distance between the cities of Hospis and Bethan? I don't want the measuring tool to round distances off any more than I want it to impose a five-foot to the "inch" scale. Indeed there isn't an inch. On my monitor the grid squares are about 17 mm across, or 2/3 of an inch. But Roll20 calls them "in." in a couple of places, including in the grid-size setting in the page settings pane. Finally: no, 70' is not the best approximation to 65' that you can get with scale marked in 5' increments. Twelve over and five up gives you thirteen exactly on the diagonal, a figure that doesn't need to be approximated at all, and is not properly approximated to fourteen.

That is not what I was saying. What I was saying is that if you don't use squares, you are going to use distance units per pixel instead of distance units per square. But except if the token you use is 1 pixel across, you are going to work with a margin of error depending on the size of your tokens. Secondly, if your margin of error is 5' (which is the case if you use squares or if your tokens are 70 pixels across), there is no difference between 65' and 70' because you are within your margin of error. Moreover, if the system you use has range bands that make no difference between 65' and 70', it has no effects on the game (generally you have something like short/medium/long distances). And if it makes a difference, it shall be because an arbitrary range band has been placed at 68' and it shall work as well 2' or 3' aside (doubly so because it shall affect all the PCs an NPCs the same way). What it all adds to, is that simulating a reality in a roleplaying game necessarily is a work of approximations with margins of error widely greater than 6%. Measuring by the pixel just gives a feeling of precision but doesn't make the game more realistic and has no bearing on what happens in the game. Your exemple of the cities is a good one. If your characters want to travel from Hospis to Betan, you are going to say to them: "The distance is 296 miles, 8 feet", but: - if you use a map where the cities are depicted by something other than a 1 pixel point, it is only an approximation - they are not going to go straight, so trying to simulate a journey in a rpg introduces its own approximation, they are going to walk anything between 300 to maybe 400 miles depending on the bends of the road (a far greater approximation than the one introduced by using 1.5 for the diagonal). And you are going to calculate the time it shall take them with a formula given by your game which is itself a big approximation from the designer -the approximation by calculating a diagonal as 1.5 is 6%. Which is much less than the other sources of approximations. So if you had said at the beginning that the distance was 314 miles, it would have been the same and you would probably have given the players the same travel time. And it wouldn't have been less realistic. -and anyway it would have had no bearing on the game. You have still to say the rules you use that need that level of exactitude to work properly. I don't know any ruleset that is so precise that it can't bear a 6% margin of error on a diagonale without breaking down (but I don't know all RPGs, so I am very curious). I don't see any benefit to have a false impression of precision in a game whilst losing the ease of use of taking 1 for a square and 1.5 for a diagonale. And no, it doesn't have to be 5 feet, it is just a ratio.

That is not what I was saying. What I was saying is that if you don't use squares, you are going to use distance units per pixel instead of distance units per square. But except if the token you use is 1 pixel across, you are going to work with a margin of error depending on the size of your tokens. What if I'm not using tokens? Secondly, if your margin of error is 5' (which is the case if you use squares or if your tokens are 70 pixels across), there is no difference between 65' and 70' because you are within your margin of error. On a five-foot grid errors in x and y position ought to be two-and-a-half feet or less. Besides, measuring 24 squares across and ten up, the true distance is 26 squares (130 feet) but the approximation reports 29 squares, an error of fifteen feet. Moreover, if the system you use has range bands that make no difference between 65' and 70', it has no effects on the game (generally you have something like short/medium/long distances). And if it makes a difference, it shall be because an arbitrary range band has been placed at 68' and it shall work as well 2' or 3' aside (doubly so because it shall affect all the PCs an NPCs the same way). Not so. Quite aside from its coarse rounding, the approximation makes a consistent error of about 11% when measuring at angles of about 25 degrees to the horizontal or vertical—it draws circles as irregular octagons. At whatever range game rules or real-life considerations might impose significant distances, the approximation will place them wrongly at that angle. What it all adds to, is that simulating a reality in a roleplaying game necessarily is a work of approximations with margins of error widely greater than 6%. Measuring by the pixel just gives a feeling of precision but doesn't make the game more realistic and has no bearing on what happens in the game. But why not get it right? Getting it right makes things no harder, but reduces these errors. If the difference between the Pythagorean metric and the D&D3 metric doesn't matter, why are you arguing to keep the D&D3 metric? Your exemple of the cities is a good one. If your characters want to travel from Hospis to Betan, you are going to say to them: "The distance is 296 miles, 8 feet", No, I'm going to say "It's 260 miles". And I will be displeased by a measuring tool that tells me 290 miles when the actual figure is 260. but: - if you use a map where the cities are depicted by something other than a 1 pixel point, it is only an approximation Sure, but it can be a much better approximation than saying "290 miles" when the actual distance is between 258 and 262. I'm not complaining about the measuring tool's imprecision but about its inaccuracy. - they are not going to go straight, so trying to simulate a journey in a rpg introduces its own approximation, they are going to walk anything between 300 to maybe 400 miles depending on the bends of the road (a far greater approximation than the one introduced by using 1.5 for the diagonal). And you are going to calculate the time it shall take them with a formula given by your game which is itself a big approximation from the designer What if they aren't walking a road? What if they are using a teleport spell? Or steering a straight course over the sea, in a powerboat with satnav? Or flying in a private plane or an aircar? What if the issue is not travel time but whether they at in range of a missile or a radar set? -the approximation by calculating a diagonal as 1.5 is 6%. Along the diagonal, yes. But in between the diagonal and the orthogonal it if greater. Consider a rectangle ten by 24. By Pythagoras' Theorem you find that's its diagonal is 26, but by the D&D metric that is approximated at 29, an error of three parts in 26, or 11.5%. Mis-stating the length of the diagonal of the square is not the only source of inaccuracy in this approximation. Approximating distance by a linear combination also contributes to the error, because it inherently treats arcs as straight lines. The "circle" in D&D 3 is an irregular octagon. Counting diagonals as 1.4142 etc. would make the octagons regular, but would not make them into circles. Which is much less than the other sources of approximations. Maybe it is, but maybe it isn't. In either case, you don't reduce or ameliorate errors from other sources by adding in further error from inaccurate measurement. So if you had said at the beginning that the distance was 314 miles, it would have been the same and you would probably have given the players the same travel time. And it wouldn't have been less realistic. -and anyway it would have had no bearing on the game. That's if I were using the line measurement to base an estimate of a walking distance on. But as established before I might be using a distance measurement for something that is not subject to the winding of roads or the variability of walking speeds and march durations. In any case, it isn't up to the Roll20 developers to pre-judge whether an error of 11% matters to my game or not. You have still to say the rules you use that need that level of exactitude to work properly. I don't know any ruleset that is so precise that it can't bear a 6% margin of error on a diagonale without breaking down (but I don't know all RPGs, so I am very curious). Well, in the first place the error can be over 11%, as discussed above. I known at least four RPGs that give the speeds of aircraft to the nearsest five kilometres per hour or nearest five miles per hour, with those figures going up to 1125 or so. Also, some that give spell ranges and weapon ranges with two significant figures. I don't see any benefit to have a false impression of precision in a game I'm not complaining about imprecision, but about inaccuracy. When the true distance is 26 +/- 0.6, then reporting "26" instead of "29" is not a case of false precision. "26.0" would be false precision. "29" is just inaccurate. whilst losing the ease of use of taking 1 for a square and 1.5 for a diagonale. And no, it doesn't have to be 5 feet, it is just a ratio. There is no such ease when you are using a measuring tool. Getting it right is no more difficult than using the approximation. You just extend the tool. When it is a case of ease, then that's because you are counting squares, and not using the measuring tool anyway.

Your measure of the diagonale take the farther points in the squares which is not the way a measure tool counting squares works. When I measures the distance in a 24X10 rectangle using a virtual tabletop program that uses the 1/1.5 ratio (maptool), the result is 27 (not 29 as you say) to the real distance of 26, less than 4% approximation (and that from the real use of a VTT measure program). And I still compare it with the "real" distance you use between the farthest corners, which is not really realistic. I still don't see which RPG would break using 1.5 instead of 1.41421356237309504880168872420969807856967187537694807317667973799... which BTW is 6% approximation (ok, not exactly). And I am still curious about which one you use that couldn't stand that level of approximation? And rules that you are using for a game that doesn't use tokens in Roll20? Even more curious. Maybe you should be a little more clear on what you use (or want to use), it would make your points also clearer. I also know lots of games and probably can find one for any case I could make. Giving their names and the way they work would make the discussion more practical. And if you use an aircraft speed to the nearest 5 km per hour, you are indeed using false precision, because nobody can guarantee so precise a speed on any long trip. It could give you the speed to the tenth of inch, that would not be more meaningful. The problem is that if you want real precision, any value should be given as a medium value with a margin of variations. Just giving a simple value is not precision, it is simply meaningless. I am not sure that there are many peoples ready to use this, just to know if the plane took 1 hour and 40 minutes instead of 1 hour and 44 minutes to go from A to B. I am certainly not. I see that you are using exemples with long ranges, but what happens with simple moves? Do you carry the unused part of the move to the next turn. I mean, if your character has a move allowance of 3.34753257869 (I suppose the rules you use give that level of precision) and makes two diagonales moves (spending 2,82842712474619 of his move), do you carry the 0,51910545394381 unspent move to the next turn, because if you don't, your imprecision is more than 15%, showing that precision in input doesn't translate in precision in results when using an approximate model like a board in a rpg. I don't think I am going to convince you, so, I'll leave it at that. But, for me, using a grid is a great way to regulate movements in a game, and using a ratio of 1 to 1.5 in a square is an acceptable approximation, giving a simplified and immediately understandable situation without getting bogged down with meaningless numbers.

Your measure of the diagonale take the farther points in the squares which is not the way a measure tool counting squares works. When I measures the distance in a 24X10 rectangle using a virtual tabletop program that uses the 1/1.5 ratio (maptool), the result is 27 (not 29 as you say) to the real distance of 26 No, that's not right. Take a square for your origin and count 24 squares to the right, and then count ten squares up for your destination. The true distance from the centre of the origin square to the centre of the destination square is thirteen edges. But counting the D&D3 way you get 29. I still don't see I see. which RPG would break using 1.5 instead of 1.41421356237309504880168872420969807856967187537694807317667973799... which BTW is 6% approximation (ok, not exactly). As I explained before, that approximation is only one of two source of error. The other arises out of the act of the fundamental act of counting diagonals, multiplying then by a scalar, and adding. If you used 1.4142 instead of 1.5 that would reduce the error in distances measured at 45° to less than one part in ten thousand. But there would still be an error in distances measured at 22.5°, amounting to (cos(22.5°) + 0.5 * sin(22.5°))-1. Get out some graph paper and draw a diagram. Pick an origin square and mark the squares that are 25 squares away from it over one eighth of a circle between, say, due right and the diagonal in the rightwards-upwards direction. Observe that they approximate a straight line. Now take a pair of compasses, set it to a radius of 25 squares, and draw an arc centred at the middle of the origin square, through the same arc. Notice how the arc bulges away from the approximate line in the middle? At the end of the arc near that is near the diagonal the distance between the arc and the approximate line is only 6%. But in the middle the distance is bigger because of the curve of the arc. Now draw a straight line segment with a ruler from the beginning to the end of the arc. That is the set of points that you would measure as being 25 squares from the origin counting diagonals by counting diagonals using a precise value for tan(45°). Notice the gap between the straight line and the arc? In the middle it is more than 11%. Maybe you should be a little more clear on what you use (or want to use), it would make your points also clearer. I want to use a measuring tool that reports the actual distance between end-points, for use in all sorts of contexts including things that might not be a tactical grid at all, such as strategic-scale maps, and that might not involve movement regulated by a grid, such as sensor ranges, strategic and theatre weapon and spell ranges and areas of effect, and long-distance travel. And if you use an aircraft speed to the nearest 5 km per hour, you are indeed using false precision, because nobody can guarantee so precise a speed on any long trip. It could give you the speed to the tenth of inch, that would not be more meaningful. As it happens I use a game system in which the unpredictable speed of long-distance travel is taken account of by the drivers' or pilot's skill roll, so I'm not using false precision after all. I want to deal with the inconsistency of performance explicitly and consciously, in the amount that is appropriate to the situation. Not to have it imposed on my willy-nilly by an inaccurate measuring tool. Also, you have to be aware of the difference between inconsistency and bias. A measuring tool that consistently over-states distances in certain directions by highly consistent proportions is not the same thing at all as a measuring tool that reports only appropriate precision. The problem is that if you want real precision, any value should be given as a medium value with a margin of variations. In ForeSight vehicles are given a maximum speed and a cruising speed (which are adjusted for terrain value when that is significant), and the result of the driver's skill roll determines where the achieved speed falls in that range, at cruise speed for a bare success, and nearer to the maximum for successively better rolls. I am not sure that there are many peoples ready to use this, just to know if the plane took 1 hour and 40 minutes instead of 1 hour and 44 minutes to go from A to B. I am certainly not. Well, if you don't care, you don't mind my having it my way. If an 11% error doesn't matter, why are you fighting to defend it? And I certainly run games in which it sometimes matters whether the characters travelling in their aircar take 1 hour 40 minutes or 1 hour 52 minutes to arrive somewhere. It can make the difference as to whether they get Princess Ineffabelle to the coronation ceremony with two minutes to spare or ten minutes after Black Michael is crowned king. If can make the difference as to whether they can easily get into the shelter of Mt Samar before the Emperor Bomb explodes, with twelve minutes to deal with contingencies, or whether running for the shelter of the mountain is a completely impractical I see that you are using examples with long ranges That's to minimise the distracting issue of rounding. but what happens with simple moves? Do you carry the unused part of the move to the next turn. That would depend on the rules of the game you were playing: it could work the way you suggest. But in the non-gridded games I have played, such as Basic D&D or AD&D, movement is on a "use it or lose it" basis. You can move anything up to you movement allowance before attacking, but can't carry over unused movement. So in AD&D if you had a move of 12" (typical for a human) and were, say, 10" west of an enemy and 6" south of him you ought to be able to reach him in a turn, but counting the D&D3 way he would be 13" away and out of reach until next turn. I don't think I am going to convince you, so, I'll leave it at that. But, for me, using a grid is a great way to regulate movements in a game, and using a ratio of 1 to 1.5 in a square is an acceptable approximation, giving a simplified and immediately understandable situation without getting bogged down with meaningless numbers. That is something to take up with game designers. It is not a decision that Roll20 should impose on users regardless of the actual rules of the game they choose to play. I'll add that when you are moving a token a modest distance on a grid it is easy to just count the squares without using a measuring tool. That's why those rules were written: it's to make the games easy to play when you don't have a tape measure. So if the measuring tool is not useful to people who want to play out combats on a gridded map they have an easy fallback: the counting that their rules were designed for. On the other hand, when you need a tape measure and don't have one, there is no such easy fallback.

No, that's not right. Take a square for your origin and count 24 squares to the right, and then count ten squares up for your destination. The true distance from the centre of the origin square to the centre of the destination square is thirteen edges. But counting the D&D3 way you get 29. Well, I was not calculating. This was a real experience with a VTT that use 1/1.5 ratio. Saying it is not true is a little childish, it is the way it works and you can try it yourself. And I don't know how many times I'll have to say that I don't use D&D (none of the versions), just a VTT using squares and 1/1.5 ratio (used with Savage Worlds, Flashing Blades, Dragon Warriors, and a lot of other games). And the result is 27, even if you don't like it. Disagreeing with facts that you can reproduce for yourself anytime you want is not very productive. If you don't want to try it, I can post screenshots showing the results. Well, if you don't care, you don't mind my having it my way. If an 11% error doesn't matter, why are you fighting to defend it? 4%, not 11% and your way to measure is going to have a bigger error, except in a very rare situation (which you seem to think is making or breaking a game). But I defend it because using squares and 1/1.5 ratio is going to produce a consistent, repeatable, predictable result. Anytime you are going to repeat the measure, you are going to have the same result expressed in "squares" units, easily understandable. Using a per pixel calculation is going to to produce different results every time depending on the point you choose on the square or the token. And if you don't use squares or token, depending on the size of your map markings. As the error it is going to produce is a constant (and not a percentage), the smaller the distance, the more the approximation, until it can be 50% or more. From a screenshot (in another thread) that I have seen of one of your (FATE?) game, measuring distances on the tokens present would have been completely random. Your way to calculate is going to produce exact distances, better than the square counting, only for playing without grid or tokens, with marks 1 pixel across on the map, and only for aerial movements directly through the space. Not a very common way to play, not a very common occurence and much complications for a small result in an unfrequent situation. And as I still don't know what you play, I still don't know why it would be important. All VTT I know use the square 1/1.5 way to regulate movement and there seems to be a reason for it. So if the measuring tool is not useful to people who want to play out combats on a gridded map they have an easy fallback: the counting that their rules were designed for. Yes, but it is much easier to have the measuring tool doing the measure itself and giving the result in "squares" units. And counting 30 or 40 squares is not easy and is better left to the measuring tool. So, the measuring tool "is" useful for peoples counting squares. Edit: and I don't know why I use your expression "counting squares", it is not what it is about. What I would like for Roll20 measuring tool is a tool that measure distances on a squared background with straight distance equal to one (wathever unit) and diagonale equal to 1.5 (wathever unit) like Maptool or other VTTs.

This was a real experience with a VTT that use 1/1.5 ratio. Saying it is not true is a little childish, . I'll bet that you measured the distance between the interior corner squares of a rectangle of which the exterior dimensions were 24 squares by ten squares, and not the distance between one square and another that was 24 to its right and ten above. 4%, not 11% The largest error does not occur at 45 degrees, and is not due to approximating the square root of two by 1.5. It occurs at about 25 degrees, is due to approximating an arc by a straight line, and amounts to 11%. But I defend it because using squares and 1/1.5 ratio is going to produce a consistent, repeatable, predictable result. Anytime you are going to repeat the measure, you are going to have the same result expressed in "squares" units, easily understandable. The same is of course true of proper geometry when you measure between the same points, such as for instance the corners of grid squares, the centre dots of hexes, etc. What I would like for Roll20 measuring tool is a tool that measure distances on a squared background with straight distance equal to one (wathever unit) and diagonale equal to 1.5 (wathever unit) like Maptool or other VTTs. Other VTTs are dedicated to playing D&D 3, it's clones, and D&D 4, games that happen to use a square grid. It is the mission of Roll20 to be "system agnostic", to make no assumption about what rules the users are using. Most RPGs do not use a square grid. It is Roll20's stated mission to be just as functional for games that use a hex grid (e.g. TFT, Dragonquest, GURPS, HERO, Traveller, ForeSight) or no grid at all (e.g. Basic D&D, AD&D, Aftermath, Bushido). And in many games, such as most of mine, most of what goes on is not on the combat grid at all.

I'll bet that you measured the distance between the interior corner squares of a rectangle of which the exterior dimensions were 24 squares by ten squares, and not the distance between one square and another that was 24 to its right and ten above. . No, I did not. It is the result square to square, where the measure tool snaps, because it counts a number of squares, not pixels. Have a try yourself, Maptool is free. What you describe is what you could have with a pixels measuring tool, though. The largest error does not occur at 45 degrees, and is not due to approximating the square root of two by 1.5. It occurs at about 25 degrees, is due to approximating an arc by a straight line, and amounts to 11%. 6% is the approximation of the diagonale. 4% is what I obtained making a real measure in the exemple you gave and I never saw 11%. All this using a VTT for real, not using geometry. I don't know (or care) what algorithm Maptool uses, but it is what I would like Roll20 to do. But I defend it because using squares and 1/1.5 ratio is going to produce a consistent, repeatable, predictable result. Anytime you are going to repeat the measure, you are going to have the same result expressed in "squares" units, easily understandable. The same is of course true of proper geometry when you measure between the same points, such as for instance the corners of grid squares, the centre dots of hexes, etc. True, but you are not going to do that easily when eyeballing the same place in a square with the system you defend and, "What if you don't use squares" (your words), then there is no reference to take the same point each time you measures. So you are going to have an error amounting to the size of your token divided by the distance. For exemple, if you have a monster that is 150 pixels across and another token is two squares away, your approximation is 100%, probably less because you can choose the point you measure from. But your distance is completely meaningless because it only depends on the points you choose to take the measure. What I would like for Roll20 measuring tool is a tool that measure distances on a squared background with straight distance equal to one (wathever unit) and diagonale equal to 1.5 (wathever unit) like Maptool or other VTTs. Other VTTs are dedicated to playing D&D 3, it's clones, and D&D 4, games that happen to use a square grid. It is the mission of Roll20 to be "system agnostic", to make no assumption about what rules the users are using. No, other VTTs are as system agnostics as Roll20 would like to be. You should download and experiment with a few of them, some are free and those that are not have a demo. There is no problem with hexes, hex counting works as well as squares counting. BTW, if I followed your demonstration (choosing a way to measure implies a kind of rules) choosing pixels measuring is no more system agnostic than choosing squares counting.

I'll bet that you measured the distance between the interior corner squares of a rectangle of which the exterior dimensions were 24 squares by ten squares, and not the distance between one square and another that was 24 to its right and ten above. . No, I did not. It is the result square to square, where the measure tool snaps, Start in some square, and move to the right fourteen times. Then move diagonally up-and-right ten times. That's a distance of fourteen for the fourteen straight moves plus fifteen for the ten diagonal moves, which is a total of 29. But the place you end up in is 26 squares from the place you started, in a straight line. (29 - 26)/26 = 0.11538+ That's a discrepancy of over 11%, not 4%. Most of it does not arise from approximating the length of the diagonal, but from measuring distance along a crooked course.

OK. Maybe we can quit it here. If you know better than what is visible when making the measure itself, there is not much left to discuss. Replacing experiment with prejudice seems a little odd, but suits yourself. You have pre-decided on a result, whatever the visible real result could be. It is of course easier to criticize that way. I prefer to believe what I see when doing the measure with a VTT (which is what this discussion here is about, isn't it?). So, for peoples wanting to make the experiment for themselves, open Maptool, set distances to 1 for straight lines and 1.5 for diagonals in the settings. Draw a rectangle 10X24 squares and measure from one corner to the other with both methods. You'll see the results. And what I see is the way I would like Roll20 to behave. Anyway this discussion have lasted enough for me, for something Roll20's designers shall have the final word anyway. I think I have made my position clear. And given evidences that anyone can reproduce to check, not formulas.

OK. Maybe we can quit it here. If you want a truce, call a truce and stop fighting. To call a truce and then immediately try to land a hit is never going to work So, for peoples wanting to make the experiment for themselves, open Maptool, set distances to 1 for straight lines and 1.5 for diagonals in the settings. Draw a rectangle 10X24 squares and measure from one corner to the other with both methods. You'll see the results. When you have done that, use the same tool to measure the bottom and the side of the rectangle. Although the rectangle is 24 squares wide, the measurement from the bottom left square to the bottom right square is only 23. Although the rectangle is ten squares high, the measurement from the bottom right to top right is only nine. That is because the tool measures between the centre points of the selected squares, not from their outside corners. The diagonal of a rectangle 23 by nine ought to be approximately 24.7. Now start at a square and move to the right 24 times. Then move up ten times. Measure the distance to your original square. The diagonal of a rectangle 24 by ten ought to be 26. And what I see is the way I would like Roll20 to behave. I think that Roll20 ought to offer GMs a choice of distance metrics suitable to different games. Or perhaps the ability to customise a metric. For example it ought to offer the D&D 3 metric, the Chessboard metric (diagonals count as one), and the Manhattan metric (diagonals count as two) for use on square grids, and a hex-count metric for hex grids. And it certainly ought to offer the Pythagorean metric. However, if that is impractical or undesireable, I observe that the Pythagorean metric (true straight-line distance) is the hardest to use with a grid but no measuring tool, and therefore the one with the strongest claim to need the tool.

So TLDR (is that bad for a moderator to say?) but just so you know ruler re-design is on the TODO list. I don't know the details of how exactly it will be done but if you guys can come to some sort of summary of features you'd like to see that would be very helpful. Just for background big discussions like this do end up influencing things. The Turn Tracker had some rather long and passionate threads as well and we ended up with a TT tool that generally made everyone happy.

Well, if you think that the way I did it underestimated the size of the rectangle, the way you did it is worse because, with the way you measure, depending on the point of the square you use, it is a rectangle of between 8 and 10 squares X between 22 and 24 squares. My advice to you would be to use another VTT to have an idea of how those things work in practice not just in theoretical measurements. However, if that is impractical or undesireable, I observe that the Pythagorean metric (true straight-line distance) is the hardest to use with a grid but no measuring tool, and therefore the one with the strongest claim to need the tool. That's also the less used, less precise and less useful. But maybe having a poll and voting should decide which system has the strongest claim to be needed.

So remember we don't necessarily have to come up with the "one true ruler". Perhaps in the page settings or campaign settings we just list a few easy to implement options: -Measure From () Corner, () Center -Measure Style () Square/4e, () Square/3.5e, () Pythagorean, .....

Ok, for me the settings needed would be: Measures in "square" unit (I mean one unit is a square side). One straight distance is 1. One diagonal distance is 1.5 (just a proportion, you can use 2 and 3 if you prefer). Tool snaps to square (highlight) and measures from center. And gives full figures distances (no decimals) If it is not clear, you can see it certainly in Maptool and I think Battlegrounds, Gametable, and others. I never really thought about it before, it seemed universal. So I would have to check to see if there are VTTs that do otherwise.

This where it gets fun with the various systems. You need two different rulers just for D&D 3.5 vs 4 In 4e diagonals don't matter, 4 squares north and 4 squares west of your current position is considered to be 4 squares away. In 3.5 that was considered to be 6 squares away with the alternating 1/2 counting. I'm rather naive beyond just those two systems but I'm sure there are other game systems out there with different rules and we should make sure Roll20 can support them in a reasonable simple system agnostic manner.

Can't help there, I have no real experience with D&D. I have used the settings above, in the VTTs I have used, with a lot of different systems, but mostly as a way to regulate easily movements and because it simplified tracking of distances. Not really because it was coming from a rulebook. Edit: I am not sure that there are so many systems around giving an explanation on how to add squares...

This where it gets fun with the various systems. You need two different rulers just for D&D 3.5 vs 4 In I'm rather naive beyond just those two systems but I'm sure there are other game systems out there with different rules and we should make sure Roll20 can support them in a reasonable simple system agnostic manner. There are four different metrics used for approximation on the square grid. * There's "Chessboard distance", also called "Chebyshev distance", which counts the number of chess-king moves between the origin and destination. Another way to describe that is that is that diagonals count as one. Mathematically, DIST = MAX ( (ABS X2 - X1 ) , ABS( Y2 - Y1 ) ). I'm told that that is the rule in D&D 4. * There's "Manhattan distance", also known as "Taxicab distance", in which you add horizontal moves to vertical moves. Another way to describe that is that diagonals count as two. Mathematically, DIST = ABS( X2 - X1 ) + ABS( Y2 - Y1 ). That's the rule in, for example, "Frag" from SJ Games. * There's D&D 3 distance, which is the average of the previous two. In other words diagonals count as one-and-a-half, rounded down. Mathematically, DIST = MAX ( ABS( X2 - X1 ) , ABS( Y2 - Y1 ) ) + 0.5 MIN ( ABS( X2 - X1 ) , ABS( Y2 - Y1 ) ). That's used in for example D&D 3.x, Pathfinder, D20 Modern, and we've had at least two users in these forums argue that it is the correct distance metric for all RPGs and ought to be used to the exclusion of all others. * And there is true, "straight line", "Euclidean", or "Pythagorean" distance. DIST = SQRT ( ( X2 - X1 )^2 + ( Y2 - Y1 )^2 ), perhaps rounded to the nearest integer. That's used by e.g. Basic D&D and AD&D, and it is the one that is hardest to use without a tool. On a hex grid there are two metrics of interest. A straightforward hex count (though the formula in X and Y values depends on whether you grid is aligned with true hexes or true columns), and the ubiquitous Euclidean distance. I'm not sure what hex-grid games use Euclidean distance, but sometimes you see hex paper with a dot in the middle of each hex, which is mostly for working out line-of-sight with a straight edge, but also to facilitate measuring distances from hex to hex. Games that don't use a grid either don't care about distance at all (e.g. FATE v3) or use Euclidean straight-line distance. Whenever anyone wants to use the measuring tool on something other than a tactical display, e.g. a small-scale map or to measure an object in a picture, they almost always want Euclidean distance. Though there are apparently exceptions.

... we've had at least two users in these forums argue that it is the correct distance metric for all RPGs and ought to be used to the exclusion of all others. Not exclusive, just first choice if there is a need to that. I know one user who wants the same for euclidian measure... Who is the second user? Did I missed his posts?

... we've had at least two users in these forums argue that it is the correct distance metric for all RPGs and ought to be used to the exclusion of all others. Who is the second user? I forget: it was a couple of months ago. And I having trouble finding search term specific enough to isolate that conversation. In any case, the fellow might have changed his or her mind since being told that what he or she called the correct method is not used in the current version of D&D. Did I missed his posts? Probably. It was very early, two or three weeks before you joined.

Ok, thanks.

Thanks for the summary of the options Agemegos, including the Hex options. I'll be sure the devs take a look at this and we'll see if we can make everyone at least mostly happy :) Any thoughts on the ability to measure from the center of a square/hex vs a corner?

If you're measuring from the centre to the centre that will always be the same as measuring from a corner to a corresponding corner. For example, the distance from the top-left corner of one square to the top-left corner of another is the same as the distance between the centres, and so forth. In tabletop wargames you often measure the distance between units as being the distance between the closest points of their bases, and it is possible on that sort of basis that some users might want an automatic measure between the closest corners of each of two squares. It's not quite the same thing, though, and I don't know of any games that work that way. So it might be confusing and it might not be necessary. I suggest leaving such variations off the list unless you hear from someone who needs them. As far as I know no-one uses any of the funky linear approximations for distance other than for integer range and movement on a tactical grid. So true straight-line distance is perhaps the only one that needs both a point-to-point variant and a rounded-off square-to-square variant. But that's only as far as I know. You might hear better from someone else soon.