Recoil:RmlUI Starter Guide

2026-03-06T06:15:42Z

Qrow: Undo revision 2703 by Qrow (talk)

Recoil:RmlUI Starter Guide

2026-03-06T06:02:34Z

Qrow:

{{DISPLAYTITLE:Making A Basic Recoil Game}}
__TOC__

= Making A Basic Recoil Game =

This guide walks you through creating a minimal but functional game with the Recoil engine.
By the end you will have a working game archive that loads in the engine, with a playable Commander unit, a simple weapon, and a basic Lua gadget.
No prior Spring or Recoil experience is assumed, though familiarity with Lua is helpful.

{{warning|1=This guide targets the current Recoil engine. If you are migrating an existing Spring 105 game, see [[Recoil:Migrating From Spring]] for a list of breaking changes.}}

----

== 1. What is Recoil? ==

Recoil is an open-source, cross-platform RTS game engine descended from Spring (which itself descended from Total Annihilation).
It provides out of the box:

* '''Physics simulation''' — projectile trajectories, terrain collision, unit movement
* '''Resource system''' — metal and energy by default, fully customisable
* '''Networking''' — authoritative server, deterministic lockstep simulation, replays
* '''Lua scripting''' — every mechanic is overridable via Lua gadgets and widgets
* '''VFS''' — a virtual file system that loads content from game archives, maps, and basecontent

Your game is a Lua + asset package that rides on top of the engine.
You control the rules, the units, the UI, and everything else; the engine provides the platform.

=== Key terminology ===

{| class="wikitable"
! Term !! Meaning
|-
| '''Game''' || Your content archive loaded by the engine (units, Lua scripts, textures, etc.)
|-
| '''Map''' || The terrain archive (.smf height data + textures). Distributed separately from the game.
|-
| '''Gadget''' || A Lua script that runs game logic (synced or unsynced). Lives in <code>luarules/gadgets/</code>.
|-
| '''Widget''' || A Lua script that runs UI logic. Lives in <code>luaui/widgets/</code>.
|-
| '''Wupget''' || Informal collective term for widgets and gadgets.
|-
| '''Callin''' || A function in your Lua code that the engine calls (e.g. <code>gadget:UnitCreated</code>).
|-
| '''Callout''' || A function the engine exposes to Lua (e.g. <code>Spring.GetUnitPosition</code>).
|-
| '''VFS''' || Virtual File System — unified view of game archive, map archive, basecontent.
|-
| '''Basecontent''' || Engine-bundled archive with default handlers, water textures, and other bare necessities.
|-
| '''.sdd''' || Development game folder (name must end in <code>.sdd</code>). Equivalent to an archive but uncompressed.
|-
| '''.sdz''' || Production game archive (renamed .zip). Faster to distribute and load.
|}

----

== 2. Prerequisites ==

Before starting you need:

# '''The Recoil engine binary.''' Download a pre-built release from [https://github.com/beyond-all-reason/RecoilEngine/releases GitHub Releases] or build from source. The main executable is <code>spring</code> (or <code>spring.exe</code> on Windows).
# '''A map archive''' (<code>.smf</code> / <code>.sd7</code>) placed in the <code>maps/</code> subfolder of your Recoil data directory. Any map from an existing Recoil game works for testing. Map archives and game archives live in separate directories.
# '''A text editor.''' Any editor works. For the best experience, set up the [[Recoil:Lua Language Server|Lua Language Server]] with Recoil type stubs so you get autocomplete on all <code>Spring.*</code> functions.

Your Recoil data directory typically looks like:

<pre>
recoil-data/
├── spring ← engine binary (linux) or spring.exe (windows)
├── spring_headless ← headless binary (no rendering)
├── spring_dedicated ← dedicated server binary
├── games/ ← your game archives / folders go here
├── maps/ ← map archives go here
└── (engine config files)
</pre>

----

== 3. Game Archive Structure ==

During development use an <code>.sdd</code> folder — it's just a normal directory the engine treats as an archive.
Create it inside your <code>games/</code> directory:

<pre>
games/
└── mygame.sdd/
├── modinfo.lua ← required: identifies your game to the engine
├── units/ ← unit definition files
│ └── commander.lua
├── weapons/ ← weapon definition files
│ └── laser.lua
├── features/ ← feature (prop/wreck) definitions
├── gamedata/ ← def pre/post processing, options
│ ├── unitdefs_post.lua
│ └── modrules.lua
├── luarules/
│ └── gadgets/ ← synced and unsynced game logic
│ └── game_end.lua
├── luaui/
│ └── widgets/ ← UI scripts
├── objects3d/ ← unit models (.dae / .obj / .s3o)
├── unittextures/ ← unit icon textures (unitname.png)
└── maps/ ← embedded map resources (optional)
</pre>

{{warning|1=The <code>.sdd</code> extension on the folder name is mandatory. Without it the engine will not recognise it as a game archive.}}

For production, compress the contents into a <code>.sdz</code> (zip) archive or <code>.sd7</code> (7-zip) archive.
The folder contents become the archive root — <code>modinfo.lua</code> should be at the top level.

=== VFS and dependencies ===

Your game archive can declare '''dependencies''' on other archives (including other games) via <code>modinfo.lua</code>.
The engine merges all archives into the VFS.
Files in your game take priority over dependencies.
This means you can build on an existing game without copying its assets.

See [[Recoil:VFS Basics]] for full details on VFS modes and the load order.

----

== 4. modinfo.lua ==

<code>modinfo.lua</code> is the single most important file — without it the engine will not recognise your archive as a game.

<syntaxhighlight lang="lua">
-- games/mygame.sdd/modinfo.lua

local modinfo = {
-- Displayed in lobbies and the engine title bar
name = "My Recoil Game",
-- Short unique identifier used internally; no spaces, keep it stable
shortName = "MRG",
-- Shown to players in lobby browsers and descriptions
description = "A minimal Recoil game for learning purposes.",
-- Semantic version string
version = "0.1.0",
-- Mutator name; leave empty for base games (not mods on top of other games)
mutator = "",
-- Archive names this game depends on; engine always loads basecontent itself
depend = {},
-- Replaces list: names of games this game supersedes in rapid/lobby
replace = {},
-- URL shown in lobby if a player does not have the game
modtype = 1, -- 1 = game/mod, 0 = hidden
-- Primary unit sides available to players
-- These correspond to the "Side" key in start scripts and unit defs
sides = { "MyFaction" },
-- For each side, which unit the engine spawns as the starting unit
startscreens = {
MyFaction = "commander", -- references a unit def name
},
}

return modinfo
</syntaxhighlight>

{{warning|1=<code>shortName</code> must be unique across all games the engine knows about. Pick something distinctive. Changing it later breaks lobby integrations and replays.}}

=== ModOptions.lua ===

To expose configurable options in lobbies (e.g. starting resources, game mode), add a <code>gamedata/ModOptions.lua</code>:

<syntaxhighlight lang="lua">
-- gamedata/ModOptions.lua
-- Returned options appear as sliders/checkboxes/dropdowns in lobby UIs.

return {
{
key = "startmetal",
name = "Starting Metal",
desc = "Amount of metal each player starts with.",
type = "number",
def = 1000,
min = 0,
max = 10000,
step = 100,
},
{
key = "commanderdie",
name = "Commander Death Ends Game",
desc = "Lose when your Commander is destroyed.",
type = "bool",
def = true,
},
}
</syntaxhighlight>

Options are readable in gadgets via <code>Spring.GetModOptions()</code>.

----

== 5. Your First Unit Definition ==

Unit defs are Lua files in <code>units/</code> that return a table of unit type definitions.
The convention is one unit per file, where the filename matches the unit def name.

<syntaxhighlight lang="lua">
-- units/commander.lua
-- The starting unit for the MyFaction side.

return {
commander = {
-- ── Display ──────────────────────────────────────────────────
name = "Commander",
description = "The starting unit. Its death ends the game.",
-- Path to the icon shown in the unit HUD (unittextures/commander.png)
buildPic = "commander.png",

-- ── Model ────────────────────────────────────────────────────
-- Path inside the archive (objects3d/commander.dae)
objectName = "commander.dae",

-- ── Physics ──────────────────────────────────────────────────
-- Maximum health points
health = 3000,
-- Armour class name; controls damage reduction from weapon types
armorType = "commander",
-- Size of the footprint in map squares (8 elmos each)
footprintX = 2,
footprintZ = 2,
-- The height of the collision sphere
collisionVolumeScales = "30 50 30",
collisionVolumeType = "ellipsoid",

-- ── Movement ─────────────────────────────────────────────────
-- Movement class name; references a MoveClass def (see MoveClasses below)
moveDef = {
family = "tank",
-- Units above this slope can't be traversed
maxSlope = 36,
-- Turns per second at max speed
turnRate = 1024,
},
-- Maximum speed in elmos/second
maxVelocity = 42,
-- Acceleration in elmos/second²
maxAcc = 0.5,
-- Braking in elmos/second²
maxDec = 1.5,

-- ── Construction ─────────────────────────────────────────────
-- How many build power units this unit provides
workerTime = 200,
-- How much metal it costs to build
buildCostMetal = 0, -- Commanders are free (spawned by engine)
buildCostEnergy = 0,
-- Build time in seconds at 1 build power
buildTime = 1,

-- ── Energy and Metal Production ───────────────────────────────
metalMake = 1, -- passively trickles 1 metal/second
energyMake = 20, -- passively generates 20 energy/second

-- ── Weapons ──────────────────────────────────────────────────
-- Up to 3 weapons can be listed; name references a weapon def
weapons = {
{ def = "COMMANDER_LASER" },
},

-- ── Self-Destruct ─────────────────────────────────────────────
selfDExplosion = "commander_sdc", -- optional; a weapon def name

-- ── Misc ─────────────────────────────────────────────────────
-- Used in start scripts to assign this unit as Commander
commander = true,
-- Sight radius in elmos
sightDistance = 660,
-- Radar range in elmos (0 = no radar)
radarDistance = 0,
},
}
</syntaxhighlight>

{{warning|1=Key names in unit def files are '''case-insensitive''' as far as the engine is concerned, but Lua itself is case-sensitive. Adopt a consistent convention (all lowercase is common) and use <code>lowerkeys()</code> in <code>gamedata/unitdefs_post.lua</code> if you mix styles.}}

=== Notable unit def keys ===

{| class="wikitable"
! Key !! Type !! Notes
|-
| <code>name</code> || string || Display name in UI. Not the def name (the Lua table key).
|-
| <code>health</code> || number || Max HP.
|-
| <code>moveDef</code> || table || Inline move class definition. See engine docs for all fields.
|-
| <code>maxVelocity</code> || number || Elmos per second. 1 elmo ≈ 8 map height units.
|-
| <code>buildCostMetal</code> || number || Metal cost. Constructor must have enough resources to start building.
|-
| <code>buildTime</code> || number || Seconds to build at 1 build power. Actual time = buildTime / workerTime.
|-
| <code>workerTime</code> || number || Build power this unit contributes when constructing.
|-
| <code>weapons</code> || table || Up to 3 entries; each entry is a table with a <code>def</code> key naming a WeaponDef.
|-
| <code>commander</code> || bool || Marks this unit as a Commander. Lobby UI and engine use this.
|-
| <code>customParams</code> || table || Arbitrary key/value pairs preserved by the engine for gadget use.
|}

