Movedefs.lua - beyond-all-reason/springrts_engine_wiki_mirror GitHub Wiki
movedefs.lua is a file in the Gamedata/ directory of a Spring Game.
This file defines MoveClasses which are used to determine pathing for units.
The engine source code which parses the data from this file is viewable here:
A mobile unit is assigned a MoveClass using the tag. The engine determines the unit's pathfinding based on the properties of the MoveClass, so analogous properties (e.g. ) in the UnitDef should be the same for optimal behaviour.
All MoveClasses must belong to one of four possible types. A
MoveClass is assigned a type simply by including it within the name
string e.g. Tank_MyMoveClassName. Types are used in
TypeMaps of Spring maps, which
allow mappers to set per-type speed multipliers.
-
Bot- A ground based MoveClass. The default type if no matching type string is found. -
Tank- A ground based MoveClass. Identical toBotother than interaction with TypeMaps. -
ShiporBoat- Are synonyms. All ships / boat MoveClasses must belong to this type to behave as ships. -
Hover- All hovercraft MoveClasses (traverse any depth of water without speed reduction) must belong to this class.
These tags are used in unit avoidance.
These tags are used in unit avoidance.
Only read for Bot and Tank MoveClasses, the depthModParams group
contains several sub-tags. Depthmod is a system for changing the speed
of units depending on how deep they are underwater.
new formula is given by
if h < depthModParams.minHeight: 1.0
if h > depthModParams.maxHeight: 0.0
else:
depthScale = MAX(0.01, MIN(depthModParams.maxScale, (a * h * h) + (b * h) + c))
depthMod = 1 / depthScale
where
h = unit's absolute height below water surface
a = depthModParams.quadraticCoeff
b = depthModParams.linearCoeff
c = depthModParams.constantCoeff
The following tags control the behavior of the unit within the active portion of the curve (depth is greater than but less than ). It would be best to simply open up your graphing program of choice and use the provided formula, but if you're scared of graphs you should read the descriptions below:
These previously hard-coded variables allow control over how the pathfinder (default only, not QTPFS, see Modrules.lua) calculates the cost for a MoveClass for squares containing mobile units, if and only if .
Spring doesn't represent terrain slopes in degrees, internally it uses
(1.0 - the terrain normal's y-component) so the slope of vertical
faces is 1 and that of horizontal ones 0. A unit's maxSlope value
(which is in degrees in its movedef) is converted so that the "can we go
here?" (ie "maxSlope > terrainSlope?") comparisons are meaningful, the
formula is 1.0 - cos(DEG2RAD(maxSlope * 1.5)). If you want to know the
terrain angle in degrees, compute RAD2DEG(arccos(1.0 - terrainSlope)).
For a bot with a maxSlope of 36 degrees (~0.41221 in "Spring
format"), the maximum tolerable terrain angle is approximately
RAD2DEG(arccos(1.0 - 0.41221))
or 54 degrees. If maxSlope was 30, the MTTA would be 45, and if it
was 60 (the highest sensible value due to that 1.5 scalar and the
absence of overhanging cliffs) the bot could mount any terrain. In other
words you do not need the long mathematical derivation, just remember
that maxTerrainAngle = maxSlope * 1.5
--kloot, Thu Jul 31, 2008
that game developers have used for years and find it quite useful.
'Balanced Annihilation' movedefs.lua
'Spring Tutorial Game' movedefs.lua
Category:Gamedata