Do we know if there is any need for the rmgen system to use the scale it does?

It could use metres like the simulation too if one changes every number in every line of every map to use metres instead of tiles, which is why I went for the much shorter variant.

The entire simulation uses the metres thing, the entire rmgen code used terrain tiles except in that one place removed.

If I understand correctly, there is currently no bug in svn but in order to convert the simulation template footprint sizes into the terrain tile sizes used by rmgen the constant would be needed?

If so, then this diff isn't wrong, but the constant should be received through the MapReader.cpp. If you need it I can go look into it, should be easy. (Only a new getter of a scriptinterface in c++)

In rP20396#25105, @elexis wrote:

Do we know if there is any need for the rmgen system to use the scale it does?

It could use metres like the simulation too if one changes every number in every line of every map to use metres instead of tiles, which is why I went for the much shorter variant.

I was vaguely wondering if there was some historical reason for it.

If I understand correctly, there is currently no bug in svn but in order to convert the simulation template footprint sizes into the terrain tile sizes used by rmgen the constant would be needed?

You understand correctly.

If so, then this diff isn't wrong, but the constant should be received through the MapReader.cpp. If you need it I can go look into it, should be easy. (Only a new getter of a scriptinterface in c++)

Yes please 😄

In rP20396#25106, @s0600204 wrote:

I was vaguely wondering if there was some historical reason for it.

About the reason code-wise:
It's exactly the hardcoded magic numbers passed to Constraints, such as avoidClasses and stayClasses that must be changed in every map.
Also some hardcoded absolute distances, for instance the distance of the starting resources to the CC.
At least a big minority of calls to scaleByMapSize would be affected.

The historic reason is rP2733 introducing the first maps with tile coordinates and then everything getting copied 60 times in 12 years.
rP9096 introduced the rmgen JS library and contains some more remarks and links to historically relevant versions.

(Changing the coordinate system in every rmgen file is becoming much easier with every rmgen commit in case someone wants to go through the trouble)

We could also make getter functions like RMS.MetresToTiles(getMapSize() / 2) and RMS.TilesToMetres(cmpFootprint.size), but a simple JS const initiated from C++ getter Engine.GetSomeCellSize() + 2 JS functions seems nicer.

Meanwhile you can continue to process D900 as usual - just add back that one line const in your diff and the rebase should be complete. If you want to save time later you could remove the concern now already xP