For the full list of unit def keys and their effects, see the [https://beyond-all-reason.github.io/spring/ldoc/ Recoil Lua API documentation].

=== Def pre- and post-processing ===

The engine reads <code>gamedata/defs.lua</code> (provided by basecontent) which orchestrates def loading.
It first executes <code>gamedata/unitdefs_pre.lua</code> (if present) to populate a <code>Shared</code> table visible to all unit def files, then loads every <code>units/*.lua</code> file, and finally runs <code>gamedata/unitdefs_post.lua</code>.

<syntaxhighlight lang="lua">
-- gamedata/unitdefs_post.lua
-- Normalize key casing and apply game-wide tweaks.

for _, unitDef in pairs(UnitDefs) do
-- lowerkeys() is provided by basecontent; makes all keys lowercase
lowerkeys(unitDef)
end

-- Example: give all units 10% extra health
for _, unitDef in pairs(UnitDefs) do
if unitDef.health then
unitDef.health = unitDef.health * 1.1
end
end
</syntaxhighlight>

{{warning|1=The <code>UnitDefs</code> table inside gadgets/widgets is '''not the same''' as the one in post-processing. After loading, the engine parses the def tables into internal structures and re-exposes them with different key names and value scales. Never copy-paste keys between def files and wupget code.}}

----

== 6. Weapon Definitions ==

Weapon defs follow the same pattern as unit defs — Lua files in <code>weapons/</code> returning tables.

<syntaxhighlight lang="lua">
-- weapons/laser.lua

return {
COMMANDER_LASER = {
name = "Commander Laser",
description = "Short-range direct-fire laser.",

-- Weapon category controls which targets it can engage
-- Options: ground, air, sea, land, building, etc. (combinable)
onlyTargetCategory = "SURFACE",

-- ── Visuals ───────────────────────────────────────────────────
-- Weapon class drives the physics model
-- Options: Cannon, LaserCannon, MissileLauncher, AircraftBomb,
-- BeamLaser, LightningCannon, Flame, TorpedoLauncher, ...
weaponType = "LaserCannon",
-- Colour of the beam/tracer (R G B A each 0-255)
rgbColor = "1 0.2 0.2",
-- Colour at the other end of the beam (optional)
rgbColor2 = "1 0.9 0.9",
-- Visual length of the laser beam in elmos
beamtime = 1,
-- Thickness of the beam in pixels
thickness = 3,
corethickness = 0.3,
laserflaresize = 8,

-- ── Ballistics ────────────────────────────────────────────────
-- Projectile/beam speed in elmos/second
projectilespeed = 800,
-- Range in elmos
range = 350,
-- Reload time in seconds
reloadtime = 1.5,
-- Burst: number of shots per fire command
burst = 1,
-- Spread in degrees (0 = perfectly accurate)
accuracy = 0,

-- ── Damage ────────────────────────────────────────────────────
damage = {
-- 'default' applies to all armour types not explicitly listed
default = 50,
},
-- Area of effect in elmos (0 = single target)
areaOfEffect = 8,
-- Impulse applied to targets on hit (0 = none)
impulse = 0,
-- Does this weapon set things on fire?
firestarter = 0,
},
}
</syntaxhighlight>

Like unit defs, you can post-process weapon defs via <code>gamedata/weapondefs_post.lua</code>.

----

== 7. Feature Definitions ==

Features are non-commandable props: trees, rocks, wrecks, and so on.
They occupy the map by default via map configuration, or can be spawned by Lua.
A minimal feature def:

<syntaxhighlight lang="lua">
-- features/trees.lua

return {
tree = {
description = "A tree.",
-- Model to render
object = "tree.dae",
-- Health before the feature is destroyed
damage = 50,
-- Metal reclaimed when a constructor takes it apart
metal = 0,
-- Energy reclaimed when destroyed or reclaimed
energy = 0,
-- Blocks ground unit pathfinding
blocking = true,
-- Visible on radar/sonar
geoThermal = false,
-- What this feature becomes when destroyed (nil = nothing)
deathFeature = "",
-- Whether this can be reclaimed by a constructor
reclaimable = true,
},
}
</syntaxhighlight>

----

== 8. Game Rules (modrules.lua) ==

<code>gamedata/modrules.lua</code> is read by basecontent's <code>defs.lua</code> to configure fundamental engine behaviour that is not driven by unit/weapon defs.

<syntaxhighlight lang="lua">
-- gamedata/modrules.lua

return {
system = {
-- Starting resources (also overridable via ModOptions / start script)
startMetal = 1000,
startEnergy = 1000,

-- Maximum units per team (0 = unlimited)
maxUnits = 1000,

-- Commander handling: 0 = game continues, 1 = game ends, 2 = lineage
gameMode = 1,

-- Limit on repair speed (% of max health per second; 0 = unlimited)
repairSpeed = 0,

-- Whether resurrect restores health
resurrectHealth = false,

-- Resource multiplier for reclaiming metal from living units
reclaimUnitMethod = 1,

-- Whether ground features leave wrecks
featureDeathResurrect = true,
},
sound = {
-- Optional: override specific engine sound events
},
}
</syntaxhighlight>

----

== 9. Running Your Game ==

The engine is launched with a '''start script''' — a plain text file (conventionally <code>.sdf</code>) that describes who is playing, which game, and which map.

=== Minimal start script ===

<syntaxhighlight lang="ini">
[GAME]
{
GameType = My Recoil Game; -- must match modinfo.lua name or shortName
MapName = my_map.smf; -- the .smf file inside the map archive

IsHost = 1;
MyPlayerName = Dev;

[PLAYER0]
{
Name = Dev;
Password = ;
Spectator = 0;
Team = 0;
}

[TEAM0]
{
TeamLeader = 0;
AllyTeam = 0;
RgbColor = 0.1 0.4 1.0;
Side = MyFaction; -- must match a side declared in modinfo.lua
StartPosX = 4000;
StartPosZ = 4000;
}

[ALLYTEAM0]
{
NumAllies = 0;
}
}
</syntaxhighlight>

Save this as <code>game.sdf</code> in your Recoil data directory, then launch:

<pre>
./spring game.sdf
</pre>

On Windows:

<pre>
spring.exe game.sdf
</pre>

The engine will:
# Read the start script
# Mount your game archive from <code>games/mygame.sdd</code>
# Mount the map archive from <code>maps/my_map.sd7</code>
# Load basecontent (default widget handlers, etc.)
# Start the simulation and call into your Lua scripts

{{warning|1=If the engine cannot find your game archive, check that the folder name ends in exactly <code>.sdd</code> (case-sensitive on Linux) and that <code>modinfo.lua</code> is at the root of that folder, '''not''' in a subfolder.}}

=== Quick test with headless ===

For automated testing (or when you don't need graphics), use the headless binary:

<pre>
./spring_headless game.sdf
</pre>

Widgets still run, so you can run AI vs AI matches or data-gathering scripts without a window.

----

== 10. Lua Scripting Basics ==

Lua is the scripting language for everything above the C++ engine layer.
The engine provides several isolated Lua environments:

{| class="wikitable"
! Environment !! Location !! Purpose
|-
| '''LuaRules''' (synced) || <code>luarules/main.lua</code> || Authoritative game logic. Desync if misused.
|-
| '''LuaRules''' (unsynced) || <code>luarules/draw.lua</code> || Unsynced effects and UI driven by game logic.
|-
| '''LuaUI''' || <code>luaui/main.lua</code> || Player-facing UI: HUD, minimap overlays, etc.
|-
| '''LuaGaia''' || <code>luagaia/main.lua</code> || Logic for the neutral Gaia team (wrecks, features, world events).
|-
| '''LuaIntro''' || <code>luaintro/main.lua</code> || Loading screen, briefings.
|-
| '''LuaMenu''' || <code>luamenu/main.lua</code> || Main menu (pre-game). Requires a menu archive.
|}

Basecontent provides default <code>main.lua</code> entry points and wupget handler boilerplate so you can start writing gadgets and widgets without building the handler yourself.

=== Your first gadget ===

A gadget is a Lua file the gadget handler loads from <code>luarules/gadgets/</code>.

<syntaxhighlight lang="lua">
-- luarules/gadgets/game_end.lua
-- Ends the game when a player's Commander is destroyed.

local gadget = gadget ---@type Gadget

function gadget:GetInfo()
return {
name = "Game End Conditions",
desc = "Ends the game on Commander death.",
author = "YourName",
date = "2025",
license = "GNU GPL, v2 or later",
layer = 0,
enabled = true,
}
end

-- Only run the logic in synced mode
if not gadgetHandler:IsSyncedCode() then return end

-- Track alive Commanders per team
local commanderByTeam = {}

function gadget:UnitFinished(unitID, unitDefID, teamID)
local def = UnitDefs[unitDefID]
-- UnitDefs inside wupgets is indexed by numeric ID, not name
if def and def.isCommander then
commanderByTeam[teamID] = unitID
end
end

function gadget:UnitDestroyed(unitID, unitDefID, teamID)
if commanderByTeam[teamID] == unitID then
commanderByTeam[teamID] = nil
-- Check whether any other living Commander still belongs to this allyteam
local allyTeamID = Spring.GetTeamAllyTeamID(teamID)
local hasCommander = false
for _, ally in ipairs(Spring.GetTeamList(allyTeamID)) do
if commanderByTeam[ally] then
hasCommander = true
break
end
end
if not hasCommander then
-- GameOver sends the end-of-game event to all clients
Spring.GameOver({ allyTeamID })
end
end
end
</syntaxhighlight>

=== Your first widget ===

A widget is a Lua file the widget handler loads from <code>luaui/widgets/</code>.

<syntaxhighlight lang="lua">
-- luaui/widgets/resources_display.lua
-- Draws current metal and energy income in the corner of the screen.

local widget = widget ---@type Widget

function widget:GetInfo()
return {
name = "Resources Display",
desc = "Shows current resource income.",
author = "YourName",
date = "2025",
license = "GNU GPL, v2 or later",
layer = 0,
enabled = true,
}
end

function widget:DrawScreen()
local metal, energy = Spring.GetTeamResources(Spring.GetMyTeamID())
if not metal then return end

gl.Color(1, 1, 1, 1)
gl.Text(string.format("Metal: %.0f Energy: %.0f", metal, energy),
10, 40, 16, "s")
end
</syntaxhighlight>

=== Callins and callouts ===

'''Callins''' are functions in your code the engine calls at the right moment: <code>UnitCreated</code>, <code>UnitDestroyed</code>, <code>GameOver</code>, <code>DrawScreen</code>, <code>Update</code>, etc.
Check the full list at runtime with <code>Script.GetCallInList()</code>.

'''Callouts''' are <code>Spring.*</code> functions you call out to the engine: <code>Spring.GetTeamResources</code>, <code>Spring.GiveOrderToUnit</code>, <code>Spring.Echo</code>, etc.
Full documentation is at [https://beyond-all-reason.github.io/spring/ldoc/ beyond-all-reason.github.io/spring/ldoc/].

{{warning|1=Synced gadgets have strict rules — only call synced-safe functions. Calling unsynced functions from synced code causes a desync error. When in doubt, check <code>gadgetHandler:IsSyncedCode()</code> and gate appropriately.}}

=== Communicating between environments ===

The Lua environments are isolated from each other by design.
Common bridges:

{| class="wikitable"
! Method !! Direction !! Notes
|-
| <code>WG</code> / <code>GG</code> table || Within one environment || Widgets share <code>WG</code>; gadgets share <code>GG</code>.
|-
| <code>SendToUnsynced</code> / <code>RecvFromSynced</code> || Synced → Unsynced || Pass data from game logic to rendering/UI.
|-
| <code>Spring.SendLuaRulesMsg</code> / <code>gadget:RecvLuaMsg</code> || LuaUI → LuaRules || UI triggers a game action beyond unit orders.
|-
| <code>Spring.SendLuaUIMsg</code> / <code>widget:RecvLuaMsg</code> || LuaUI ↔ LuaUI (all players) || Broadcast UI state to other players.
|-
| Rules params (<code>Spring.SetRulesParam</code>) || LuaRules → all || Expose synced data as read-only key/values.
|}

See [[Recoil:Wupget Communication]] for detailed examples.

----

== 11. Useful Debug Commands ==

In-game chat commands prefixed with <code>/</code> control engine and game state.
With cheats enabled (<code>/cheat</code>) additional commands become available:

{| class="wikitable"
! Command !! Effect
|-
| <code>/cheat</code> || Toggle cheats on/off. Required for most debug commands.
|-
| <code>/give [unitname]</code> || Spawn a unit at the cursor position.
|-
| <code>/destroy</code> || Destroy selected units immediately.
|-
| <code>/invincible</code> || Toggle invincibility for selected units.
|-
| <code>/godmode</code> || Toggle god mode (all units obey all players).
|-
| <code>/speed [x]</code> || Set game speed multiplier (e.g. <code>/speed 5</code>).
|-
| <code>/nopause</code> || Disallow pausing.
|-
| <code>/luarules reload</code> || Reload LuaRules scripts without restarting.
|-
| <code>/luaui reload</code> || Reload LuaUI scripts without restarting.
|-
| <code>/editdefs</code> || Enter def-editing mode (requires cheats). See unit def docs.
|-
| <code>Spring.Echo("msg")</code> || Print a message to the in-game console from Lua.
|}

----

== 12. Maps and Map Integration ==

Maps are separate archives (<code>.sd7</code> or <code>.sdz</code>) placed in <code>maps/</code>.
They are not shipped with your game.
The map defines the terrain height data (<code>.smf</code>), sky, water, and can optionally define starting metal spots and features.

=== Controlling what maps do to your game ===

Maps can include a <code>mapinfo.lua</code> which may set atmosphere, gravity, and other properties.
A map can also override unit def values via <code>MapOptions.lua</code>, which your game can read with <code>Spring.GetMapOptions()</code>.

You can '''restrict which maps are compatible''' by checking map properties in a gadget at startup and calling <code>Spring.GameOver</code> if requirements are not met.

=== Metal spots ===

Metal spots (mexes) are typically defined in the map as SMF/SMD metal map data, or via a Lua file in the map archive.
Your gadgets can read them with <code>Spring.GetMetalMapSize()</code> and <code>Spring.ExtractorInRangeMetalMap()</code>.
Extractor units that generate metal must have a <code>extractsMetal</code> unit def key > 0 and be placed over a metal spot.

----

== 13. Packaging and Distribution ==

When your game is ready for distribution, compress the <code>.sdd</code> folder contents into an <code>.sdz</code> (zip) or <code>.sd7</code> (7-zip) file.

<pre>
# Linux: create .sdz (zip)
cd games/mygame.sdd
zip -r ../mygame-0.1.0.sdz .

# Linux: create .sd7 (7-zip, better compression)
cd games/mygame.sdd
7z a ../mygame-0.1.0.sd7 .
</pre>

{{warning|1=Make sure <code>modinfo.lua</code> ends up at the '''root''' of the archive, not inside a subfolder. Some zip tools create an extra folder level automatically.}}

=== Rapid ===

[https://github.com/beyond-all-reason/rapid Rapid] is the standard package distribution system for Recoil games.
It allows lobby clients (e.g. Chobby) to download and update games automatically.
See the Rapid documentation and the [https://github.com/beyond-all-reason/RecoilEngine/blob/master/doc/site/content/articles/start-script-format.md start script format] for integration details.

----

== 14. Next Steps ==

With a working minimal game, the typical next steps are:

; '''More unit types'''
: Add builders, resource extractors, power generators, turrets, and mobile combat units. Follow the same unit def pattern — each is a Lua file in <code>units/</code>.

; '''Resource extractors'''
: A unit with <code>extractsMetal > 0</code> placed over a metal spot generates metal. Add an energy converter unit to turn metal into energy and vice versa.

; '''Pathfinding and MoveClasses'''
: Define <code>movedefs</code> in <code>gamedata/movedefs.lua</code> to control how different unit types traverse terrain (hover, boat, amphibious, kbot, tank, aircraft).

; '''AI support'''
: The Skirmish AI interface lets players add bot opponents without any extra gadget work. Beyond that, you can write a [[https://springrts.com/wiki/Lua_AI Lua AI]] for fully custom bot behaviour inside your game's Lua scripting.

; '''Full UI'''
: The basecontent widget handler gives you a basic HUD for free. For a polished interface use [[Recoil:RmlUI Starter Guide|RmlUI]] for HTML/CSS-style widgets, or raw OpenGL via <code>gl.*</code> callouts.

; '''Maps'''
: Creating your own map requires tools like [https://github.com/beyond-all-reason/MapConv MapConv] (height and texture compilation) and [https://springrts.com/wiki/SpringMapEdit SpringMapEdit]. See the Recoil map documentation for details.

; '''Replays and dedicated servers'''
: Replays are recorded automatically when <code>RecordDemo=1</code> is set in the start script. For large-scale multiplayer use the dedicated binary (<code>spring_dedicated</code>) and an autohost such as [https://springrts.com/wiki/SPADS SPADS] or [https://springrts.com/wiki/Springie Springie].

----

== 15. Further Reading ==

=== On this wiki ===

* [[Recoil:VFS Basics]] — full documentation of the Virtual File System, modes, and load order
* [[Recoil:Unit Types Basics]] — deep dive into unit defs, post-processing, and the wupget-facing UnitDefs table
* [[Recoil:Widgets and Gadgets]] — the addon (wupget) system in full detail
* [[Recoil:Wupget Communication]] — how to pass data between Lua environments
* [[Recoil:RmlUI Starter Guide]] — reactive HTML/CSS-style UI for your game
* [[Recoil:Headless and Dedicated]] — server binaries and automated testing
* [[Recoil:Migrating From Spring]] — for existing Spring 105 games

=== External resources ===

* [https://beyond-all-reason.github.io/spring/ldoc/ Recoil Lua API reference] — complete callout/callin documentation
* [https://github.com/beyond-all-reason/RecoilEngine RecoilEngine on GitHub] — source, releases, and issue tracker
* [https://recoilengine.org/ recoilengine.org] — official website with downloads and changelog
* [https://discord.gg/recoil Recoil Discord] — community support and engine developer discussions
* [https://springrts.com/wiki/Simple_Game_Tutorial Spring Simple Game Tutorial] — older but still broadly applicable tutorial (Spring and Recoil are highly compatible)

[[Category:Guides]]
[[Category:Recoil]]
[[Category:Game Development]]

Recoil

2026-03-06T06:01:55Z

Qrow:

<div style="text-align: center;">
<h2 data-notoc="">Recoil is a battle tested open-source RTS engine that, allied with a flexible Lua API, allows you to implement the perfect UI and mechanics for your game with the ability to support thousands of complex units simultaneously.</h2>
</div>

{{Note|text=Recoil is a recent hard fork of [Spring](https://github.com/spring/spring) from the [105 tree](https://github.com/spring/spring/releases/tag/105.0.1), many references to it might and will be present. Overall most documented Spring API and tutorials are compatible with Recoil since they are based on the 105 tree.}}

{|border="0" cellpadding="4" cellspacing="1"
| width="50%" valign="top" |
== For Players ==

=== Content ===
'''[[Recoil Games]]''' Games that use the Recoil engine.

'''[[Maps]]''' All about maps for the Spring engine and where to get them.

'''[[Getting Recoil Content]]''' Sites from which you can download spring Games, Maps, and more.

'''[[AI:Skirmish|AIs]]''' Skirmish AIs for Singleplayer.

'''[[Lua Widgets]]''' All about installing and using LuaUI widgets.

'''[[Recoil:Replays|Replays]]''' Watching recordings of previously played matches.

'''[[Community:Recoil| Community]]''' Documents that shape our online community.

=== Help ===

'''[[FAQ]]''' Has it been asked before?

'''[[Hosting Recoil]]''' Autohosting and related topics.

'''[[Spring_on_MacOSX |Mac OS]]''' Mac OSX information.

'''[[SetupGuide |Linux]]''' NetBSD / Solaris / Linux / Cross-platform information.

| width="50%" valign="top" |
== For Developers ==

=== Content Development ===

'''[[Gamedev:Main|Game Development]]''' Lots of links to valuable Articles and forum threads regarding Game/Unit Development.

'''[[Mapdev:Main|Map Development]]''' Tutorials and other useful information for creating maps.

'''[[Lua Scripting]]''' Information regarding the use of the supplementary Lua scripting language for Widgets and beyond.

'''[[Chili|Chili UI framework]]''' Framework for creating GUIs in Lua.

'''[[Map, Mod, And Unit Development Programs|Content Development Programs]]''' Links to all kind of useful programs.

'''[[General Resources]]''' Usable textures, sounds and code snippets by the community, for the community.

'''[[Associated Development Groups]]''' Teams, Forums and Groups associated with Spring content and code development.

=== Engine and Native Development ===

'''[[Development:Getting_Started|Engine Development]]''' Starting point for engine development.

'''[[Building spring|Compiling Engine]]''' How to build the Spring engine from source.

'''[[Lobby_Development|Lobby Development (Clients and Servers)]]''' Information regarding contributing to the source code of the different lobby clients and servers available for Spring.

'''[[AI:Development|AI Development]]''' Lots of information about developing Skirmish, and Unit AIs for Spring.

|}

{||
|
=This wiki needs your help!=

''"A wiki is a web application that allows users to add content, as on an Internet forum, but also allows anyone to edit the content."''
- [http://en.wikipedia.org/wiki/Wiki Wikipedia.org]

The Spring project is very dependent on its community of users to help new players and developers. [[FightOrderEditing|Learn more here.]]

|}

{| |
|

__NOTOC__
__NOEDITSECTION__
[[Category:Spring]]

Hosting Spring/Springie

2026-03-06T05:55:27Z

Qrow: Created page with "Springie is an Autohost for Spring, it creates a battleroom and starts automatically when enough people have joined. It also reacts to a number of chat commands. ==Requirements== *Spring *Open UDP Port *Springie ==Using== Springie is easy to use but you will need an open UDP port to be able to host a game. You can download it using the link at the end of the page, no install is required. ===Creating=== After opening an UDP port, you need to create a new account fo..."

[[Springie]] is an Autohost for Spring, it creates a battleroom and starts automatically when enough people have joined. It also reacts to a number of chat commands.

==Requirements==
*Spring
*Open UDP Port
*Springie

==Using==
Springie is easy to use but you will need an open UDP port to be able to host a game. You can download it using the link at the end of the page, no install is required.

===Creating===
After opening an UDP port, you need to create a new account for the bot and ask a GO (Game Operator) to put a bot flag on it. Now you only need to log in with Springie and configure the map and other settings!

'''''Note:''' Spring changes Spring settings to 40 x 40 pixels and windowed mode, so if you want to play you will need to reconfigure it.''

===Commands===
'''HELP''''

*!help - lists the commands that are available to you
*!helpall - lists all commands (sorted by their level) - you may not be able to use all of them

'''COMMUNICATION'''
*!ring [<filters>..]- rings either all unready or specified users
*!say - allows you to talk between lobby and game (not needed if chat is enabled)
*!notify - Springie will notify you when game ends

'''TEAM AND ALLY MANAGEMENT'''
*!fix - fixes teamnumbers
*!fixcolors - fixes team colors (similar colors are changed)
*!random [<allycount>] - assigns people to <allycount> alliances (default: 2 alliances)
*!balance [<allycount>] - scans all ally combinations and randomly chose one which is balanced (eg regarding ranks) (warning: not tested for large teams, might take a long time)
*!cbalance [<allycount>] - assigns people to allycount random balanced alliances, attempting to put clanmates on the same alliance
*!ally <allynum> [<player>..] - forces ally number
*!team <teamnum> [<player>..] - forces team number
*!spec <username> - forces a player to become spectator
*!specafk - forces all AFK players to become spectators

'''GAME CONTROL'''
*!start - starts game (checks for duplicate team numbers and ally fairness)
*!forcestart - overrides ordinary !start checks (duplicate team numbers and ally fairness)
*!force - makes spring force start (ctrl+enter in-game)
*!exit - exits the game
*!manage <minplayer> [<maxplayers>] - automanage game for min to max players. If minplayers is 0, it won't manage. In this mode, Springie keeps alliances even, colors fixed, autorings and spec afk or even kicks them.

'''VOTING'''
*!voteforcestart - starts vote to execute !forcestart
*!voteforce - starts vote to force (in-game)
*!voteexit - starts vote to exit game
*!votekick [<filters>] - starts vote to kick player
*!votemap [<filters>] - starts vote for given map
*!voterehost [<filter>] - starts vote to rehost the game
*!votepreset [<presetname>..] - starts a vote to apply the given preset
*!voteboss <name> - sets <name> as a new boss, use without parameter to remove any current boss. If there is a boss on server, other non-admin people have their rights reduced
*!votekickspec - starts a vote to enables or disable automatic spectator kicking
*!votesetoptions <name>=<value>[,<name>=<value>] - starts a vote to apply the given option(s)
*!vote <number> - casts your vote (you must say it in battle window)
*!endvote - ends current poll

'''BATTLE LOCKING'''
*!lock - locks battle
*!unlock - unlocks battle
*!autolock [<players>] - sets desired number of players in game. If this number is reached, Springie will lock the server, and if someone leaves, it will unlock it again. !autolock without parameter disables auto locking.

'''PRESETS'''
*!listpresets [<presetname>..] - lists all the known presets (with name filtering)
*!presetdetails [<presetname>..] - shows the details of the given preset
*!preset [<presetname>..] - applies the given preset to current battle

'''BOXES'''
*!addbox <left> <top> <width> <height> [<number>] - adds a new box rectangle
*!clearbox [<number>] - removes a box (or removes all boxes if no number is specified)
*!split <"h"/"v"> <percent> - makes 2 boxes in h or v direction
*!corners <"a"/"b"> <percent> - makes 4 corners, a/b determines ordering

'''MAPS'''
*!listmaps [<filters>] - lists maps (can apply filtering)
*!map <filters> - changes map, and prints the new maplink in the battle
*!maplink - looks for map links on unknown files
*!dlmap <mapname/dllid/url> - downloads map to server. You can either specify map name or map id (from unknown files) or map URL

'''MODS'''
*!listmods [<filters>] - lists mods (can apply filtering)
*!modlink - looks for mod links on unknown files
*!dlmod <modname/dllid/url> - downloads mod to server. You can either specify mod name or mod id (from unknown files) or mod URL
*!rehost [<filter>] - rehosts game (optionally with new mod)
*!listoptions - lists all mod options
*!setoptions <name>=<value>[,<name>=<value>] - applies mod/map options

'''ADMINISTERING'''
*!admins - list privileged users
*!boss <name> - sets <name> as a new boss, use without parameter to remove any current boss. If there is a boss on server, other non-admin people have their rights reduced.
*!kick <filters> - kicks specified players from server (both game and lobby)
*!setlevel <username> <level> - sets rights level for given player
*!ban <username> [<duration>] [<reason>...] - bans user username for duration (in minutes) with given reason. Duration 0 = ban for 1000 years
*!unban <username> - unbans user
*!listbans - lists currently banned users
*!reload - reloads mod and map list
*!kickspec [0|1] - enables or disables automatic spectator kicking
*!mincpuspeed <GHz> - sets minimum CPU for this host - players with CPU speed below this value are auto-kicked, 0 = no limit
*!setpassword <newpassword> - sets server password (needs !rehost to apply)
*!setminrank <minrank> - sets server minimum rank (needs !rehost to apply)
*!setmaxplayers <maxplayers> - sets server size (needs !rehost to apply)
*!setgametitle <new title> - sets server game title (needs !rehost to apply)
*!springie - displays basic springie information
*!cheats - enables/disables .cheats in game

'''STATISTICS'''
*!stats - lists various stats
*!smurfs - lists smurfs

==Links==
*[http://spring.clan-sy.com/phpbb/viewtopic.php?t=7921 Springie Topic]

[[Category: Autohosts]]

Hosting Spring/Autohost

2026-03-06T05:55:08Z

Qrow: Redirected page to Hosting Spring/Springie

#REDIRECT [[Hosting Spring/Springie]]

Ubuntu install

2026-03-06T05:54:06Z

Qrow: Created page with "Linux Setup Guide < {{FULLPAGENAME}} __TOC__ Image:Ubuntulogo.png packages are available for: 12.10, 12.04, 11.04, 10.10, 10.04, 9.10, 9.04, 8.10 For packaging <font color="#00DD00">requests</font> or <font color="#FF0000">complaints</font>, please contact the packagers. = Ubuntu 9.10 and newer = 10.04 & 10.10 have propretary drivers for ATI & Nvidia GPU's in the menu aplication / system / additionnal drivers (they are not..."

[[Linux|Linux Setup Guide]] < {{FULLPAGENAME}}

__TOC__
[[Image:Ubuntulogo.png]]

packages are available for: 12.10, 12.04, 11.04, 10.10, 10.04, 9.10, 9.04, 8.10

For packaging <font color="#00DD00">requests</font> or <font color="#FF0000">complaints</font>, please contact [[Linux:Packaging#Ubuntu | the packagers]].

= Ubuntu 9.10 and newer =

10.04 & 10.10 have propretary drivers for ATI & Nvidia GPU's in the menu aplication / system / additionnal drivers (they are not free but mandatory if spring is very slow and the ground of the map ingame is full white );
ATI catalyst config panel ask password for be edited but always get a bad password error for open it it need to open console and write :" sudo amdcccle "then that will ask the password and accept it

== Installation Instructions ==
Go to ''Applications - Ubuntu Software Center'', search for ''springlobby'' and click go.
If you want to be able to play online, see [[#Updating to newer releases|the next section]].

== Updating to newer releases ==
Go to ''System - Administration - Software Sources'', click the Other tab, click ''Add''. Type '''ppa:spring/ppa''' and close the window. Allow it to reload the packages, and you will find the new version of Spring and Spring Lobby in update manager.

If you're running Ubuntu 10.10, see "Missing repositories in Ubuntu 10.10 on this help page for software sources: https://help.ubuntu.com/community/Repositories/Ubuntu.

= Ubuntu 9.04 and 8.10 =
We now have a maintained and up to date APT repository for Ubuntu 9.04 (Jaunty) and 8.10 (Intrepid). If you have some older version of Ubuntu, you can easily upgrade with these instructions: http://www.ubuntu.com/getubuntu/upgrading.

You will need to add the Spring PPA below and install the ''springlobby'' package. Or you can upgrade to Ubuntu 9.10 and just install the ''springlobby'' package from the new Software Center.

== Installing the repository key ==
First, we need to add the Launchpad PPA package-signing key; this allows Ubuntu to know the packages have been provided by the right people can can be trusted to be installed. If you skip this step then Ubuntu will complain about an unverifiable package every time there's an update for Spring.

Go to:
[http://keyserver.ubuntu.com:11371/pks/lookup?op=get&search=0xFC66403D8670A035]

Cut and paste the page contents to a file called ''ppa-spring.pgp'' or something recognizable like that. Do not use ''Save As'' in your browser, as this will likely not work because of added HTML formatting. You can use ''Applications - Accessories - Text Editor'' to copy&paste into and save to disk.

Security-conscious people can go to the Spring Developers PPA page at [https://launchpad.net/~spring/+archive/ppa launchpad.net] to verify that the key mentioned above is indeed the right one to trust.

Now go to ''System - Administration - Software Sources'' and click on the ''Authentication'' tab to add the saved ''ppa-spring.pgp'' with the ''Import Key File'' button. The new key should now pop up in the list.

== Installing the repository ==
In ''System - Administration - Software Sources'', click on the ''Third-Party Software'' tab. Then, click the ''Add'' button, and paste one of the two lines corresponding to your Ubuntu release (9.04 or 8.10).

'''Ubuntu 9.04 "Jaunty Jackalope"''':
<code><pre>
deb http://ppa.launchpad.net/spring/ubuntu jaunty main
</pre></code>

'''Ubuntu 8.10 "Intrepid Ibex"''':
Note: Please note if out of date. (It i easy enough to try.)
<code><pre>
deb http://ppa.launchpad.net/spring/ubuntu intrepid main
</pre></code>

Close the dialog, and click on ''Reload'' when it asks.

After that is done, you can just [http://springoo.mooo.com CLICK HERE TO INSTALL EVERYTHING]. Alternatively, you can head to ''System - Administration - Synaptic Package Manager'', and search for ''spring''. For the bare essentials, you will need to install the ''spring-engine'' and ''springlobby'' packages.

SpringLobby can be found in ''Applications - Games'' after install. (Please note that you also need mods and maps to play. The easiest way to get them is to download them from within SpringLobby itself.

= Alternative installation using the terminal =
Press ''Alt-F2'' to run a command. Enter:

<code><pre>
gksudo -- wget -O - "http://keyserver.ubuntu.com:11371/pks/lookup?op=get&search=0xFC66403D8670A035" | \
apt-key add -
</pre></code>

This will add the Spring-Developers PPA package-signing key to the list of keys that Ubuntu should trust for software packages. (See above for more info).

==Ubuntu 10.10 and newer==
<code><pre>
sudo add-apt-repository ppa:spring
sudo apt-get update
sudo apt-get install spring
</pre></code>

==Older==

Then do:
<code><pre>
gksudo gedit /etc/apt/sources.list.d/springproject.list
</pre></code>

Copy and paste the following into the file:

===Ubuntu 9.04:===
<code><pre>
deb http://ppa.launchpad.net/spring/ubuntu jaunty main
deb-src http://ppa.launchpad.net/spring/ubuntu jaunty main
</pre></code>

===Ubuntu 8.10:===
<code><pre>
deb http://ppa.launchpad.net/spring/ubuntu intrepid main
deb-src http://ppa.launchpad.net/spring/ubuntu intrepid main
</pre></code>

Save the file. You can then either use the graphical package manager Synaptic (''System - Administration - Synaptic Package Manager'') and search for ''spring'' related packages, or just install spring from a terminal using:
<code><pre>
sudo apt-get update
sudo apt-get install spring spring-maps-default
</pre></code>

== Other information ==
You can view the web page for the repository [https://edge.launchpad.net/~spring/+archive here]. Additional packages (such as one for Kernel Panic) are there as well.

The package installs the Spring executable at <code>/usr/games/spring</code> and read-only data in <code>/usr/share/games/spring</code>.

= See Also: =
* [[Finalizing_linux_install]]
* [[Troubleshooting_linux]]

[[Category: Linux]]

LINUX:SetupSpringie

2026-03-06T05:53:36Z

Qrow: Created page with "= Basics = Springie is a standalone windows/linux application written in C# by Licho. It is an alternative to the SPADS Autohost written by bibim. There is a [http://springrts.com/phpbb/viewtopic.php?f=1&t=7921&st=0&sk=t&sd=a forum-thread] dealing with springie. More information can be found in "How to use Springie". In order to run the application on Linux, you need to have mono installed. It is possible to run Springie on a dedicated sev..."

= Basics =

Springie is a standalone windows/linux application written in C# by Licho. It is an alternative to the SPADS Autohost written by bibim. There is a [http://springrts.com/phpbb/viewtopic.php?f=1&t=7921&st=0&sk=t&sd=a forum-thread] dealing with springie. More information can be found in "[[Hosting Spring/Autohost|How to use Springie]]".

In order to run the application on Linux, you need to have mono installed.

It is possible to run Springie on a dedicated sever without graphical interface.

= Springie on Ubuntu =

The following steps have led to a successful installation of Springie on an Ubuntu 9.04 (Jaunty) server.

1. Install Spring as described [[Ubuntu_install|here]].

2. Install mono:

sudo apt-get install mono-common libmono-winforms2.0-cil

3. Get Springie:
wget http://springie.licho.eu/springie.zip

4. Extract "springie.zip" in a separate directory, e.g.:

In your home-directory:
mkdir springie
mv path/to/springie.zip springie
cd springie
unzip springie.zip

5. Read the readme.txt file.

6. Edit the main.xml file in your springie directory:

Replace:
<ExecutableName>spring-dedicated.exe</ExecutableName>
with:
<ExecutableName>/usr/games/spring-dedicated</ExecutableName>

7. Run Springie.

When running Springie for the first time, it creates a bunch of files in its directory.

Run Springie either with
mono Springie.exe
or
mono Springie.exe -nogui
in case of a headless display.

8. Stop Springie.

Use Ctrl+C (Strg+C) to stop Springie.

9. Configure Springie as described below.

10. Run Springie as described in item number 7.

= Configure Springie =

== Bot account ==
In order to be able to play Spring and to host games at the same time, you need a new spring account.The easiest way to register a new account is to use your Multiplayer Lobby client, e.g. SpringLobby.

== Server Settings ==
In case you are hosting on a server with a display attached, you simply can use the Springie GUI for configuration.

If you set Springie up on a headless server, you have to manually edit autohost.xml to set the configuration options. Of course, you can use Springie on a host with a display, use the GUI for configuration and then copy over the autohost.xml file.

=== Add admin users ===
Between the closing </DefaultRectangles>-tag and the opening <AutoLockMinPlayers>-tag insert:
<PrivilegedUsers>
</PrivilegedUsers>

Then for each admin insert between these tags:
<PrivilegedUser>
<Level>LEVEL</Level>
<Name>ADMIN</Name>
</PrivilegedUser>

where LEVEL is a number from 1 to 5 and ADMIN is a player's name who should be able to perform admin tasks.

The result could look like this:
<PrivilegedUsers>
<PrivilegedUser>
<Level>5</Level>
<Name>YOUR-SPRING-PLAYER-ACCOUNT</Name>
</PrivilegedUser>
<PrivilegedUser>
<Level>4</Level>
<Name>admin1</Name>
</PrivilegedUser>
</PrivilegedUsers>

=== Set a password ===
To set a password replace
<Password>*</Password>
with
<Password>YOUR-PASSWORD</Password>
in autohost.xml.

=== Set default map and mod ===
The tags
<DefaultMap></DefaultMap>
enclose the default map, the tags
<DefaultMod></DefaultMod>
the default mod.

An example for hosting a BA 6.95 mod with the SmallDivide map is:
<DefaultMap>SmallDivide.smf</DefaultMap>
<DefaultMod>Balanced Annihilation V6.95</DefaultMod>

=== Change the game title ===
Use the
<GameTitle></GameTitle>
tags to set the game title, e.g.:
<GameTitle>MYCOOLSERVER!!!1!</GameTitle>

=== Administer Springie ===
You can use the commands listed in the readme.txt to administer Springie by "talking" to the bot user. The commands !help and !helpall provide lists of accepted commands.

== Add mods ==
''TO DO''
[[Category:Linux]]
[[Category: Autohosts]]

Map Making Guide

2026-03-06T05:52:58Z

Qrow: Redirected page to Tutorial:MapMakingGuide(aGorm)

#REDIRECT [[Tutorial:MapMakingGuide(aGorm)]]

New to xta

2026-03-06T00:54:02Z

Qrow: Created page with " Image:Xta_logo_white.jpg '''Here you can find a neat guide for beginners to XTA''' == Light Laser Tower == Light laser towers (LLTs) have a much different role in XTA. They cost 250+ metal and should '''NOT''' be spammed unless in specific circumstances. It is widely thought that 2-3 well spread LLTs will kill a Commander. They are more for holding a strategic point than defending a small area. Units will defeat equal metal cost in def..."

[[Image:Xta_logo_white.jpg]]

'''Here you can find a neat guide for beginners to XTA'''

== Light Laser Tower ==

Light laser towers (LLTs) have a much different role in XTA.

They cost 250+ metal and should '''NOT''' be spammed unless in specific circumstances.

It is widely thought that 2-3 well spread LLTs will kill a Commander.

They are more for holding a strategic point than defending a small area.

Units will defeat equal metal cost in defence.

----

== Commander ==

XTA is built around the Commanders and Commander Pushing is common.

For a specific guide on Commanders, go [http://springrts.com/wiki/Xta_commander here].

Unlike BA, there are differences between Core and Arm Commanders:
*Arm is faster moving
*Core has bigger decloak radius (easy to decloak)
*Core has longer D-Gun (260 compared to Arm's 240)
At morphing, they are also different:
*Core gets a heavier laser, closer range = more damage at Level Two
*Arm gets a paralyser at Level Two
*Core gets a plasma shot at Level Four
*Arm gets three raven rockets at Level Four

The Commanders have shorter range than BA Commanders.

It costs 200 Energy to cloak a stationary unmorphed Commander, and 1000 a moving one.

The D-Gun also has a wider impact.

Commanders can make all Tech one and Tech Two labs, like all constructors.

'''BUT DO NOT GO TECH TWO AT START'''

'''Commanders do NOT leave a wreckage. '''

== Morphing ==

Commanders can be morphed in XTA (toggled On/Off in host options).
Commanders can be morphed 4 times. The first level requires 0.01 experience.
First level gives:
*+3 metal, +75 Energy (starts at +2 and +50)
*2,000 metal + Energy storage (starts at 1,000)
*Build speed increases by 25, gets full Tech one radar as well as increased LoS
*Range increases by 20, more powerful primary laser and +250 extra health
*When cloaked and moving Commander uses only 700 energy, not 1000
*Level Two requires 0.25 experience and gives improvement on level 1
*Level Three requires 0.10 experience (will go to 0.09 if excess after Level Two)
*Level Three gives improvement on Level Two as well as self repair option
*Level Four requires 0.25 experience and gives improvement on Level Three
*'''Commander will be paralysed during morphing!'''

----

== Vehicles or Kbots? ==

In XTA both types are useful.

It is best to go Kbots on hilly areas and Vehicles on flat areas.

Flash are not as powerful and a wide spread of units is best.

Vehicle Constructors are faster builders but cost more.

All AA shoots ground.

Scouts in XTA are very strong and can survive a lot of damage, however have low damage output.

----

== Nanos ==

XTA Nano Towers have shorter range but more build power than in BA.

They chain explode, so place them at your own risk!

Try space them out and not so close to your lab (but within range).

----

== Anti Air ==

Unlike BA, Vehicle and Kbot AA, Tech One and Two shoots ground and air.

All stationary Anti Air shoots ground.

Anti Air ships also shoot ground (and surface sea).

There is only one Tech one and Tech Two stationary Land Anti Air for both factions.

There is only one Tech one and Tech Two stationary Sea Anti Air for both factions.

There is no Tech Two Kbot Anti Air, although Armâ€™s Pelican has a weak missile.

----

== Difference in Techs ==

'''Tech one'''

It is usually best to only have one Tech One land lab, with assisters to improve build power.

XTA is very similar to OTA with Tech one units (less than BA).

Toaster/Ambusher is Tech One; Guardian/Punisher is Tech Two.

Dragonâ€™s Teeth blocks Rockets and majority of Missiles (terrain dependant).

All Tech One Constructors can make all Tech one and Tech Two labs.

Sub Pen and Shipyard are both sea Tech one.

Level one Metal Makers do not chain explode.

Popups do not have "High Trajectory" function.

'''Tech 1.5'''

Hovercraft and Sea Planes are Tech 1.5

Labs cost 1,700 metal.

The Constructors can make Mohos and Anti Nukes.

Hover Platform can be built on Land and Sea.

''' Tech Two'''

Tech Two is very different in XTA, and is usually made earlier.

Once Tech Two is out, Tech one units will suffer heavily in head on combat.

Resurrection Kbots are Tech Two and can make structures.

'''Mohos cost 300 Energy to run not 25!'''

Zippers/Freakers are in Tech one and 2 labs.

Fleas have 700 HP and are less a scout unit more Skirmish.

Guardians/Punishers do not have "High Trajectory" function.

There are no Plasma Shields.

'''Tech Three'''

All Core land and air Tech Two cons can make the Krogoth Gantry.

Arm has no Tech Three.

Krogoth is only Tech Three unit (30,000+ metal).

----

== Resources ==

There is no Advanced Solar.

Cloakable Fusions give 800 Energy
*Arm takes 125 Energy to Cloak
*Core takes 150 Energy to Cloak
*Arm takes 500 Energy to Stealth (625 for Cloak and Stealth)
*Core takes 550 Energy to Stealth (725 for Cloak and Stealth)

Heavy Fusions give 3500 Energy.

Arm have Mobile Fusions (260 E) in Advanced Vehicle Lab.

Core have Mini Fusions (300 E) built by all Tech Two Constructors.

NEVER start with a Heavy Fusion.

Moho Metal Extractors cost 300 Energy per second to maintain.

There is no gradual reclaim.

Metal storages give 10,000 storage extra.

Energy Storages give 30,000 extra storage.

No Tech Two Storages (there are Tech one underwater ones).

Underwater Storages give increased amounts of storage, but cost a little more.

----

== Micro ==

XTA is more about Micro as opposed to Macro.

Controlling a select amount of units can win games.

Units have more Health and are harder to kill.

Wasting units by not microing '''WILL''' cost games.

Commanders are widely microed.

[[Category:xta]]

Category:NOTA

2026-03-06T00:53:09Z

Qrow: Created blank page

IceXuick Map Design Help

2026-03-06T00:52:26Z

Template:EngineVersion:Testing:ReleaseDate

2026-03-06T00:45:03Z

Qrow: Created page with "02. September 2017"

02. September 2017

Template:EngineVersion:Testing

2026-03-06T00:44:07Z

Qrow: Created page with "develop"

develop

Download Testing

2026-03-06T00:43:49Z

Qrow: Created page with "= Spring Engine Testing Release = Current test version: {{EngineVersion:Testing}} ({{EngineVersion:Testing:ReleaseDate}}) == Get It == === SpringLobby === Go to Tools->Download Archives, then enter <code> engine:spring {{EngineVersion:Testing}} {{EngineBranch:Testing}} </code> Click ok. === pr-downloader === easiest way is by using pr-downloader (which is included into spring) <code> pr-downloader --download-engine "{{EngineVersion:Testing}} {{EngineBran..."

= Spring Engine Testing Release =

Current test version: {{EngineVersion:Testing}} ({{EngineVersion:Testing:ReleaseDate}})

== Get It ==

=== [[SpringLobby]] ===

Go to Tools->Download Archives, then enter

<code>
engine:spring {{EngineVersion:Testing}} {{EngineBranch:Testing}}
</code>

Click ok.

=== [[pr-downloader]] ===
easiest way is by using pr-downloader (which is included into spring)

<code>
pr-downloader --download-engine "{{EngineVersion:Testing}} {{EngineBranch:Testing}}"
</code>

=== Windows ===

{|
| style="padding-right:10px"| [[Image:Distributions-windows.png]]
|
<ul>
<li> [https://springrts.com/dl/buildbot/default/{{EngineBranch:Testing}}/{{EngineVersion:Testing}}/win32/spring_{{{EngineBranch:Testing}}}{{EngineVersion:Testing}}_win32.exe installer]
<li> [https://springrts.com/dl/buildbot/default/{{EngineBranch:Testing}}/{{EngineVersion:Testing}}/win32/spring_{{{EngineBranch:Testing}}}{{EngineVersion:Testing}}_win32-minimal-portable.7z portable] (Lobby not included)
<li> [https://springrts.com/dl/buildbot/default/{{EngineBranch:Testing}}/{{EngineVersion:Testing}}/win32/ whole build]
</ul>
|}

=== Linux ===

{|
| style="padding-right:10px"| [[Image:Tux-G2.png]]
|
<ol>
<li> '''get the source'''
<ol>
<li> creating the repo (first time only):<br>
<code>git clone git://github.com/spring/spring.git spring_src</code>
<li> update to latest sources:<br>
<code>cd spring_src && git fetch && git checkout {{EngineVersion:Testing}}</code>
</ol>
<li> '''build''' by following the [[Building_Spring_on_Linux|build from source]] guide, or in short:<br>
<code>cmake -G "Unix Makefiles" . && make spring && sudo make install-spring</code>
</ol>
|}

===static builds===
as alternative you can try the one of the linux static builds:

* [https://springrts.com/dl/buildbot/default/{{EngineBranch:Testing}}/{{EngineVersion:Testing}}/linux32/spring_%7b{{EngineBranch:Testing}}%7d{{EngineVersion:Testing}}_minimal-portable-linux32-static.7z static linux build (32 bit)]

* [https://springrts.com/dl/buildbot/default/{{EngineBranch:Testing}}/{{EngineVersion:Testing}}/linux64/spring_%7b{{EngineBranch:Testing}}%7d{{EngineVersion:Testing}}_minimal-portable-linux64-static.7z static linux build (64 bit)]

=== Mac OS X ===

{|
| style="padding-right:10px"| [[Image:Distributions-mac-2.png]]
|
[https://springrts.com/dl/buildbot/default/{{EngineBranch:Testing}}/{{EngineVersion:Testing}}/osx64/spring_%7b{{EngineBranch:Testing}}%7d{{EngineVersion:Testing}}_MacOSX-10.6-SnowLeopard.zip '''App Bundle'''] (tested on 10.6 Snow-Leopard only)

In case the above fails, check out [[Spring_on_MacOSX|alternative ways]].
|}

== Lobby ==

Make sure your lobby client is configured to use the correct spring binary & unitsync!
On Linux, this will usually be ''/usr/local/bin/spring'' & ''/usr/local/lib/libunitsync.so''.

Use one of the test lobby servers (recommended):
* ''lobby1.springlobby.info:8200''
* ''lobby2.springlobby.info:8200''

Or alternatively, configure your lobby so it does not insist using the release version of the engine:
* SpringLobby: set <code>DisableVersionCheck=1</code> in ''springlobby.conf''
* TASClient: press CTRL+SHIFT+F6 and enable "Ignore server version incompatibility"

== Bugs and issues ==

Report on [https://springrts.com/mantis/ Mantis].
Remember to upload [[infolog.txt]] if you crash!

== Changelog ==

For changes please look into the [https://github.com/spring/spring/blob/{{EngineVersion:Testing}}/doc/changelog.txt Change Log] or the [https://github.com/spring/spring/compare/{{EngineVersion:Stable}}...{{EngineVersion:Testing}} diff log] for details.

See the topmost for changes to the upcoming version.

[[Category: Development]]

Complete Annihilation

2026-03-06T00:43:17Z

Qrow: Created page with "CA is now Zero-K"

CA is now [[Zero-K]]

Create maps

2026-03-06T00:42:53Z

Qrow: Redirected page to Tutorial:CreateMaps(Fnordia et al)

#REDIRECT [[Tutorial:CreateMaps(Fnordia et al)]]

Template:Template doc

2026-03-05T05:22:39Z

Qrow: Created page with "{{#invoke:documentation|main|_content={{ {{#invoke:documentation|contentTitle}}}}}}<noinclude>  </noinclude>"

{{#invoke:documentation|main|_content={{ {{#invoke:documentation|contentTitle}}}}}}<noinclude>

</noinclude>

Template:Counter

2026-03-05T05:22:15Z

Qrow: Created page with "{{#switch:{{{1}}} |GA={{formatnum:{{#expr:{{PAGESINCATEGORY:Wikipedia_good_articles|R}}-15}}}} |FA={{formatnum:{{#expr:{{PAGESINCATEGORY:Featured_articles|R}}}}}} |FL={{formatnum:{{#expr:{{PAGESINCATEGORY:Wikipedia_featured_lists|R}}-5}}}} |SUM={{formatnum:{{#expr:{{PAGESINCATEGORY:Wikipedia_good_articles|R}}-15+{{PAGESINCATEGORY:Featured_articles|R}}+{{PAGESINCATEGORY:Wikipedia_featured_lists|R}}-5}}}} |RGA={{formatnum:{{#expr:ceil({{NUMBEROFARTICLES:R}}/({{PAGESINCATEG..."

{{#switch:{{{1}}}
|GA={{formatnum:{{#expr:{{PAGESINCATEGORY:Wikipedia_good_articles|R}}-15}}}}
|FA={{formatnum:{{#expr:{{PAGESINCATEGORY:Featured_articles|R}}}}}}
|FL={{formatnum:{{#expr:{{PAGESINCATEGORY:Wikipedia_featured_lists|R}}-5}}}}
|SUM={{formatnum:{{#expr:{{PAGESINCATEGORY:Wikipedia_good_articles|R}}-15+{{PAGESINCATEGORY:Featured_articles|R}}+{{PAGESINCATEGORY:Wikipedia_featured_lists|R}}-5}}}}
|RGA={{formatnum:{{#expr:ceil({{NUMBEROFARTICLES:R}}/({{PAGESINCATEGORY:Wikipedia_good_articles|R}}-15))}}}}
|RFA={{formatnum:{{#expr:ceil({{NUMBEROFARTICLES:R}}/{{PAGESINCATEGORY:Featured_articles|R}})}}}}
|RFL={{formatnum:{{#expr:ceil({{NUMBEROFARTICLES:R}}/({{PAGESINCATEGORY:Wikipedia_featured_lists|R}}-5))}}}}
|RSUM={{formatnum:{{#expr:ceil({{NUMBEROFARTICLES:R}}/({{PAGESINCATEGORY:Wikipedia_good_articles|R}}-15+{{PAGESINCATEGORY:Featured_articles|R}}+{{PAGESINCATEGORY:Wikipedia_featured_lists|R}}-5))}}}}
|{{NUMBEROFARTICLES}}}}<noinclude>
{{template doc}}
</noinclude>

Template:Warning

2026-03-05T05:21:29Z

Qrow: Created page with "<languages/> <onlyinclude>{{#if: {{{msg|{{{1|}}}}}}|<table class="warning-message" style="background-color: var( --background-color-error-subtle, #ffe9e5 ); color: inherit; border: 1px var( --border-color-error, #9f3526 ) solid; box-sizing: border-box; margin: 0.5em 0; padding: 0.5em;"><tr><td style="white-space: nowrap; vertical-align: top;">}}<span style="position: relative; top: -2px;">File:OOjs_UI_icon_notice-destructive.svg|18px|alt=<translate> Warning</..."

<languages/>
<onlyinclude>{{#if: {{{msg|{{{1|}}}}}}|<table class="warning-message" style="background-color: var( --background-color-error-subtle, #ffe9e5 ); color: inherit; border: 1px var( --border-color-error, #9f3526 ) solid; box-sizing: border-box; margin: 0.5em 0; padding: 0.5em;"><tr><td style="white-space: nowrap; vertical-align: top;">}}<span style="position: relative; top: -2px;">[[File:OOjs_UI_icon_notice-destructive.svg|18px|alt=<translate> Warning</translate>|link=]]</span> '''<translate> Warning:</translate>''' {{#if: {{{msg|{{{1|}}}}}}|</td><td style="padding-{{dir|{{pagelang}}|right|left}}: 0.5em vertical-align: top;">{{{msg|{{{1|}}}}}}</td></tr></table>}}</onlyinclude>
{{Documentation|content=
<translate>
== Usage == 


This template has two possible usages:
</translate>

# <translate> Will have the text flow below when the warning text is too long</translate>
# <translate> Uses a table to indent the text.</translate>

<translate>
=== Method 1 === 
</translate>
<translate> The following displays the warning icon and the word "Warning:".</translate>
<translate> You can follow this with whatever text/images/markup you like.</translate>

<translate> Wiki Code:</translate>

<nowiki>{{warning}}</nowiki> <translate> Don't do that!</translate>

{{warning}} <translate> Don't do that!</translate>

<translate>
=== Method 2 === 


The following includes the text passed to the template, and uses a table to stop the text flowing round the icon.


Wiki Code:
</translate>

<nowiki>{{warning|1=</nowiki><translate> Here is a long warning, which is sufficiently wordy to run onto a second line (unless you have a really large screen!), which would normally cause it to wrap round the icon, but because we passed it as a parameter it keeps its left alignment straight.</translate><nowiki>}}</nowiki>

{{warning|1=<translate> Here is a long warning, which is sufficiently wordy to run onto a second line (unless you have a really large screen!), which would normally cause it to wrap round the icon, but because we passed it as a parameter it keeps its left alignment straight.</translate>}}
<translate>
== See also == 
</translate>
* {{tl|Caution}}
* {{tl|Fixtext}}
* {{tl|Note}}
* {{tl|Tip}}
}}
[[Category:Warning templates{{#translation:}}]]

Recoil:RmlUI Starter Guide

2026-03-05T05:20:03Z

Qrow: Created page with "{{DISPLAYTITLE:RmlUI Starter Guide}} __TOC__ = RmlUI Starter Guide = '''''For RecoilEngine game developers — build reactive, HTML/CSS-style game UIs in Lua.''''' {| class="wikitable" ! Attribute !! Value |- | Engine || RecoilEngine (Spring) |- | Framework || RmlUi ([https://github.com/mikke89/RmlUi mikke89/RmlUi]) |- | Language || Lua (via sol2 bindings) |- | Availability || LuaUI (LuaIntro / LuaMenu planned) |} ---- == 1. Introduction == RmlUI is a UI framework..."

Finalizing linux install

2026-03-05T05:16:55Z

Qrow: Created page with "= Finalizing installation = You should have Spring installed by now; if not, please see the SetupGuide. == Maps & Mods == Since Spring is only an engine, you need to download games for it, and the maps that go with those games. SpringLobby will automatically do this for you when you attempt to join a game with a map or mod that you do not currently have, using an integrated downloader. If you want to download it manually or browse existing maps, there are se..."

= Finalizing installation =
You should have Spring installed by now; if not, please see the [[SetupGuide]].

== Maps & Mods ==

Since Spring is only an engine, you need to download [[games]] for it, and the maps that go with those games.

SpringLobby will automatically do this for you when you attempt to join a game with a map or mod that you do not currently have, using an integrated downloader.

If you want to download it manually or browse existing maps, there are several easy to use websites:
*[http://spring.jobjol.nl/subcategory.php?id=1 SpringFiles]
*[http://spring-portal.com/ Spring-Portal]
*[http://www.darkstars.co.uk/downloads/index.php?dir=spring Darkstars]

Pick any of those sites, download a map or mod, and then double click it. This will move it to your Spring folder, using the spring map/mod installer program. If you wish to move maps/mods by hand, they are located under <code>~/.spring/maps/</code> or <code>~/.spring/mods/</code> (if the folder does not exist - create it). Do not unpack the file in any way though, just download and save it. Reload your maps/mods in SpringLobby, (''Tools - Reload maps/mods'') and they will be ready to use.

These sites also may provide other neat things like Lua widgets, epic replays, AI bots (for playing offline or to team up on with a friend). Generally the installation requires you to download the file and place it in the appropriate folder in your ''~/.spring'' directory. (you may have to create the folder)

''Hint:'' If you know the name of the map you want, there is a Search function provided in those websites. Just write a part of the name, like one word, and you will easily find the map you were looking for.

[[Category:Linux]]

Main Page

2026-03-05T05:13:43Z

Qrow: /* Welcome to Fightorder! */

{{DISPLAYTITLE:<span style="position: absolute; clip: rect(1px 1px 1px 1px); clip: rect(1px, 1px, 1px, 1px);">{{FULLPAGENAME}}</span>}}
[[File:Fightorderlonglogo.png]]

== Welcome to Fightorder! ==

We are a resource repository for SpringRTS and Recoil Engine powered games.
We primarily host information pertaining to Zero-K and BAR, and for development of resources of those games.

More than that planned for future development!

Click on a game or feature below to see its page.

<imagemap>Image:menu.png|800px|
rect 80 6 223 655 [[Spring Engine|Spring Engine]]
rect 325 1 470 672 [[Recoil|Recoil]]
rect 569 7 721 666 [[Zero-K|Zero-K]]
rect 798 3 944 667 [[BAR|BAR]]
rect 1036 3 1186 666 [[Metal Factions|Metal Factions]]
rect 1273 7 1416 671 [[EVO RTS|EVO RTS]]
rect 1510 1 1713 666 [[Kernel Panic|Kernel Panic]]

</imagemap>

Recoil:RmlUi

2026-03-05T04:48:07Z

Qrow:

RmlUi is a UI framework that is defined using a HTML/CSS style workflow (using Lua instead of JS) intended to simplify UI development especially for those already familiar with web development. It is designed for interactive applications, and so is reactive by default. You can learn more about it on the [RmlUI website] and [differences in the Recoil version here](#differences-between-upstream-rmlui-and-rmlui-in-recoil).

== How does RmlUI Work? ==

To get started, it's important to learn a few key concepts.
- Context: This is a bundle of documents and data models.
- Document: This is a document tree/DOM (document object model) holding the actual UI.
- RML: This is the markup language used to define the document, it is very similar to XHTML (HTML but must be well-formed XML).
- RCSS: This is the styling language used to style the document, it is very similar to CSS2 but does differ in some places.
- Data Model: This holds information (a Lua table) that is used in the UI code in data bindings.

On the Lua side, you are creating 1 or more contexts and adding data models and documents to them.

On the Rml side, you are creating documents to be loaded by the Lua which will likely include data bindings to show information from the data model, and references to lua functions for event handlers.

As each widget/component you create will likely comprise of several files (.lua, .rml & .rcss) you may find having a folder for each widget/component a useful way to organise your files.

# Getting Started

RmlUi is available in LuaUI (the game UI) with future availability in LuaIntro & LuaMenu planned, so it is already there for you to use.
However, to get going with it there is some setup code that should be considered for loading fonts, cursors and configuring ui scaling, an example script is provided below.
If you are working on a widget for an existing game, it is likely that the game already has some form of this setup code in, so you may be able to skip this section.

### Setup script

Here is the "[handler](https://github.com/beyond-all-reason/Beyond-All-Reason/blob/master/luaui/rml_setup.lua)", written by lov and ChrisFloofyKitsune, 2 of the people responsible for the RmlUi implementation.

```lua
-- luaui/rml_setup.lua
-- author: lov + ChrisFloofyKitsune
--
-- Copyright (C) 2024.
-- Licensed under the terms of the GNU GPL, v2 or later.

if (RmlGuard or not RmlUi) then
return
end
-- don't allow this initialization code to be run multiple times
RmlGuard = true

--[[
Recoil uses a custom set of Lua bindings (check out rts/Rml/SolLua/bind folder in the C++ engine code)
Aside from the Lua API, the rest of the RmlUi documentation is still relevant
https://mikke89.github.io/RmlUiDoc/index.html
]]

--[[ create a common Context to be used for widgets
pros:
* Documents in the same Context can make use of the same DataModels, allowing for less duplicate data
* Documents can be arranged in front/behind of each other dynamically
cons:
* Documents in the same Context can make use of the same data models, leading to side effects
* DataModels must have unique names within the same Context

If you have lots of DataModel use you may want to create your own Context
otherwise you should be able to just use the shared Context

Contexts created with the Lua API are automatically disposed of when the LuaUi environment is unloaded
]]

local oldCreateContext = RmlUi.CreateContext

local function NewCreateContext(name)
local context = oldCreateContext(name)

-- set up dp_ratio considering the user's UI scale preference and the screen resolution
local viewSizeX, viewSizeY = Spring.GetViewGeometry()

local userScale = Spring.GetConfigFloat("ui_scale", 1)

local baseWidth = 1920
local baseHeight = 1080
local resFactor = math.min(viewSizeX / baseWidth, viewSizeY / baseHeight)

context.dp_ratio = resFactor * userScale

context.dp_ratio = math.floor(context.dp_ratio * 100) / 100
return context
end

RmlUi.CreateContext = NewCreateContext

-- Load fonts
local font_files = {
}
for _, file in ipairs(font_files) do
Spring.Echo("loading font", file)
RmlUi.LoadFontFace(file, true)
end

-- Mouse Cursor Aliases
--[[
These let standard CSS cursor names be used when doing styling.
If a cursor set via RCSS does not have an alias, it is unchanged.
CSS cursor list: https://developer.mozilla.org/en-US/docs/Web/CSS/cursor
RmlUi documentation: https://mikke89.github.io/RmlUiDoc/pages/rcss/user_interface.html#cursor
]]

-- when "cursor: normal" is set via RCSS, "cursornormal" will be sent to the engine... and so on for the rest
RmlUi.SetMouseCursorAlias("default", 'cursornormal')
RmlUi.SetMouseCursorAlias("pointer", 'Move') -- command cursors use the command name. TODO: replace with actual pointer cursor?
RmlUi.SetMouseCursorAlias("move", 'uimove')
RmlUi.SetMouseCursorAlias("nesw-resize", 'uiresized2')
RmlUi.SetMouseCursorAlias("nwse-resize", 'uiresized1')
RmlUi.SetMouseCursorAlias("ns-resize", 'uiresizev')
RmlUi.SetMouseCursorAlias("ew-resize", 'uiresizeh')

RmlUi.CreateContext("shared")
```

What this does is create a unified context 'shared' for all your documents and data models, which is currently the recommended way to architect documents. If you have any custom font files, list them in `font_files`, otherwise leave it empty.

The setup script above can then be included from your `luaui/main.lua` (main.lua is the entry point for the LuaUI environment).

```lua
VFS.Include(LUAUI_DIRNAME .. "rml_setup.lua", nil, VFS.ZIP) -- Runs the script
```
> [!NOTE] The rml_setup.lua script included in base content only imports a font and cursor and doesn't create a context or set scaling

### Writing Your First Document

You will be creating files with .rml and .rcss extensions, as these closely resemble HTML and CSS it is worth configuring your editor to treat these file extensions as HTML and CSS respectively, see the [IDE Setup](#ide-setup) section for more information.

Now, create an RML file somewhere under `luaui/widgets/`, like `luaui/widgets/getting_started.rml`. This is the UI document.

Writing it is much like HTML by design. There are some differences, the most immediate being the root tag is called rml instead of html, most other RML/HTML differences relate to attributes for databindings and events, but for the time being, we don't need to worry about them.

By default RmlUi has *NO* styles, this includes setting default element behaviour like block/inline and styles web developers would expect like input elements default appearances, as a starting point you can use [RmlUi documentation](https://mikke89.github.io/RmlUiDoc/pages/rml/html4_style_sheet.html) though these do not include styles for form elements.

Here's a basic widget written by Mupersega.

```html
<rml>
<head>
<title>Rml Starter</title>

<style>
#rml-starter-widget {
pointer-events: auto;
width: 400dp;
right: 0;
top: 50%;
transform: translateY(-90%);
position: absolute;
margin-right: 10dp;
}
#main-content {
padding: 10dp;
border-radius: 8dp;
z-index: 1;
}
#expanding-content {
transform: translateY(0%);
transition: top 0.1s linear-in-out;
z-index: 0;
height: 100%;
width: 100%;
position: absolute;
top: 0dp;
left: 0dp;
border-radius: 8dp;
display: flex;
flex-direction: column;
justify-content: flex-end;
align-items: center;
padding-bottom: 20dp;
}
/* This is just a checkbox sitting above the entirety of the expanding content */
/* It is bound directly with data-checked attr to the expanded value */
#expanding-content>input {
height: 100%;
width: 100%;
z-index: 1;
position: absolute;
top: 0dp;
left: 0dp;
}
#expanding-content.expanded {
top: 90%;
}
#expanding-content:hover {
background-color: rgba(255, 0, 0, 125);
}
</style>
</head>
<body>
<div id="rml-starter-widget" class="relative" data-model="starter_model">
<div id="main-content">
<h1 class="text-primary">Welcome to an Rml Starter Widget</h1>
<p>This is a simple example of an RMLUI widget.</p>
<div>
<button onclick="widget:Reload()">reload widget</button>
</div>
</div>
<div id="expanding-content" data-class-expanded="expanded">
<input type="checkbox" value="expanded" data-checked="expanded"/>
<p>{{message}}</p>
<div>
<span data-for="test, i: testArray">name:{{test.name}} index:{{i}}</span>
</div>
</div>
</div>
</body>
</rml>
```

Let's take a look at different areas that are important to look at.

`<div id="rml-starter-widget" class="relative" data-model="starter_model">`
1. Here, we bind to the data model using `data-model`. This is what we will need to name the data model in our Lua script later. Everything inside the model will be in scope and beneath the div.
2. Typically, it is recommended to bind your data model inside of a div beneath `body` rather than `body` itself.

```html
<div id="expanding-content" data-class-expanded="expanded">
<input type="checkbox" value="expanded" data-checked="expanded"/>
```
any attribute starting with `data-` is a "data event". We will go through a couple below, but you can find out more here [on the RmlUi docs site](https://mikke89.github.io/RmlUiDoc/pages/data_bindings/views_and_controllers.html).
1. Double curly braces are used to show values from the data model within the document text. e.g. `{{message}}` shows the value of `message` in the data model.
2. `data-class-expanded="expanded"` applies the `expanded` class to the div if the value `expanded` in the data model is `true`.
3. `<input type="checkbox" value="expanded" data-checked="expanded"/>` This checkbox will set the data model value in `data-checked` to true.
4. When the data model is changed, the document is rerendered automatically. So, the expanding div will have the `expanded` class applied to it or removed whenever the check box is toggled.

There are data bindings to allow you to loop through arrays (data-for) have conditional sections of the document (data-if) and many others.

### The Lua

> [!NOTE] For information on setting up your editor to provide intellisense behaviour see the [Lua Language Server guide]({{% ref "lua-language-server" %}}).

To load your document into the shared context we created earlier and to define and add the data model you will need to have a lua script something like the one below.

```lua
-- luaui/widgets/getting_started.lua
if not RmlUi then
return
end

local widget = widget ---@type Widget

function widget:GetInfo()
return {
name = "Rml Starter",
desc = "This widget is a starter example for RmlUi widgets.",
author = "Mupersega",
date = "2025",
license = "GNU GPL, v2 or later",
layer = -1000000,
enabled = true
}
end

local document
local dm_handle
local init_model = {
expanded = false,
message = "Hello, find my text in the data model!",
testArray = {
{ name = "Item 1", value = 1 },
{ name = "Item 2", value = 2 },
{ name = "Item 3", value = 3 },
},
}

local main_model_name = "starter_model"

function widget:Initialize()
widget.rmlContext = RmlUi.GetContext("shared") -- Get the context from the setup lua

-- Open the model, using init_model as the template. All values inside are copied.
-- Returns a handle, which we will touch on later.
dm_handle = widget.rmlContext:OpenDataModel(main_model_name, init_model)
if not dm_handle then
Spring.Echo("RmlUi: Failed to open data model ", main_model_name)
return
end
-- Load the document we wrote earlier.
document = widget.rmlContext:LoadDocument("luaui/widgets/getting_started.rml", widget)
if not document then
Spring.Echo("Failed to load document")
return
end

-- uncomment the line below to enable debugger
-- RmlUi.SetDebugContext('shared')

document:ReloadStyleSheet()
document:Show()
end

function widget:Shutdown()
widget.rmlContext:RemoveDataModel(main_model_name)
if document then
document:Close()
end
end

-- This function is only for dev experience, ideally it would be a hot reload, and not required at all in a completed widget.
function widget:Reload(event)
Spring.Echo("Reloading")
Spring.Echo(event)
widget:Shutdown()
widget:Initialize()
end
```

### The Data Model Handle

In the script, we are given a data model handle. This is a proxy for the Lua table used as the data model; as the Recoil RmlUi integration uses Sol2 as a wrapper data cannot be accessed directly.

In most cases, you can simply do `dm_handle.expanded = true`, but this only works for table entries with string keys. What if you have an array, like `testArray` above? To loop through on the Lua side, you will need to get the underlying table:

```lua
local model_handle = dm_handle:__GetTable()
```

As of writing, this function is not documented in the Lua API, due to some problems with language server generics that haven't been sorted out yet. It is there, however, and will be added back in in the future. it returns the table with the shape of your inital model.
You can then iterate through it, and change things as you please:

```lua
for i, v in pairs(model_handle.testArray) do
Spring.Echo(i, v.name)
v.value = v.value + 1
end
-- If you modified anything in the table, as we did here, we need to set the model handle "dirty", so it refreshes.
dm_handle:__SetDirty("testArray") -- We modified something nested in the array, so we mark the top level table entry as dirty
```

### Debugging

RmlUi comes with a debugger that lets you see and interact with the DOM. It's very handy! To use it, use this:

```lua
RmlUi.SetDebugContext(DATA_MODEL_NAME)
```

And it will appear in-game. A useful idiom I like is to put this in `rml_setup.lua`:

```lua
local DEBUG_RMLUI = true

--...

if DEBUG_RMLUI then
RmlUi.SetDebugContext('shared')
end
```

If you use the shared context, you can see everything that happens in it! Neat!

## Things to Know and Best Practices

### Things to know
Some of the rough edges you are likely to run into have already been discussed, like the data model thing, but here are some more:

---

Unlike a web browser a default set of styles is not included, as a starting point you can look at the [RmlUi documentation](https://mikke89.github.io/RmlUiDoc/pages/rml/html4_style_sheet.html) though this doesn't provide styles for form elements.

When using Context:OpenDataModel in Lua you must assign the return value to a variable, not doing so will cause the engine to crash when the model is reference in RML.

Input elements of type submit & button behave differently to HTML and more like Button elements in that their text is not set by the value attribute. (This is likely to be corrected in a future version)

The alpha/transparency value of an RGBA colour is different to CSS (0-1) and instead uses 0-255. The css opacity does still use 0-1.

List styling is unavailable (list-style-type etc.), you can still use UL/OL/LI elements but there is no special meaning to them, whilst you could use background images to replicate bullets there isn't a practical way to achieve numbered list items with RML/RCSS.

Only solid borders are supported, so the border-style property is unavailable and the shorthand border property doesn't include a style part (```border: 1dp solid black;``` won't work, instead use ```border: 1dp black;```).

background-color behaves as expected, all other background styles are different and use decorators instead see the [RmlUi documentation for more information on decorators.](https://mikke89.github.io/RmlUiDoc/pages/rcss/decorators.html)

There are two kinds of events: data events, like `data-mouseover`, and normal events, like `onmouseover`. These have different data in their scopes.
- Data events have the data model in their scope.
- Normal events don't have the data model, but they *do* have whatever is passed into `widget` on `widget.rmlContext:LoadDocument`. `widget` doesn't have to be a widget, just any table with data in it.

For example, take this:

```lua
local model = {
add = function(a, b)
Spring.Echo(a + b)
end
}
local document_table = {
print = function(msg)
Spring.Echo(msg)
end,
}

dm_handle = widget.rmlContext:OpenDataModel("test", model)
document = widget.rmlContext:LoadDocument("document.rml", document_table)
```

```html
<h1>Normal Events</h1>
<input type="button" onclick="add(1, 2)">Won't work!</input>
<input type="button" onclick="print('test')">Will work!</input>

<h1>Data Events</h1>
<input type="button" data-click="add(1, 2)">Will work!</input>
<input type="button" data-click="print('test')">Won't work!</input>
```

### Best Practices

- To create a scalable interface the use of the dp unit over px is recommended as the scale can be set per context with SetDensityIndependentPixelRatio.
- For styles unique to a document, put them in a `style` tag. For shared styles, put them in an `rcss` file.
- Rely on Recoil's RmlUi Lua bindings doc for what you can and can't do. The Recoil implementation has some extra stuff the RmlUi docs don't.
- The Beyond All Reason devs prefer to use one shared context for all rmlui widgets.

### Differences between upstream RmlUI and RmlUI in Recoil

- The SVG element allows either a filepath or raw SVG data in the src attribute, allowing for inline svg to be used (this may change to svg being supported between the opening and closing tag when implemented upstream)
- An additional element ```<texture>``` is available which allows for textures loaded in Recoil to be used, this behaves the same as an ```<img>``` element except the src attribute takes a [texture reference]({{% ref "articles/texture-reference-strings" %}})

### IDE Setup

To get the best experience with RmlUi, you should set up your editor to use HTML syntax highlighting for .rml file extensions and CSS syntax highlighting for .rcss file extensions.

In VS Code, this can be done by opening a file with the extension you want to setup, then clicking on the language mode in the bottom right corner of the window (probably shows as Plain Text). From there, you can select "Configure File Association for '.rml'" from the top menu that appears and choose "HTML" from the list. Do the same for .rcss files, but select "CSS".

[RmlUI website]: https://mikke89.github.io/RmlUiDoc/

Spring guide!

2026-03-05T02:17:08Z

Qrow: Created page with "{{deprecated}} ''' This page describes the gameplay of TA-based games on the Spring engine. The Spring engine can run a wide selection of Games and thus this text does not apply to every one of them. ---- Keep in mind that Spring is still in beta, therefore crashes can occur (a lot) and we (well, not me!) haven't got everything fixed yet. Before we start, let's have some background info. == TA: so what's so cool about this game? == OTA | TA (Total Annihilation)..."

{{deprecated}}
'''
This page describes the gameplay of TA-based games on the Spring engine.
The Spring engine can run a wide selection of [[Games]] and thus this text does not apply to every one of them.
----

Keep in mind that Spring is still in beta, therefore crashes can occur (a lot) and we (well, not me!) haven't got everything fixed yet.

Before we start, let's have some background info.

== TA: so what's so cool about this game? ==

[[OTA | TA (Total Annihilation)]] was created by Cavedog (R.I.P) in 1997, about half a year before(!!!) Starcraft was released. It was revolutionary in many ways, with 3D graphics (but a fixed camera), good animations (aircraft barrel rolled and leaned when they turned etc.), 3D terrain and many units (150 in the original game.) But in my not so humble opinion, the 3 greatest things that set TA apart were...

* Its physics! Every shot trajectory was calculated! An artillery shell could try to get over a hill and hit an aircraft, which exploded into bits, damaging other troops nearby, which could also explode and set forests on fire. Yeah, might not sound that big after 7 years, but back then we had Starcraft, which defied at least a half dozen laws of physics.

(Example of the tentacle through space. Yeah, really realistic)
[http://fast.filespace.org/Kixxe/WTF.png Click here]

* The order system! You could have 300 units waiting to be built, and when they were done, they could go and patrol an area and attack anyone in it. Order queues were limitless. You could build your whole base and drink tea while it was getting built. Construction units on patrol would repair damaged units, help build things and reclaim stuff (sucking it in and transforming it into resources.)

* The resource system! Contrary to other RTS games, the resources in TA are infinite. What limits resource consumption is the rate at which they can be gathered. This sole fact would make for longer and more epic games, with hundreds or thousands of units fighting in the endgame.

Pretty cool game. If you want, check out their old website for more info. [http://www.fileuniverse.com/Total_Annihilation_Mirror/totala/index.html Click here]

Anyway, enough of my rambling, onto Spring!

Now, as I told you, Spring was inspired by TA and has the same features TA had. Plus a few new things, check out the Spring features page for more info.
[http://taspring.clan-sy.com/wiki/Features Click here]

----

==Controls==
Keyboard controls here:
[http://img108.imagevenue.com/img.php?image=03721_PK06A_Compact_Keyboard_ProdImage_Black_V2_122_972lo.jpg]

Don't forget: shift+ right click to queue orders.
----

==Resources==

There are two types of resources in Spring, namely ''metal'' and ''energy''. Each of these two resources can be collected in a number of different ways. The amount of each resource that you currently have stockpiled is represented by a colored bar, one for each resource, along the upper edge of the screen. The rate at which you are presently collecting and consuming each of the two types is represented by a number and a + or - sign. If you are collecting at a faster rate then the rate at which you are consuming you will see your colored bar grow as resources accumulate. Your stockpiled resources are being depleted whenever the colored bar is shrinking. There are storage buildings which you can build for each type of resource and these will increase the amount of each which can be stored. Units and structures cost both metal and energy to build, while some units or structures also require energy to walk, shoot or operate in general.

Metal is collected continuously from either a metal extractor, often called "mexes" which extract from certain areas of the map, or by using a metal maker, abbreviated as "MM" which convert energy into metal. Both will only operate so long as there is sufficient energy to power them. However, metal makers require a lot of energy.
A faster way to gather metal is by using either your commander or a construction bot to 'reclaim' it from the remains of destroyed units and buildings! They can even reclaim buildings which have not been destroyed and they don't have to belong to your enemy to be reclaimed.

Energy can be produced by a number of different buildings or it can be reclaimed (you can reclaim trees to gather energy). There are many different types of energy producers, including solar collectors and power plants, but they will be covered in another section.

In a game, always keep an eye on your metal and energy bar because if one of them goes to zero, particularly energy, your building rate will stall,(metal makers and extractors will stop producing) and some units will be unable to fire their energy weapons (eg. LRPCs, Annihilators, Doomsday Machines).

----

==A Normal Spring Game==

Anyway, now you will learn the basics of a normal Spring game, as I see it.
Every Spring game starts with all players only having:

'''The COMMANDER'''! (Insert DUN DUN DUUUUUNN)

The Commander is the unit you start with and the most important one in the game. He is unique and cannot be rebuilt. In fact, there is a mode where the game ends when the commander dies, so never leave him alone.

The fastest builder, he can walk and build underwater, he makes a nuke-sized explosion when he dies, he has a laser and the privilege of a Disintegrator Gun (alias D-Gun).
The D-Gun is the single most powerful weapon in the whole game, which kills ANY (ANY, I mean it!) unit in one hit (friend or foe no difference, be careful!). Even if that sounds a like a little overkill, keep in mind that the Commander has a very limited range, is defenceless against any aircraft and long range artillery, and when submerged, he cannot shoot. (Subs! Onoz!)

The Commander is used for setting up a base, and early base defences. The D-Gun should protect him against any level 1 unit that tries to kill him, so if you lose your Commander in the beginning of the game, then you're dead. You lose your best (only?) builder and attacker, plus you have a nuke-sized explosion that may destroy half or all of your base.

Anyway, if you're seeing everything in a top down perspective, click the Commander (type Ctrl+C if you can't find him) with left mouse button to select him.

(If you have a crosshair as a mouse, press j. If your camera is zoomed out or all jerky, press ctrl+j until you find the OTA(Original Total Annihilation) camera.)

Okay, let's now discuss '''how to build stuff'''.

Like any normal RTS, it's choose a unit and click a location, but there is more with Spring. Hold shift and click on different locations to make the unit build the same building there. Hold shift and drag and you will make a line of the building. Hold ctrl and shift to make boxes/rectangular shapes of buildings. Use these! Make a line of DT (Dragon Teeth, small piece of wall/cover) instead of clicking each and every one. The controls are there to help you.
This is called queuing up stuff. You can use almost every single command in a queue. Buildings can be queued to build lots of different units, and then the other orders in the behaviour of the unit. You can make them walk to something, or guard/follow a unit by pressing G and selecting the unit to guard. Try it.
Selecting a unit and pressing shift key will show the orders queue.

Build 2 solar generators, or 4 wind generators to gather energy. Keep in mind that wind is pretty unstable, and that a number of maps (like lunar ones) have no wind at all! (The level of wind and tides in the map is indicated in the Map Selector in the Lobby).

Now select the Metal extractors and the whole screen turns black and green. Okay, place one on the green stuff. (The greener, the better! Like broccoli!)

Oh, and the minimap controls in spring are reversed. Meaning that you have to right-click to move the screen to the location. Once the new GUI is out and official, this will be fixed.

----

==The TA Bestiary==

Okay, time to describe the cool units that are at your disposal to make your enemies bleed. 8)

(Disclaimer : This will discuss the types of units, not every unit. Therefore, if I say that vehicles have large armour, I don't mean artillery of course.)

On to the first level 1 lab/plant to build. The categories are:

===Vehicles===

These babies are all about armour. The level 1 units are pretty basic, with more armour and (build) speed and than their K-bot counterparts. Level 2 vehicles show even more of the same pattern: better armour than their K-bot counterparts. Level 2 also offers the mobile Flak unit, which is the only real level 2 mobile AA.
Their weakness is that they are clumsy, turn slowly, and most of them can't climb mountains at all. Leads to trouble when an explosion makes a crater; units survive but can get stuck in the crater. Or just when they are trying to get up a steep hill. But sooner or later, you'll learn what kind of destruction a rush of 30 Goliaths can do!

===K-Bots===

K-bots generally have less powerful weapons than tanks, and are also less heavily armored.
So why build them in the first place?
Because they are cheaper! And since they are cheaper, you can build more and outnumber your enemies. This doesn't work out that good in game though, since tanks ARE stronger. K-bots are also smaller, and will slip through DT and such alike easier than tanks.
And finally, the third advantage (which IMO is the biggest) of K-bots are that they can climb most mountains with ease! Climb by defences, up on mountains, through holes, these are all-purpose units.

===Aircraft===

Planes are planes. In Spring, there's a plane for every role. Bombers, fighters, gunships, flying radar, transports, stealth fighters and torpedo bombers. Planes are fast, and are not affected by terrain. There is no wall or relief that can stop a plane. You can just swoop into a base and take out AA with your gunship, and then bomb the crap out of their important structures. To stop them, you've got to rely on Anti Air (AA) units.

On the downside, planes are quite expensive to build and are relatively fragile. They are also the only units that have an anti unit against them (Except subs). When someone finds out you're building a large air fleet, they just cram their base full of AA and their army with mobile AA. And the only counter is more planes than their AA can handle, or a ground troop to take the AA down. A combined ground and air attack can be very destructive. Good luck!

===Ships===

Ships are good on a map with water. (DUH!) Ships come in many different kinds, but mostly for taking out other ships or bombing the crap out of land units in some way or another. The ships' strength is their powerful weaponry and their long range. All ships made to take out land have long range. Ships also have lots of armor. Another thing that's good about ships is that there is not much you can do to stop them because they are usually out of range. Once you see that the enemy has ships, either build a dock and a navy real fast or build planes and pray that he doesn't have too many AA ships.
Their weaknesses are slowness (especially when turning), they can be taken out by submarines, and of course they are confined to water, meaning that they are often stuck with units just outside of their reach.

And they are *extremely* expensive, metal-wise.

===Hovercraft===

(These are counted as level 2 units, so I would not recommend them as the first to build unless it's the perfect map for them)

Hovercrafts are a tank and a ship(some say plane, but I find ships to be more accurate for some reason O.o) mixed. Sure it's weaker than your average tank, and slower than your average boat. Whats their use? They are meant for swampy maps that means that both tanks and ships are a weakness, and offcourse since none can't be used, everyone just spams out AA since they think aircrafts are the only way. Great suprise for the enemy when 50 hovercrafts comes in agsint their flakkers and MT...
Long story short, Hovercrafts are good for those who like (or must) attack from the ground, but can't since there is too much water.

Their weakness is their low climbing ability, and that they're weaker than a tank and boats. (Don't build them on a land map, tanks ARE better.)

===Towers and Turrets===

The impressive range of fixed towers, cannons and turrets from Total Annihilation is again at your disposal. Proper use of these structures will help you control a map and stop your opponents in their tracks.

*'''Light Laser Towers (LLTs):'''
These cheap and fast lasers boast pinpoint accuracy and respectable damage against level 1 units. They suffer from short range, and are vulnerable to artillery and missile units which can kill them from out of reach. Since they fire faster than their bigger brothers, LLTs have an advantage against hordes of small weak units.

*'''Heavy Laser Towers (HLTs):'''
With a lower rate of fire but much more power than LLTs, these upgraded lasers are ideal for those pesky level 2 units that just don't want to die. They also have a longer range, and can be quite effective against aircraft. They cost a fair amount and take a long time to build, but in the right situation they can be extremely dangerous.

*'''Missile Towers (MTs):'''
The cheap yet deadly missile tower is guaranteed to shred airborne attackers, and its low cost and long range also makes it a good early-game point defense against weaker level 1 units. MTs are very fragile, and tend to chain-explode if placed too close together; they work best when scattered as random surprises for invading aircraft or with natural terrain or dragon's teeth to provide some cover from ground attacks. The huge damage bonus of missiles against aircraft makes these effective against even level 2 planes, though it would be wise to back them up with a few flak towers as well.

*'''Pop-up Cannons:'''
Pop-ups are the smallest and wiliest fixed plasma cannons. When not firing they retreat down into the ground, where they are extremely resistant to damage; a closed pop-up in XTA 9.1 can survive two consecutive direct nuclear missile impacts! They can be installed by lowly level 1 construction units, and outclass virtually all level 1 opponents in range and firepower. Their durability and effectiveness is not without cost, however, as even a single pop-up represents a huge gamble of time and resources in the early stages of a game. Consider carefully whether rushing a pop-up will cripple the enemy forces or your own economy...

*'''Medium Range Plasma Cannons (MRPCs):'''
MRPCs are huge, brutal plasma turrets that really suck on your energy reserves but inflict serious pain over a wide area. Fast and accurate targeting combined with excellent damage and range make them a sound defensive investment against level 2 armies. Remember that a smart enemy will look for a way to simply bypass your expensive static emplacements, and that even if you don't leave any way around these guns still make big fat targets; they work best when used to lock down choke points with overlapping fields of fire, and deserve supporting defenses against air raids and skirmishers. Put one on a hill, cover it with a HLT and some flak or missile towers behind a wall of DT, and don't forget to occasionally send in a builder to reclaim the resulting wreckage.

*'''Long Range Plasma Cannons (LRPCs):'''
When you want to hammer an enemy installation into gravel from the comfort of your own base, an Intimidator or Big Bertha might be the tool for the job. The enormous range and hitting power of a single LRPC can dominate the whole of a small map or take an enthusiastic bite out of a large one, and a battery of them can obliterate just about anything in only a few volleys. Too slow to effectively track moving targets, the LRPC is not a defensive emplacement but an offensive weapon of mass destruction; as such, building one is a challenge that simply can't be ignored. Surround these with AA and ground troops to fend off your victim's inevitable desperate attempt to halt the rain of destruction.

*'''Very Long Range Cannons (VLRCs):'''
The ultimate, absurd limit of long-range artillery is the repeating Buzzsaw or Vulcan. These guns are incredibly expensive and ludicrously energy hungry (be prepared to dedicate a couple of fusion plants to powering just one such monster) but have ''double'' the range of a "mere" LRPC and a withering rate of fire. Just don't forget to go equally overboard defending your Uber-gun, because it doesn't have very much health compared to its build cost and it screams "kick me" like nothing else.

===The first steps===

Now comes the tricky part. The first minute is always the same really, so what after that?
Well, it's hard to judge. But here are some paths that can be taken.

'''1.''' Build many construction units and send them out to build mexxes and Geothermal Power Plants. Then a defence and maybe some DT.

'''2.''' Build some construction units, and then start building defences. Follow the line defence guide lines.
Build Fusion Power Plants and Metal makers, and then an army. After that, use the army how armies are used best.
This strategy is called PORCING, and is considered by many as BAD.
There are disadvantages with this. You can't use many metal extractors or Geos, so you have slim to no resources to build your base. A popular strategy is to kill the anti-nuke, and then blow the whole compact base to bits.

'''3.''' Build a small army of 3-6 units and attack the enemy. The goal isn't to kill him, but to do as much damage as possible to his resources and hinder his economy. Mexxes are the most important, and then look for wind or solar generators.
Try to keep on attacking him, but remember to still tech up and build defences.

Anyway, use your construction units to build defences of SOME kind. Take advantage of Geothermal gases. Yeah the smoking stuff. You can place Geo plants there for good, cheap and space saving energy. If you're expanding, use every Mex' positions, and try to find a place to settle your defence line.

When you can defend yourself from most level 1 units, start on your level 2 building.

When it's done, ALWAYS build a construction unit first. Use it for your first mini Fusion. (Or build some mobile fusion at the vehicle plant if you're Arm)
Build level 2 units in the meantime.
Low on metal? Upgrade the finest of your Mexxes to Moho Mexxes. They are bigger and better (but they suck up energy).
You can also build a Moho Metal maker if you have enough energy to support it. (MMM :p)
Okay, if you made this far, you must really start thinking about how to defeat the enemy. Look for his weak spot. Maybe a K-bot assault from the mountains ? Maybe planes. Maybe using amphibious units. That part is for you to figure out.

----

==STRATEGY==

I read through this guide, and suddenly realized.

''where is the strategy?''

So I fiddled this section up. Hope you'll learn something from it and thereby increase your Spring gaming experience.

===Defence===

Ah, the overall defence. There are many different ways to make a good defence, but here are 4 oft seen approaches.

''Compact defence!''

The most common type of defence is a single line of defence, often with Dragon Teeth (DT) in front. Inside your base is some AA, and that's about it. The good thing about this is that it's pretty easy and fast to set up, and you know where your territory ends, which can make the game much easier. Problem is, if something makes it past the line of defence, then you're screwed, unless you're building line after line of defence, or have some units to stop them.

''Spread out defence!''

I saw a guy pull this off one time, and he won by a large margin. The trick with this is to never really have a defined line of defence, just a Heavy Laser Tower (HLT) here, a radar there, some DT there, a mine here and there.
Basically, you expand every time you build a defence building, so in the end you have ENORMOUS space to move in. Since the defence is spread out, no one is gonna rush past it with some Goliaths. You can have some units hide behind mountains and attack. He used Merls who he trapped in fortification walls. I tried to run past the defence with an army of 30 Bulldogs. His HLT and missile/plasma batteries stopped me before I even reached his final defence line.
Even though this defence is the best of them all, it's hard to build up, and requires lots of resources and time. IF you're able to pull it off, the only problem may be if they are fast enough to run by all of it, or if you don't have much AA and 30 Brawlers are coming.

''No defence at all?''

Yes, this is an option. Okay, you may want some mines here and there, and some DT to stop them from running right through the door and AA in your base if they're building planes. But how do you defend with no defence?
With units; the whole concept is that you put all your effort into making units. This works pretty well, since when you see where the enemy is going to attack, you can MOVE your whole defence to that location.
The problem with this defence is that when you are attacking, you lose most of your defence. Sure, you can leave units behind, but I find it hard mentally to leave half the army at home when I am attacking.
If you manage to pull this off, and make enough units to both attack and defend, then you have not wasted any money on defence, and you have a strong army!

''The All Out Defence''

''-- addendum by Cain''

The opposite of the "no defence" strategy, mixed with the "spread out defence" strategy: the main concept is to invest resources in lots of level 1 build planes, and use them to quickly gather huge amounts of territory and resources, while keeping a lot of planes building/repairing turrets all over the map. This could be very effective on maps with few choke points where your defence can be concentrated in a small area, or mostly flat maps where the overlapping range of defensive structures will create a large grid of protected territory. The concept is to expand the defence line until you can shoot straight into the enemy base. When using this strategy, it is wise to have a lot of level 2 aircraft defending the construction point, as you will need to constantly move your mobile defences around the map, protecting under-contruction defensive areas. I usually end up with a hundred builder planes and 20 to 50 Brawlers floating around... keep them away from Kroghot!

These are the defensive strategies I have found effective.

Also, one thing to remember is to eliminate the largest threat first. If you're relying on DT, take out the FARK or construction planes first.

Okay, you've built a good defence.
The next thing you should do is attempt to get into the mindset of your enemy. Put yourself in his shoes, and determine how he would most likely proceed given your defensive strategy. Would he attempt a gunship raid, or launch an attack from a defenceless mountain position? Once you know what his most likely plan of attack will be, rethink your defences with this in mind. If there is an area that is defenceless under your current strategy, and you believe it is a prime spot for your enemy to attack, set up some sort of defence there as well.

===Moving===
Moving or attacking is pretty easy right? Just move from point a to point b and attack c?
Nope.
First, you have to have your units move TOGETHER. . If some are trailing behind, then you just have to wait a little for them. A way of having your units stick together is to take a pretty slow unit, like a Can, and have others guard it.
Pressing control while moving units will make them keep their position in the formation, but not their speed. (they will spread out along the way, but ''try'' to get back into the position they were in when reaching the destination)
The ''Simple formation'' is also a way of doing this, and the units will automatically form a couple of lines, often with the right units first, too!
Transports are useful for moving units, but use the air transports (Valkyrie /Atlas) intelligently and protect them. The other transportation units are harder to use, since they take more time to load/unload.

===Attacking===

When attacking, remember what each unit's role is in the fight. Farks are used to repair important units that have been damaged. Bulldogs are meant to take damage and give damage back. Merls are used to shoot missiles from a distance, and don't require a clear LOS (line of sight). The question is what to repair. Merls die quickly, so one shot = dead. Knowing this, your first instinct might be to repair a Bulldog instead. Bulldogs are often the first thing that the enemy targets, and thus their HP often drops too rapidly to repair. Therefore, it is often wise to repair the middle-range units; not the giant HP monsters, not the units with a weak defence and strong/useful attack, but the average units that have acceptable HP and are not an enemy's first choice when selecting targets. One exception to this is mobile artillery. While it only has enough HP to survive one or two attacks, its attacks are well worth it, and the enemy still may not target them first, giving them a chance to deal massive damage.

===Army vs Army===

Many units attacking one unit is the best thing you can do, as when you kill one of their units, they lose one source of firepower. Focusing your fire is very important. Using focus fire in a group of weak units is very effective. Focus fire is, however, less effective on HP powerhouses.
When you're facing an army, always try to attack from behind or the side. Keep your units a little spread out when attacking. Not to far, but just so that area of effect weapons don't do as much damage. Have your HP powerhouses at the front, or at the front and sides. Keep em pretty close together but not side by side. Having your units spread out in this manner allows the units in the back to attack, and prevents splash damage units such as Zippers and Pyros from damaging many of your units at once.

This is the normal way of attacking an enemy army. There is the classical pincher movement too.
In this, you run one third of your HP powerhouses to the left, one third to the right and have the last third stay where they are.
This gives you 3 advantages:
*it's easier to get past the units and attack their weak units, or just run past them into the base
*you do more damage, since their units will have to change their target all the time and can't escape
*it makes it MUCH harder for the enemy to run away or try to get past you.

===Army vs Base===

Okay, you may have made it past the ground troops, but the fight is not over (unless your enemy used up his units to defend.) Now you must face his base defence, and act depending on the type of defence he has.

''Line defence''

Gather your army and set up for battle a bit away from his base, and get ready to move in. Have the FARKS guard your main HP powerhouses, so they are in the front but can still hide behind em. Everything else behind that. When attacking, have several units attacking the HLT and plasma batteries, and use the FARKS to reclaim his Dragon Teeth. When you have a hole in the DT wall, just run into the heart of the base like a maniac. Split your tanks into 2 groups, 1 guarding your long range/high damage units and the other going into the heart of the base. Find the Fusion reactors with your second group of tanks, and try to move the other big group to a place that is easy to defend while hitting the Fusions. Behind buildings is perfect! Kill as much as you can, or kill everything ^^
If there are several lines of defence, make a hole in each DT wall and repeat the same tactics.

''Spread out defence''

Argh The tough one. While the individual towers are easy to beat, you can't run past his defences unless you enjoy suicide. (and if you do, ctrl+a and then ctrl+d will do the trick. A slice of the wrist works well, too.)
Use your army to begin killing the defence step by step, structure by structure. Keep building units, and moving them into the fray (you can use air transports with the repeat command and make them drop the units a little ways from the fight). Once you start getting close to his last line of defence, think of it as a line defence and act accordingly.

''Units defence''

Think army vs army. Don't rush past them with all your units. Your units will spread out and try to go through holes in the enemy's formation. In a word, they are dead meat. If you MUST get to the base, have half of the tanks go around the units.

===Naval Battles===

Naval battles are hard to predict if you don't play island maps a lot, since there are many factors to take into account. Since land units are removed, you have to think in a WHOLE new perspective. No land means that only Sea, Air and Hover units can fight (and LRC of course).
Anyway, try to have air units scouting land and sea, and determine how much AA the enemy has. Ships roam around assaulting other ships, with a mix of subs, sub killers, AA ships and normal ships. Hovercrafts are the unit to use when assaulting land that's a little far from shore. Provide them with an escort consisting of planes and/or ships.

====Ships====
When using ships, have scout ships or planes scout the area in front, then send in subs and sub killers. Use long range ships at the sides to protect anything of value you might have with you (a sea transport or an aircraft carrier). When in battle, try to have the subs run away from sub killers, while your sub killers kill the enemy subs. Your subs should try to attack the most important ship in the area, and then just go crazy.
When facing land, you're pretty much in for an easy win. Just have your ships blow it all up. If you face LRC, take them out first. The rest of it is out of your hands.
Remember if your opponent has air superiority or LRPCs use subs as they can't hit them :)

====Hovercraft====
Use the Army vs Army or Army vs Base strategy here.

''-- addendum by Cain.''

Hovercraft are quite expensive compared to other land units, but are very useful in maps with a bit of water, able to target enemies without worrying about those pesky Goliaths... note that they're much cheaper than ships, anyway.

===Planes===
Hohoho, planes. Fun stuff to attack with. Anyway, most of the strategy involving planes is simple.
First, always attack the AA first, unless you are going to do a suicide mission. Kill the AA with gunships, and use bombers to kill structures. Many players use gunships only, which is a bad idea. Bombers take a little time to master but combined with gunships, they do a very good job. Scout early, so you can quickly see WHAT the enemy has and WHERE he has it. Use gunships to take out AA and act as overall decoys. Have Bombers fly in and bomb the crap out of his Fusion or whatever strategic point, and use the fighters to guard the bombers.
When facing units, do the same.
When facing sea, do the same thing, but add Torpedoes to bombers and gunships.

''-- addendum by Cain''

Know where the enemy commander is! In games where the commander's death is a winning condition, a lot of bombers could just converge on him, killing him on the first run.. especially the 2nd level bombers that have a nice turreted fast targeting laser! Also, gunships could create a diversion to keep the main enemy defences away from your main attack force, or you could use them to make the defences of distracted players shoot their own base...

===Using Terrain===

Using terrain wisely is very important. The issue of a game can depend on a good use of terrain.
First, Line of Sight (LOS) and RADAR. Both are blocked by terrain. So build your radars as high up as possible, otherwise you may not see anything. Use the relief to your advantage to hide an army or your important buildings from enemy radars.
Of course, one can also take advantage of altitude to increase fire range. A couple of Guardians on top of two high hills can easily devastate a small army.
Terrain also helps shield your units against attacks. Therefore, when you're building something high on top of a hill, try placing it a little behind the top. This is like crouching behind a crate where just your head and gun sticks up. But remember that terrain in Spring is deformable and can be leveled by impacts!
Know the climbing ability of your units. Hovercrafts and vehicles have pretty low climbing ability. But if a foe thinks he has sealed up all exits, your K-bots can still climb the mountains where he hasn't put any Dragon Teeth
Another good thing about terrain is that it mentally makes you feel safe. If there is a water barrier between me and the enemy, with 3 land bridges here and there, I probably won't have much ground defence at a location AWAY from the bridges. Presuming the map is pretty flat (like "Flooded Desert") a hovercraft assault would do A LOT of damage, right?

===Energy and all the problems with it===
(in XTA)
As I said before, most level 2 units require energy to move, shoot and operate in general, meaning that if you have no energy to support your army, you can't do anything! You can use this in your favor, by attacking your enemy's Fusions, or
by ''giving'' Metal makers to your enemy when you are attacking him(although Metal makers are now turned off when given to an enemy), or he is attacking you! Things that drain a lot of energy include LRPC, Goliaths, HLT, and most level 2 units.
(/in XTA)

===Paper-rock-scissors?===

Try to look at all units as individuals. Even if I didn't write much about every single unit, know your favorite ones and how to use them effectively in conjunction with the others. You'll find that some units are very complementary. The only real paper-rock relationships are AA and planes... Maybe subs vs sub killers...

I didn't even mention cloaking, radar jamming, troops behaviour facing attacks, mines, etc, etc. The possibilities are immense, but I don't want to spoil your pleasure any longer, so I'll let you discover them by yourself.

'''Have fun !!!'''

----

===Strategy Tips===

* Expand! Metal is scarce. The more you get, the more you can build. Even if you have a good base, making it bigger is not a bad thing.
* Scout! Knowledge is power. You must know what your enemy is planning, and what the enemy knows about you. (Or thinks he knows about you) Check what he has, and what he is building. If he's building aircrafts, do something about it. Look for weaknesses in defense and such. If you or your ally are scouting, don't look away. Gather as much information as possible. ALL buildings once in sight range will remain visible as 'ghost' buildings if this option isn't turned off by the host.
* Radar = GOOD ^^ Radar checks areas for units, increases your units LOS and is, overall, quite helpful. A radar with your army makes a big difference when attacking. But so is Jamming. Jamming is good for sneak attacks. They are cheap, so just build one and make your units guard it.
* Work Together! Often I see allies who just mind their own business and don't care what the other person's doing. DON'T DO THIS!!! Listen to each other, make up a plan. Prepare combined attacks. If there is a 2v2, then it's 2 allies vs 2 allies. Not a FFA with neutral partners. Type h to share units. Left click on your resource bars to auto share resources with allies.
* Power Plants. In order to level out the building costs, it is important to make a smooth transition from the least powerful generators to the most powerful ones in succession. First solar, then Geo, then mobile/mini Fusion then Fusion.
* Check your resource bar. Try to keep a fine line between having too many resources/wasting, and having a nanostall. Use your factories and such accordingly. If you have a lot of resources, try using your old level 1 factories to build some units. Also, try to find the time to build an energy/metal storage...
* Spread out your buildings/units. Since every unit explodes, they damage units close to them. This is especially important with Fusions... (I once saw someone put 13 mobile fusions close to each other... blew up half his base with 2 (!!!) LRPC shots...)
* Queue (yeah, easy word for it too :/) up orders! You can almost win the game by pausing, queuing up some stuff, and then go eat lunch. Not really, but holding shift is good whilst putting up buildings.
* Guard = following and protection. Use planes to guard your tanks, subs to guard your transports, construction units to automatically repair important units and so on. They will choose to attack whatever is hurting their guard object first. You can even do this to structures, for units who are built to move to a unit's position or AA to attack whatever is shooting on the Fusion reactors, etc... Overall, this makes working with several unit types easier.
* Reclaim stuff (sucking it in and transforming it into resources). When you're starting to run low on metal, reclaim the enemy's and your own corpses. Trees give energy, so if you're out of energy in the beginning... You can reclaim a whole area by shift-clicking.
* The key for porcers are to build LRPC. Or even better, build a nuke and use LOTS of planes to kill his anti-nuke. Then BOOM! Also as you have way loads more metal and space to move in than your opponent, you can easily afford 2 nukes. An anti-nuke can't deal with 2 nukes heading towards it(and if you aim the nukes at the anti-nuke...^^!
* Experiment! I suggest you go into single player and try every unit. Use commanders for arm, and small battle (watch that Krogoth!) for core. Try every approach to a problem. Remember, just because a unit is good, it's not invincible. Also, try how much metal and energy a building uses while in operation. For instance, a level 1 factory uses about 50 energy and 5 metal. This varies depending on what you build. This could help you prevent nanostalling.
* Several types of factories. Yeah, even if it costs money. An advanced building costs as much as a Bulldog or 2... You've got the time, and the money. Build it.
* Raid. Take the Weasel or a couple of Peewees on a cruise right by the enemy's mexes. Having trouble finding them? Type F4 to see where the ground is drained ^^ (Edit) This doesn't apply anymore, but you can still see where a mex is by trying to build one of your own there. If you can't, there's already one on the spot... A tip is to stay away from the Commander, or use buildings as hostages. Hide behind stuff and kill it off, then move on. If you're sure you're going to die, move close to a building and self-destruct.
* Just because Peewees are better then AK's doesn't meant that AK's are useless. (And so on). In fact, no unit is useless. If you believe it is, try it once. On what it was meant to do.
* Mix armies. Oh boy, if you haven't heard this one a thousand times before, you've only been playing Half-Life for the last 7 years or something. Even if Goliaths rule, a couple of missile units will make them much more effective.
* FARKs are useful in combat. Always have 1-3 with you. Reclaiming DT, or doing what they were meant to do: Repair -.-* (also, when I say FARKs somewhere in the guide, construction units work too...)
* Ask questions. No one is going to laugh at you. And if someone does, he's an ass and should be paid no mind. No question is too stupid. Just don't expect anyone in the heat of a battle to answer to ''how do I play''?.
* Learn! If you lost, use the replay to watch the game and try to understand why you died. What did the enemy do better than you? What was their key to winning? And so on.
* ''The Readme'' file has some cool keyboard shortcuts... check it out.
* Develop! Are you a programmer, a 3D design artist or just some regular Joe? Come to the forum for a talk, chatter, and make wacky suggestions! In the end you may contribute to making Spring better! Remember, Spring is open source. So just dive into there and replace AK's with flying monkeys in space suits or whatever.
* Try having some good music on when playing. It can give you a good kick. I recommend the War of the Worlds (the strategy game, yes it exists) Eve of the War Another great choice is, of course, [http://www.fileuniverse.com/?page=listing&ID=54 the original TA music]! You can choose whatever music you like, though.
* Need more strategy and tips? Since Spring is a remake of TA, any TA strategy guide works...
* LAST BUT NOT LEAST: '''Don't get too serious. It's only a game.'''

This guide was written by Kixxe before everyone edited (and improved!) it mercilessly.

[[Category:Playing]]

Springie

2026-03-05T01:50:53Z

Qrow: Created page with "Springie is now defunct."

Springie is now defunct.

SPADS

2026-03-05T01:50:23Z

Qrow: Created page with "== Support == *[https://github.com/Yaribz/SPADS/blob/master/INSTALL.md Installation] *[https://springrts.com/phpbb/viewtopic.php?f=1&t=17130 Discussion in Spring forums] *[https://github.com/Yaribz/SPADS/issues Issue tracker] == Reference documents == *[http://planetspads.free.fr/spads/doc/spadsDoc.html Commands and settings reference guide] *[http://planetspads.free.fr/spads/conf/templates/ Configuration templates] *[https://github.com/Yaribz/SPADS/wiki/SPADS-official-..."

== Support ==
*[https://github.com/Yaribz/SPADS/blob/master/INSTALL.md Installation]
*[https://springrts.com/phpbb/viewtopic.php?f=1&t=17130 Discussion in Spring forums]
*[https://github.com/Yaribz/SPADS/issues Issue tracker]

== Reference documents ==
*[http://planetspads.free.fr/spads/doc/spadsDoc.html Commands and settings reference guide]
*[http://planetspads.free.fr/spads/conf/templates/ Configuration templates]
*[https://github.com/Yaribz/SPADS/wiki/SPADS-official-plugins-list Official plugins list]

== Memos ==
*[https://github.com/Yaribz/SPADS/wiki/SPADS-update-procedure-for-new-Spring-version SPADS update procedure for new Spring version]
*[https://github.com/Yaribz/SPADS/blob/master/UPDATE.md Manual procedure for major SPADS update]
*[https://github.com/Yaribz/SPADS/wiki/SPADS-plugin-install-notes Plugin installation notes]
*[https://github.com/Yaribz/SPADS/wiki/Balancing-teams-on-a-LAN-server Balancing teams on a LAN server]

== Beyond All Reason specific ==
*[https://github.com/Yaribz/SPADS/wiki/Beyond-All-Reason-LAN-server-quick-install-guide-(Windows) Beyond All Reason LAN server quick install guide (Windows)]
*[https://github.com/Yaribz/SPADS/wiki/Beyond-All-Reason-LAN-server-quick-install-guide-(Linux) Beyond All Reason LAN server quick install guide (Linux)]
*[https://github.com/Yaribz/SPADS/wiki/Beyond-All-Reason-client-configuration-to-connect-to-a-LAN-server Beyond All Reason client configuration to connect to a LAN server]
*[https://github.com/Yaribz/SPADS/wiki/Beyond-All-Reason-LAN-server-customization Beyond All Reason LAN server customization]
*[https://github.com/Yaribz/SPADS/wiki/Beyond-All-Reason-offline-LAN-server-guide Beyond All Reason offline LAN server guide]

== Development ==
*[https://github.com/Yaribz/SPADS Source code]
*[http://planetspads.free.fr/spads/repository/CHANGELOG Detailed changelog]
*[http://planetspads.free.fr/spads/doc/spadsPluginApiDoc.html Plugin API documentation]
*[https://github.com/Yaribz/SPADS/wiki/SPADS-plugin-development Plugin development tutorials (Perl)]
*[https://github.com/Yaribz/SPADS/wiki/SPADS-plugin-development-(Python) Plugin development tutorials (Python)]

__NOTOC__
[[Category:Autohosts]]
[[Category:SPADS]]

Links

2026-03-05T01:50:02Z

Qrow: Created page with "Development < {{FULLPAGENAME}} = Community Links = *Associated Development Groups - various forums etc *[http://springfiles.springrts.com/ SpringFiles] - download page for maps & games *[http://weblobby.springrts.com WebLobby] *mumble server *[http://feeds.feedburner.com/SpringCommunityHeadlines SpringInfo Community News] *[http://replays.springrts.com/ Spring Replays] = Development Links<br/> = *[htt..."

[[Engine Development|Development]] < {{FULLPAGENAME}}

= Community Links =
*[[Associated_Development_Groups|Associated Development Groups]] - various forums etc
*[http://springfiles.springrts.com/ SpringFiles] - download page for maps & games
*[http://weblobby.springrts.com WebLobby]
*[[mumble|mumble server]]
*[http://feeds.feedburner.com/SpringCommunityHeadlines SpringInfo Community News]
*[http://replays.springrts.com/ Spring Replays]

= Development Links<br/> =

*[http://stacktranslate.springrts.com Stacktrace Translator]
*[http://springrts.com/mantis/ Mantis] - place to report engine bugs, problems & (minor) feature requests
*[http://buildbot.springrts.com/waterfall?reload=30 buildbot waterfall]
*[http://springrts.com/dl/buildbot/default/ spring engine development builds]
*[[Rapid]] - the games download api

= Repo. Links =
== Engine & Content ==
*[https://github.com/spring Spring github repo]
*[[Gamedev:PublicRepos | Game Repos]] - Publicly readable game repos
=== [https://github.com/jk3064/ jK's lua repos] ===
*[https://github.com/jk3064/Map-Blueprint Map Blueprint] - basic container to create new maps ([[MakingMapsWithBluePrintAndMapConv |see]])
*[https://github.com/jk3064/chiliui Chili] - a lua based gui framework
*[https://github.com/jk3064/chili_loadscreen Chili Loadscreen] - a chili based loadscreen
*[https://github.com/jk3064/Custom-Unit-Shader-Framework CustomUnitShaders] - a lua based per-unit shader framework (includes normalmap support)

== Lobby Server & Clients ==
*[[uberserver]] - the lobby server
*[http://code.google.com/p/zero-k/ ZKLobby's google code page] - a .net lobby
*[[SpringLobby]] - a wxWidgets lobby
*[https://github.com/cleanrock/flobby flobby] - a FLTK based lobby (linux only)

== AutoHosts (dedicated servers) ==
*[[SPADS]]
*[[Springie]] - mainly used by ZK

== Content Downloaders ==
*[[pr-downloader]] - an unified download app & lib (can dl from plasma, rapid, ...)
*[https://github.com/spring/RapidTools rapid server tools] - tools to create a rapid repository
*[[Plasma]] - a torrent based download system (mostly for maps, games should use rapid)

== Tools ==
*[[Upspring]]
*[[MapConv]]
*[[MapConvNG]]

= SpringFiles API =
*[https://springfiles.springrts.com/json.php json api]
*[https://github.com/springfiles/upq/blob/master/doc/exampleclient.py example client]

= Miscellaneous =

*[https://packages.springrts.com Rapid Upload Interface] - Mappers & GameDevs can upload their files via it

= Statistics =

*[http://zero-k.info/stats/ lobby stats]

[[Category:Development]]

Building Spring on Buildbot

2026-03-05T01:48:47Z

Qrow: Created page with "Development < Building Spring < {{FULLPAGENAME}} == Current == See Buildbot:Gentoo or Buildbot:OSX for how to set it up. ==New (since 0.82)== Watch progress and errors of builds: http://buildbot.springrts.com/waterfall The outcome of builds can be found here: http://springrts.com/dl/buildbot/default/ ==Old (until 0.81)== The spring build-bot is a server that is setup to compile spring automatically, and is usabl..."

[[Engine_Development|Development]] < [[Building_spring|Building Spring]] < {{FULLPAGENAME}}

== Current ==
See [[Buildbot:Gentoo]] or [[Buildbot:OSX]] for how to set it up.

==New (since 0.82)==

Watch progress and errors of builds:

http://buildbot.springrts.com/waterfall

The outcome of builds can be found here:

http://springrts.com/dl/buildbot/default/

==Old (until 0.81)==

The spring build-bot is a server that is setup to compile spring automatically, and is usable by everyone.
It currently supports compiling for:
* Windows 32bit with TDM-MinGW (default)
* Windows 32bit with MinGW
* Windows 64bit with MinGW
* Linux with GCC

You may use the build-bot from within your Spring lobby client. Join channel '''#buildserv''', type ''!help'' and follow the instructions. Most useful commands are ''!rebuild'' and ''!translate''.

It is maintained by bibim and mainly used by devs for testing if their changes would compile on other systems too, but as it also generates windows installers, that can be downloaded by everyone, it can be also useful for casual users willing to try the latest changes to spring.

The outcome of builds can be found here:
[http://buildbot.eat-peet.net/spring/ http://buildbot.eat-peet.net/spring/]

[[Category:Buildbot]]

Building Spring Cross Compiled

2026-03-05T01:48:11Z

Qrow: Created page with "Development < Building Spring < {{FULLPAGENAME}} __TOC__ Cross-compiling allows you to build for other platforms than the machine you are building on. You can, for example, compile Windows 32-bit binaries on a Linux 64-bit machine. = Obtaining the Source = {{Obtaining_The_Source_Code}} = CMake cross compiling = == Setting up the cross compiler == The compiler is called MinGW, which is a port of GCC to windows. The version..."

[[Engine_Development|Development]] < [[Building_spring|Building Spring]] < {{FULLPAGENAME}}

__TOC__

Cross-compiling allows you to build for other platforms than the machine you are building on. You can, for example, compile Windows 32-bit binaries on a Linux 64-bit machine.

= Obtaining the Source =

{{Obtaining_The_Source_Code}}

= CMake cross compiling =

== Setting up the cross compiler ==

The compiler is called MinGW, which is a port of GCC to windows. The version are going to need is MinGW GCC 4.4.0 (which is MinGW 2.7) or later. Most Linux distributions come with MinGW-GCC 4.1.2 only in their standard repos (Summer 2009), so you have to do extra work to get 4.4.0+.

===Gentoo===
<code><pre>
emerge crossdev
EXTRA_ECONF="--with-dwarf2 --disable-sjlj-exceptions" crossdev -t i686-mingw32
</pre></code>
Additional instructions can be found [http://en.gentoo-wiki.com/wiki/Crossdev here] or [http://psas.pdx.edu/GentooCrossCompilerHowto/ here].

===Ubuntu 10.04===

Use the repository specified [https://launchpad.net/~tobydox/+archive/mingw mingw ppa], and then install the required packages:

<code>
sudo add-apt-repository ppa:tobydox/mingw
sudo apt-get update
sudo apt-get install mingw32-x-binutils mingw32-x-gcc mingw32-x-runtime mingw-x-w32api
</code>

===Ubuntu 11.10===

see the section [https://github.com/spring/spring/blob/develop/buildbot/README.markdown Recompile MinGW package with dwarf2 exceptions instead of sjlj exceptions].

===Other distros===

You have to find a way yourself, or use [http://www.profv.de/mingw_cross_env/#tutorial these] instructions to get the sources and compile it yourself. When doing so, make sure to use these build flags for gcc:

<code>
--with-dwarf2 --disable-sjlj-exceptions --enable-shared --enable-version-specific-runtime-libs
</code>

you can add them under ''src/gcc-core.mk''.

''Note:'' This method will most likely not work anymore, as the checksum of the build files is checked by the makefile.

Alternatively, use this line to compile all the deps (which will then be used instead of mingwlibs):
<code><pre>make zlib boost devil ogg vorbis openal freetype sdl glew gcc</pre></code>

== Getting Spring's windows dependencies ==

These are called '''mingwlibs'''. How to get them is described below.

=== official MinGW - dwarf2 (default) ===
You can get it here ('''Download Source''' button, or use ''git''):
* [http://github.com/spring/mingwlibs '''mingwlibs''']

=== TDM MinGW - sjlj (alternative) ===
http://github.com/spring/spring/downloads

== Setting up your directories ==
Here is my recommended layout

<pre>
~/spring-xcompile/ (or wherever you want to put it all)
___ spring/ (the spring source)
___ win32/ (your target platform)
_______ build/ (the build files for your target will go here)
_______ final/ (the compiled binaries and libs will be installed here)
_______ libs/ (mingwlibs, the target libraries you just downloaded)
_______ win32.cmake (see below)
</pre>

== Create your cmake toolchain ==
Create the toolchain file:
<code><pre>pico "~/spring-xcompile/win32/win32.cmake"</pre></code>
=== Example toolchain file ===
An example should be self-explanatory:
<code><pre>
# the name of the target operating system
SET(CMAKE_SYSTEM_NAME Windows)

# which compilers to use for C and C++
SET(CMAKE_C_COMPILER i686-mingw32-gcc)
SET(CMAKE_CXX_COMPILER i686-mingw32-g++)

# here is the target environment located
SET(CMAKE_FIND_ROOT_PATH /usr/i686-mingw32)

# the spring mingw32 dependencies
SET(MINGWLIBS ~/spring-xcompile/win32/libs)

# the path that make install will use to put the final binaries
SET(CMAKE_INSTALL_PREFIX ~/spring-xcompile/win32/final)
</pre></code>

Pass this with <code>-DCMAKE_TOOLCHAIN_FILE=~/spring-xcompile/win32/win32.cmake</code> to cmake or select it in the gui to make a cross-compilation (see below).

=== Some Options Explained ===
* '''MINGWLIBS''': absolute path to the directory where [[Building_Spring_Cross_Compiled#Getting_Spring.27s_windows_dependencies |'''mingwlibs''']] are located
* '''CMAKE_INSTALL_PREFIX''': installation prefix (defaults to ''/usr/local'') defines the base directory for installing
* '''DATADIR''', '''LIBDIR''', '''BINDIR''': where to install data, libraries or binaries (relative paths are based on ''CMAKE_INSTALL_PREFIX'', absolute paths are absolute (''DESTDIR'' is still respected))
* '''APPLICATIONS_DIR''', '''MIME_DIR''', '''PIXMAPS_DIR''': where to install freedesktop-files (icons, mime-types and application-description)

=== Further reference ===
* [http://www.vtk.org/Wiki/CMake_FAQ CMake FAQ]
* ''man CMake''
* [http://www.cmake.org/HTML/cmake-2.6.html CMake documentation] (long!)

== Run CMake ==

=== The GUI method ===
CMake offers a nice Qt4 gui to ease the following steps (to use the gui explained here, cmake must be at least version 2.6.1). Doing so should be straightforward:
* run <code>cmake-gui</code>
* select source directory
* select (and/or create) build directory where temporary files are stored
* hit configure button
* choose your build type:
** Unix makefile if you are using linux and want to compile linux executables
** mingw makefiles if you are working on windows
** Unix makefile with cross compiler setup to cross-compile mingw32 executables, you have to select the toolchain file you want to use (see below)
* configure variables to your need (move the mouse over the options and read the tooltip for further informations on them and or see Section "Options")
* push generate button
* open commandline and do "make" and "make install"

=== The commandline method ===

* cd to build directory
<code><pre>cd ~user/spring-xcompile/win32/build</pre></code>
* <code>cmake <path to source tree> <options></code> where:
** <code><path to source tree></code> is the path to the spring source directory
** <code><options></code> are defined like <code>-D<option name>=<value></code>

* IMPORTANT: depending on your settings you may need to run this command twice. It can't hurt so I recommend doing it anyway.
<code><pre>cmake "~user/spring-xcompile/spring" "-DCMAKE_TOOLCHAIN_FILE=~user/spring-xcompile/win32/win32.cmake"</pre></code>
* run <code>make</code> and <code>make install</code>
<code><pre>make spring && make install-spring DESTDIR=~user/spring-xcompile/win32/final</pre></code>

to show other build targets type: <code>make help</code>

== Package Maintainers Note: ==
* doing <code>make install DESTDIR=/some/path</code> will install spring in the specified place, putting files in subdirectories like configured. This may be helpful when making packages so Spring don't get installed on your system for real (see also CMake FAQ [[http://www.vtk.org/Wiki/CMake_FAQ#Does_CMake.27s_.22make_install.22_support_DESTDIR.3F]]).
* You need to update the mime database (<code>update-mime-database</code>) and the kde database (<code>kbuildsycoca</code>) after installing to make the system aware of the newly installed mime types and desktop shortcuts.

==Buildbot==
For setting up a buildbot slave, see: {{sourcelink|file=buildbot/README.markdown}}

[[Category:Linux]]

Create map texture with povray

2026-03-04T02:12:03Z

Qrow: Redirected page to Tutorial:MapWithPOVRay(Tinnut)

#REDIRECT [[Tutorial:MapWithPOVRay(Tinnut)]]