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

  • We have updated our Community Code of Conduct. Please read through the new rules for the forum that are an integral part of Paradox Interactive’s User Agreement.
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.
26.25 seems like the best fit to me too. It doesn't perfectly fit all the test data, namely a 165 speed firestarter/commando should be able to move forward 5 hexes and forward/diagonal 2 hexes, since that would total 163.93 meters, but they can't.
GyGtMYU.png


On the other hand, if you adjust the dot distance enough for the firefighter/commando to make sense, then it doesn't make sense that a locust can walk 8 dots in a straight line. So 26.25 is about as close as it can get to matching my test data. It's mathematically impossible to fit all the test data to a single dot-distance without making assumptions about the test data being wrong, such as uneven terrain, etc.
kl1Zf7r.png
 
One thing your table is masking (at least, I think it is, from the numbers you have... I'm not entirely sure how to read some of those columns) is that the X direction plus a lateral shift is not simply the mathematically calculated straight-line distance between the two points.
It's the straight line distance along the path actually traveled.

For instance, if I want to move 4 dots forward and shift three dots laterally to the side of the X-line I was originally on, your calculated distance is listed as 6.0828. That's not how it would work in Battletech; I would move forward 4 hexes, turn, and then move forward along my new heading the remaining 3 hexes. On flat, level terrain, that would actually cost me 8 movement in CBT.

Are you factoring in a movement allowance for each facing change during the move, as compared to straight-line moves?

For that matter, are you factoring in any facing change/deviation at the end of the move, no matter how small or unintentional? That should, in theory, still cost movement. I know that from personal experience, if I move one of my units to its maximum displacement from starting position, my facing choices are very constrained on arrival. In order to get additional facing 'spread', I usually have to back up one or two dots from the maximum distance.
 
So, I tested edting the "ExperimentalGridDistance" variable and it works as expected. Moving it to 25 from 24 makes the grid dots line up perfectly with a 100m Rangefinder. These numbers are indeed the same between direct range meters and movement, and likely all distance numbers in the game are meters. Here is a gfy of each,the links below the gifs go to the high res. You can see that the stock 24m dots fall about 4m short of the 100m range bracket and then line up perfectly on the 25m set. The game seems to take slight slopes in to account most of the time, but I don't have time to test this right now. I'm glad I got this much done. If anyone wants to do more: Set a Victor's movedef to Walking: Your target testing value, Sprint: 500 or 600 to get where you need to go fast, MedLas weapondef to 100, 100, 200 on range brackets and then the combatgameconstants grid distance to your test value. Use a 2/2/2/2 pilot if you have one for no pilot bonuses. Set the AI to a single Urbie for quickest AI turn and no interference.

EDIT: Oh, neat hidden feature: You can hold Left ALT while selecting your moves to get any dots within 4 spaces to show over your mouse. Even if your mouse is on the other side of the map.

STOCK 24 Grid
LoneHeavenlyDrafthorse-max-14mb.gif

https://gfycat.com/LoneHeavenlyDrafthorse

25 Grid
AngelicPlainFrogmouth-max-14mb.gif

https://gfycat.com/AngelicPlainFrogmouth
 
4.582576
One thing your table is masking (at least, I think it is, from the numbers you have... I'm not entirely sure how to read some of those columns) is that the X direction plus a lateral shift is not simply the mathematically calculated straight-line distance between the two points.
It's the straight line distance along the path actually traveled.

For instance, if I want to move 4 dots forward and shift three dots laterally to the side of the X-line I was originally on, your calculated distance is listed as 6.0828. That's not how it would work in Battletech; I would move forward 4 hexes, turn, and then move forward along my new heading the remaining 3 hexes. On flat, level terrain, that would actually cost me 8 movement in CBT.

Are you factoring in a movement allowance for each facing change during the move, as compared to straight-line moves?

For that matter, are you factoring in any facing change/deviation at the end of the move, no matter how small or unintentional? That should, in theory, still cost movement. I know that from personal experience, if I move one of my units to its maximum displacement from starting position, my facing choices are very constrained on arrival. In order to get additional facing 'spread', I usually have to back up one or two dots from the maximum distance.

I understand why you would expect that behavior based on tabletop rules; however, even though there's a lot we don't fully understand about movement in this game, it definitely doesn't work like that. For example, look at where this Battlemaster can and cannot move at walking speed (note, only the valid spots within 4 dots of my mouse cursor are lit up):
iCzphJZ.png

As you can see:
1: It is able to move 4 points in a straight line (downward from this angle).
2: It is not able to move 5 points in a straight line (downward from this angle).
3: It is not able to move 4 dots forward and shift 1 dots laterally to its left. This is a distance of 4.58 dots
4: It is able to move 3 dots forward and shift 2 dots laterally to its left. This is a distance of 4.36 dots.

So in reality this 'Mech's maximum walk distance would appear to not be 4, but rather somewhere between 4.36 and 4.58. I realize this is not how it would work in tabletop, but it is how it works in HBS Battletech.

That said, you may have indirectly solved the mystery: Sure, sometimes it does draw a straight line to a target dot, but other times (like this screenshot shows) it makes a series of turns to get to a destination instead of going perfectly straight. So although the specific formula used in tabletop (which used only 6 directional paths and turns in 60 degree turn increments) is clearly not used, they may have followed the spirit of it with these pathfinding turns en route to these unusual-angle destinations counting against our maximum distance.

That could explain the discrepancy in the proposed formula for walking from dot to dot costing 26.25 as described before... The Locust walking in a straight line didn't have to pay this "pathfinding tax" because it was going in a perfectly straight line along the grain of the hex grid. But the Firestarter, walking 5 dots forward and 2 dots diagonal, would likely have to pay a little movement tax from using an irregular path to reach that destination, and given that the destination was only just barely within its range as the crow flies, a little lost range is all it would take to make it unreachable.
 
So, things are about to get weird.

I edited out the penalty for movement through water in the designMasks folder. This gives me a very flat platform to test movement numbers and is as close to a blank map as I can get. I found there is a kind of "natural grain" of each map where moving along only 1 axis is somehow cheaper than the other 2. I first started with a movement of 24, the confirmed size of the movement grid, nothing. Moving to 25 lets me move up or down the native grain of the map, but nowhere else. Note, this movement was available even if I was facing perpendicular to the native grain. Once I hit 27, things get interesting. But first, the 25 and 27 numbers confirm movements need to be one greater than whatever numbers the game is using, in this case, strait grid distance of 24m and that magical 26.25 that keeps coming up, but I can't find why it's so important or where it's declared.

Here is a VTR with 27m walk movement and its facing options, this screen shows the directions I will be using below. The composite shots show the maximum facing angles to the left and right after entering each hex. The 1 direction is "with the grain" of the hexes and the direction the VTR is facing. However, it's not with the "native grain" of the map that runs along the 2-5 axis and that means we see some strange results below.

Tjtvznf.jpg

Here is my turning raduis for 1. Note that my path along 1 is crooked to the left, and my final facing options favor the inside of my curved path.
77sAEp5.jpg


For 2, this runs along the native grain and my facing options are greatest, with over 240 degrees (if my math is right) of freedom. The pathing is in a strait line, suggesting this route is somehow shorter than hex 1 and leaves more facing angles.
OtTal8n.jpg


We see 3 works like hex 1, in that the pathway is curved and my facings favor one side, to the right this time.
aD4nycO.jpg


Hex 4 is also curved like 1 and 3, but note this is behind the VTR. This kind of action is probably why reverse isn't needed. We don't really pay much cost to turn around at the start of our movement, it's costly to turn at the end but it seems stepping off in any direction is free.
BARmAtD.jpg


Now back to the native grain on hex 5. Again, this is somehow cheaper (strait line shorter than curved used to calc mp spent?) and I get a wide range of facing options.
i0kktbr.jpg


Now we get to hex 6. The pathing is strait, but I don't get the same +240degree range of the 2-5 axis. I only get around 230degrees or so. This "strait but not with the native grain" movement and limited facing can be replicated on many points of the map. Some hexes have two or maybe 3 off native grain movements that look strait but don't get the native grain bonus.
dPExhSW.jpg

I think the game's pathing line is the raw distance of the move displayed. That's why the curved moves cost more MP and leave me with less facing angles at the end. As to why some 1 hex moves don't travel in the strait line and soak up MP, or why some seemingly strait moves have more or less facing after, I got no clue.
 
Question for everyone looking into this: Do you feel this knowledge will have a material effect on how one plays the game, or is it just peeking under the hood for funsies (which I totally get)?
 
Question for everyone looking into this: Do you feel this knowledge will have a material effect on how one plays the game, or is it just peeking under the hood for funsies (which I totally get)?

Practically, not much and this is more a under the hood kind of thing. I think at best you might be able to squeeze out an extra dot or some more facing if you know the native grain for the map and everything happens to align just right. Really, the enemy position is going to be way more important than this. However, the "How big is the grid? 30m hexes like TT? Is this even in meters?" and other questions have been longstanding since we got the initial beta and we are just starting to learn the answers. This could also be useful for anyone trying to make a 1:1 TT ruleset mod, as now they can change hex size to 30 and would need to know the minutiae of how the game calculates things with how rigid the MP rules are compared to how granular this game handles it.

Thinking about it, I might try some LCT/SDR testing and see if I can or can't snag an extra dot somewhere. But that's for another time.
 
...strait grid distance of 24m and that magical 26.25 that keeps coming up, but I can't find why it's so important or where it's declared....

"How big is the grid? 30m hexes like TT? Is this even in meters?"

Okay this is funny: 24 meters equals... wait for it... 26.25 yards. Are the map dots in meters, but our walking speed is in yards? I could swear they are messing with us.
 
Last edited:
Okay this is funny: 24 meters equals... wait for it... 26.25 yards. Are the map dots in meters, but our walking speed is in yards? I could swear they are messing with us.

I'm on mobile all day, but a way to test this would be take take a LCTs movedef numbers and convert from yards to meters, giving it back it's "full" movement. So if it said "100" and only gets 91.44m it's new value would be 109.361(not sure how to round that, probably downward) to see if you can reach that real meter distance.

This still doesn't explain the native grain movement though. I almost want to @ ping a dev about the meter/yard thing. There might be some other constant we can't see and it just happens to fall right at that value. Or it's possibly a bug/unity quirk they might have had to work around at some point.
 
The "grain" of the map could also be explained by rounding errors.
In other words, if one axis of the grid is defined as the primary axis, then by definition all of its points are spaced exactly X units apart. If the game then calculates the distance to non-colinear points, rather than defining the distance, you would get situations exactly like what you demonstrated, where it costs ever-so-slightly more movement to move to a point "off-axis" due to a rounding error.
It also appears, from your 1-point move experiments, that turning facing requires only a tiny amount of movement to accomplish; something on the order of a fraction of a movement unit. This would corroborate the 'rounding error' explanation.

Something else worth checking on: I believe that the devs mentioned that certain chassis would have inherently better/worse turning speeds. Is this reflected in some as-yet-untweaked variable, where perhaps a Victor takes more absolute movement to turn 180 degrees than a Locust does?
 
Question for everyone looking into this: Do you feel this knowledge will have a material effect on how one plays the game, or is it just peeking under the hood for funsies (which I totally get)?
Basically, it's primarily of interest for us modders.

When you start changing things wily-nily, the behind-the-scenes math can start to matter quite a bit.
 
i have nothing to add except that i love this thread and everything about it.

I have to say, great job to everyone at HBS! The system is amazingly resilient to all kinds of whacky changes. I can edit the grid distance and the maps automatically adapt the water/forest/normal classifications for the new dots and during our LoS testing the game held up at all ranges, even in MP. I find the only reliable way to break the game is to give it a syntax error or a missing file in the VerMan.csv. I'm happy to see I can just enter in ludicrously low or high values nearly anywhere and see the engine just accept it and put it in to play. You've built a very solid sandbox.
 
I'm happy to see I can just enter in ludicrously low or high values nearly anywhere and see the engine just accept it and put it in to play. You've built a very solid sandbox.
early on, all the engineers realized that the design team was indecisive and useless and we'd ask for a dozen changes within a day of a new system coming online. They're very diligent about giving us access to tuning and configuration constants, and making those as hands-off for engineering as possible... because otherwise we'd be constantly bugging them.
 
early on, all the engineers realized that the design team was indecisive and useless and we'd ask for a dozen changes within a day of a new system coming online. They're very diligent about giving us access to tuning and configuration constants, and making those as hands-off for engineering as possible... because otherwise we'd be constantly bugging them.

If it's not too much to ask, how does the movement point system work? Why are we seeing it take about 27m to move 24 in some directions and 25m in others?
 
If it's not too much to ask, how does the movement point system work? Why are we seeing it take about 27m to move 24 in some directions and 25m in others?
Absolutely no idea. I'll ask Andy on Monday if it's something he wants to get into or not. I think it's not exaggeration to say we spent the first 9 months of this project just iterating the movement system, and we re-examined it every few months after that until we were happy with it. So there's a lot of design decision water under that particular bridge.
 
Absolutely no idea. I'll ask Andy on Monday if it's something he wants to get into or not. I think it's not exaggeration to say we spent the first 9 months of this project just iterating the movement system, and we re-examined it every few months after that until we were happy with it. So there's a lot of design decision water under that particular bridge.

Thanks, it would be hilarious if it turned out 'Mech movement points were in Yards and grid points in Meters.