PSA: Each "dot" is 24 meters, not 30

[HonorKnight]

This is based on testing performed by Amechwarrior in the old forums, here: https://community.battletechgame.com/forums/threads/11027/comments/216317

It's actually really weird how this works. Amechwarrior tested it by going to the flattest place he could find (near the road by the spawn point in death valley) and testing a modified json files with 101 max walking distance: that was just barely enough to walk 4 dots in a straight line (so clearly 4 dots was not 120 meters, as was the common wisdom). Oddly 100 was too short and couldn't reach the 4th dot. So either each dot is like 25.1 meters, or they're exactly 25 meters but even that very flat land is not perfectly flat so a tiny amount is lost in microscopic slopes across that distance. Either way, it's pretty darn close to 25 meters, and not the 30 meters that everyone has been assuming this whole time. I don't even want to think about how many of my charts I'm going to have to rewrite with this new knowledge.

EDIT: A dev has said the actual distance between dots is 24 meters.

 

[OathOfFealty]

Like to read all your stuff. Keep it coming.

 

[Amechwarrior]

Also, I recently noticed a value in the combatgameconstants.json, way at the bottom under movement:

"ExperimentalGridDistance": 24.0,

This lines up a little better with the 100m Laser Rangefinder in the screenshot above, just shy of the 100m mark. However, it doesn't explain why it takes 101 movement units to reach that 4th dot, the movement cost per dot might be slightly over 25 units/dot even if the grid distance is 24m. I haven't had time to experiment with the griddistance number, but if someone wants to give it a try, moving to 30 should produce some interesting results if it's what I think it is.

 

[ronhatch]

Also, I recently noticed a value in the combatgameconstants.json, way at the bottom under movement:

"ExperimentalGridDistance": 24.0,

This lines up a little better with the 100m Laser Rangefinder in the screenshot above, just shy of the 100m mark. However, it doesn't explain why it takes 101 movement units to reach that 4th dot, the movement cost per dot might be slightly over 25 units/dot even if the grid distance is 24m. I haven't had time to experiment with the griddistance number, but if someone wants to give it a try, moving to 30 should produce some interesting results if it's what I think it is.

Yeah, I was going to say it's 24 and not 25. Although technically the numbers are unitless and only the fact that the movement speeds are (sort of) in multiples of 30 turns it into meters. I suspect this is why the mech speeds got fudged a bit, but haven't figured out the exact implications of the differences yet.

I've been looking into this whole area since the major house rules mod I want to eventually make will likely allow fractional tabletop speeds. Setting the ExperimentalFlag to false breaks the game, unfortunately... apparently the code has moved on too much from when the grid really was experimental. You can definitely set the grid spacing much tighter, though.

I've also confirmed that the log shows that mechs stop in locations that are always multiples of the grid spacing in the X axis (offset by half the spacing on every other row), and the Z axis is always the expected multiple for a hex grid (the square root of 3 multiplied by half the GridDistance). The Y axis is unconstrained and is clearly the terrain height (well, it's constrained to the terrain height, I guess... which isn't an exact multiple of anything).

 

[Kereminde]

Yeah, I was going to say it's 24 and not 25. Although technically the numbers are unitless and only the fact that the movement speeds are (sort of) in multiples of 30 turns it into meters. I suspect this is why the mech speeds got fudged a bit, but haven't figured out the exact implications of the differences yet.

Those were getting fudged a little anyway, I recall, as a function of trying to bring the outliers (UrbanMech and Locust) from being too slow or too fast respectively. Not a lot but enough, and then the grid was developed when "total free-range movement" ran into "UX issues".

 

[ronhatch]

Those were getting fudged a little anyway, I recall, as a function of trying to bring the outliers (UrbanMech and Locust) from being too slow or too fast respectively. Not a lot but enough, and then the grid was developed when "total free-range movement" ran into "UX issues".

Y'know... saying that the UrbanMech is "too slow" or the Locust is "too fast" just doesn't compute for me when they have paid dearly for that weapon loadout/movement profile.

I mean... sure, you need to make the game balanced... I think I would have balanced that by adjusting the cost, though.

 

[Kereminde]

Y'know... saying that the UrbanMech is "too slow" or the Locust is "too fast" just doesn't compute for me when they have paid dearly for that weapon loadout/movement profile.
I mean... sure, you need to make the game balanced... I think I would have balanced that by adjusting the cost, though.

Been down this road on the old forums, there's no good way of slicing it since I'm not the one who made the call or phrased the decision to the forums. Bear in mind, this was over eight months old so I may be off-base here.

The general consensus was "there was a problem, this mitigates it without totally making a mess due to other consequences" from what I could determine. The other major contribution was the change in movement types, because suddenly movement which was entirely free like . . . say . . . "Alpha Strike vs CBT"? That's a bigger contributor than nudging speeds up a tad, because now you have the movements nailed down and are changing movement *styles*. In CBT you pay in speed for turning your facing but in Alpha Strike you don't, and it affects things just a tad.

 

[Lord of Riva]

