Expose engine constants to random map libraries

[FeXoR]

As for example random maps need to take into account some engine parameters it would be nice if some would be added to ​globalscripts e.g. in a file EngineParameters.js in an dictionary like object g_EngineParameters.

The following parameters are needed by random maps (Most of them allready found at the beginning of ​library.js):

• CELL_SIZE = 4 (The width of a terrain texture tile in horizontal engine space units)
• HEIGHT_UNITS_PER_METRE = 92 (The number of vertical engine space units matching a horizontal engine space unit)
• MAX_HEIGHT_RANGE = 0xFFFF / HEIGHT_UNITS_PER_METRE (The maximum value for vertical engine space in horizontal engine space units)
• MAP_BORDER_WIDTH = 3 (The width in )

NOTE: Any space unit will do if the scaling is given as well.

Some other parameters would be nice to also have access to but I'm not sure if they are engine parameters or set in the mods:

• MIN_MAP_SIZE = 128 (The map width of the smallest map as chosable in mapsetup/Atlas in terrain tiles)
• MAX_MAP_SIZE = 512 (Same just the largest chosable map size)
• BUILDING_ORIENTATION = - PI / 4 (The placement angle buildings should be placed by default. For random maps it's rotated and the direction changed, see ​map.js getMapData)

Other components like simulation/UnitAI/PlayerAI, Atlas might also need some parameters so further comments welcome!

This is basically for reducing hardcoding the same things at multiple places. However, it's also quite vital for mods if build from scratch.

[elexis]

The simulation components are initialized prior to the map generator. So we can simply add getters to the map generator JS interface in MapGenerator.cpp.

MAP_BORDER_WIDTH is a special case because the simulation doesn't have a central place for this yet and instead hardcodes that magic number all over the place, see #4636.

Other components like simulation/UnitAI/PlayerAI, Atlas might also need some parameters so further comments welcome!

For the simulation people already take care not to copy magic numbers and it's easy to access C++ simulation constants from JS simulation components. Not aware of any existing hardcodings in the JS sim.

For atlas, we have

tools/atlas/AtlasUI/ScenarioEditor/Tools/PlaceObject.cpp:static float g_DefaultAngle = (float)(M_PI*3.0/4.0);

Not aware of any other atlas hardcodings. (One might or might not argue it doesn't have to be the same default angle for atlas and random maps.)

the direction changed, see ​map.js getMapData

Don't see anything changing angles there

[elexis]

These two constants are not engine limits but a choice by the GUI of the launched mod (map_sizes.json). One can change them in that file and it still works.

const MIN_MAP_SIZE = 128;
const MAX_MAP_SIZE = 512;

They are only used here:

function scaleByMapSize(min, max)
{
	return min + (max - min) * (g_Map.size - MIN_MAP_SIZE) / (MAX_MAP_SIZE - MIN_MAP_SIZE);
}

If there was a map using these constants as an out-of-bounds check, it would break if the mod changes the mapsize. So no map should refer to these constants.

There are two use cases for mods to change these constants: 1) Use all existing maps but change the mapsize choices 2) Replace all existing maps and change the mapsize choices

For (1), replacing the constants with a reference to map_sizes.json is wrong, because the numbers passed to scaleByMapSize are optimized for the current range. Moving 128 and 512 to the scale function would perfectly work for arbitrary mapsizes.

For (2), the map could provide or overwrite the scaleByMapSize function and be done with it.

So the best solution for the two constants seems to be to inline the magic numbers and explain them.

[FeXoR]

I agree removing MIN_MAP_SIZE andMAX_MAP_SIZE and make the parameters of scaleByMapSize optional with the default being 128 to 512.

[elexis]

In 20368:

Remove min/max mapsize constants from the rmgen library, refs #4034.
The removed values were in fact arbitrary GUI numbers no map script should confuse with engine limits.

To not make it my words, quoting FeXoR from #4034:
"I agree removing MIN_MAP_SIZE and MAX_MAP_SIZE and make the parameters of scaleByMapSize optional with the default being 128 to 512."

[elexis]

In 20396:

Use only one coordinate system for locations in the rmgen system.

Thereby fix the distance check of the SimpleObject, refs #4338, D189 and
remove the CELL_SIZE engine constant magic number, refs #4034.

Differential Revision: ​https://code.wildfiregames.com/D996
Thanks a lot to rapidelectron and temple who independently discovered this!

[elexis]

In 20504:

Pass the size in meters of a terrain grid tile from Terrain.h to the rmgen JS code to avoid hardcoding thereof.

Refs #4034, D900
Differential Revision: ​https://code.wildfiregames.com/D1059
Reviewed By: s0600204

[elexis]

In 20512:

Delete FALLBACK_CIV "athen" and related code in rmgen/, refs #4034.

It was only triggered if a civ wasn't set in Atlas.
Because civs are expected to be well-defined everywhere, alwas set the property in Atlas too, fixing the non-GUI part of #4869.
Use the existing player defaults value then instead of hardcoding a fallback civ string.

[elexis]

In 21171:

Make Belgian Uplands a circular map and clean it's code, refs rP12813.

Replace needlessly complicated code with a call to HeightConstraint, stayClasses and randomPlayerLocations, refs #4805.
Do texture painting and actor placement at the impassable map border too.
Replace another occurrence of the number of impassable tiles at the map border, refs #4034.
Delete useless clone from rP18141 since setRandomHeightmap replaces the result.
Remove unneeded setReliefmap and operate on the target heightmap directly.

[elexis]

​Phab:D2061 for MAP_BORDER_WIDTH

[elexis]

In 22459:

Unify the magic number indicating the number of impassable tiles at the map edge redundant in the Pathfinder, RangeManager and MapGenerator.

Refs #4034, #4636.
Differential Revision: ​https://code.wildfiregames.com/D2061
Reviewed By: wraitii