Movedefs.lua

Location

movedefs.lua is a file in the Gamedata/ directory of a Spring Game.

Purpose

This file defines MoveClasses which are used to determine pathing for units.

Source

The engine source code which parses the data from this file is viewable here: rts/Sim/MoveTypes/MoveInfo.cpp

Details

A mobile unit is assigned a MoveClass using the movementClass UnitDef tag. The engine determines the unit's pathfinding based on the properties of the MoveClass, so analogous properties (e.g. FootprintX) 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.

Types

• Bot - A ground based MoveClass. The default type if no matching type string is found.
• Tank - A ground based MoveClass. Identical to Bot other than interaction with TypeMaps.
• Ship or Boat - 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, as well as having canHover in their UnitDef to behave as hovers.

MoveClass Tags

• Name
• FootprintX
• FootprintZ (ignored in pre0.83 releases!)
• CrushStrength
  • power of unit to crush features
• SlopeMod
  • how much a slope will slow a unit, 0 means no slowdown
• MaxSlope

Heat Tags

These tags are used in unit avoidance.

• HeatMapping
• HeatMod
• HeatProduced

Tank & Bot-Only Tags

• DepthMod
  • how much to slow down amphibian speed when they're underwater

Ship-Only Tags

• MinWaterDepth
• MaxWaterDepth
• SubMarine

Special notes

• Hover movetypes require "HOVER" in the name to work
• Ship movetypes require "SHIP" or "BOAT" in the name to work
• Tank movetypes require "TANK" in the name to work
• KBot movetype is default
• depth is measured in elmos
• Slope is not measured in degrees.
• CrushStrength uses mass to determine if a feature can be crushed by a unit.
  • default feature: mass = metal * 0.4 + maxHealth * 0.1
  • default unit: mass = metalCost
• Slope/Depth mod
  • This value applies directly based on the slope/depth, meaning the deeper or higher the slope, the MORE it slows a unit down.

How slope is determined.

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 kbot 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 kbot 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

Example

External Examples

'Balanced Annihilation' movedefs.lua

'Complete Annihilation' movedefs.lua

'Spring: 1944' movedefs.lua

'Spring Tutorial Game' movedefs.lua

'ZeroK' movedefs.lua