Opened 5 years ago

Last modified 22 months ago

#4034 new enhancement

Expose engine constants to random map libraries

Reported by: FeXoR Owned by:
Priority: Should Have Milestone: Backlog
Component: Maps Keywords:
Cc: Patch: Phab:D1059

Description (last modified by elexis)

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.

Change History (13)

comment:1 by elexis, 4 years ago

Summary: Give some engine parameters to JavaScript shared functionsExpose engine constants to random map libraries

comment:2 by elexis, 4 years ago

Component: Core engineMaps
Description: modified (diff)
Milestone: BacklogAlpha 23
Owner: set to elexis
Priority: Nice to HaveShould Have

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

Version 0, edited 4 years ago by elexis (next)

comment:3 by elexis, 4 years ago

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.

comment:4 by FeXoR, 4 years ago

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

comment:5 by elexis, 3 years ago

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."

comment:6 by elexis, 3 years ago

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:
Thanks a lot to rapidelectron and temple who independently discovered this!

comment:7 by elexis, 3 years ago

Patch: Phab:D1059

comment:8 by elexis, 3 years ago

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:
Reviewed By: s0600204

comment:9 by elexis, 3 years ago

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.

comment:10 by elexis, 3 years ago

Milestone: Alpha 23Backlog
Owner: elexis removed

comment:11 by elexis, 3 years ago

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.

comment:12 by elexis, 22 months ago


comment:13 by elexis, 22 months ago

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:
Reviewed By: wraitii

Note: See TracTickets for help on using tickets.