I would take a guess that there is some code in place to stop the variable to go into the negative to avoid bugs and the line says it has to be always bigger than 0 (instead of it possibly being just not lower than 0, its something that happens quite frequently let me assure you ) therefore you would not be able to execute a precise movement.

It would be interesting if you could test 200/201 or 300/301 meters as well, if it always needs that one extra meter it may be just that, if the amount increases with distance it is probably as you suggest.

 

[ronhatch]

Been down this road on the old forums, there's no good way of slicing it since I'm not the one who made the call or phrased the decision to the forums. Bear in mind, this was over eight months old so I may be off-base here.

Yeah, totally not my intention to re-hash an old discussion... the numbers just looked odd to me and I hadn't commented on said old discussion.

 

[Soldryn The Red]

Hmm...24-25m eh? I always got the feeling that the dots were only 15m apart. At least that's how it felt to my rather imprecise measurements.

 

[Kereminde]

I always thought trying to translate it into meters was crazy as then you had the problem of effective weapon ranges being really short.

 

[Amechwarrior]

I always thought trying to translate it into meters was crazy as then you had the problem of effective weapon ranges being really short.

It basically has to be meters or close to it due to the known human scale items like roads, buildings and etc that populate the map. Short weapons ranges were done back on the TT inception to make things reasonable on a table. We know roughly how large the 'Mechs should be and that also establishes the scale of our weapons ranges.

 

[Packrat]

I always thought trying to translate it into meters was crazy as then you had the problem of effective weapon ranges being really short.

What are you talking about? Everyone knows that atmospheric friction causes machine gun bullets to disintegrate after 90 meters.

 

[Kereminde]

What are you talking about? Everyone knows that atmospheric friction causes machine gun bullets to disintegrate after 90 meters.

It's why I added the word "effective" - you might be able to hit with the bullets but not do appreciable damage. Sort of like being able to fire a handgun and hit a target well outside its effective range. Plus, in tabletop, there's a unit in a hex roughly 30m across which shouldn't begin to take up the whole area so it's assumed (at least I assume) it's a matter of playing Battleship when you know which row a target is on but not which column.

 

[HonorKnight]

I did more testing last night and it still seems super inconsistent. I don't know if this data dump will make sense to anyone other than me, but here I go anyhow.

As an example of the perplexing numbers, if dots really are 24 meters apart, why can't a 5-speed (150 meters) Kintaro walk 6 dots (144 meters) in a straight line? They should be able to walk that far and a quarter-dot farther, what rounding error or slope/terrain impact is causing this much of a disparity?

Here in Sprint mode we can see that walking those 6 hexes sure looks super flat and straight, none of those zigzagging paths we often see when traversing slopes and obstacles.

Yet in walk/move mode at max walking speed 150 according to the chassis JSON file, it can't reach that spot which is allegedly 144 away according the the constants file.

It sure seems like it's more than 24 between each dot. Even a smidge over 26 seems to fit the data much better. I bet it really is 24, only there are other weird factors dragging our speeds down, which they did to try to fudge the max distances of each 'Mech to where they wanted them to be.

 

[ronhatch]

I did more testing last night and it still seems super inconsistent. I don't know if this data dump will make sense to anyone other than me, but here I go anyhow.

I'd recommend that if you want to understand this better, look in the log files.

I don't have time at the moment, but I'll try to point out the bits that look the most useful next time I check in.

 

[ulziel]

Thanks that explains a lot more when I played as to clearly why some mechs had that speed boost or even some similar heavy ton mechs were different

 

[Xinxspuz]

Have you tried repeating these measurements and tweaks on a different map (with different base terrain)?

It's possible that the sand/desert terrain is applying some sort of modifier to the movement distance, one that's not immediately apparent from the comparison.
Alternately, take 'Mechs with Jump, and see how the Jump distance matches up to the Walk/Run distance on flat terrain. (Don't try this with the Shadow Hawk, though.) Jump movement should be completely independent of terrain, unless they've REALLY jiggered the movement system.

 

[HonorKnight]

Have you tried repeating these measurements and tweaks on a different map (with different base terrain)?

It's possible that the sand/desert terrain is applying some sort of modifier to the movement distance, one that's not immediately apparent from the comparison.
Alternately, take 'Mechs with Jump, and see how the Jump distance matches up to the Walk/Run distance on flat terrain. (Don't try this with the Shadow Hawk, though.) Jump movement should be completely independent of terrain, unless they've REALLY jiggered the movement system.

There really aren't a lot of even remotely flat areas on the beta maps large enough to do this kind of testing in... Jump distance actually is impacted by the terrain in some small way, specifically slopes. For example, jumping uphill can reduce how far you can jump; it's not a big difference, even for the tallest cliffs, but it's there. And there's really no way to measure slopes that I know of, so that's one more confounding variable. I did validate the jump distances in water since that's (presumably) totally flat, but I can't do that for walking distances without adding just more variables to the equation

 

[Amechwarrior]

Yea, I hit those same inconsistencies in my initial testing. The number 26.25 kept coming up when I did the math for most units dots/distance in the files. It seems it costs 26.25 to move a hex, but each hex is only actually 24 apart, given you set a weapon to 100/200 ranges as a "Laser Range Finder" and turn all others off.