Zero-K - User contributions [en]

Magpie

2023-12-06T18:24:15Z

Darloth3: Better than nothing, right? There's probably a tool to generate these, but instead, I copied it by hand from the game infobox and the lua definition.

The '''{{PAGENAME}}''' is a tactical strike bomber from the [[Airplane Plant]].{{ Infobox zkunit
| name = Magpie
| defname = bomberstrike
| description = Tactical Strike Bomber
| image = http://manual.zero-k.info/unitpics/bomberstrike.png
| icontype = bomberskirm
| cost = 220
| hitpoints = 900
| movespeed = 252
| sight = 780
| altitude = 240
| weapons =
{{ Infobox zkweapon
| name = Heavy Missiles
| type = MissileLauncher
| damage = 180 × 2
| reloadtime = 18
| range = 550
| aoe = 24
| homing = 75
| projectilespeed = 400
}}
}}==Description==
The Magpie launches short-range homing missiles at ground and air targets. It makes up for its low damage and long reload time by boasting the range and manoeuverability to hit dangerous targets and make it back to base.

==Tactics and Strategy==
(none yet)

{{Navbox units}}

Airplane Plant

2023-12-04T14:08:10Z

Darloth3: Added missing link to magpie. I've no idea how a unit page is generated, but at least now people will know there ought to be one.

The '''{{PAGENAME}}''' is a factory that produces airplanes.{{ Infobox zkunit
| name = Airplane Plant
| defname = factoryplane
| description = Produces Airplanes
| image = http://manual.zero-k.info/unitpics/factoryplane.png
| icontype = facair
| cost = 700
| hitpoints = 4000
| sight = 273
| abilities =
{{ Infobox zkability construction
| buildpower = 10
}}
}}==Description==
The Airplane Plant offers a variety of fixed-wing aircraft to suit your needs. Choose between multi-role fighters that can double as light attackers or specialized interceptors, and between precision bombers for taking down specific targets or their saturation counterparts for destroying swarms. The plant also comes bundled with one rearm pad.

The Airplane Plant builds:<dl>
{{icon unit def|planecon|Crane|Construction Aircraft}}
{{icon unit def|fighter|Swift|Multi-role Fighter}}
{{icon unit def|planeheavyfighter|Raptor|Air Superiority Fighter}}
{{icon unit def|unknown|Magpie|Tactical Bomber}}
{{icon unit def|bomberprec|Raven|Precision Bomber}}
{{icon unit def|bomberriot|Phoenix|Saturation Napalm Bomber}}
{{icon unit def|bomberdisarm|Thunderbird|Disarming Lightning Bomber}}
{{icon unit def|bomberheavy|Likho|Singularity Bomber}}
{{icon unit def|planescout|Owl|Radar/Sonar Plane}}
{{icon unit def|planelightscout|Sparrow|Light Scout Plane}}
</dl>{{clear}}
==Tactics and Strategy==

The Airplane Plant provides the most unique array of units of any factory in Zero-K; the Planes are more like a support force, as opposed to combat units. Both the speed of the Planes and their first-strike capability is unparalleled. The Swift is the Planes' main air-to-air option, while the Raven, Thunderbird and Likho bombers punish any poorly-covered ground forces.

In contrast to the Gunships, the Airplane bombers deliver their damage in a very short period of time, so anti-air which relies on prolonged engagements is less effective against them. On the other hand, the bombers have to return to base and rearm before making another run. The Swift fighter relies on similar hit-and-run tactics against enemy air forces.

=== Example Unit Combinations ===

Once your fleet of Swifts is large enough, add a few Raptors for more sustained damage. Make sure your Swifts are in position to protect the Raptors' flank and rear.

Fly a Swift or two over enemy territory before a bombing run to soak up a few missiles and scout for an unexpected concentration of anti-air. Losing a Swift or two is far less painful than losing a Likho.

Follow up a Thunderbird strike with swift ground units such as the [[Glaive]] or [[Scorcher]] to capitalise while the enemy is disarmed.

Use Owls to scout for your artillery pieces like the [[Sling]], [[Emissary]] or [[Lance]].

Owls jam enemy radar in an area around and below them. Order a line of Owls to fly circles behind your team's front lines to provide radar, line of sight, and to hide your allies from enemy radar.

=== Bombing Mechanics ===

The Airplane Plant provides its owner with access to four bombers, being the [[Raven]], [[Phoenix]], [[Thunderbird]], and [[Likho]]. Upon attacking they will drop their payload, which differs between the different types of bomber.

*The [[Raven]] will drop a single gliding bomb, dealing 800 damage.
*The [[Phoenix]] will drop 15 napalm bomblets, each doing 25 damage on impact and another 150 damage per unit hit as it burns. The bomblets are dropped over a wide area, which means small units may dodge the majority of bomblets, whereas large groups may be hit multiple times.
*The [[Thunderbird]] releases disarming lightning from its belly towards the ground in a line, with the center of the line at the ordered point of attack or target unit. The Thunderbird is free to change direction while firing, and can be manually fired (default 'D').
*The [[Likho]] drops a single homing implosion bomb dealing approximately 2000 damage.

The four different bombers will move differently during their payload release. As mentioned above, [[Thunderbird]]s will happily continue flying in a straight line unless ordered not to. The [[Phoenix]] is the exact opposite, and will prefer to drop its payload in a J-shape unless given a move order to continue on in the direction it came from. The [[Likho]] launches its bomb at 500 range before turning around immediately. The [[Raven]] will simply drop its bomb and turn around.

After releasing their payload, bombers will seek out the closest [[Airpad]], Airplane Plant, or [[Reef]] aircraft carrier to rearm. If they are given a move order after attacking, either by putting a move order into their command queue or by manually ordering them to move, they will first complete their move order before proceeding to a repair pad. If they are instead given a second attack order, they will first return to a repair pad to rearm before executing this attack.

=== Bombing Strategy and Tactics ===

====General tips:====

*When selecting Ravens and Likhos, a line on the right of the selection panel will inform you about how much damage your total selection can perform in one run (Burst Damage). Use this to gauge whether your currently selected bomber wing can destroy the high value target of your choosing (A default strike commander, for example, takes 4 Ravens).
*Use move orders after bombing to make your bombers take the shortest way out of enemy anti-air coverage. Often it is safer to make a 90 degree turn and fly out to the side than to turn the full 180 degrees inside enemy anti-air cover.
*Raven bombs will pass through water surfaces, allowing you to bomb submerged units. Phoenix bomblets explode on the surface.
*Owls provide sonar coverage as well as radar, making them invaluable for spotting submerged units.
*Be careful bombing around EMP units such as [[Venom]]s or [[Faraday]]s! Stunned planes will slowly drift down to the ground, where they can be shot to pieces by any old unit that happens by.
*Using the 'Force fire' command (Default {{key press|F}}), and holding down the left mouse button allows you to draw a circle. Release to order your bombers to attack enemy units inside this circle in turn.
*Hold down {{key press|Ctrl}} while issuing the above command to tell your bombers to pick a unit inside the circle to bomb. This distributes your bombers between units. It is especially useful against [[Lotus]]es, [[Picket]]s, or light mobile units which all do not warrant multiple [[Raven]] bombs. Consider using this with [[Phoenix]]es to spread them over a larger mass of enemy units.
*Use the Area Attack command (Default {{key combo|Alt|A}}) to designate an area in which to bomb. When enemy units enter this area, they will be bombed by your bombers. When there are no enemy units to be found, your bombers will bomb random points of terrain in the area. Consider combining with [[Phoenix]]es to hunt down suspected cloaked units.

==== Raven tips: ====

[[Raven]]s are the workhorse of the Airplane Plant. They're the cheapest bombers, they deal a lot of damage, and have the most hit points for their cost.
*Sometimes it's worth it to channel your inner World War 2 British bomber command officer and sacrifice some of your Ravens to take out an important enemy target. With five ravens you can bomb a [[Razor]] anti air turret to pave the way for more bombers to follow them. Or you can strike at a [[Singularity Reactor]] deep within enemy territory. If five of your bombers make it through, you will cripple your enemy's economy and perhaps take out a large portion of their base. Or if your allies are facing a particularly deadly unit, like a [[Dante]], you could turn the tide in favour of your allies with a well-timed bomb run.
*If your enemy pushes out from under their AA cover, a quick wing of Ravens using the spread attack command (Default {{key combo|Ctrl|A}}) can quickly soften the enemy units up for a follow-up by ground forces, or take care of the units on their own if used in sufficient numbers.

==== Phoenix tips: ====

[[Phoenix]]es are more vulnerable than other bombers. They are also more dangerous to vulnerable units.
*While the low initial damage of the Phoenix is underwhelming, the 10-second burn can make quick work of lighter units like [[Dart]]s even when they dodge most initial damage.
*Burn damage will reset the countdown for units with regenerative abilities like [[Glaive]]s or [[Reaver]]s, as well as keep units with a cloak from disappearing from sight.
*Be careful when using Phoenixes around allied units, as the same properties that make them useful against enemy hordes make them a liability in a chaotic front line.

==== Thunderbird tips: ====

[[Thunderbird]]s do not deal damage themselves, but provide utility on the battlefield that can make the difference between a successful assault or a complete catastrophe.
* If you can spare the time to micro, it is often much more effective to manually give your Thunderbird move orders and to deploy its lightning attack (Default {{key press|D}}) when it is going to be most effective.
* Do not hesitate to inform your team that you're about to disarm the units they're fighting, so they can rush them just as you finish your attack run.
* Be careful not to fly over allied units on your attack run. There's not much point to disarming your enemies if your allies are also disarmed. Though sometimes it can be worth it just to buy your team some time to react.

==== Likho tips: ====

The [[Likho]] is your heavy-duty end-game bomber. It can survive enemy fire that would destroy two [[Raven]]s, but costs as much as 6.5 of them. Depending on what you find yourself having to deal with, you may be better off with more Ravens!

*The Likho is especially useful against units that like to clump together into balls, like units from the [[Shieldbot Factory]], [[Ravager]]s, and [[Blitz]]es.
*The Likho's large cost means that it's a prime target for reclamation if you do lose it. Try not to lose it over enemy territory! If possible, lose it as close to your own front lines as you can! Better still, do not lose it at all.
*The homing bomb of the Likho means it's much less likely to miss moving targets than the bombs the Raven drops. This also means it doesn't have to get so close to the enemy and can be more safely used against units with low range but high damage like [[Reaver]]s, [[Mace]]s, or [[Ogre]]s.

=== Beating Airplanes ===

Anti-air units or structures which deliver high burst damage are generally more effective against Planes than those with sustained damage. The [[Picket]] is generally preferred over the [[Hacksaw]] due to its larger range and flexibility to engage ground targets. The range of the [[Chainsaw]] and [[Artemis]] makes them effective against any air threat, though they are more expensive.

You'll generally need a few mobile anti-air units to shoot down bombers, although the [[Flail]], [[Crasher]], [[Vandal]] and [[Angler]]'s high burst damage is helpful here.

The most important thing to keep in mind when playing against Planes is not to over-extend. Valuable units may be sniped by Ravens, and if you move a large raiding group or army beyond the range of your anti-air it will likely be disarmed by a Thunderbird and destroyed. Don't stick anything outside anti-air range unless you're prepared to lose it. The best defence against bombers is to have your own Swift planes, since they are fast enough to defend you anywhere on the map.

If you are using Gunships against a player with Planes, don't move your anti-ground gunships away from anti-air protection unless you're prepared to lose them. Try to make the Airplane player engage you in a direct fight, since your air-to-air units are tougher than theirs.

If you are playing the Airplane mirror match-up, try to have more Swifts than they do, while still making things happen in the ground war using the cheaper bombers if you can (Raven, Phoenix and Thunderbird). Hold your Swift boost in reserve as long as possible to counter enemy bombing runs or to escape from a losing fighter battle.

{{Navbox buildings}}

Blender To Zero-K

2020-10-21T18:25:49Z

Darloth3: Fixed mistakes, expanded bits, specified version of mod file.

Here is a tutorial covering all of the steps to make or edit a model in [https://www.blender.org/ Blender] (a free 3d modelling program) and transfer it to the Spring engine, then have Zero-K load it as a mutator so you can test it in-game.

The contents page here will also act as a quick reference for all of the necessary steps, in order:

__TOC__

== Make or Edit the model in Blender ==
=== Setting up Blender for use in Zero-K ===
If you are totally new to blender there are a few things you probably ought to do to set up blender for use with Zero-K. Additionally, this tutorial will assume you are using left-click to select (the new default) and a fairly typical window layout similar to the default.

Blender comes with several add-ons and scripts, not all of which are enabled by default. While there are many additional ones you might have to pay for that could prove useful (meshmachine, decalmachine and hard ops are probably the most well known three) there are a few free add-ons you may wish to consider. You should absolutely go to the Edit->Preferences->Add-ons submenu and enable Node Wrangler, and Looptools.

To import s3o models from spring, you will need an addon which can be found [https://github.com/sanguinariojoe/blender_s3o_import here]. You need to download the python (.py) file and then use the Install button inside blender's add-ons submenu, pointing it at that .py file, so that blender knows how to import .s3o models. Make sure to enable the add-on after installation.

If you want to export animations, you will also need [https://github.com/Anarchid/blender2lus this] animation exporter, though the output it produces will likely still require manual adjustment and will not be covered by this tutorial.

=== Importing a model (optional) ===
With the s3o importer installed and enabled, you should be able to import s3o models from spring into blender by using the File->Import->s3o option. Then navigate to your model file and select it.

s3o models often come in rotated to one side, as Spring uses Y-axis-up and Blender uses Z-axis-up. You can rotate them to look right in Blender, and then when exporting them there are options to deal with this so that they export rotated correctly.

If the importer can find them, it will also import textures and the UV map along with the model. The texture files may need to be placed appropriately or in the same directory as the model file for this to work.

=== Importing textures ===
To open a texture you need to set a window to either the Image Editor or UV Editor mode, and then press the Open button in the top menu bar. This will bring up a file menu where you can select a texture to bring into Blender. Blender supports .dds textures by default, as well as most other image formats.

You can certainly import any old texture and work with it, but if you are importing textures already used by Spring you should know that they are somewhat unusual.

Spring has two separate texture formats. The first of these, referred to as tex1 or colour texture, uses Red Green Blue (RGB) channels to store colour data, and Alpha (A) to store whether that part of the file is teamcolour or not. This means that by default a tex1 texture looks mostly blank(transparent) with some odd black bits scattered around. You can fix this in Blender by scrolling the menu bar (hold middle button with cursor on menu, drag mouse to side) all the way to the right, and clicking the little drop down which says Display Channels [[File:Blender_display_channels.png]]. By default it is set to ''Colour and Alpha'' but you should set it to ''Colour'' when working with tex1 files to ignore the alpha channel.

Tex2 files are the ones in greenyblue with bits of red. In those files the Red channel is how much that part of the texture emits light, the Green channel is how rough or smooth that part of the texture is (which determines how it reacts to light), and the Blue channel is how metallic and reflective that part of the texture is. Areas which are cyan (full green and full blue) are mirror-smooth metal, so reflect the environment perfectly. These should always have their colourspace set to non-colour data as they use each channel separately. You can find that option in the right hand popout menu when in an image editor viewing them (shortcut key N by default) under the Image tab.

You may also need or want to use Normal map textures, which are the ones that look mostly blue with some oddly coloured parts around the edges. Whenever you use these normal map textures you should always change the colourspace to non-colour data as it can cause visual errors if you do not, since it will process the channels differently in the render pipeline.

If nothing in the scene uses your texture it will be discarded from the file when you save and exit. You may click the shield icon next to the file name to prevent this, if you want to have the textures kept around even with nothing using it. As long as you've assigned the texture to a material, and the material to a model (see below) this will not be a problem, but it's useful to know this option exists and why a texture might be dropped.

Blend files do not by default contain the textures referenced in them, but you 'can' optionally pack the textures into them for easy transfer between users or computers. Explore the File->External Data menu for those options.

=== Modelling for Zero-K ===
There are not many special considerations when modelling for Zero-K, and a general explanation of modelling and blender is too detailed to go here. However, you could consult tutorials such as [https://www.youtube.com/watch?v=7MRonzqYJgw&list=PLn3ukorJv4vs_eSJUQPxBRaDS8PrVmIri Grant Abbitt's beginner series] or [https://www.youtube.com/watch?v=1jHUY3qoBu8 Imphenzia's introduction and low poly modelling] tutorial.

Generally, you should attempt to keep the number of triangles used in a model as low as is reasonable. That number varies depending on how frequent the unit is planned to be - a commander or other functionally unique unit would be fine with up to 30,000 triangles, but for a very spammable unit such as a flea this would be extremely excessive, as you can build a vast number of fleas. Something in the region of 500-1000 would be more appropriate, with less being ideal as long as the model still looks good.

The size of the model (or part of model) and how visible it is also has an impact on how many polygons you should be using. A large model covering a lot of screen space should use more polygons and texels than a small one or a part of the model that people rarely or never see.

=== Texturing for Zero-K, and Spring texture oddities ===
As mentioned earlier, spring uses two textures per model and cannot use multiple UV Maps, cannot use vertex colours, and cannot use additional textures other than a normal map.

The tex1 format covers the diffuse colour and whether a pixel is teamcoloured or not, wheras tex2 covers the emissivity, roughness, and metalness of the model in its RGB channels respectively.

Remember that most DDS normal maps are slightly different from typical OpenGL normal maps, and adjust appropriately as needed. Typically inverting the Red and Green channels does the trick.

If you import a texture then the importer will set up the nodes for you, however, if you are starting from scratch then you probably just want to replicate this node setup. This mostly approximates what Spring will do in-engine, giving you a workable preview in Blender when you use a lookdev(Material Preview) view mode.

[[File:Spring_shader.png]]

There are three textures referenced here, which in this case happen to be atlas textures which can be reused for multiple models. The core_color.dds is tex1 and has colours and teamcolours - the alpha channel is split off, inverted, and used to colour the alpha areas green (you can click the green colour to replace it with any other colour, if you like).

The core_other.dds is the tex2 file, so it is split into RGB channels and each of these channels appropriately processed and connected to the relevant part of the material.

Finally the core_normals.dds contains a direct-x formatted normal map, so it is converted to an openGL format by inverting just the Green channel and is then passed through the normal calculation node to convert the image into a vector map, and then the vector map passed to the shader.

TODO: Provide a blend file here that already has this material set up, just need to plug in textures. Or just include atlas texture. Airpad_packed.blend is sadly larger than 2mb so the wiki will not host it.

== Export the model to .dae format ==
Nowadays Spring can read .dae (Collada) files directly via the use of Assimp (Asset Importer). This means the export process is reasonably simple.

Either clean your scene of everything you do not want to be exported, or select only the things you want exported. Go to the File->Export menu and select Collada (.dae) format. A file browser will open with various export settings on the right hand side.

You should pick Selection Only from the Main tab of export options if you want to limit it to selection.

Make sure that the orientation settings are correct. You want to tell the exporter what axes you've been modelling with, not the axes you're looking for. These are the default options and should usually be right, Spring/Assimp will then adjust them for use in engine, but if after checking things in Spring your object is oriented wrongly, you can try adjusting these and exporting again. If all else fails, you can parent the root object(s) to an empty placed at the origin and rotate that. [[File:collada_default_export.png]]

=== A note on animation ===
Although Collada (.dae) files do support exporting animation, you should not do this as Spring cannot read the animation data. Instead, animations in Zero-K are handled by a lua animation script known as LUS.

Although you cannot export the animations to Collada, you can still do your animations in Blender and use the Blender2Lus export script linked earlier to export a starting animation script. It has several limitations, such as only exporting the active action from each object in the scene, but running it several times and tweaking and combining the generated scripts can reduce the amount of work in generating animation scripts immensely. Further use of this script is, for the moment, outside the scope of this tutorial (because I haven't done it myself yet - feel free to replace this with detailed explanation if you have, though!)

== Set up texture associations and .dae.lua metadata ==
Although Spring can read .dae files and the contained UV map, it does not support any sort of material or texture import, so you have to specify these manually. Since at this point you have already set Blender up with a reasonable approximation of the texture process it should not be especially difficult.

You will need to provide a .dae.lua file with the same name as your model file, in the same directory, to tell Spring which texture files and associated data to use with the model.

For example, if your model export is snazzyUnit.dae and it is present under the /objects3d folder of your testing mod, you should make a snazzyUnit.dae.lua file and place that at /objects3d/snazzyUnit.dae.lua .

The documentation for these metadata files is [https://springrts.com/wiki/3DModels:AssimpMetadata here], but they are reasonably simple and a minimal example file is provided below:

<pre>
return {
tex1 = "core_color.dds",
tex2 = "core_other.dds",
invertteamcolor = false
}</pre>

Obviously if you are not using the atlas textures you will need to replace those names with the actual texture files you intend to use. There are several other things that may need to be in this file, but as these differ per-unit you will need to decide what, if anything, to provide. You should probably also decide on a radius to set - leaving it out autogenerates a large radius covering the entire model, but for many reasons it's not always appropriate. Examine similar units in game (ctrl-alt-B shows collision bounds, radius is the grey sphere) and match them if necessary.

== Set up Zero-K mod that contains and uses your files ==
To get Zero-K to see your files and locally test your units (new or otherwise) you can use a mod, or download all the source and point your original version at it. I will use a mod.

This is selectable in local skirmish mode (and theoretically you can distribute them to test in multiplayer) which allows you to check everything works in the engine without requiring any changes to the official repositories or a local development copy of the game - all you need is a working copy of Zero-K. You should eventually check it works with a properly set up dev copy (and that copy can be used for many changes, if necessary) but for now a mod is simpler.

=== Making the mod ===
Inside the Zero-K folder there is a games subfolder. Inside that are numerous things, but if you make a new subfolder with a name ending in .sdd it will be read by the engine on startup. A base mod is available to download [File:BaseMod.sdd.zip here] to build from if you would like an example. More details on mod creation can be found here: [[Mod Creation]]

Create a mod and fill out the modinfo.lua, making sure to change the name and description so you can tell it apart when you are selecting it. If the depends tag is listed as [[rapid:/zk:stable]] you will have to manually change it to the latest ZK version in this format:
<pre>depend = {
[[Zero-K v1.8.10.0]]
},</pre>
Update the version number appropriately.

=== File locations ===
Like many mods, the file structure downwards from the modname.sdd folder should exactly match the Zero-K internal virtual file system, and if there are any files in your mod that match names with base files, Zero-K will use your mod's file instead of the base file.

This allows you to selectively replace any files with whatever changed version you want, which is ideal for our purposes of testing a mod. Any ''new'' files will also be loaded, allowing you to test entirely new units - although you may have to modify the buildoptions list of an existing factory or constructor to allow them to build your new unit.

<blockquote>AN IMPORTANT NOTE:
You should keep all of filenames and folder names lower case, as the virtual file system lowercases everything. Double check your filenames, it needs to match exactly if you are replacing things.</blockquote>

=== Testing your mod ===
Once you have filled out your folders and files, probably (but not exclusively) using /objects3d , /units and /unittextures , you can progress to actually testing it works in-engine.

Load up Zero-K and go to singleplayer, then Skirmish. The map and opponents do not especially matter, though if you are testing a lot you probably want to use an inactive AI (check through main lobby options for additional AI types if it's not there by default).

Go into Adv Options, and pick 'Select Mod'. If the folder and modinfo are correct you should see your mod on the list. If you do not, download the base mod, unzip it to the appropriate place and check if that shows up - if it does, the problem is with your mod. If it does not, then something is probably in the wrong place.

Once you've selected your mod you should start the skirmish and attempt to test whatever you've actually changed. At one point while doing this, Zero-K would not load because the interpreter for the mod's unitdef files was more strict than the main game's, so you may wish to follow the format used in the base mod (it overwrites lotus turrets) more exactly if you have this problem.

== Fix whatever isn't right ==
Do not expect everything to be perfect. This is a very complicated process and something is probably broken somewhere - either way, check everything, and get used to the idea that you may have to edit, re-export, then restart the game a lot to retry with changes quite often. Although unit definitions and such may be reloaded without quitting the game (TODO: what is the command to do this? How reliable is it?) you should eventually restart Zero-K to do a round of final testing just to ensure that everything loads correctly from startup.

== The other bits ==
Ever heard about software development that first you need to complete 90% of the project, and then you need to complete the other 90% of the project? The same sometimes applies to modding.

Even though by this point you should have your unit or building in game and working, there are other things to do before it's ready!

=== groundplane decal and ao bake ===
If your unit is a building, you will need to create a ground plane to go underneath it - at the very least an ambient occlusion baked shadow, usually referred to as an aoplane. This is simply a texture which is sized appropriately for your model and is placed underneath it by the engine. This adds a little soft shadowing around the edge of the building which helps immensely to integrate it with the map.

There are a few ways to make these, but the easiest if following this tutorial is probably just to bake your own in Blender.

==== Create and size the virtual ground plane ====
First, create a plane and place it under your model. It should be at zero relative to where the model is going to go, but this plane will never leave blender directly - it will be the Spring engine painting the decal onto the terrain. Scale it until it completely covers all of your model, then apply the scale and scale it *again* so that it is appropriately larger than the footprint of your model. This size may need adjusting so that it fits an integer value - for example, if the unitdef lists your unit as 5 footprint-units wide, then (since you can only set the decal footprint size to an integer) you would have to choose 6 (6/5 = 120% of the model size) or 7 (7/5 = 140% of the model size). Somewhere between 120% and 140% is probably fine.

==== Setup for AO Baking ====
Once you have the plane appropriately sized, go to the render tab [[File:Blender_render_tab.png]] and change the Render engine to Cycles. You may wish to change the feature set and compute device appropriate to your system (especially if you have a powerful GPU) but the defaults should be fine for this.

Make sure you set the number of samples in the Sampling section high enough. 512 is a good number to start from, though as high as 1024 is useful to reduce noise. More samples mean more render time, even for something as simple as baking a simple ambient occlusion map.

Next, go to the world tab [[File:Blender_world_tab.png]] and activate Ambient Occlusion. Factor should be 1.0, and the distance parameter depends on how large your model is. You may have to tweak this value until the resulting bake looks correct, but start with a distance parameter somewhere around 25% to 50% of the width of your model, turning it up if this is not sufficient.

To properly bake, we need somewhere to put the texture - so open up a shader node window somewhere, select the ground plane and make sure that it is using a new material and that material is using nodes. Connect a texture node using the Ctrl-T shortcut. Press New to make a new texture, and set it to the appropriate size - typically 512px square for something the size of a factory or 128px square for smaller buildings. Set the image colourspace to non-colour data to prevent shading artefacts later. Make sure this texture node has been clicked on and is selected, because it's the last selected texture for each relevant object that receives the bake.

Finally we're almost ready to do the baking! Return to the render tab [[File:Blender_render_tab.png]] and scroll down to the Bake section. From the Bake Type dropdown select Ambient Occlusion. Make sure that Selected to Active is OFF, as that is intended to transfer high poly modelling data to low poly objects and we actually do want just a general scene-wide bake of ambient occlusion, it's just we only care about the result on this one ground plane object. Margin can be adjusted but the default of 16px is probably fine.

==== Do the bake ====
Press Bake!

If blender crashed that's fine, go check in the log file to see what did it - the last time I had a crash here, I had an addon (bezier tools, totally unrelated to anything to do with baking) going wrong, and so I had to temporarily disable it.

If all went well, you should have seen a few textures render if you were on something with a texture view, and if you go to find your new ambient occlusion texture it should be a black outline in the shape of your building with a white outside, and a blurry shadowy bit around the edge of the black outline, which is what the game will draw onto the ground. Export this as a png.

==== Touchup and adjust format in external image editor ====
The next bit you will need to do in GIMP/Glimpse, or any other image processing software capable of exporting DDS textures. Simply load your image file, turn the white colour into transparency by whatever method you prefer such that full black is opaque and full white is transparent, and then export as DDS. Spring wants textures to be DXT5 compressed, with mipmaps generated.

If you want some other decal underneath your unit, perhaps a metallic decal if it is a factory for example, you can add that as another layer in your image editing software here. Ensure that the ambient occlusion layer overlays it where necessary.

==== Adjust unitdef to include groundplane ====
Now you've got a groundplane texture, rename it to something like unitname_aoplane.dds and put it into the /unittextures folder. Then go to the unitdef and make sure that these tags are filled out:

<pre>
buildingGroundDecalDecaySpeed = 30, --Seconds decal takes to fade out of existence
buildingGroundDecalSizeX = 12, --Size of the decal's X axis in footprint units
buildingGroundDecalSizeY = 12, --Size of the decal's Y axis in footprint units
buildingGroundDecalType = [[unitname_aoplane.dds]], --filename of decal

useBuildingGroundDecal = true,
</pre>

After saving the updated unitdef, go and check that the ground plane exists in game. They can be quite subtle, but by toggling on and off the "show ground decals" option, you should be able to see the difference easily.

If needed, you can edit your original png file in the image editor again and apply gaussian blur to the image to spread the shadow out further. Ensure that the shadow's edge doesn't touch the edge of the image, as this tends to look obvious.

=== unitpic ===
Unit pictures in the buildmenu are generated by an automated script. This script lives as a Lua gadget within the Zero-K base content, so if you have your mod working you can load that up and generate a buildpic.

First, press F8 to show the debug console, then turn on cheats with /cheat (or !cheats in multiplayer, which will require host permissions.)

Then run <pre>/luarules buildicon {unitname}</pre>. You can run it with no unit name and instead buildicons if you want to generate buildicons for every unit in the game. It should output the icons to your Zero-K folder under the /buildicons folder. You will then have to move it to the /unitpics folder of your mod, name it appropriately, and check it works.

=== Developer mode test with full file system ===

Now is the time to test against the full developer mode run - see [[Developing]] for information on how to set that up. Copy your files to an up to date copy of the latest source files from GitHub and check if they work there.

Once they do you should be ready to make a pull request. If you forked from the development version as the linked instructions suggest, you should be able to use your fork to do this.

Blender To Zero-K

2020-10-16T08:24:25Z

Darloth3: I was wrong, red does not need to be inverted. Oops. Will upload new version of shader soon.

Here is a tutorial covering all of the steps to make or edit a model in [https://www.blender.org/ Blender] (a free 3d modelling program) and transfer it to the Spring engine, then have Zero-K load it as a mutator so you can test it in-game.

The contents page here will also act as a quick reference for all of the necessary steps, in order:

__TOC__

== Make or Edit the model in Blender ==
=== Setting up Blender for use in Zero-K ===
If you are totally new to blender there are a few things you probably ought to do to set up blender for use with Zero-K. Additionally, this tutorial will assume you are using left-click to select (the new default) and a fairly typical window layout similar to the default.

Blender comes with several add-ons and scripts, not all of which are enabled by default. While there are many additional ones you might have to pay for that could prove useful (meshmachine, decalmachine and hard ops are probably the most well known three) there are a few free add-ons you may wish to consider. You should absolutely go to the Edit->Preferences->Add-ons submenu and enable Node Wrangler, and Looptools.

To import s3o models from spring, you will need an addon which can be found [https://github.com/sanguinariojoe/blender_s3o_import here]. You need to download the python (.py) file and then use the Install button inside blender's add-ons submenu, pointing it at that .py file, so that blender knows how to import .s3o models. Make sure to enable the add-on after installation.

If you want to export animations, you will also need [https://github.com/Anarchid/blender2lus this] animation exporter, though the output it produces will likely still require manual adjustment and will not be covered by this tutorial.

=== Importing a model (optional) ===
With the s3o importer installed and enabled, you should be able to import s3o models from spring into blender by using the File->Import->s3o option. Then navigate to your model file and select it.

s3o models often come in rotated to one side, as Spring uses Y-axis-up and Blender uses Z-axis-up. You can rotate them to look right in Blender, and then when exporting them there are options to deal with this so that they export rotated correctly.

If the importer can find them, it will also import textures and the UV map along with the model. The texture files may need to be placed appropriately or in the same directory as the model file for this to work.

=== Importing textures ===
To open a texture you need to set a window to either the Image Editor or UV Editor mode, and then press the Open button in the top menu bar. This will bring up a file menu where you can select a texture to bring into Blender. Blender supports .dds textures by default, as well as most other image formats.

You can certainly import any old texture and work with it, but if you are importing textures already used by Spring you should know that they are somewhat unusual.

Spring has two separate texture formats. The first of these, referred to as tex1 or colour texture, uses Red Green Blue (RGB) channels to store colour data, and Alpha (A) to store whether that part of the file is teamcolour or not. This means that by default a tex1 texture looks mostly blank(transparent) with some odd black bits scattered around. You can fix this in Blender by scrolling the menu bar (hold middle button with cursor on menu, drag mouse to side) all the way to the right, and clicking the little drop down which says Display Channels [[File:Blender_display_channels.png]]. By default it is set to ''Colour and Alpha'' but you should set it to ''Colour'' when working with tex1 files to ignore the alpha channel.

Tex2 files are the ones in greenyblue with bits of red. In those files the Red channel is how much that part of the texture emits light, the Green channel is how rough or smooth that part of the texture is (which determines how it reacts to light), and the Blue channel is how metallic and reflective that part of the texture is. Areas which are cyan (full green and full blue) are mirror-smooth metal, so reflect the environment perfectly. These should always have their colourspace set to non-colour data as they use each channel separately. You can find that option in the right hand popout menu when in an image editor viewing them (shortcut key N by default) under the Image tab.

You may also need or want to use Normal map textures, which are the ones that look mostly blue with some oddly coloured parts around the edges. Whenever you use these normal map textures you should always change the colourspace to non-colour data as it can cause visual errors if you do not, since it will process the channels differently in the render pipeline.

If nothing in the scene uses your texture it will be discarded from the file when you save and exit. You may click the shield icon next to the file name to prevent this, if you want to have the textures kept around even with nothing using it. As long as you've assigned the texture to a material, and the material to a model (see below) this will not be a problem, but it's useful to know this option exists and why a texture might be dropped.

Blend files do not by default contain the textures referenced in them, but you 'can' optionally pack the textures into them for easy transfer between users or computers. Explore the File->External Data menu for those options.

=== Modelling for Zero-K ===
There are not many special considerations when modelling for Zero-K, and a general explanation of modelling and blender is too detailed to go here. However, you could consult tutorials such as [https://www.youtube.com/watch?v=7MRonzqYJgw&list=PLn3ukorJv4vs_eSJUQPxBRaDS8PrVmIri Grant Abbitt's beginner series] or [https://www.youtube.com/watch?v=1jHUY3qoBu8 Imphenzia's introduction and low poly modelling] tutorial.

Generally, you should attempt to keep the number of triangles used in a model as low as is reasonable. That number varies depending on how frequent the unit is planned to be - a commander or other functionally unique unit would be fine with up to 30,000 triangles, but for a very spammable unit such as a flea this would be extremely excessive, as you can build a vast number of fleas. Something in the region of 500-1000 would be more appropriate, with less being ideal as long as the model still looks good.

The size of the model (or part of model) and how visible it is also has an impact on how many polygons you should be using. A large model covering a lot of screen space should use more polygons and texels than a small one or a part of the model that people rarely or never see.

=== Texturing for Zero-K, and Spring texture oddities ===
As mentioned earlier, spring uses two textures per model and cannot use multiple UV Maps, cannot use vertex colours, and cannot use additional textures other than a normal map.

The tex1 format covers the diffuse colour and whether a pixel is teamcoloured or not, wheras tex2 covers the emissivity, roughness, and metalness of the model in its RGB channels respectively.

Remember that most DDS normal maps are slightly different from typical OpenGL normal maps, and adjust appropriately as needed. Typically inverting the Red and Green channels does the trick.

If you import a texture then the importer will set up the nodes for you, however, if you are starting from scratch then you probably just want to replicate this node setup. This mostly approximates what Spring will do in-engine, giving you a workable preview in Blender when you use a lookdev(Material Preview) view mode.

[[File:Spring_shader.png]]

There are three textures referenced here, which in this case happen to be atlas textures which can be reused for multiple models. The core_color.dds is tex1 and has colours and teamcolours - the alpha channel is split off, inverted, and used to colour the alpha areas green (you can click the green colour to replace it with any other colour, if you like).

The core_other.dds is the tex2 file, so it is split into RGB channels and each of these channels appropriately processed and connected to the relevant part of the material.

Finally the core_normals.dds contains a direct-x formatted normal map, so it is converted to an openGL format by inverting just the Green channel and is then passed through the normal calculation node to convert the image into a vector map, and then the vector map passed to the shader.

TODO: Provide a blend file here that already has this material set up, just need to plug in textures. Or just include atlas texture. Airpad_packed.blend is sadly larger than 2mb so the wiki will not host it.

== Export the model to .dae format ==
Nowadays Spring can read .dae (Collada) files directly via the use of Assimp (Asset Importer). This means the export process is reasonably simple.

Either clean your scene of everything you do not want to be exported, or select only the things you want exported. Go to the File->Export menu and select Collada (.dae) format. A file browser will open with various export settings on the right hand side.

You should pick Selection Only from the Main tab of export options if you want to limit it to selection.

Make sure that the orientation settings are correct. You want to tell the exporter what axes you've been modelling with, not the axes you're looking for. These are the default options and should usually be right, Spring/Assimp will then adjust them for use in engine, but if after checking things in Spring your object is oriented wrongly, you can try adjusting these and exporting again. If all else fails, you can parent the root object(s) to an empty placed at the origin and rotate that. [[File:collada_default_export.png]]

=== A note on animation ===
Although Collada (.dae) files do support exporting animation, you should not do this as Spring cannot read the animation data. Instead, animations in Zero-K are handled by a lua animation script known as LUS.

Although you cannot export the animations to Collada, you can still do your animations in Blender and use the Blender2Lus export script linked earlier to export a starting animation script. It has several limitations, such as only exporting the active action from each object in the scene, but running it several times and tweaking and combining the generated scripts can reduce the amount of work in generating animation scripts immensely. Further use of this script is, for the moment, outside the scope of this tutorial (because I haven't done it myself yet - feel free to replace this with detailed explanation if you have, though!)

== Set up texture associations and .dae.lua metadata ==
Although Spring can read .dae files and the contained UV map, it does not support any sort of material or texture import, so you have to specify these manually. Since at this point you have already set Blender up with a reasonable approximation of the texture process it should not be especially difficult.

You will need to provide a .dae.lua file with the same name as your model file, in the same directory, to tell Spring which texture files and associated data to use with the model.

For example, if your model export is snazzyUnit.dae and it is present under the /objects3d folder of your testing mod, you should make a snazzyUnit.dae.lua file and place that at /objects3d/snazzyUnit.dae.lua .

The documentation for these metadata files is [https://springrts.com/wiki/3DModels:AssimpMetadata here], but they are reasonably simple and a minimal example file is provided below:

<pre>
return {
tex1 = "core_color.dds",
tex2 = "core_other.dds",
invertteamcolor = false
}</pre>

Obviously if you are not using the atlas textures you will need to replace those names with the actual texture files you intend to use. There are several other things that may need to be in this file, but as these differ per-unit you will need to decide what, if anything, to provide.

== Set up Zero-K mod that contains and uses your files ==
To get Zero-K to see your files and locally test your units (new or otherwise) you should use a mod.

This is selectable in local skirmish mode (and theoretically you can distribute them to test in multiplayer) which allows you to check everything works in the engine without requiring any changes to the official repositories or even building a local development copy of the game - all you need is a working copy of Zero-K.

=== Making the mod ===
Inside the Zero-K folder there is a games subfolder. Inside that are numerous things, but if you make a new subfolder with a name ending in .sdd it will be read by the engine on startup. A base mod is available to download [File:BaseMod.sdd.zip here] to build from if you would like an example. More details on mod creation can be found here: [[Mod Creation]]

Create a mod and fill out the modinfo.lua, making sure to change the name and description so you can tell it apart when you are selecting it.

=== File locations ===
Like many mods, the file structure downwards from the modname.sdd folder should exactly match the Zero-K internal virtual file system, and if there are any files in your mod that match names with base files, Zero-K will use your mod's file instead of the base file.

This allows you to selectively replace any files with whatever changed version you want, which is ideal for our purposes of testing a mod. Any ''new'' files will also be loaded, allowing you to test entirely new units - although you may have to modify the buildoptions list of an existing factory or constructor to allow them to build your new unit.

<blockquote>AN IMPORTANT NOTE:
You should keep all of filenames and folder names lower case, as the virtual file system lowercases everything. Double check your filenames, it needs to match exactly if you are replacing things.</blockquote>

=== Testing your mod ===
Once you have filled out your folders and files, probably (but not exclusively) using /objects3d , /units and /unittextures , you can progress to actually testing it works in-engine.

Load up Zero-K and go to singleplayer, then Skirmish. The map and opponents do not especially matter, though if you are testing a lot you probably want to use an inactive AI (check through main lobby options for additional AI types if it's not there by default).

Go into Adv Options, and pick 'Select Mod'. If the folder and modinfo are correct you should see your mod on the list. If you do not, download the base mod, unzip it to the appropriate place and check if that shows up - if it does, the problem is with your mod. If it does not, then something is probably in the wrong place.

Once you've selected your mod you should start the skirmish and attempt to test whatever you've actually changed. At one point while doing this, Zero-K would not load because the interpreter for the mod's unitdef files was more strict than the main game's, so you may wish to follow the format used in the base mod (it overwrites lotus turrets) more exactly if you have this problem.

== Fix whatever isn't right ==
Do not expect everything to be perfect. This is a very complicated process and something is probably broken somewhere - either way, check everything, and get used to the idea that you may have to edit, re-export, then restart the game a lot to retry with changes quite often. Although unit definitions and such may be reloaded without quitting the game (TODO: what is the command to do this? How reliable is it?) you should eventually restart Zero-K to do a round of final testing just to ensure that everything loads correctly from startup.

== The other bits ==
Ever heard about software development that first you need to complete 90% of the project, and then you need to complete the other 90% of the project? The same sometimes applies to modding.

Even though by this point you should have your unit or building in game and working, there are other things to do before it's ready!

=== groundplane decal and ao bake ===
If your unit is a building, you will need to create a ground plane to go underneath it - at the very least an ambient occlusion baked shadow, usually referred to as an aoplane. This is simply a texture which is sized appropriately for your model and is placed underneath it by the engine. This adds a little soft shadowing around the edge of the building which helps immensely to integrate it with the map.

There are a few ways to make these, but the easiest if following this tutorial is probably just to bake your own in Blender.

==== Create and size the virtual ground plane ====
First, create a plane and place it under your model. It should be at zero relative to where the model is going to go, but this plane will never leave blender directly - it will be the Spring engine painting the decal onto the terrain. Scale it until it completely covers all of your model, then apply the scale and scale it *again* so that it is appropriately larger than the footprint of your model. This size may need adjusting so that it fits an integer value - for example, if the unitdef lists your unit as 5 footprint-units wide, then (since you can only set the decal footprint size to an integer) you would have to choose 6 (6/5 = 120% of the model size) or 7 (7/5 = 140% of the model size). Somewhere between 120% and 140% is probably fine.

==== Setup for AO Baking ====
Once you have the plane appropriately sized, go to the render tab [[File:Blender_render_tab.png]] and change the Render engine to Cycles. You may wish to change the feature set and compute device appropriate to your system (especially if you have a powerful GPU) but the defaults should be fine for this.

Make sure you set the number of samples in the Sampling section high enough. 512 is a good number to start from, though as high as 1024 is useful to reduce noise. More samples mean more render time, even for something as simple as baking a simple ambient occlusion map.

Next, go to the world tab [[File:Blender_world_tab.png]] and activate Ambient Occlusion. Factor should be 1.0, and the distance parameter depends on how large your model is. You may have to tweak this value until the resulting bake looks correct, but start with a distance parameter somewhere around 25% to 50% of the width of your model, turning it up if this is not sufficient.

To properly bake, we need somewhere to put the texture - so open up a shader node window somewhere, select the ground plane and make sure that it is using a new material and that material is using nodes. Connect a texture node using the Ctrl-T shortcut. Press New to make a new texture, and set it to the appropriate size - typically 512px square for something the size of a factory or 128px square for smaller buildings. Set the image colourspace to non-colour data to prevent shading artefacts later. Make sure this texture node has been clicked on and is selected, because it's the last selected texture for each relevant object that receives the bake.

Finally we're almost ready to do the baking! Return to the render tab [[File:Blender_render_tab.png]] and scroll down to the Bake section. From the Bake Type dropdown select Ambient Occlusion. Make sure that Selected to Active is OFF, as that is intended to transfer high poly modelling data to low poly objects and we actually do want just a general scene-wide bake of ambient occlusion, it's just we only care about the result on this one ground plane object. Margin can be adjusted but the default of 16px is probably fine.

==== Do the bake ====
Press Bake!

If blender crashed that's fine, go check in the log file to see what did it - the last time I had a crash here, I had an addon (bezier tools, totally unrelated to anything to do with baking) going wrong, and so I had to temporarily disable it.

If all went well, you should have seen a few textures render if you were on something with a texture view, and if you go to find your new ambient occlusion texture it should be a black outline in the shape of your building with a white outside, and a blurry shadowy bit around the edge of the black outline, which is what the game will draw onto the ground. Export this as a png.

==== Touchup and adjust format in external image editor ====
The next bit you will need to do in GIMP/Glimpse, or any other image processing software capable of exporting DDS textures. Simply load your image file, turn the white colour into transparency by whatever method you prefer such that full black is opaque and full white is transparent, and then export as DDS. Spring wants textures to be DXT5 compressed, with mipmaps generated.

If you want some other decal underneath your unit, perhaps a metallic decal if it is a factory for example, you can add that as another layer in your image editing software here. Ensure that the ambient occlusion layer overlays it where necessary.

==== Adjust unitdef to include groundplane ====
Now you've got a groundplane texture, rename it to something like unitname_aoplane.dds and put it into the /unittextures folder. Then go to the unitdef and make sure that these tags are filled out:

<pre>
buildingGroundDecalDecaySpeed = 30, --Seconds decal takes to fade out of existence
buildingGroundDecalSizeX = 12, --Size of the decal's X axis in footprint units
buildingGroundDecalSizeY = 12, --Size of the decal's Y axis in footprint units
buildingGroundDecalType = [[unitname_aoplane.dds]], --filename of decal

useBuildingGroundDecal = true,
</pre>

After saving the updated unitdef, go and check that the ground plane exists in game. They can be quite subtle, but by toggling on and off the "show ground decals" option, you should be able to see the difference easily.

If needed, you can edit your original png file in the image editor again and apply gaussian blur to the image to spread the shadow out further. Ensure that the shadow's edge doesn't touch the edge of the image, as this tends to look obvious.

=== unitpic ===
Unit pictures in the buildmenu are generated by an automated script. This script lives as a Lua gadget within the Zero-K base content, so if you have your mod working you can load that up and generate a buildpic.

First, press F8 to show the debug console, then turn on cheats with /cheat (or !cheats in multiplayer, which will require host permissions.)

Then run <pre>/luarules buildicon {unitname}</pre>. You can run it with no unit name and instead buildicons if you want to generate buildicons for every unit in the game. It should output the icons to your Zero-K folder under the /buildicons folder. You will then have to move it to the /unitpics folder of your mod, name it appropriately, and check it works.

Blender To Zero-K

2020-10-15T11:29:58Z

Darloth3: Unit pic and other bits.

Here is a tutorial covering all of the steps to make or edit a model in [https://www.blender.org/ Blender] (a free 3d modelling program) and transfer it to the Spring engine, then have Zero-K load it as a mutator so you can test it in-game.

The contents page here will also act as a quick reference for all of the necessary steps, in order:

__TOC__

== Make or Edit the model in Blender ==
=== Setting up Blender for use in Zero-K ===
If you are totally new to blender there are a few things you probably ought to do to set up blender for use with Zero-K. Additionally, this tutorial will assume you are using left-click to select (the new default) and a fairly typical window layout similar to the default.

Blender comes with several add-ons and scripts, not all of which are enabled by default. While there are many additional ones you might have to pay for that could prove useful (meshmachine, decalmachine and hard ops are probably the most well known three) there are a few free add-ons you may wish to consider. You should absolutely go to the Edit->Preferences->Add-ons submenu and enable Node Wrangler, and Looptools.

To import s3o models from spring, you will need an addon which can be found [https://github.com/sanguinariojoe/blender_s3o_import here]. You need to download the python (.py) file and then use the Install button inside blender's add-ons submenu, pointing it at that .py file, so that blender knows how to import .s3o models. Make sure to enable the add-on after installation.

If you want to export animations, you will also need [https://github.com/Anarchid/blender2lus this] animation exporter, though the output it produces will likely still require manual adjustment and will not be covered by this tutorial.

=== Importing a model (optional) ===
With the s3o importer installed and enabled, you should be able to import s3o models from spring into blender by using the File->Import->s3o option. Then navigate to your model file and select it.

s3o models often come in rotated to one side, as Spring uses Y-axis-up and Blender uses Z-axis-up. You can rotate them to look right in Blender, and then when exporting them there are options to deal with this so that they export rotated correctly.

If the importer can find them, it will also import textures and the UV map along with the model. The texture files may need to be placed appropriately or in the same directory as the model file for this to work.

=== Importing textures ===
To open a texture you need to set a window to either the Image Editor or UV Editor mode, and then press the Open button in the top menu bar. This will bring up a file menu where you can select a texture to bring into Blender. Blender supports .dds textures by default, as well as most other image formats.

You can certainly import any old texture and work with it, but if you are importing textures already used by Spring you should know that they are somewhat unusual.

Spring has two separate texture formats. The first of these, referred to as tex1 or colour texture, uses Red Green Blue (RGB) channels to store colour data, and Alpha (A) to store whether that part of the file is teamcolour or not. This means that by default a tex1 texture looks mostly blank(transparent) with some odd black bits scattered around. You can fix this in Blender by scrolling the menu bar (hold middle button with cursor on menu, drag mouse to side) all the way to the right, and clicking the little drop down which says Display Channels [[File:Blender_display_channels.png]]. By default it is set to ''Colour and Alpha'' but you should set it to ''Colour'' when working with tex1 files to ignore the alpha channel.

Tex2 files are the ones in greenyblue with bits of red. In those files the Red channel is how much that part of the texture emits light, the Green channel is how rough or smooth that part of the texture is (which determines how it reacts to light), and the Blue channel is how metallic and reflective that part of the texture is. Areas which are cyan (full green and full blue) are mirror-smooth metal, so reflect the environment perfectly. These should always have their colourspace set to non-colour data as they use each channel separately. You can find that option in the right hand popout menu when in an image editor viewing them (shortcut key N by default) under the Image tab.

You may also need or want to use Normal map textures, which are the ones that look mostly blue with some oddly coloured parts around the edges. Whenever you use these normal map textures you should always change the colourspace to non-colour data as it can cause visual errors if you do not, since it will process the channels differently in the render pipeline.

If nothing in the scene uses your texture it will be discarded from the file when you save and exit. You may click the shield icon next to the file name to prevent this, if you want to have the textures kept around even with nothing using it. As long as you've assigned the texture to a material, and the material to a model (see below) this will not be a problem, but it's useful to know this option exists and why a texture might be dropped.

Blend files do not by default contain the textures referenced in them, but you 'can' optionally pack the textures into them for easy transfer between users or computers. Explore the File->External Data menu for those options.

=== Modelling for Zero-K ===
There are not many special considerations when modelling for Zero-K, and a general explanation of modelling and blender is too detailed to go here. However, you could consult tutorials such as [https://www.youtube.com/watch?v=7MRonzqYJgw&list=PLn3ukorJv4vs_eSJUQPxBRaDS8PrVmIri Grant Abbitt's beginner series] or [https://www.youtube.com/watch?v=1jHUY3qoBu8 Imphenzia's introduction and low poly modelling] tutorial.

Generally, you should attempt to keep the number of triangles used in a model as low as is reasonable. That number varies depending on how frequent the unit is planned to be - a commander or other functionally unique unit would be fine with up to 30,000 triangles, but for a very spammable unit such as a flea this would be extremely excessive, as you can build a vast number of fleas. Something in the region of 500-1000 would be more appropriate, with less being ideal as long as the model still looks good.

The size of the model (or part of model) and how visible it is also has an impact on how many polygons you should be using. A large model covering a lot of screen space should use more polygons and texels than a small one or a part of the model that people rarely or never see.

=== Texturing for Zero-K, and Spring texture oddities ===
As mentioned earlier, spring uses two textures per model and cannot use multiple UV Maps, cannot use vertex colours, and cannot use additional textures other than a normal map.

The tex1 format covers the diffuse colour and whether a pixel is teamcoloured or not, wheras tex2 covers the emissivity, roughness, and metalness of the model in its RGB channels respectively.

Remember that most DDS normal maps are slightly different from typical OpenGL normal maps, and adjust appropriately as needed. Typically inverting the Red and Green channels does the trick.

If you import a texture then the importer will set up the nodes for you, however, if you are starting from scratch then you probably just want to replicate this node setup. This mostly approximates what Spring will do in-engine, giving you a workable preview in Blender when you use a lookdev(Material Preview) view mode.

[[File:Spring_shader.png]]

There are three textures referenced here, which in this case happen to be atlas textures which can be reused for multiple models. The core_color.dds is tex1 and has colours and teamcolours - the alpha channel is split off, inverted, and used to colour the alpha areas green (you can click the green colour to replace it with any other colour, if you like).

The core_other.dds is the tex2 file, so it is split into RGB channels and each of these channels appropriately processed and connected to the relevant part of the material.

Finally the core_normals.dds contains a direct-x formatted normal map, so it is converted to an openGL format by inverting just the Red and Green channels and is then passed through the normal calculation node to convert the image into a vector map, and then the vector map passed to the shader.

TODO: Provide a blend file here that already has this material set up, just need to plug in textures. Or just include atlas texture. Airpad_packed.blend is sadly larger than 2mb so the wiki will not host it.

== Export the model to .dae format ==
Nowadays Spring can read .dae (Collada) files directly via the use of Assimp (Asset Importer). This means the export process is reasonably simple.

Either clean your scene of everything you do not want to be exported, or select only the things you want exported. Go to the File->Export menu and select Collada (.dae) format. A file browser will open with various export settings on the right hand side.

You should pick Selection Only from the Main tab of export options if you want to limit it to selection.

Make sure that the orientation settings are correct. You want to tell the exporter what axes you've been modelling with, not the axes you're looking for. These are the default options and should usually be right, Spring/Assimp will then adjust them for use in engine, but if after checking things in Spring your object is oriented wrongly, you can try adjusting these and exporting again. If all else fails, you can parent the root object(s) to an empty placed at the origin and rotate that. [[File:collada_default_export.png]]

=== A note on animation ===
Although Collada (.dae) files do support exporting animation, you should not do this as Spring cannot read the animation data. Instead, animations in Zero-K are handled by a lua animation script known as LUS.

Although you cannot export the animations to Collada, you can still do your animations in Blender and use the Blender2Lus export script linked earlier to export a starting animation script. It has several limitations, such as only exporting the active action from each object in the scene, but running it several times and tweaking and combining the generated scripts can reduce the amount of work in generating animation scripts immensely. Further use of this script is, for the moment, outside the scope of this tutorial (because I haven't done it myself yet - feel free to replace this with detailed explanation if you have, though!)

== Set up texture associations and .dae.lua metadata ==
Although Spring can read .dae files and the contained UV map, it does not support any sort of material or texture import, so you have to specify these manually. Since at this point you have already set Blender up with a reasonable approximation of the texture process it should not be especially difficult.

You will need to provide a .dae.lua file with the same name as your model file, in the same directory, to tell Spring which texture files and associated data to use with the model.

For example, if your model export is snazzyUnit.dae and it is present under the /objects3d folder of your testing mod, you should make a snazzyUnit.dae.lua file and place that at /objects3d/snazzyUnit.dae.lua .

The documentation for these metadata files is [https://springrts.com/wiki/3DModels:AssimpMetadata here], but they are reasonably simple and a minimal example file is provided below:

<pre>
return {
tex1 = "core_color.dds",
tex2 = "core_other.dds",
invertteamcolor = false
}</pre>

Obviously if you are not using the atlas textures you will need to replace those names with the actual texture files you intend to use. There are several other things that may need to be in this file, but as these differ per-unit you will need to decide what, if anything, to provide.

== Set up Zero-K mod that contains and uses your files ==
To get Zero-K to see your files and locally test your units (new or otherwise) you should use a mod.

This is selectable in local skirmish mode (and theoretically you can distribute them to test in multiplayer) which allows you to check everything works in the engine without requiring any changes to the official repositories or even building a local development copy of the game - all you need is a working copy of Zero-K.

=== Making the mod ===
Inside the Zero-K folder there is a games subfolder. Inside that are numerous things, but if you make a new subfolder with a name ending in .sdd it will be read by the engine on startup. A base mod is available to download [File:BaseMod.sdd.zip here] to build from if you would like an example. More details on mod creation can be found here: [[Mod Creation]]

Create a mod and fill out the modinfo.lua, making sure to change the name and description so you can tell it apart when you are selecting it.

=== File locations ===
Like many mods, the file structure downwards from the modname.sdd folder should exactly match the Zero-K internal virtual file system, and if there are any files in your mod that match names with base files, Zero-K will use your mod's file instead of the base file.

This allows you to selectively replace any files with whatever changed version you want, which is ideal for our purposes of testing a mod. Any ''new'' files will also be loaded, allowing you to test entirely new units - although you may have to modify the buildoptions list of an existing factory or constructor to allow them to build your new unit.

<blockquote>AN IMPORTANT NOTE:
You should keep all of filenames and folder names lower case, as the virtual file system lowercases everything. Double check your filenames, it needs to match exactly if you are replacing things.</blockquote>

=== Testing your mod ===
Once you have filled out your folders and files, probably (but not exclusively) using /objects3d , /units and /unittextures , you can progress to actually testing it works in-engine.

Load up Zero-K and go to singleplayer, then Skirmish. The map and opponents do not especially matter, though if you are testing a lot you probably want to use an inactive AI (check through main lobby options for additional AI types if it's not there by default).

Go into Adv Options, and pick 'Select Mod'. If the folder and modinfo are correct you should see your mod on the list. If you do not, download the base mod, unzip it to the appropriate place and check if that shows up - if it does, the problem is with your mod. If it does not, then something is probably in the wrong place.

Once you've selected your mod you should start the skirmish and attempt to test whatever you've actually changed. At one point while doing this, Zero-K would not load because the interpreter for the mod's unitdef files was more strict than the main game's, so you may wish to follow the format used in the base mod (it overwrites lotus turrets) more exactly if you have this problem.

== Fix whatever isn't right ==
Do not expect everything to be perfect. This is a very complicated process and something is probably broken somewhere - either way, check everything, and get used to the idea that you may have to edit, re-export, then restart the game a lot to retry with changes quite often. Although unit definitions and such may be reloaded without quitting the game (TODO: what is the command to do this? How reliable is it?) you should eventually restart Zero-K to do a round of final testing just to ensure that everything loads correctly from startup.

== The other bits ==
Ever heard about software development that first you need to complete 90% of the project, and then you need to complete the other 90% of the project? The same sometimes applies to modding.

Even though by this point you should have your unit or building in game and working, there are other things to do before it's ready!

=== groundplane decal and ao bake ===
If your unit is a building, you will need to create a ground plane to go underneath it - at the very least an ambient occlusion baked shadow, usually referred to as an aoplane. This is simply a texture which is sized appropriately for your model and is placed underneath it by the engine. This adds a little soft shadowing around the edge of the building which helps immensely to integrate it with the map.

There are a few ways to make these, but the easiest if following this tutorial is probably just to bake your own in Blender.

==== Create and size the virtual ground plane ====
First, create a plane and place it under your model. It should be at zero relative to where the model is going to go, but this plane will never leave blender directly - it will be the Spring engine painting the decal onto the terrain. Scale it until it completely covers all of your model, then apply the scale and scale it *again* so that it is appropriately larger than the footprint of your model. This size may need adjusting so that it fits an integer value - for example, if the unitdef lists your unit as 5 footprint-units wide, then (since you can only set the decal footprint size to an integer) you would have to choose 6 (6/5 = 120% of the model size) or 7 (7/5 = 140% of the model size). Somewhere between 120% and 140% is probably fine.

==== Setup for AO Baking ====
Once you have the plane appropriately sized, go to the render tab [[File:Blender_render_tab.png]] and change the Render engine to Cycles. You may wish to change the feature set and compute device appropriate to your system (especially if you have a powerful GPU) but the defaults should be fine for this.

Make sure you set the number of samples in the Sampling section high enough. 512 is a good number to start from, though as high as 1024 is useful to reduce noise. More samples mean more render time, even for something as simple as baking a simple ambient occlusion map.

Next, go to the world tab [[File:Blender_world_tab.png]] and activate Ambient Occlusion. Factor should be 1.0, and the distance parameter depends on how large your model is. You may have to tweak this value until the resulting bake looks correct, but start with a distance parameter somewhere around 25% to 50% of the width of your model, turning it up if this is not sufficient.

To properly bake, we need somewhere to put the texture - so open up a shader node window somewhere, select the ground plane and make sure that it is using a new material and that material is using nodes. Connect a texture node using the Ctrl-T shortcut. Press New to make a new texture, and set it to the appropriate size - typically 512px square for something the size of a factory or 128px square for smaller buildings. Set the image colourspace to non-colour data to prevent shading artefacts later. Make sure this texture node has been clicked on and is selected, because it's the last selected texture for each relevant object that receives the bake.

Finally we're almost ready to do the baking! Return to the render tab [[File:Blender_render_tab.png]] and scroll down to the Bake section. From the Bake Type dropdown select Ambient Occlusion. Make sure that Selected to Active is OFF, as that is intended to transfer high poly modelling data to low poly objects and we actually do want just a general scene-wide bake of ambient occlusion, it's just we only care about the result on this one ground plane object. Margin can be adjusted but the default of 16px is probably fine.

==== Do the bake ====
Press Bake!

If blender crashed that's fine, go check in the log file to see what did it - the last time I had a crash here, I had an addon (bezier tools, totally unrelated to anything to do with baking) going wrong, and so I had to temporarily disable it.

If all went well, you should have seen a few textures render if you were on something with a texture view, and if you go to find your new ambient occlusion texture it should be a black outline in the shape of your building with a white outside, and a blurry shadowy bit around the edge of the black outline, which is what the game will draw onto the ground. Export this as a png.

==== Touchup and adjust format in external image editor ====
The next bit you will need to do in GIMP/Glimpse, or any other image processing software capable of exporting DDS textures. Simply load your image file, turn the white colour into transparency by whatever method you prefer such that full black is opaque and full white is transparent, and then export as DDS. Spring wants textures to be DXT5 compressed, with mipmaps generated.

If you want some other decal underneath your unit, perhaps a metallic decal if it is a factory for example, you can add that as another layer in your image editing software here. Ensure that the ambient occlusion layer overlays it where necessary.

==== Adjust unitdef to include groundplane ====
Now you've got a groundplane texture, rename it to something like unitname_aoplane.dds and put it into the /unittextures folder. Then go to the unitdef and make sure that these tags are filled out:

<pre>
buildingGroundDecalDecaySpeed = 30, --Seconds decal fades in or out of existence?
buildingGroundDecalSizeX = 12, --Size of decal X axis in footprint units
buildingGroundDecalSizeY = 12, --Size of decal Y axis in footprint units
buildingGroundDecalType = [[unitname_aoplane.dds]], --filename of decal

useBuildingGroundDecal = true,
</pre>

After saving the updated unitdef, go and check that the ground plane exists in game. They can be quite subtle, but by toggling on and off the "show ground decals" option, you should be able to see the difference easily.

If needed, you can edit your original png file in the image editor again and apply gaussian blur to the image to spread the shadow out further. Ensure that the shadow's edge doesn't touch the edge of the image, as this tends to look obvious.

=== unitpic ===
Unit pictures in the buildmenu are generated by an automated script. This script lives as a Lua gadget within the Zero-K base content, so if you have your mod working you can load that up and generate a buildpic.

First, press F8 to show the debug console, then turn on cheats with /cheat (or !cheats in multiplayer, which will require host permissions.)

Then run <pre>/luarules buildicon {unitname}</pre>. You can run it with no unit name and instead buildicons if you want to generate buildicons for every unit in the game. It should output the icons to your Zero-K folder under the /buildicons folder. You will then have to move it to the /unitpics folder of your mod, name it appropriately, and check it works.

Blender To Zero-K

2020-10-15T11:19:05Z

Darloth3: /* Set up Zero-K mod that contains and uses your files */

Here is a tutorial covering all of the steps to make or edit a model in [https://www.blender.org/ Blender] (a free 3d modelling program) and transfer it to the Spring engine, then have Zero-K load it as a mutator so you can test it in-game.

The contents page here will also act as a quick reference for all of the necessary steps, in order:

__TOC__

== Make or Edit the model in Blender ==
=== Setting up Blender for use in Zero-K ===
If you are totally new to blender there are a few things you probably ought to do to set up blender for use with Zero-K. Additionally, this tutorial will assume you are using left-click to select (the new default) and a fairly typical window layout similar to the default.

Blender comes with several add-ons and scripts, not all of which are enabled by default. While there are many additional ones you might have to pay for that could prove useful (meshmachine, decalmachine and hard ops are probably the most well known three) there are a few free add-ons you may wish to consider. You should absolutely go to the Edit->Preferences->Add-ons submenu and enable Node Wrangler, and Looptools.

To import s3o models from spring, you will need an addon which can be found [https://github.com/sanguinariojoe/blender_s3o_import here]. You need to download the python (.py) file and then use the Install button inside blender's add-ons submenu, pointing it at that .py file, so that blender knows how to import .s3o models. Make sure to enable the add-on after installation.

If you want to export animations, you will also need [https://github.com/Anarchid/blender2lus this] animation exporter, though the output it produces will likely still require manual adjustment and will not be covered by this tutorial.

=== Importing a model (optional) ===
With the s3o importer installed and enabled, you should be able to import s3o models from spring into blender by using the File->Import->s3o option. Then navigate to your model file and select it.

s3o models often come in rotated to one side, as Spring uses Y-axis-up and Blender uses Z-axis-up. You can rotate them to look right in Blender, and then when exporting them there are options to deal with this so that they export rotated correctly.

If the importer can find them, it will also import textures and the UV map along with the model. The texture files may need to be placed appropriately or in the same directory as the model file for this to work.

=== Importing textures ===
To open a texture you need to set a window to either the Image Editor or UV Editor mode, and then press the Open button in the top menu bar. This will bring up a file menu where you can select a texture to bring into Blender. Blender supports .dds textures by default, as well as most other image formats.

You can certainly import any old texture and work with it, but if you are importing textures already used by Spring you should know that they are somewhat unusual.

Spring has two separate texture formats. The first of these, referred to as tex1 or colour texture, uses Red Green Blue (RGB) channels to store colour data, and Alpha (A) to store whether that part of the file is teamcolour or not. This means that by default a tex1 texture looks mostly blank(transparent) with some odd black bits scattered around. You can fix this in Blender by scrolling the menu bar (hold middle button with cursor on menu, drag mouse to side) all the way to the right, and clicking the little drop down which says Display Channels [[File:Blender_display_channels.png]]. By default it is set to ''Colour and Alpha'' but you should set it to ''Colour'' when working with tex1 files to ignore the alpha channel.

Tex2 files are the ones in greenyblue with bits of red. In those files the Red channel is how much that part of the texture emits light, the Green channel is how rough or smooth that part of the texture is (which determines how it reacts to light), and the Blue channel is how metallic and reflective that part of the texture is. Areas which are cyan (full green and full blue) are mirror-smooth metal, so reflect the environment perfectly. These should always have their colourspace set to non-colour data as they use each channel separately. You can find that option in the right hand popout menu when in an image editor viewing them (shortcut key N by default) under the Image tab.

You may also need or want to use Normal map textures, which are the ones that look mostly blue with some oddly coloured parts around the edges. Whenever you use these normal map textures you should always change the colourspace to non-colour data as it can cause visual errors if you do not, since it will process the channels differently in the render pipeline.

If nothing in the scene uses your texture it will be discarded from the file when you save and exit. You may click the shield icon next to the file name to prevent this, if you want to have the textures kept around even with nothing using it. As long as you've assigned the texture to a material, and the material to a model (see below) this will not be a problem, but it's useful to know this option exists and why a texture might be dropped.

Blend files do not by default contain the textures referenced in them, but you 'can' optionally pack the textures into them for easy transfer between users or computers. Explore the File->External Data menu for those options.

=== Modelling for Zero-K ===
There are not many special considerations when modelling for Zero-K, and a general explanation of modelling and blender is too detailed to go here. However, you could consult tutorials such as [https://www.youtube.com/watch?v=7MRonzqYJgw&list=PLn3ukorJv4vs_eSJUQPxBRaDS8PrVmIri Grant Abbitt's beginner series] or [https://www.youtube.com/watch?v=1jHUY3qoBu8 Imphenzia's introduction and low poly modelling] tutorial.

Generally, you should attempt to keep the number of triangles used in a model as low as is reasonable. That number varies depending on how frequent the unit is planned to be - a commander or other functionally unique unit would be fine with up to 30,000 triangles, but for a very spammable unit such as a flea this would be extremely excessive, as you can build a vast number of fleas. Something in the region of 500-1000 would be more appropriate, with less being ideal as long as the model still looks good.

The size of the model (or part of model) and how visible it is also has an impact on how many polygons you should be using. A large model covering a lot of screen space should use more polygons and texels than a small one or a part of the model that people rarely or never see.

=== Texturing for Zero-K, and Spring texture oddities ===
As mentioned earlier, spring uses two textures per model and cannot use multiple UV Maps, cannot use vertex colours, and cannot use additional textures other than a normal map.

The tex1 format covers the diffuse colour and whether a pixel is teamcoloured or not, wheras tex2 covers the emissivity, roughness, and metalness of the model in its RGB channels respectively.

Remember that most DDS normal maps are slightly different from typical OpenGL normal maps, and adjust appropriately as needed. Typically inverting the Red and Green channels does the trick.

If you import a texture then the importer will set up the nodes for you, however, if you are starting from scratch then you probably just want to replicate this node setup. This mostly approximates what Spring will do in-engine, giving you a workable preview in Blender when you use a lookdev(Material Preview) view mode.

[[File:Spring_shader.png]]

There are three textures referenced here, which in this case happen to be atlas textures which can be reused for multiple models. The core_color.dds is tex1 and has colours and teamcolours - the alpha channel is split off, inverted, and used to colour the alpha areas green (you can click the green colour to replace it with any other colour, if you like).

The core_other.dds is the tex2 file, so it is split into RGB channels and each of these channels appropriately processed and connected to the relevant part of the material.

Finally the core_normals.dds contains a direct-x formatted normal map, so it is converted to an openGL format by inverting just the Red and Green channels and is then passed through the normal calculation node to convert the image into a vector map, and then the vector map passed to the shader.

TODO: Provide a blend file here that already has this material set up, just need to plug in textures. Or just include atlas texture. Airpad_packed.blend is sadly larger than 2mb so the wiki will not host it.

== Export the model to .dae format ==
Nowadays Spring can read .dae (Collada) files directly via the use of Assimp (Asset Importer). This means the export process is reasonably simple.

Either clean your scene of everything you do not want to be exported, or select only the things you want exported. Go to the File->Export menu and select Collada (.dae) format. A file browser will open with various export settings on the right hand side.

You should pick Selection Only from the Main tab of export options if you want to limit it to selection.

Make sure that the orientation settings are correct. You want to tell the exporter what axes you've been modelling with, not the axes you're looking for. These are the default options and should usually be right, Spring/Assimp will then adjust them for use in engine, but if after checking things in Spring your object is oriented wrongly, you can try adjusting these and exporting again. If all else fails, you can parent the root object(s) to an empty placed at the origin and rotate that. [[File:collada_default_export.png]]

=== A note on animation ===
Although Collada (.dae) files do support exporting animation, you should not do this as Spring cannot read the animation data. Instead, animations in Zero-K are handled by a lua animation script known as LUS.

Although you cannot export the animations to Collada, you can still do your animations in Blender and use the Blender2Lus export script linked earlier to export a starting animation script. It has several limitations, such as only exporting the active action from each object in the scene, but running it several times and tweaking and combining the generated scripts can reduce the amount of work in generating animation scripts immensely. Further use of this script is, for the moment, outside the scope of this tutorial (because I haven't done it myself yet - feel free to replace this with detailed explanation if you have, though!)

== Set up texture associations and .dae.lua metadata ==
Although Spring can read .dae files and the contained UV map, it does not support any sort of material or texture import, so you have to specify these manually. Since at this point you have already set Blender up with a reasonable approximation of the texture process it should not be especially difficult.

You will need to provide a .dae.lua file with the same name as your model file, in the same directory, to tell Spring which texture files and associated data to use with the model.

For example, if your model export is snazzyUnit.dae and it is present under the /objects3d folder of your testing mod, you should make a snazzyUnit.dae.lua file and place that at /objects3d/snazzyUnit.dae.lua .

The documentation for these metadata files is [https://springrts.com/wiki/3DModels:AssimpMetadata here], but they are reasonably simple and a minimal example file is provided below:

<pre>
return {
tex1 = "core_color.dds",
tex2 = "core_other.dds",
invertteamcolor = false
}</pre>

Obviously if you are not using the atlas textures you will need to replace those names with the actual texture files you intend to use. There are several other things that may need to be in this file, but as these differ per-unit you will need to decide what, if anything, to provide.

== Set up Zero-K mod that contains and uses your files ==
To get Zero-K to see your files and locally test your units (new or otherwise) you should use a mod.

This is selectable in local skirmish mode (and theoretically you can distribute them to test in multiplayer) which allows you to check everything works in the engine without requiring any changes to the official repositories or even building a local development copy of the game - all you need is a working copy of Zero-K.

=== Making the mod ===
Inside the Zero-K folder there is a games subfolder. Inside that are numerous things, but if you make a new subfolder with a name ending in .sdd it will be read by the engine on startup. A base mod is available to download [File:BaseMod.sdd.zip here] to build from if you would like an example. More details on mod creation can be found here: [[Mod Creation]]

Create a mod and fill out the modinfo.lua, making sure to change the name and description so you can tell it apart when you are selecting it.

=== File locations ===
Like many mods, the file structure downwards from the modname.sdd folder should exactly match the Zero-K internal virtual file system, and if there are any files in your mod that match names with base files, Zero-K will use your mod's file instead of the base file.

This allows you to selectively replace any files with whatever changed version you want, which is ideal for our purposes of testing a mod. Any ''new'' files will also be loaded, allowing you to test entirely new units - although you may have to modify the buildoptions list of an existing factory or constructor to allow them to build your new unit.

<blockquote>AN IMPORTANT NOTE:
You should keep all of filenames and folder names lower case, as the virtual file system lowercases everything. Double check your filenames, it needs to match exactly if you are replacing things.</blockquote>

=== Testing your mod ===
Once you have filled out your folders and files, probably (but not exclusively) using /objects3d , /units and /unittextures , you can progress to actually testing it works in-engine.

Load up Zero-K and go to singleplayer, then Skirmish. The map and opponents do not especially matter, though if you are testing a lot you probably want to use an inactive AI (check through main lobby options for additional AI types if it's not there by default).

Go into Adv Options, and pick 'Select Mod'. If the folder and modinfo are correct you should see your mod on the list. If you do not, download the base mod, unzip it to the appropriate place and check if that shows up - if it does, the problem is with your mod. If it does not, then something is probably in the wrong place.

Once you've selected your mod you should start the skirmish and attempt to test whatever you've actually changed. At one point while doing this, Zero-K would not load because the interpreter for the mod's unitdef files was more strict than the main game's, so you may wish to follow the format used in the base mod (it overwrites lotus turrets) more exactly if you have this problem.

== Run Zero-K and point at your mod ==

== Fix whatever isn't right ==

== The other bits ==
Ever heard about software development that first you need to complete 90% of the project, and then you need to complete the other 90% of the project? The same sometimes applies to modding.

Even though by this point you should have your unit or building in game and working, there are other things to do before it's ready!

=== groundplane decal and ao bake ===
If your unit is a building, you will need to create a ground plane to go underneath it - at the very least an ambient occlusion baked shadow, usually referred to as an aoplane. This is simply a texture which is sized appropriately for your model and is placed underneath it by the engine. This adds a little soft shadowing around the edge of the building which helps immensely to integrate it with the map.

There are a few ways to make these, but the easiest if following this tutorial is probably just to bake your own in Blender.

==== Create and size the virtual ground plane ====
First, create a plane and place it under your model. It should be at zero relative to where the model is going to go, but this plane will never leave blender directly - it will be the Spring engine painting the decal onto the terrain. Scale it until it completely covers all of your model, then apply the scale and scale it *again* so that it is appropriately larger than the footprint of your model. This size may need adjusting so that it fits an integer value - for example, if the unitdef lists your unit as 5 footprint-units wide, then (since you can only set the decal footprint size to an integer) you would have to choose 6 (6/5 = 120% of the model size) or 7 (7/5 = 140% of the model size). Somewhere between 120% and 140% is probably fine.

==== Setup for AO Baking ====
Once you have the plane appropriately sized, go to the render tab [[File:Blender_render_tab.png]] and change the Render engine to Cycles. You may wish to change the feature set and compute device appropriate to your system (especially if you have a powerful GPU) but the defaults should be fine for this.

Make sure you set the number of samples in the Sampling section high enough. 512 is a good number to start from, though as high as 1024 is useful to reduce noise. More samples mean more render time, even for something as simple as baking a simple ambient occlusion map.

Next, go to the world tab [[File:Blender_world_tab.png]] and activate Ambient Occlusion. Factor should be 1.0, and the distance parameter depends on how large your model is. You may have to tweak this value until the resulting bake looks correct, but start with a distance parameter somewhere around 25% to 50% of the width of your model, turning it up if this is not sufficient.

To properly bake, we need somewhere to put the texture - so open up a shader node window somewhere, select the ground plane and make sure that it is using a new material and that material is using nodes. Connect a texture node using the Ctrl-T shortcut. Press New to make a new texture, and set it to the appropriate size - typically 512px square for something the size of a factory or 128px square for smaller buildings. Set the image colourspace to non-colour data to prevent shading artefacts later. Make sure this texture node has been clicked on and is selected, because it's the last selected texture for each relevant object that receives the bake.

Finally we're almost ready to do the baking! Return to the render tab [[File:Blender_render_tab.png]] and scroll down to the Bake section. From the Bake Type dropdown select Ambient Occlusion. Make sure that Selected to Active is OFF, as that is intended to transfer high poly modelling data to low poly objects and we actually do want just a general scene-wide bake of ambient occlusion, it's just we only care about the result on this one ground plane object. Margin can be adjusted but the default of 16px is probably fine.

==== Do the bake ====
Press Bake!

If blender crashed that's fine, go check in the log file to see what did it - the last time I had a crash here, I had an addon (bezier tools, totally unrelated to anything to do with baking) going wrong, and so I had to temporarily disable it.

If all went well, you should have seen a few textures render if you were on something with a texture view, and if you go to find your new ambient occlusion texture it should be a black outline in the shape of your building with a white outside, and a blurry shadowy bit around the edge of the black outline, which is what the game will draw onto the ground. Export this as a png.

==== Touchup and adjust format in external image editor ====
The next bit you will need to do in GIMP/Glimpse, or any other image processing software capable of exporting DDS textures. Simply load your image file, turn the white colour into transparency by whatever method you prefer such that full black is opaque and full white is transparent, and then export as DDS. Spring wants textures to be DXT5 compressed, with mipmaps generated.

If you want some other decal underneath your unit, perhaps a metallic decal if it is a factory for example, you can add that as another layer in your image editing software here. Ensure that the ambient occlusion layer overlays it where necessary.

==== Adjust unitdef to include groundplane ====
Now you've got a groundplane texture, rename it to something like unitname_aoplane.dds and put it into the /unittextures folder. Then go to the unitdef and make sure that these tags are filled out:

<pre>
buildingGroundDecalDecaySpeed = 30, --Seconds decal fades in or out of existence?
buildingGroundDecalSizeX = 12, --Size of decal X axis in footprint units
buildingGroundDecalSizeY = 12, --Size of decal Y axis in footprint units
buildingGroundDecalType = [[unitname_aoplane.dds]], --filename of decal

useBuildingGroundDecal = true,
</pre>

After saving the updated unitdef, go and check that the ground plane exists in game. They can be quite subtle, but by toggling on and off the "show ground decals" option, you should be able to see the difference easily.

If needed, you can edit your original png file in the image editor again and apply gaussian blur to the image to spread the shadow out further. Ensure that the shadow's edge doesn't touch the edge of the image, as this tends to look obvious.

=== unitpic ===

Blender To Zero-K

2020-10-15T10:58:55Z

Darloth3: /* Set up texture associations and .dae.lua metadata */

Here is a tutorial covering all of the steps to make or edit a model in [https://www.blender.org/ Blender] (a free 3d modelling program) and transfer it to the Spring engine, then have Zero-K load it as a mutator so you can test it in-game.

The contents page here will also act as a quick reference for all of the necessary steps, in order:

__TOC__

== Make or Edit the model in Blender ==
=== Setting up Blender for use in Zero-K ===
If you are totally new to blender there are a few things you probably ought to do to set up blender for use with Zero-K. Additionally, this tutorial will assume you are using left-click to select (the new default) and a fairly typical window layout similar to the default.

Blender comes with several add-ons and scripts, not all of which are enabled by default. While there are many additional ones you might have to pay for that could prove useful (meshmachine, decalmachine and hard ops are probably the most well known three) there are a few free add-ons you may wish to consider. You should absolutely go to the Edit->Preferences->Add-ons submenu and enable Node Wrangler, and Looptools.

To import s3o models from spring, you will need an addon which can be found [https://github.com/sanguinariojoe/blender_s3o_import here]. You need to download the python (.py) file and then use the Install button inside blender's add-ons submenu, pointing it at that .py file, so that blender knows how to import .s3o models. Make sure to enable the add-on after installation.

If you want to export animations, you will also need [https://github.com/Anarchid/blender2lus this] animation exporter, though the output it produces will likely still require manual adjustment and will not be covered by this tutorial.

=== Importing a model (optional) ===
With the s3o importer installed and enabled, you should be able to import s3o models from spring into blender by using the File->Import->s3o option. Then navigate to your model file and select it.

s3o models often come in rotated to one side, as Spring uses Y-axis-up and Blender uses Z-axis-up. You can rotate them to look right in Blender, and then when exporting them there are options to deal with this so that they export rotated correctly.

If the importer can find them, it will also import textures and the UV map along with the model. The texture files may need to be placed appropriately or in the same directory as the model file for this to work.

=== Importing textures ===
To open a texture you need to set a window to either the Image Editor or UV Editor mode, and then press the Open button in the top menu bar. This will bring up a file menu where you can select a texture to bring into Blender. Blender supports .dds textures by default, as well as most other image formats.

You can certainly import any old texture and work with it, but if you are importing textures already used by Spring you should know that they are somewhat unusual.

Spring has two separate texture formats. The first of these, referred to as tex1 or colour texture, uses Red Green Blue (RGB) channels to store colour data, and Alpha (A) to store whether that part of the file is teamcolour or not. This means that by default a tex1 texture looks mostly blank(transparent) with some odd black bits scattered around. You can fix this in Blender by scrolling the menu bar (hold middle button with cursor on menu, drag mouse to side) all the way to the right, and clicking the little drop down which says Display Channels [[File:Blender_display_channels.png]]. By default it is set to ''Colour and Alpha'' but you should set it to ''Colour'' when working with tex1 files to ignore the alpha channel.

Tex2 files are the ones in greenyblue with bits of red. In those files the Red channel is how much that part of the texture emits light, the Green channel is how rough or smooth that part of the texture is (which determines how it reacts to light), and the Blue channel is how metallic and reflective that part of the texture is. Areas which are cyan (full green and full blue) are mirror-smooth metal, so reflect the environment perfectly. These should always have their colourspace set to non-colour data as they use each channel separately. You can find that option in the right hand popout menu when in an image editor viewing them (shortcut key N by default) under the Image tab.

You may also need or want to use Normal map textures, which are the ones that look mostly blue with some oddly coloured parts around the edges. Whenever you use these normal map textures you should always change the colourspace to non-colour data as it can cause visual errors if you do not, since it will process the channels differently in the render pipeline.

If nothing in the scene uses your texture it will be discarded from the file when you save and exit. You may click the shield icon next to the file name to prevent this, if you want to have the textures kept around even with nothing using it. As long as you've assigned the texture to a material, and the material to a model (see below) this will not be a problem, but it's useful to know this option exists and why a texture might be dropped.

Blend files do not by default contain the textures referenced in them, but you 'can' optionally pack the textures into them for easy transfer between users or computers. Explore the File->External Data menu for those options.

=== Modelling for Zero-K ===
There are not many special considerations when modelling for Zero-K, and a general explanation of modelling and blender is too detailed to go here. However, you could consult tutorials such as [https://www.youtube.com/watch?v=7MRonzqYJgw&list=PLn3ukorJv4vs_eSJUQPxBRaDS8PrVmIri Grant Abbitt's beginner series] or [https://www.youtube.com/watch?v=1jHUY3qoBu8 Imphenzia's introduction and low poly modelling] tutorial.

Generally, you should attempt to keep the number of triangles used in a model as low as is reasonable. That number varies depending on how frequent the unit is planned to be - a commander or other functionally unique unit would be fine with up to 30,000 triangles, but for a very spammable unit such as a flea this would be extremely excessive, as you can build a vast number of fleas. Something in the region of 500-1000 would be more appropriate, with less being ideal as long as the model still looks good.

The size of the model (or part of model) and how visible it is also has an impact on how many polygons you should be using. A large model covering a lot of screen space should use more polygons and texels than a small one or a part of the model that people rarely or never see.

=== Texturing for Zero-K, and Spring texture oddities ===
As mentioned earlier, spring uses two textures per model and cannot use multiple UV Maps, cannot use vertex colours, and cannot use additional textures other than a normal map.

The tex1 format covers the diffuse colour and whether a pixel is teamcoloured or not, wheras tex2 covers the emissivity, roughness, and metalness of the model in its RGB channels respectively.

Remember that most DDS normal maps are slightly different from typical OpenGL normal maps, and adjust appropriately as needed. Typically inverting the Red and Green channels does the trick.

If you import a texture then the importer will set up the nodes for you, however, if you are starting from scratch then you probably just want to replicate this node setup. This mostly approximates what Spring will do in-engine, giving you a workable preview in Blender when you use a lookdev(Material Preview) view mode.

[[File:Spring_shader.png]]

There are three textures referenced here, which in this case happen to be atlas textures which can be reused for multiple models. The core_color.dds is tex1 and has colours and teamcolours - the alpha channel is split off, inverted, and used to colour the alpha areas green (you can click the green colour to replace it with any other colour, if you like).

The core_other.dds is the tex2 file, so it is split into RGB channels and each of these channels appropriately processed and connected to the relevant part of the material.

Finally the core_normals.dds contains a direct-x formatted normal map, so it is converted to an openGL format by inverting just the Red and Green channels and is then passed through the normal calculation node to convert the image into a vector map, and then the vector map passed to the shader.

TODO: Provide a blend file here that already has this material set up, just need to plug in textures. Or just include atlas texture. Airpad_packed.blend is sadly larger than 2mb so the wiki will not host it.

== Export the model to .dae format ==
Nowadays Spring can read .dae (Collada) files directly via the use of Assimp (Asset Importer). This means the export process is reasonably simple.

Either clean your scene of everything you do not want to be exported, or select only the things you want exported. Go to the File->Export menu and select Collada (.dae) format. A file browser will open with various export settings on the right hand side.

You should pick Selection Only from the Main tab of export options if you want to limit it to selection.

Make sure that the orientation settings are correct. You want to tell the exporter what axes you've been modelling with, not the axes you're looking for. These are the default options and should usually be right, Spring/Assimp will then adjust them for use in engine, but if after checking things in Spring your object is oriented wrongly, you can try adjusting these and exporting again. If all else fails, you can parent the root object(s) to an empty placed at the origin and rotate that. [[File:collada_default_export.png]]

=== A note on animation ===
Although Collada (.dae) files do support exporting animation, you should not do this as Spring cannot read the animation data. Instead, animations in Zero-K are handled by a lua animation script known as LUS.

Although you cannot export the animations to Collada, you can still do your animations in Blender and use the Blender2Lus export script linked earlier to export a starting animation script. It has several limitations, such as only exporting the active action from each object in the scene, but running it several times and tweaking and combining the generated scripts can reduce the amount of work in generating animation scripts immensely. Further use of this script is, for the moment, outside the scope of this tutorial (because I haven't done it myself yet - feel free to replace this with detailed explanation if you have, though!)

== Set up texture associations and .dae.lua metadata ==
Although Spring can read .dae files and the contained UV map, it does not support any sort of material or texture import, so you have to specify these manually. Since at this point you have already set Blender up with a reasonable approximation of the texture process it should not be especially difficult.

You will need to provide a .dae.lua file with the same name as your model file, in the same directory, to tell Spring which texture files and associated data to use with the model.

For example, if your model export is snazzyUnit.dae and it is present under the /objects3d folder of your testing mod, you should make a snazzyUnit.dae.lua file and place that at /objects3d/snazzyUnit.dae.lua .

The documentation for these metadata files is [https://springrts.com/wiki/3DModels:AssimpMetadata here], but they are reasonably simple and a minimal example file is provided below:

<pre>
return {
tex1 = "core_color.dds",
tex2 = "core_other.dds",
invertteamcolor = false
}</pre>

Obviously if you are not using the atlas textures you will need to replace those names with the actual texture files you intend to use. There are several other things that may need to be in this file, but as these differ per-unit you will need to decide what, if anything, to provide.

== Set up Zero-K mod that contains and uses your files ==

== Run Zero-K and point at your mod ==

== Fix whatever isn't right ==

== The other bits ==
Ever heard about software development that first you need to complete 90% of the project, and then you need to complete the other 90% of the project? The same sometimes applies to modding.

Even though by this point you should have your unit or building in game and working, there are other things to do before it's ready!

=== groundplane decal and ao bake ===
If your unit is a building, you will need to create a ground plane to go underneath it - at the very least an ambient occlusion baked shadow, usually referred to as an aoplane. This is simply a texture which is sized appropriately for your model and is placed underneath it by the engine. This adds a little soft shadowing around the edge of the building which helps immensely to integrate it with the map.

There are a few ways to make these, but the easiest if following this tutorial is probably just to bake your own in Blender.

==== Create and size the virtual ground plane ====
First, create a plane and place it under your model. It should be at zero relative to where the model is going to go, but this plane will never leave blender directly - it will be the Spring engine painting the decal onto the terrain. Scale it until it completely covers all of your model, then apply the scale and scale it *again* so that it is appropriately larger than the footprint of your model. This size may need adjusting so that it fits an integer value - for example, if the unitdef lists your unit as 5 footprint-units wide, then (since you can only set the decal footprint size to an integer) you would have to choose 6 (6/5 = 120% of the model size) or 7 (7/5 = 140% of the model size). Somewhere between 120% and 140% is probably fine.

==== Setup for AO Baking ====
Once you have the plane appropriately sized, go to the render tab [[File:Blender_render_tab.png]] and change the Render engine to Cycles. You may wish to change the feature set and compute device appropriate to your system (especially if you have a powerful GPU) but the defaults should be fine for this.

Make sure you set the number of samples in the Sampling section high enough. 512 is a good number to start from, though as high as 1024 is useful to reduce noise. More samples mean more render time, even for something as simple as baking a simple ambient occlusion map.

Next, go to the world tab [[File:Blender_world_tab.png]] and activate Ambient Occlusion. Factor should be 1.0, and the distance parameter depends on how large your model is. You may have to tweak this value until the resulting bake looks correct, but start with a distance parameter somewhere around 25% to 50% of the width of your model, turning it up if this is not sufficient.

To properly bake, we need somewhere to put the texture - so open up a shader node window somewhere, select the ground plane and make sure that it is using a new material and that material is using nodes. Connect a texture node using the Ctrl-T shortcut. Press New to make a new texture, and set it to the appropriate size - typically 512px square for something the size of a factory or 128px square for smaller buildings. Set the image colourspace to non-colour data to prevent shading artefacts later. Make sure this texture node has been clicked on and is selected, because it's the last selected texture for each relevant object that receives the bake.

Finally we're almost ready to do the baking! Return to the render tab [[File:Blender_render_tab.png]] and scroll down to the Bake section. From the Bake Type dropdown select Ambient Occlusion. Make sure that Selected to Active is OFF, as that is intended to transfer high poly modelling data to low poly objects and we actually do want just a general scene-wide bake of ambient occlusion, it's just we only care about the result on this one ground plane object. Margin can be adjusted but the default of 16px is probably fine.

==== Do the bake ====
Press Bake!

If blender crashed that's fine, go check in the log file to see what did it - the last time I had a crash here, I had an addon (bezier tools, totally unrelated to anything to do with baking) going wrong, and so I had to temporarily disable it.

If all went well, you should have seen a few textures render if you were on something with a texture view, and if you go to find your new ambient occlusion texture it should be a black outline in the shape of your building with a white outside, and a blurry shadowy bit around the edge of the black outline, which is what the game will draw onto the ground. Export this as a png.

==== Touchup and adjust format in external image editor ====
The next bit you will need to do in GIMP/Glimpse, or any other image processing software capable of exporting DDS textures. Simply load your image file, turn the white colour into transparency by whatever method you prefer such that full black is opaque and full white is transparent, and then export as DDS. Spring wants textures to be DXT5 compressed, with mipmaps generated.

If you want some other decal underneath your unit, perhaps a metallic decal if it is a factory for example, you can add that as another layer in your image editing software here. Ensure that the ambient occlusion layer overlays it where necessary.

==== Adjust unitdef to include groundplane ====
Now you've got a groundplane texture, rename it to something like unitname_aoplane.dds and put it into the /unittextures folder. Then go to the unitdef and make sure that these tags are filled out:

<pre>
buildingGroundDecalDecaySpeed = 30, --Seconds decal fades in or out of existence?
buildingGroundDecalSizeX = 12, --Size of decal X axis in footprint units
buildingGroundDecalSizeY = 12, --Size of decal Y axis in footprint units
buildingGroundDecalType = [[unitname_aoplane.dds]], --filename of decal

useBuildingGroundDecal = true,
</pre>

After saving the updated unitdef, go and check that the ground plane exists in game. They can be quite subtle, but by toggling on and off the "show ground decals" option, you should be able to see the difference easily.

If needed, you can edit your original png file in the image editor again and apply gaussian blur to the image to spread the shadow out further. Ensure that the shadow's edge doesn't touch the edge of the image, as this tends to look obvious.

=== unitpic ===

Blender To Zero-K

2020-10-15T10:49:59Z

Darloth3: /* Export the model to .dae format */

Here is a tutorial covering all of the steps to make or edit a model in [https://www.blender.org/ Blender] (a free 3d modelling program) and transfer it to the Spring engine, then have Zero-K load it as a mutator so you can test it in-game.

The contents page here will also act as a quick reference for all of the necessary steps, in order:

__TOC__

== Make or Edit the model in Blender ==
=== Setting up Blender for use in Zero-K ===
If you are totally new to blender there are a few things you probably ought to do to set up blender for use with Zero-K. Additionally, this tutorial will assume you are using left-click to select (the new default) and a fairly typical window layout similar to the default.

Blender comes with several add-ons and scripts, not all of which are enabled by default. While there are many additional ones you might have to pay for that could prove useful (meshmachine, decalmachine and hard ops are probably the most well known three) there are a few free add-ons you may wish to consider. You should absolutely go to the Edit->Preferences->Add-ons submenu and enable Node Wrangler, and Looptools.

To import s3o models from spring, you will need an addon which can be found [https://github.com/sanguinariojoe/blender_s3o_import here]. You need to download the python (.py) file and then use the Install button inside blender's add-ons submenu, pointing it at that .py file, so that blender knows how to import .s3o models. Make sure to enable the add-on after installation.

If you want to export animations, you will also need [https://github.com/Anarchid/blender2lus this] animation exporter, though the output it produces will likely still require manual adjustment and will not be covered by this tutorial.

=== Importing a model (optional) ===
With the s3o importer installed and enabled, you should be able to import s3o models from spring into blender by using the File->Import->s3o option. Then navigate to your model file and select it.

s3o models often come in rotated to one side, as Spring uses Y-axis-up and Blender uses Z-axis-up. You can rotate them to look right in Blender, and then when exporting them there are options to deal with this so that they export rotated correctly.

If the importer can find them, it will also import textures and the UV map along with the model. The texture files may need to be placed appropriately or in the same directory as the model file for this to work.

=== Importing textures ===
To open a texture you need to set a window to either the Image Editor or UV Editor mode, and then press the Open button in the top menu bar. This will bring up a file menu where you can select a texture to bring into Blender. Blender supports .dds textures by default, as well as most other image formats.

You can certainly import any old texture and work with it, but if you are importing textures already used by Spring you should know that they are somewhat unusual.

Spring has two separate texture formats. The first of these, referred to as tex1 or colour texture, uses Red Green Blue (RGB) channels to store colour data, and Alpha (A) to store whether that part of the file is teamcolour or not. This means that by default a tex1 texture looks mostly blank(transparent) with some odd black bits scattered around. You can fix this in Blender by scrolling the menu bar (hold middle button with cursor on menu, drag mouse to side) all the way to the right, and clicking the little drop down which says Display Channels [[File:Blender_display_channels.png]]. By default it is set to ''Colour and Alpha'' but you should set it to ''Colour'' when working with tex1 files to ignore the alpha channel.

Tex2 files are the ones in greenyblue with bits of red. In those files the Red channel is how much that part of the texture emits light, the Green channel is how rough or smooth that part of the texture is (which determines how it reacts to light), and the Blue channel is how metallic and reflective that part of the texture is. Areas which are cyan (full green and full blue) are mirror-smooth metal, so reflect the environment perfectly. These should always have their colourspace set to non-colour data as they use each channel separately. You can find that option in the right hand popout menu when in an image editor viewing them (shortcut key N by default) under the Image tab.

You may also need or want to use Normal map textures, which are the ones that look mostly blue with some oddly coloured parts around the edges. Whenever you use these normal map textures you should always change the colourspace to non-colour data as it can cause visual errors if you do not, since it will process the channels differently in the render pipeline.

If nothing in the scene uses your texture it will be discarded from the file when you save and exit. You may click the shield icon next to the file name to prevent this, if you want to have the textures kept around even with nothing using it. As long as you've assigned the texture to a material, and the material to a model (see below) this will not be a problem, but it's useful to know this option exists and why a texture might be dropped.

Blend files do not by default contain the textures referenced in them, but you 'can' optionally pack the textures into them for easy transfer between users or computers. Explore the File->External Data menu for those options.

=== Modelling for Zero-K ===
There are not many special considerations when modelling for Zero-K, and a general explanation of modelling and blender is too detailed to go here. However, you could consult tutorials such as [https://www.youtube.com/watch?v=7MRonzqYJgw&list=PLn3ukorJv4vs_eSJUQPxBRaDS8PrVmIri Grant Abbitt's beginner series] or [https://www.youtube.com/watch?v=1jHUY3qoBu8 Imphenzia's introduction and low poly modelling] tutorial.

Generally, you should attempt to keep the number of triangles used in a model as low as is reasonable. That number varies depending on how frequent the unit is planned to be - a commander or other functionally unique unit would be fine with up to 30,000 triangles, but for a very spammable unit such as a flea this would be extremely excessive, as you can build a vast number of fleas. Something in the region of 500-1000 would be more appropriate, with less being ideal as long as the model still looks good.

The size of the model (or part of model) and how visible it is also has an impact on how many polygons you should be using. A large model covering a lot of screen space should use more polygons and texels than a small one or a part of the model that people rarely or never see.

=== Texturing for Zero-K, and Spring texture oddities ===
As mentioned earlier, spring uses two textures per model and cannot use multiple UV Maps, cannot use vertex colours, and cannot use additional textures other than a normal map.

The tex1 format covers the diffuse colour and whether a pixel is teamcoloured or not, wheras tex2 covers the emissivity, roughness, and metalness of the model in its RGB channels respectively.

Remember that most DDS normal maps are slightly different from typical OpenGL normal maps, and adjust appropriately as needed. Typically inverting the Red and Green channels does the trick.

If you import a texture then the importer will set up the nodes for you, however, if you are starting from scratch then you probably just want to replicate this node setup. This mostly approximates what Spring will do in-engine, giving you a workable preview in Blender when you use a lookdev(Material Preview) view mode.

[[File:Spring_shader.png]]

There are three textures referenced here, which in this case happen to be atlas textures which can be reused for multiple models. The core_color.dds is tex1 and has colours and teamcolours - the alpha channel is split off, inverted, and used to colour the alpha areas green (you can click the green colour to replace it with any other colour, if you like).

The core_other.dds is the tex2 file, so it is split into RGB channels and each of these channels appropriately processed and connected to the relevant part of the material.

Finally the core_normals.dds contains a direct-x formatted normal map, so it is converted to an openGL format by inverting just the Red and Green channels and is then passed through the normal calculation node to convert the image into a vector map, and then the vector map passed to the shader.

TODO: Provide a blend file here that already has this material set up, just need to plug in textures. Or just include atlas texture. Airpad_packed.blend is sadly larger than 2mb so the wiki will not host it.

== Export the model to .dae format ==
Nowadays Spring can read .dae (Collada) files directly via the use of Assimp (Asset Importer). This means the export process is reasonably simple.

Either clean your scene of everything you do not want to be exported, or select only the things you want exported. Go to the File->Export menu and select Collada (.dae) format. A file browser will open with various export settings on the right hand side.

You should pick Selection Only from the Main tab of export options if you want to limit it to selection.

Make sure that the orientation settings are correct. You want to tell the exporter what axes you've been modelling with, not the axes you're looking for. These are the default options and should usually be right, Spring/Assimp will then adjust them for use in engine, but if after checking things in Spring your object is oriented wrongly, you can try adjusting these and exporting again. If all else fails, you can parent the root object(s) to an empty placed at the origin and rotate that. [[File:collada_default_export.png]]

=== A note on animation ===
Although Collada (.dae) files do support exporting animation, you should not do this as Spring cannot read the animation data. Instead, animations in Zero-K are handled by a lua animation script known as LUS.

Although you cannot export the animations to Collada, you can still do your animations in Blender and use the Blender2Lus export script linked earlier to export a starting animation script. It has several limitations, such as only exporting the active action from each object in the scene, but running it several times and tweaking and combining the generated scripts can reduce the amount of work in generating animation scripts immensely. Further use of this script is, for the moment, outside the scope of this tutorial (because I haven't done it myself yet - feel free to replace this with detailed explanation if you have, though!)

== Set up texture associations and .dae.lua metadata ==

== Set up Zero-K mod that contains and uses your files ==

== Run Zero-K and point at your mod ==

== Fix whatever isn't right ==

== The other bits ==
Ever heard about software development that first you need to complete 90% of the project, and then you need to complete the other 90% of the project? The same sometimes applies to modding.

Even though by this point you should have your unit or building in game and working, there are other things to do before it's ready!

=== groundplane decal and ao bake ===
If your unit is a building, you will need to create a ground plane to go underneath it - at the very least an ambient occlusion baked shadow, usually referred to as an aoplane. This is simply a texture which is sized appropriately for your model and is placed underneath it by the engine. This adds a little soft shadowing around the edge of the building which helps immensely to integrate it with the map.

There are a few ways to make these, but the easiest if following this tutorial is probably just to bake your own in Blender.

==== Create and size the virtual ground plane ====
First, create a plane and place it under your model. It should be at zero relative to where the model is going to go, but this plane will never leave blender directly - it will be the Spring engine painting the decal onto the terrain. Scale it until it completely covers all of your model, then apply the scale and scale it *again* so that it is appropriately larger than the footprint of your model. This size may need adjusting so that it fits an integer value - for example, if the unitdef lists your unit as 5 footprint-units wide, then (since you can only set the decal footprint size to an integer) you would have to choose 6 (6/5 = 120% of the model size) or 7 (7/5 = 140% of the model size). Somewhere between 120% and 140% is probably fine.

==== Setup for AO Baking ====
Once you have the plane appropriately sized, go to the render tab [[File:Blender_render_tab.png]] and change the Render engine to Cycles. You may wish to change the feature set and compute device appropriate to your system (especially if you have a powerful GPU) but the defaults should be fine for this.

Make sure you set the number of samples in the Sampling section high enough. 512 is a good number to start from, though as high as 1024 is useful to reduce noise. More samples mean more render time, even for something as simple as baking a simple ambient occlusion map.

Next, go to the world tab [[File:Blender_world_tab.png]] and activate Ambient Occlusion. Factor should be 1.0, and the distance parameter depends on how large your model is. You may have to tweak this value until the resulting bake looks correct, but start with a distance parameter somewhere around 25% to 50% of the width of your model, turning it up if this is not sufficient.

To properly bake, we need somewhere to put the texture - so open up a shader node window somewhere, select the ground plane and make sure that it is using a new material and that material is using nodes. Connect a texture node using the Ctrl-T shortcut. Press New to make a new texture, and set it to the appropriate size - typically 512px square for something the size of a factory or 128px square for smaller buildings. Set the image colourspace to non-colour data to prevent shading artefacts later. Make sure this texture node has been clicked on and is selected, because it's the last selected texture for each relevant object that receives the bake.

Finally we're almost ready to do the baking! Return to the render tab [[File:Blender_render_tab.png]] and scroll down to the Bake section. From the Bake Type dropdown select Ambient Occlusion. Make sure that Selected to Active is OFF, as that is intended to transfer high poly modelling data to low poly objects and we actually do want just a general scene-wide bake of ambient occlusion, it's just we only care about the result on this one ground plane object. Margin can be adjusted but the default of 16px is probably fine.

==== Do the bake ====
Press Bake!

If blender crashed that's fine, go check in the log file to see what did it - the last time I had a crash here, I had an addon (bezier tools, totally unrelated to anything to do with baking) going wrong, and so I had to temporarily disable it.

If all went well, you should have seen a few textures render if you were on something with a texture view, and if you go to find your new ambient occlusion texture it should be a black outline in the shape of your building with a white outside, and a blurry shadowy bit around the edge of the black outline, which is what the game will draw onto the ground. Export this as a png.

==== Touchup and adjust format in external image editor ====
The next bit you will need to do in GIMP/Glimpse, or any other image processing software capable of exporting DDS textures. Simply load your image file, turn the white colour into transparency by whatever method you prefer such that full black is opaque and full white is transparent, and then export as DDS. Spring wants textures to be DXT5 compressed, with mipmaps generated.

If you want some other decal underneath your unit, perhaps a metallic decal if it is a factory for example, you can add that as another layer in your image editing software here. Ensure that the ambient occlusion layer overlays it where necessary.

==== Adjust unitdef to include groundplane ====
Now you've got a groundplane texture, rename it to something like unitname_aoplane.dds and put it into the /unittextures folder. Then go to the unitdef and make sure that these tags are filled out:

<pre>
buildingGroundDecalDecaySpeed = 30, --Seconds decal fades in or out of existence?
buildingGroundDecalSizeX = 12, --Size of decal X axis in footprint units
buildingGroundDecalSizeY = 12, --Size of decal Y axis in footprint units
buildingGroundDecalType = [[unitname_aoplane.dds]], --filename of decal

useBuildingGroundDecal = true,
</pre>

After saving the updated unitdef, go and check that the ground plane exists in game. They can be quite subtle, but by toggling on and off the "show ground decals" option, you should be able to see the difference easily.

If needed, you can edit your original png file in the image editor again and apply gaussian blur to the image to spread the shadow out further. Ensure that the shadow's edge doesn't touch the edge of the image, as this tends to look obvious.

=== unitpic ===

Blender To Zero-K

2020-10-15T10:47:54Z

Darloth3: /* Export the model to .dae format */

Here is a tutorial covering all of the steps to make or edit a model in [https://www.blender.org/ Blender] (a free 3d modelling program) and transfer it to the Spring engine, then have Zero-K load it as a mutator so you can test it in-game.

The contents page here will also act as a quick reference for all of the necessary steps, in order:

__TOC__

== Make or Edit the model in Blender ==
=== Setting up Blender for use in Zero-K ===
If you are totally new to blender there are a few things you probably ought to do to set up blender for use with Zero-K. Additionally, this tutorial will assume you are using left-click to select (the new default) and a fairly typical window layout similar to the default.

Blender comes with several add-ons and scripts, not all of which are enabled by default. While there are many additional ones you might have to pay for that could prove useful (meshmachine, decalmachine and hard ops are probably the most well known three) there are a few free add-ons you may wish to consider. You should absolutely go to the Edit->Preferences->Add-ons submenu and enable Node Wrangler, and Looptools.

To import s3o models from spring, you will need an addon which can be found [https://github.com/sanguinariojoe/blender_s3o_import here]. You need to download the python (.py) file and then use the Install button inside blender's add-ons submenu, pointing it at that .py file, so that blender knows how to import .s3o models. Make sure to enable the add-on after installation.

If you want to export animations, you will also need [https://github.com/Anarchid/blender2lus this] animation exporter, though the output it produces will likely still require manual adjustment and will not be covered by this tutorial.

=== Importing a model (optional) ===
With the s3o importer installed and enabled, you should be able to import s3o models from spring into blender by using the File->Import->s3o option. Then navigate to your model file and select it.

s3o models often come in rotated to one side, as Spring uses Y-axis-up and Blender uses Z-axis-up. You can rotate them to look right in Blender, and then when exporting them there are options to deal with this so that they export rotated correctly.

If the importer can find them, it will also import textures and the UV map along with the model. The texture files may need to be placed appropriately or in the same directory as the model file for this to work.

=== Importing textures ===
To open a texture you need to set a window to either the Image Editor or UV Editor mode, and then press the Open button in the top menu bar. This will bring up a file menu where you can select a texture to bring into Blender. Blender supports .dds textures by default, as well as most other image formats.

You can certainly import any old texture and work with it, but if you are importing textures already used by Spring you should know that they are somewhat unusual.

Spring has two separate texture formats. The first of these, referred to as tex1 or colour texture, uses Red Green Blue (RGB) channels to store colour data, and Alpha (A) to store whether that part of the file is teamcolour or not. This means that by default a tex1 texture looks mostly blank(transparent) with some odd black bits scattered around. You can fix this in Blender by scrolling the menu bar (hold middle button with cursor on menu, drag mouse to side) all the way to the right, and clicking the little drop down which says Display Channels [[File:Blender_display_channels.png]]. By default it is set to ''Colour and Alpha'' but you should set it to ''Colour'' when working with tex1 files to ignore the alpha channel.

Tex2 files are the ones in greenyblue with bits of red. In those files the Red channel is how much that part of the texture emits light, the Green channel is how rough or smooth that part of the texture is (which determines how it reacts to light), and the Blue channel is how metallic and reflective that part of the texture is. Areas which are cyan (full green and full blue) are mirror-smooth metal, so reflect the environment perfectly. These should always have their colourspace set to non-colour data as they use each channel separately. You can find that option in the right hand popout menu when in an image editor viewing them (shortcut key N by default) under the Image tab.

You may also need or want to use Normal map textures, which are the ones that look mostly blue with some oddly coloured parts around the edges. Whenever you use these normal map textures you should always change the colourspace to non-colour data as it can cause visual errors if you do not, since it will process the channels differently in the render pipeline.

If nothing in the scene uses your texture it will be discarded from the file when you save and exit. You may click the shield icon next to the file name to prevent this, if you want to have the textures kept around even with nothing using it. As long as you've assigned the texture to a material, and the material to a model (see below) this will not be a problem, but it's useful to know this option exists and why a texture might be dropped.

Blend files do not by default contain the textures referenced in them, but you 'can' optionally pack the textures into them for easy transfer between users or computers. Explore the File->External Data menu for those options.

=== Modelling for Zero-K ===
There are not many special considerations when modelling for Zero-K, and a general explanation of modelling and blender is too detailed to go here. However, you could consult tutorials such as [https://www.youtube.com/watch?v=7MRonzqYJgw&list=PLn3ukorJv4vs_eSJUQPxBRaDS8PrVmIri Grant Abbitt's beginner series] or [https://www.youtube.com/watch?v=1jHUY3qoBu8 Imphenzia's introduction and low poly modelling] tutorial.

Generally, you should attempt to keep the number of triangles used in a model as low as is reasonable. That number varies depending on how frequent the unit is planned to be - a commander or other functionally unique unit would be fine with up to 30,000 triangles, but for a very spammable unit such as a flea this would be extremely excessive, as you can build a vast number of fleas. Something in the region of 500-1000 would be more appropriate, with less being ideal as long as the model still looks good.

The size of the model (or part of model) and how visible it is also has an impact on how many polygons you should be using. A large model covering a lot of screen space should use more polygons and texels than a small one or a part of the model that people rarely or never see.

=== Texturing for Zero-K, and Spring texture oddities ===
As mentioned earlier, spring uses two textures per model and cannot use multiple UV Maps, cannot use vertex colours, and cannot use additional textures other than a normal map.

The tex1 format covers the diffuse colour and whether a pixel is teamcoloured or not, wheras tex2 covers the emissivity, roughness, and metalness of the model in its RGB channels respectively.

Remember that most DDS normal maps are slightly different from typical OpenGL normal maps, and adjust appropriately as needed. Typically inverting the Red and Green channels does the trick.

If you import a texture then the importer will set up the nodes for you, however, if you are starting from scratch then you probably just want to replicate this node setup. This mostly approximates what Spring will do in-engine, giving you a workable preview in Blender when you use a lookdev(Material Preview) view mode.

[[File:Spring_shader.png]]

There are three textures referenced here, which in this case happen to be atlas textures which can be reused for multiple models. The core_color.dds is tex1 and has colours and teamcolours - the alpha channel is split off, inverted, and used to colour the alpha areas green (you can click the green colour to replace it with any other colour, if you like).

The core_other.dds is the tex2 file, so it is split into RGB channels and each of these channels appropriately processed and connected to the relevant part of the material.

Finally the core_normals.dds contains a direct-x formatted normal map, so it is converted to an openGL format by inverting just the Red and Green channels and is then passed through the normal calculation node to convert the image into a vector map, and then the vector map passed to the shader.

TODO: Provide a blend file here that already has this material set up, just need to plug in textures. Or just include atlas texture. Airpad_packed.blend is sadly larger than 2mb so the wiki will not host it.

== Export the model to .dae format ==
Nowadays Spring can read .dae (Collada) files directly via the use of Assimp (Asset Importer). This means the export process is reasonably simple.

Either clean your scene of everything you do not want to be exported, or select only the things you want exported. Go to the File->Export menu and select Collada (.dae) format. A file browser will open with various export settings on the right hand side.

You should pick Selection Only from the Main tab of export options if you want to limit it to selection.

Make sure that the orientation settings are correct. These are the default options and should usually be right, but if after checking things in Spring your object is oriented wrongly, you can try adjusting these (or just rotate the model appropriately). [[File:collada_default_export.png]]

=== A note on animation ===
Although Collada (.dae) files do support exporting animation, you should not do this as Spring cannot read the animation data. Instead, animations in Zero-K are handled by a lua animation script known as LUS.

Although you cannot export the animations to Collada, you can still do your animations in Blender and use the Blender2Lus export script linked earlier to export a starting animation script. It has several limitations, such as only exporting the active action from each object in the scene, but running it several times and tweaking and combining the generated scripts can reduce the amount of work in generating animation scripts immensely. Further use of this script is, for the moment, outside the scope of this tutorial (because I haven't done it myself yet - feel free to replace this with detailed explanation if you have, though!)

== Set up texture associations and .dae.lua metadata ==

== Set up Zero-K mod that contains and uses your files ==

== Run Zero-K and point at your mod ==

== Fix whatever isn't right ==

== The other bits ==
Ever heard about software development that first you need to complete 90% of the project, and then you need to complete the other 90% of the project? The same sometimes applies to modding.

Even though by this point you should have your unit or building in game and working, there are other things to do before it's ready!

=== groundplane decal and ao bake ===
If your unit is a building, you will need to create a ground plane to go underneath it - at the very least an ambient occlusion baked shadow, usually referred to as an aoplane. This is simply a texture which is sized appropriately for your model and is placed underneath it by the engine. This adds a little soft shadowing around the edge of the building which helps immensely to integrate it with the map.

There are a few ways to make these, but the easiest if following this tutorial is probably just to bake your own in Blender.

==== Create and size the virtual ground plane ====
First, create a plane and place it under your model. It should be at zero relative to where the model is going to go, but this plane will never leave blender directly - it will be the Spring engine painting the decal onto the terrain. Scale it until it completely covers all of your model, then apply the scale and scale it *again* so that it is appropriately larger than the footprint of your model. This size may need adjusting so that it fits an integer value - for example, if the unitdef lists your unit as 5 footprint-units wide, then (since you can only set the decal footprint size to an integer) you would have to choose 6 (6/5 = 120% of the model size) or 7 (7/5 = 140% of the model size). Somewhere between 120% and 140% is probably fine.

==== Setup for AO Baking ====
Once you have the plane appropriately sized, go to the render tab [[File:Blender_render_tab.png]] and change the Render engine to Cycles. You may wish to change the feature set and compute device appropriate to your system (especially if you have a powerful GPU) but the defaults should be fine for this.

Make sure you set the number of samples in the Sampling section high enough. 512 is a good number to start from, though as high as 1024 is useful to reduce noise. More samples mean more render time, even for something as simple as baking a simple ambient occlusion map.

Next, go to the world tab [[File:Blender_world_tab.png]] and activate Ambient Occlusion. Factor should be 1.0, and the distance parameter depends on how large your model is. You may have to tweak this value until the resulting bake looks correct, but start with a distance parameter somewhere around 25% to 50% of the width of your model, turning it up if this is not sufficient.

To properly bake, we need somewhere to put the texture - so open up a shader node window somewhere, select the ground plane and make sure that it is using a new material and that material is using nodes. Connect a texture node using the Ctrl-T shortcut. Press New to make a new texture, and set it to the appropriate size - typically 512px square for something the size of a factory or 128px square for smaller buildings. Set the image colourspace to non-colour data to prevent shading artefacts later. Make sure this texture node has been clicked on and is selected, because it's the last selected texture for each relevant object that receives the bake.

Finally we're almost ready to do the baking! Return to the render tab [[File:Blender_render_tab.png]] and scroll down to the Bake section. From the Bake Type dropdown select Ambient Occlusion. Make sure that Selected to Active is OFF, as that is intended to transfer high poly modelling data to low poly objects and we actually do want just a general scene-wide bake of ambient occlusion, it's just we only care about the result on this one ground plane object. Margin can be adjusted but the default of 16px is probably fine.

==== Do the bake ====
Press Bake!

If blender crashed that's fine, go check in the log file to see what did it - the last time I had a crash here, I had an addon (bezier tools, totally unrelated to anything to do with baking) going wrong, and so I had to temporarily disable it.

If all went well, you should have seen a few textures render if you were on something with a texture view, and if you go to find your new ambient occlusion texture it should be a black outline in the shape of your building with a white outside, and a blurry shadowy bit around the edge of the black outline, which is what the game will draw onto the ground. Export this as a png.

==== Touchup and adjust format in external image editor ====
The next bit you will need to do in GIMP/Glimpse, or any other image processing software capable of exporting DDS textures. Simply load your image file, turn the white colour into transparency by whatever method you prefer such that full black is opaque and full white is transparent, and then export as DDS. Spring wants textures to be DXT5 compressed, with mipmaps generated.

If you want some other decal underneath your unit, perhaps a metallic decal if it is a factory for example, you can add that as another layer in your image editing software here. Ensure that the ambient occlusion layer overlays it where necessary.

==== Adjust unitdef to include groundplane ====
Now you've got a groundplane texture, rename it to something like unitname_aoplane.dds and put it into the /unittextures folder. Then go to the unitdef and make sure that these tags are filled out:

<pre>
buildingGroundDecalDecaySpeed = 30, --Seconds decal fades in or out of existence?
buildingGroundDecalSizeX = 12, --Size of decal X axis in footprint units
buildingGroundDecalSizeY = 12, --Size of decal Y axis in footprint units
buildingGroundDecalType = [[unitname_aoplane.dds]], --filename of decal

useBuildingGroundDecal = true,
</pre>

After saving the updated unitdef, go and check that the ground plane exists in game. They can be quite subtle, but by toggling on and off the "show ground decals" option, you should be able to see the difference easily.

If needed, you can edit your original png file in the image editor again and apply gaussian blur to the image to spread the shadow out further. Ensure that the shadow's edge doesn't touch the edge of the image, as this tends to look obvious.

=== unitpic ===

File:Collada default export.png

2020-10-15T10:34:58Z

Darloth3: Default orientation settings for Blender's collada exporter.

== Summary ==
Default orientation settings for Blender's collada exporter.

Blender To Zero-K

2020-10-14T12:13:15Z

Darloth3: /* Importing textures */

Blender To Zero-K

2020-10-14T12:12:00Z

Darloth3: Modelling and texturing.

File:Spring shader.png

2020-10-14T11:59:06Z

Darloth3: Darloth3 uploaded a new version of File:Spring shader.png

== Summary ==
Shader replicating what the spring engine does to various texture files to produce the final result.
== Licensing ==
{{PD}}

File:Spring shader.png

2020-10-14T11:56:43Z

Darloth3: Shader replicating what the spring engine does to various texture files to produce the final result.

== Summary ==
Shader replicating what the spring engine does to various texture files to produce the final result.
== Licensing ==
{{PD}}

Blender To Zero-K

2020-10-14T01:02:33Z

Darloth3: Importing Textures.

File:Blender display channels.png

2020-10-14T00:56:39Z

Darloth3: Blender's Display Channels dropdown icon.

== Summary ==
Blender's Display Channels dropdown icon.

Blender To Zero-K

2020-10-14T00:43:46Z

Darloth3:

Blender To Zero-K

2020-10-14T00:43:06Z

Darloth3: Setting up Blender

Blender To Zero-K

2020-10-13T23:58:15Z

Darloth3: /* The other bits */

Blender To Zero-K

2020-10-13T23:57:17Z

Darloth3: /* groundplane decal and ao bake */

Blender To Zero-K

2020-10-13T23:53:00Z

Darloth3: Adjusting headings.

Blender To Zero-K

2020-10-13T23:52:16Z

Darloth3: Adjusting headings.

Blender To Zero-K

2020-10-13T23:50:52Z

Darloth3: /* groundplane decal and ao bake */ - First draft.

File:Blender world tab.png

2020-10-13T23:21:08Z

Darloth3: Blender world tab, for ease of learning.

== Summary ==
Blender world tab, for ease of learning.

File:Blender render tab.png

2020-10-13T23:15:07Z

Darloth3: /* Licensing */

== Summary ==
A small screenshot of the blender render tab, to make learning easier.
== Licensing ==
GPL from Blender

File:Blender render tab.png

2020-10-13T23:13:50Z

Darloth3: A small screenshot of the blender render tab, to make learning easier.

== Summary ==
A small screenshot of the blender render tab, to make learning easier.
== Licensing ==
{{cc-by-4.0}}

Blender To Zero-K

2020-10-13T23:01:52Z

Darloth3: Initial draft of groundplane bake, WIP

Blender To Zero-K

2020-10-12T10:57:22Z

Darloth3: Added more headings for blender section

Blender To Zero-K

2020-10-12T10:49:09Z

Darloth3: ToC and outline

Here is a tutorial covering all of the steps to make or edit a model in Blender (a free 3d modelling program) and transfer it to the Spring engine, then have Zero-K load it as a mutator so you can test it in-game.

The contents page here will also act as a quick reference for all of the necessary steps, in order:

__TOC__

= Make or Edit the model in Blender =

= Export the model to .dae format =

= Set up texture associations and .dae.lua metadata =

= Set up Zero-K mod that contains and uses your files =

= Run Zero-K and point at your mod =

= Fix whatever isn't right =

Zero-K:Developing

2020-10-12T10:45:27Z

Darloth3: /* Artwork */ - Blender to ZK page.

New developers should read this before touching the source.

== ZK's Devving Philosophy (social rules) ==
* "War is a product of anticommunication"
** Communicate with other devs about your changes/fixes, let them understand the issue. Do not make 'random' changes.
* "Do not create work for other people."
** Have responsibility for your changes/commit. Do not leave bugs that require other people to fix.
* "Readability & performance are equally important."
** Optimize code but not to the point of unreadability. [http://c2.com/cgi/wiki?RulesOfOptimization Remember the rules of optimization]:
*** Don't.
*** Don't (yet).
*** Profile before doing it.
* "If it ain't broke, don't fix it."
** Don't code fixes that nobody wants to problems that don't exist.

== What is in source codes ==
* [https://github.com/ZeroK-RTS/Zero-K Zero-K] contains the game proper
** units folder contains unit definition files
*** You can read the wiki about game development for [http://springrts.com/wiki/Main_Page Spring Engine]
* [https://github.com/ZeroK-RTS/Zero-K-Infrastructure Zero-K-Infrastructure]
** Zero-K.info: Website sources
** ZkLobbyServer: Lobby server (for MP)
** ZkData: Website/server database structure
* [https://github.com/ZeroK-RTS/Chobby Chobby] contains the lobby client
* [https://github.com/ZeroK-RTS/Zero-K-Artwork Zero-K-Artwork] contains sources for 2D art, 3D art and sounds
* [https://github.com/ZeroK-RTS/SpringRTS-Tools SpringRTS-tools] contains various dev tools
** Upspring - required to edit the .3do and .s3o model files used in the game
** MapIconBuilder - unit map icon sources are here
* [https://github.com/ZeroK-RTS/Zero-K-Missions Zero-K-Missions] contains source files for official ZK missions

=== Style Guide===
The lua in the menu (chobby) and game proper should use the following whitespace:
* Indent with tabs.
* A tab may only follow a newline or another tab.
* If the text across two lines is being aligned (such as for a long function) then the two lines must have the same number of tabs.
* Don't try stack flow of control into one line. For example, put newlines after <code>then</code> and <code>else</code>.
* End files with a newline.
* Commas should be followed by whitespace. Relations (=, <, <=, >=, ==, ~=) should have whitespace on each side.
* if a conditional is to take up multiple lines, double indent the extra lines and end the line with a conjunction (See Gallery below)
These guidelines are not necessarily followed in old files so updating them with a separate commit is a good idea prior to making large changes. Also, unitdefs use two-space indentation instead of tabs.

There are a few guildines for dealing with Spring functions.
* Localisation of Spring.Function should be named spFunction.
* Localisation of Spring.MoveCtrl.Function should be named spMoveCtrlFunction.
* Spring.GetCommandQueue should be used rather than Spring.GetUnitCommands (it's an alias, we just picked one).

<gallery>
Styleguide-if-example.JPG|Proper multiline if statement
Styleguide-stackflow.JPG|Example of stacked flow control
</gallery>

== Getting sources ==
This is a guide to downloading Zero-K sources from [https://github.com/ GitHub] using [https://tortoisegit.org/ TortoiseGit]. The game sources are used as an example, however this method applies to other subprojects as well.
* Install [https://tortoisegit.org/download/ TortoiseGit].
* Create a [https://github.com/ GitHub] account.
[[File:ForkZK.jpg]]
* Log in to GitHub and [https://github.com/ZeroK-RTS Locate] the repository you want to edit.
* Click the "Fork" button on the GitHub website to create your own copy on GitHub.
[[File:cloneZK.jpg]]
* Locate your fork on GitHub and click "Clone or Download".
* Copy the web URL to your clipboard.
[[File:localCloneZK.jpg]]
* Create a folder called 'zk.sdd' in your Zero-K install under games.
* Right click on 'zk.sdd' and select 'Git Clone...' from the context menu.
[[File:cloneUIZK.jpg]]
* Copy the web URL into the 'URL:' field of the clone interface.
* Ensure that the 'Directory:' field ends in 'zk.sdd'. It is likely to automatically contain the path '...\Zero-K\games\zk.sdd\Zero-K' so be sure to delete the '\Zero-K' at the end.
[[File:cloneSuccess.jpg]]
* Wait for the sources to download.
* Your 'zk.sdd' folder should look something like the image above.

== Updating sources ==
Keep your sources up to date by periodically syncing your fork to the original repository (using 'compare', see: https://github.com/KirstieJane/STEMMRoleModels/wiki/Syncing-your-fork-to-the-original-repository-via-the-browser, then do "rebase and merge" instead of "merge") and doing TortoiseGit -> Pull on your repository folder to take the changes from GitHub to your local files.

== Modifying the game ==
:''For personal modding, see [[Mod Creation]]''
Follow the instructions in 'Getting sources' the download the Zero-K game sources. Feel free to inspect and edit the game files. Most developers using Windows edit lua files with [https://notepad-plus-plus.org/download/v7.6.6.html Notepad++].

To test your changes:
* Create an empty file named 'devmode.txt' in the same directory as Zero-K.exe.
* Launch Zero-K.exe.
[[File:enableDevMode.jpg]]
* Select 'Zero-K Dev' in Settings -> Developer -> Singleplayer (you may need to scroll down).
[[File:startTest.jpg]]
* From the main menu select Singleplayer -> Skirmish -> Advanced -> Start to launch a test game. Note that the game type should be automatically set to 'Zero-K $VERSION'.
* In the game, press F8 to open debug console. It'll display errors and output to the log.

== Modifying the lobby menu ==
Follow the instructions in 'Getting sources' with the following adjustments:
* The repository that you want to edit is https://github.com/ZeroK-RTS/Chobby.
* It is best to call the folder something like 'zkmenu.sdd', to avoid confusion.
Make sure that the 'Directory:' field ends in '.sdd'. You should end up with something like this:

[[File:zkmenufolder.jpg]]

To test your changes launch Zero-K.exe with the <tt>dev</tt> arg (i.e. <code>Zero-K.exe dev</code>). On windows this is best done by creating a shortcut and changing the target, as shown below.
[[File:targetZK.jpg]]

== Submitting changes ==
Git provides a systematic way to review and merge changes into the main repositories. The main game repository is used as example, but this method works for other repositories as well.

The simple way to commit changes is as follows.
* Make some changes to your local files.
* Right click on 'zk.sdd' and select 'Git Commit'.
* Write a description of the changes and click 'Commit'.
* Right click on 'zk.sdd' and select TortiseGit -> Push.
* Enter your GitHub login and password when prompted. The changes should now appear on your fork in GitHub.
* Navigate to https://github.com/ZeroK-RTS/Zero-K/pulls and click "New Pull Request".
* Click "compare across forks" to make your fork visible.
* Set your fork to be the head repository.
* Write a title and description of the changes, then create the pull request.
This creates a proposal to apply your changes to the main game. Be sure to check up on it and respond to comments.

A more advanced method involves creating branches locally with TortiseGit -> Create Branch and committing blocks of related changes to a single branch. You are then able to make pull requests from branches. This allows branches to be smaller and more focused, which is desirable when merging.

Make sure to keep your repository up to date to make merges less difficult.

== Zero-K.exe launch flags ==
<pre>Zero-K.exe [rapid tag] [engine version]</pre>
Note that the engine specified in arg won't automatically use the main Zero-K folder as its datadir. Add a <tt>springsettings.cfg</tt> file to the engine version's folder with the tag <code>SpringData = path_to_Zero-K_folder</code>

== Modifying infrastructure/tools ==
* Install [https://www.visualstudio.com/en-us/products/visual-studio-community-vs.aspx Visual Studio Community edition]
* Install [https://www.microsoft.com/en-us/sql-server/sql-server-downloads SQL Server express]
* Clone to desktop [https://github.com/ZeroK-RTS/Zero-K-Infrastructure Zero-K infrastructure]
* Test by opening Zero-K.sln in Visual Studio

=== Initializing Website Database ===
You may need to setup the database connection for the website. In order to do that: Open Visual Studio, open the Server Explorer panel (under the View menu), right click Data Connections -> Add Connection -> Sql Server. Enter <code>(localdb)\mssqllocaldb</code> in the Server Name field, after which zero-k_local will appear in the dropdown list of databases.

(If zero-k_local does not appear, type it in the text box and press OK; Visual Studio will ask whether you would like to create the database. This may require you to have administrator rights on the computer.)

[[File:zk-database-setup.png]]

=== Debugging infrastructure ===
* To run a project right click it, choose "set as startup project" and hit F5 to run using debugger.
* You can enable multiple startup projects to test entire infrastructure locally (game servers, lobby etc). Enable asp.net, springie and ZeroKLobby projects to test it all together. [http://i.imgur.com/2mgizUJ.png Setup]
* To run asp.net:
** It's required that you install MS SQL Express on your local PC.
*** You can get SQL Server 2017 (for Windows 8 and later) [https://www.microsoft.com/en-us/sql-server/sql-server-editions-express here] or SQL Server 2014 (for Windows 7) [https://www.microsoft.com/en-ie/download/details.aspx?id=42299 here]. For SQL Server 2014, the file you will need is called SQLEXPR_x64_ENU or SQLEXPR_x86_ENU. Make sure you install version that matches your version of Windows (i.e. x86 vs x64).
*** During the installation, set collation to <code>SQL_Latin1_General_CP1_CI_AS</code>. Leave all the parameters default except that I changed server name to SQLEXPRESS in one of the first steps of wizard.
[[File:SQL server collation.png|405px]]
** Right click asp.net -> properties -> web -> check "Specific Page" and leave it blank. Otherwise you get errors when trying to host locally.
** Make sure SQL Server is running (check the Sql Server Configuration Manager in the Start Menu). If you can't connect, edit the data source for <code>ModeType.Local</code> in <code>GlobalConst.cs</code> (currently line 46) to say something like: <code>Data Source=<hostname (usually your computer name)>\SQLEXPRESS</code>
** To make things run smoothly the following changes might also be a good idea: In <code>Shared/PlasmaShared/GlobalConst.cs</code> (currently line 137) replace the DefaultEngineOverride with whatever engine version is current. Comment out lines 190 and 238-298 of <code>Zero-K.info/AppCode/PlasmaServer.cs</code> unless somebody can supply instructions on how to make the torrent errors go away.

TODO: add download links for sample database tables here. Users and clans are probably easier to make yourself for most purposes. For now, if you need this ask Licho, Histidine, DeinFreund or Anarchid. Aquanim has sample tables for maps and Planetwars structures, if that is all that you need.

=== Modifying The Database Structure ===
* Modify the appropriate files in ./ZkData/Ef/... and elsewhere ( [https://github.com/ZeroK-RTS/Zero-K-Infrastructure/commit/61addee11e74b09dd5dd73e12d31a28030d84e81 this commit] should be a reasonable guide; don't worry about the migration files, they are created later )
* Open Tools > NuGet Package Manager > Package Manager Console
* At the top of the window which appears, there is a "Default project" dropdown box. Set this to ZkData.
* Type the command <code>Add-Migration [description-of-change-here]</code> into the package manager console. This should create some migration files with your description and a timestamp in the name in the Migrations folder of ZkData.
* In some cases you may now need to manually edit the created migration files to set defaults and the like?
* Type the command <code>Update-Database</code> into the package manager console. This should update the database structure.
* To revert a migration that has not yet been pushed to the main repository, run <code>Update-Database –TargetMigration: TheLastGoodMigration</code> then delete your bad migration files.

== Artwork ==
See [http://zero-k.info/Wiki/Development_Artwork Development Artwork] (outdated)

[[Blender_To_Zero-K|Blender To Zero-K]]

== Missions ==
=== Campaign ===
Campaign planets/missions are defined in [//github.com/ZeroK-RTS/Chobby/tree/master/campaign/sample Chobby/campaign/sample]

=== Standalone missions ===
See [[Mission Editor|Mission Editor start page]]

== Updating PlanetWars for new round ==
:''TODO''
Changing faction:
* Faction ID, name, color in dbo.Faction
* Faction blurb <tt>Faction<Name></tt> on sitewiki
* Add/change icons if needed
** Site: img/factions/<name>.png
** Game: LuaUI/Configs/Factions
** Chobby: LuaMenu/Images/Factions
** Does chobby download them automatically? Presumably not

Using [https://zero-k.info/PlanetwarsAdmin Planetwars admin interface]: Change to a different galaxy if desired, reset PW

== Wiki ==
See [[Editing Help]]

=== Unit pages ===
Part of each unit page is autogenerated by the [//github.com/ZeroK-RTS/SpringRTS-Tools/tree/master/unitguide Unit Guide tool], and uploaded by the [//github.com/ZeroK-RTS/Zero-K-Infrastructure/blob/master/Fixer/WikiPortingMW.cs Wiki bot].

Run <code>export_unit_templates.sh</code> to generate wiki templates for each unit (see <code>export_unit_templates.lua</code> for some configuration options), then have the bot read the generated text files and edit the unit pages accordingly (requires Visual Studio setup as detailed above). The text output can also be used to manually edit pages.

Unit buildicons and radar icons should be uploaded by FTP to manual.zero-k.info (<code>zero-k.info/zkmanual/www/unitpics</code> and <code>/icons</code> respectively). Contact Licho or Histidine for login details.

== itch.io builds ==
Instructions for updating the portable build on [https://itch.io/ itch.io]:

* Download latest Zero-K portable from https://zerok.itch.io/zero-k, extract to a folder
* Download butler (see guide at https://itch.io/docs/butler/)
* Modify extracted portable folder so that its contents are the same as what the user will download
* Run butler with command: <code>butler push <portable folder> zerok/zero-k:portable</code>

== Engine ==
See [https://springrts.com/wiki/Development:Getting_Started Spring Engine Development]

[[Category:Development]]

User:Darloth3

2020-10-12T10:43:16Z

Darloth3: Created page with "It'sa me! Darloth3! There used to be a Darloth account and may at one point have even been a Darloth2, but those were for older versions of spring and their passwords were fo..."

It'sa me! Darloth3!

There used to be a Darloth account and may at one point have even been a Darloth2, but those were for older versions of spring and their passwords were forgotten, lost to time.

So by the time I made an account for the ZK side of things I just went with Darloth3. Call me Darloth, it'll be much less confusing for everyone involved!

User:Anarchid/OmniCommanderDesign

2019-03-20T14:10:09Z

Darloth3: animated parts should be empties

This is my attempt to figure out a design for an unified commander chassis.

= Why =

Historically ZK has had several commander chassis to provide variety for a bunch of reasons:
* Initially it was the only way to provide commander variety (because procedural generation of unitdefs was not available)
* Later, because while <code>unitdefs_post</code> solved the former problem, the models existed, and provided some, albeit limited, visual feedback on what the commander was
* Even later, as commanders became mostly "dynamic", for the same legacy reasons
* No model that would display more useful information than the current system exists.

This is bad for several reasons:
* Significantly initially different chassis are pregame RPS in several situations - such as Recon commander's jump available at level zero, or Support commander's build range
* This provides useful visual representation only for one important commander ability - jump - while all other abilities are essentially hidden. Especially guns all look exactly alike.

= Design Design =
Before approaching the design of this thing, it is useful to approach the design of designing this thing.

# As with current commander design requirements, this design should not have degenerate, overpowered or useless paths.
#* Commanders should not be significantly stronger than same fair cost in units at any point, but should not be that much worse either
#* A single build or a series of builds should not be always better than the others
#* It's also a good idea to avoid as much lock-in as possible; branching systems that prohibit modules further down the line are boring (but "this module goes in the helmet slot, which is already occupied" is fine).
# For a transition from chassis to modules entirely, the first level-up should be important enough to encompass all of the variety in current chassis and first-morph modules
#* A significant part of this is chassis passive bonuses and specialization - there should be modules to imitate this
#* With the following criterion, this also means that the first morph should make commanders very *visibly* different as well.
# As much interesting information about the commander as possible should be meaningfully visible on the commander body.
#* This intrinsically suggests tying commander modules to their respective body parts, and maybe even have body part based equipment slots
#* Current stackable or weapon modules are insufficient to encompass this. A "subsystem module" approach like in Aquanim's draft may be useful.
#* The important qualitatively difference items should take priority. Guns and jump ability are first tier; everything else is secondary or tertiary.
# The technical considerations of the omni-commander model should be considered at every step
#* The model should be reasonably easy to modify and generally as low-maintenance as possible
#* Replacement or refund of current commander skins should be considered and made as easy as possible
#* Additional types of "hats" could be considered

= General Stuff =
# The omni-commander model is at least partially an atlas/lego system. The texture provides various materials to be splatted onto various geometry bits, with few of it strictly dedicated (except for core geometry). Weapons have their own dedicated mini-zones and can share materials.
## Animated parts should be empties, with the swappable visual models parented to those empties.
## Weapons and important abilities are emissive and color coded; some may be animated
# Every module is visually represented on the model.
## Important modules are called **subsystems** and take equipment **slots**. They completely take over a given body part, and more than one module cannot use the same body part. Advanced versions of a subsystem can replace a weaker version. The following slots are available:
### Head (helmet, crown, antenna, etc) - intel, aura abilities like shield, cloaker, radar
### Chest (torso front, breastplate, etc) - armor, regeneration
### Forearms (left, right) or whole arms - weapons. These should be huge and prominent as the most important things ever.
### Shoulders (left, right) - secondary weapons, construction abilities
### Back - active abilities (jump, float?)
### Legs - passive movement-related abilities (jump? climb? hover? goomba stomp?).
## Subsystem module _choices_ in the UI have to somehow show which slot they occupy
## Stackable modules, as much as they exist, are represented as small bits on or near the things they affect.
### Armor modules - rivets or small plates on chest
### Damage modules - small glowy bits on upper arms
### Speed modules - small bits on upper/lower legs
### .. etc
## Stackable module choices need to show their stacking limits in the UI.
## Enhancement modules are treated as new modules. E.g. a longer-stun version of a lightning gun simply has a different lightning gun model.

= Draft Bucket List Of Modules =

{| class="wikitable sortable" style="text-align: center"
! Name
! Type
! Slot
! Level
! scope="col" class="unsortable" | Description
! scope="col" class="unsortable" | Comments
|-
! Jetpack
| System
| Back
| 1
| Allows commander to jump
| Large, bulky, visible
|-
! Beam Laser
| Weapon
| Arm
| 1
| Kills things
| Long teal/blue emissive line along top
|-
! Combat Drone Kit
| System
| Back
| 2
| Launches Fireflies
| Moving mechanical stuff. Possibly can also dock drones if drone tech advances?
Conflicts with jump, but not with shield/cloak.
|-
! Personal Shield
| System
| Head
| 2
| Provides a small shield
| Crown that reminds an Aspis. Incompatible with cloak.
|-
! Personal Cloak
| System
| Head
| 2
| Cloaks commander
| Teal glowing halo, like Scythe/Iris backpacks. Incompatible with shield.
|-
! Advanced Nanolathe
| System
| Shoulder
| 1
| More nano range, slightly more build power
| Replaces default nano, bigger.
|}

Cheese

2018-05-29T13:15:16Z

Darloth3: /* Ogre rush */ Renamed banisher to ogre

Cheese strategies are strategies that can be described as high-risk and high-reward. These typically rely on winning hard and winning early. Below we will detail some of the finest cheese known to lobster-kind. 
Disclaimer: Some of these are quite bad strategies, but will probably sometimes work nonetheless.
==On the use of commanders==
A good rush will often include your commander. In the early parts of the game, this unit represents the majority of your combat strength. Most rushes just utilize the commander as a support unit that fills in a role that you need. However, some cheese strategies utilize the commander as a centerpiece of the strategy.

==The strategies==
===Fencer rush===
Plop rover factory, and put fencers on repeat queue. Once you have made like 2 it is time to start moving towards your opponent. Once your comm builds the starting mexes/energy move it towards the opponents base as well. Once you get to your opponent's base and see what they have been up to, choose an appropriate comm morph option. Continue streaming fencers across the map. When you have a critical mass of fencers you can just move in and kill them. But don't wait too long! If they get up significant defense you could end up losing.
*Rocket launcher is the best morph to get if they try to counter you with skirmishers.
*Riot cannon if they build lots of low-hp raiders.
*Heat ray is good if they try to make heavies.

===Reaver rush===
Much like the fencer rush.
#Plop cloaky and take 1 mex.
#Make reavers on repeat queue.
#Move out with your comm and have reavers rally to it.
This rush is more time sensitive, and requires that you hit sooner than a fencer rush. Reavers are a bit faster than your comm so they will catch up to it.

===Ogre rush===
The Ogre is probably the most robust riot unit in the game, with high DPS and HP. It can be quite difficult to stop earlygame, especially if it is unscouted. The ogre is capable of killing commanders by itself and it has splash damage, making it quite effective against the raiders people typically build as well. This rush is time sensitive, as if they scout you they can throw up lots of light defense turrets and hold it off. 
#Plop the HT foundry.
#Queue up an ogre, set the rally point to your opponents base.
#Assist the factory with your commander.
This rush is especially effective against factories with no skirmishers, like HT or rovers. Factories with awkward skirmishers like spider may struggle to deal with it as well, but HT vs spider is a rare match-up anyways.

====Defending against it====
The best defense against any cheese is scouting, and this is true here. Build your lightest raider and send it to your opponent's base. Since the banisher is an expensive unit, by the time your raider gets there it should still see the banisher in the factory being built, or just as it moves out. Since the opponent has commited quite a bit of resources to this rush you can affort to just spam lots of LLTs and the occasional Picket to hold it off. If you have a skirmisher, that would be a good choice to make as well.

===Com-Morph Push===
===Com-Drop===
===Blastwing opening===
===Raider rush===
These types of rushes are distinct from the others in that they don't bring along the commander, and rely on overwhelming your opponent with an unexpected raider force. Below are listed some of the raiders that are most effective at rushing.
====Flea rush====
Plop spider factory and build your initial 500 metal into fleas. Send your first two out to scout. Once you get your flea swarm you can either attack the opponents base, or their commander. If their commander morphed to a splash damage weapon this will not work, but it should lead to a dead commander if the commander is alone and un-morphed. Alternatively, if they only built like 1 MT or LLT in their base and all their units are gone, you are able to quickly kill the defensive turrets and possibly win the game by killing all their eco structures and factory. You need to be careful with your fleas though, the death explosions from most buildings can instantly kill them. Obviously, this strategy fails if they are not very greedy and bother to build some raiders.
====Glaive/Bandit rush====
====Scorcher rush====

Gunship Plant

2018-05-28T22:29:16Z

Darloth3: Copperhead -> Ettin, Archangel -> Toad

The '''{{PAGENAME}}''' is a factory that produces gunships.{{ Infobox zkunit
| name = Gunship Plant
| defname = factorygunship
| description = Produces Gunships, Builds at 10 m/s
| image = http://manual.zero-k.info/unitpics/factorygunship.png
| icontype = facgunship
| cost = 800
| hitpoints = 4000
| energy = 0.3
| sight = 273
| abilities =
{{ Infobox zkability construction
| buildpower = 10
}}
}}==Description==
The Gunship Plant is designed for close air support. It includes a selection of transports for hauling land units around, and combat gunships which can perform a variety of offensive or defensive roles.

The Gunship Plant builds:
* [[Wasp]]
* [[Blastwing]]
* [[Gnat]]
* [[Locust]]
* [[Harpy]]
* [[Nimbus]]
* [[Revenant]]
* [[Krow]]
* [[Trident]]
* [[Charon]]
* [[Hercules]]

==Tactics and Strategy==

The principle of Gunships is to assault the enemy from the air, at any time, and in any place. To this end, the Locust and Harpy are quick and capable of engaging enemy forces directly, while the Charon and Hercules can transport friendly land forces to the places they will be most effective. As a finishing blow, the super-heavy Krow gunship is without equal against opponents with poor anti-air coverage.

In contrast to Airplanes, Gunships never have to rearm, so they can stick around an enemy base or army and keep dealing damage. On the other hand, they are slower and require more time to deal the same amount of damage that a bombing run would. Similarly, the Trident and Harpy are favoured in a head-on, prolonged engagement against the [[Swift]] and [[Raptor]] airplane fighters, but they are slower and less able to react to air-to-ground threats presented by the enemy.

=== Example Unit Combinations ===

As a raiding force, use Blastwings to set an enemy factory on fire and halt production, then use Locusts to take out enemy infrastructure.

Tridents and Harpies together present some danger to ground units while being almost impervious to attack from enemy air forces.

Where possible, protect your dedicated anti-ground gunships like the Nimbus, Revenant and Krow from air-to-air threats with Tridents.

Use Charons to drop slow, high-damage riot units like the [[Reaver]] or [[Scallop]] close to enemy buildings or units which they could not otherwise reach. You can assist your dropped forces with Gnats to disable enemy threats.

Similar drop tactics may be pursued by transporting a heavier unit like the [[Dante]] with a Hercules. If you don't want to lose the units you're dropping, retrieve them with transports or a [[Djinn]] beacon.

More esoteric uses of transports include dropping bombs like the [[Snitch]] or [[Skuttle]] on enemy targets, or stunning a high-value target like a [[Crabe]], [[Grizzly]] or [[Commander]] with Gnats then abducting it with a Hercules.

=== Beating Gunships ===

Anti-air units or structures which deliver high sustained damage-per-second are generally more effective against Gunships than those with high burst damage. The [[Razor]] is pretty cheap and very tough, though you will need more than one to deal enough damage to a large Gunship fleet. The [[Cobra]] is more expensive but its flak cannon inflicts area-of-effect damage. The range of the [[Chainsaw]] and [[Artemis]] makes them effective against any air threat, though they are more expensive.

In terms of mobile anti-air, the [[Ettin]] and [[Toad]] are most effective against Gunships. In permissive terrain, the speed of the [[Crasher]] and [[Flail]] gives them an edge despite being burst-damage based AA. The [[Gremlin]] is effective in bulk if their passive cloak is abused to set traps for enemy Gunships.

Yout first priority against Gunships is to fend off the initial raids by Locusts and Blastwings while continuing to expand and pressure them in return. Locusts fly quite low so unlike most air units they are quite vulnerable to the [[Lotus]], and [[Picket]] are also effective in larger numbers. You might also need mobile anti-air to protect your constructors.

If you are using Airplanes against a player with Gunships, avoid a direct fight unless you have a substantial numerical advantage - Tridents are very strong against your fighters. They can't move fast enough to deal with bombing threats on multiple fronts, so focus on supporting your ground forces with bombing runs. You should still keep some fighters to contest the skies if the gunships enter your territory.

If you are playing the Gunship mirror matchup, try to have more Tridents than they do, while still making things happen in the ground war using Locust raids and the like.

{{Navbox buildings}}

User talk:Aquanim/DraftCommanders

2018-05-28T18:39:15Z

Darloth3: Some comments

Just some ideas/suggestions, otherwise like it in general. Would be willing to help implement it if I can get my dev copy set up again.

Feedback Loop - how about this increasing commander autorepair when it's stationary and idle, working as if it were repairing itself without requiring the engine to actually let it nanolathe itself?

Pocket Genie - no pun about bottles? Bottled Djinn?

Augmented Hydraulics seems pretty difficult to balance, range and speed on the same moderate-tough unit.

-- [[User:Darloth3|Darloth3]] ([[User talk:Darloth3|talk]]) 20:39, 28 May 2018 (CEST)

Commander

2018-05-21T12:56:30Z

Darloth3: Huh, damage boost is still 10%. Must have got confused with target system.

<div style="float:right;">__TOC__</div>
= Warning: portions of this page are out of date =

The commander system was substantially revamped in winter 2016. This page has only partially been updated to the new system.

= Commander intro =
Your commander can be configured with a variety of modules to suit your play-style.

After the update, modules are added only at the game and are all unlocked, and you do not need to level up to get any modules.

To keep the game balanced commander modules cost metal ingame and are not all applied at the start of the game. Commanders start at level 1 with a free peashooter and no modules but they can morph an unlimited number of times (but you'll eventually run out of modules after which it is pointless to morph). At Morph 1 (Level 2), commanders gain a single weapon. At morph 3 commanders gain a second weapon which can either be a second regular weapon or a special weapon. If a weapon slot is left empty the commander will be given a free peashooter in its place. Some weapons will replace any other weapons (e.g I get shock rifle, it will replace the first weapon I got)

Each morph level gives a commander more health, more modules or weapons. Morphs have a base cost and additional cost based on the value of the modules or weapons that it will gain when the morph is complete. You can pre-configure your commander buildouts only through level 6 but you can upgrade any number of times in-game.

Unlike regular units, your commander is not disabled while morphing.

= Modules and weapons =

== Number of slots per level ==

Commanders start at level 1. The number of modules and weapons increases with levels.

{|
! Commander level !! 1 !! 2 !! 3 !! 4 !! 5 !! +
|-
| Base [[File:Ibeam.png|20px]] cost || -     ||25 || 100 || 600 || 200 || +100
|-
| Total Weapon slots || 0 || 1 || 1 || 2 || 2 || +0
|-
| Total Module slots || 0 || 1 || 3 || 5 || 8 || +3
|-
|}

Equipping weapons and modules costs additional metal.

== Module types ==
Modules have cyan names in the unlock list, although their icon color depends on their nature. They fall into four categories.

=== Stackable ===
https://raw.githubusercontent.com/ZeroK-RTS/Zero-K/master/unitpics/module_ablative_armor.png https://raw.githubusercontent.com/ZeroK-RTS/Zero-K/master/unitpics/module_autorepair.png https://raw.githubusercontent.com/ZeroK-RTS/Zero-K/master/unitpics/module_high_power_servos.png

These modules are able to stacked as many times as they allow, 8x for some and 10x for drones. Stacking them repeatedly will create a powerful commander, even though their bonuses as quite minor. (10% range/damage/speed for those modules) These are cyan.
This type of module is the one that should be used the most, and because of their versatility, it is useful if you intend on getting commanders which do many things, or a single buff commander that is fast, invisible and deals lots of damage. Some of these modules will subtract speed or HP, and should be used with caution as too much will leave the commander a sitting duck.

Modules:
* '''Advanced targeting system:''' +7.5% range for all weapons. -2.5% speed.
* '''Damage booster:''' +10% damage for all weapons. -2.5% speed.
* '''High density plating:''' +1600 HP,-10% speed. Requires Ablative armor plates.
* '''Ablative armor plates:''' +600 HP
* '''Companion drone:''' +Weak automatically reconstructed attack drone
* '''Battle drone:''' +Upgraded autoconstructed drone with slowing laser, requires Companion drone first.
* '''Carrepairer's nanolathe:''' +4 Buildpower.
* '''High power servos:''' +8% speed.
* '''Autorepair system:''' +10HP/sec -100 HP[/list]

=== Support===
https://raw.githubusercontent.com/ZeroK-RTS/Zero-K/master/unitpics/module_fieldradar.png https://raw.githubusercontent.com/ZeroK-RTS/Zero-K/master/unitpics/module_areashield.png https://raw.githubusercontent.com/ZeroK-RTS/Zero-K/master/unitpics/module_jammer.png

Support modules are not stackable. They can provide large expensive bonuses such as a shield, cloaking, jamming or a cloaker. There are also cheap ones such as resurrect and inbuilt radar or an area shield/cloak. These are cyan as well.

=== Weapon Boosters ===
https://raw.githubusercontent.com/ZeroK-RTS/Zero-K/master/unitpics/weaponmod_standoff_rocket.png https://raw.githubusercontent.com/ZeroK-RTS/Zero-K/master/unitpics/weaponmod_autoflechette.png https://raw.githubusercontent.com/ZeroK-RTS/Zero-K/master/unitpics/weaponmod_high_frequency_beam.png

These modules are expensive but give a large bonus to a few specific weapons but can only be applied once. They are a space effective way to spend a module slot but make sure you have the weapon that they affect. They are purple.

== Weapon types ==
There are 2 types of weapon, special and normal. Both weapon types are affected by the stackable range and damage modules. Weapon names are in red.

=== Normal ===
https://raw.githubusercontent.com/ZeroK-RTS/Zero-K/master/unitpics/commweapon_beamlaser.png https://raw.githubusercontent.com/ZeroK-RTS/Zero-K/master/unitpics/commweapon_rocketlauncher.png https://raw.githubusercontent.com/ZeroK-RTS/Zero-K/master/unitpics/commweapon_gaussrifle.png

These are auto-targetting normal weapons that behave the same was as any other unit. They can be affected by weapon boosters and weapon converters given that it is the right weapon. They are all affected by stackable modules. They are red.

{|
! Name !! Range !! Reload time !! Damage !! DPS !! Commander !! Notes
|-
|Beam Laser||330||||||150||Strike   Guardian     Recon       Engineer||
|-
|Flame thrower||270||0.16 ||10 || 60||  Guardian     Recon|| Sets units on fire for 15s(15 DPS) pierces units Does more damage against larger units
|-
|Heatray||300||0.1 ||45 ||450 ||  Guardian|| Damage falls off with range
|-
|Machine Gun||285||0.16 ||30 ||180 ||Strike   Guardian     Recon||
|-
|Light particle beam||310||0.34 ||55 || 165||Strike     Recon       Engineer||
|-
|Lightning Rifle||300||1.66 ||220+550 || 132+330 ||Strike     Recon       Engineer|| EMP duration: 1s
|-
|Missile launcher||415||1 ||80 || 80||Strike       Engineer|| Homing
|-
|Riot cannon||275||2 ||220.2 || 110.1||  Guardian||
|-
|Shotgun||290||2 ||32x12 (384) || 192||Strike     Recon       Engineer||
|-
|Rocket launcher ||430||3 ||360 || 120||  Guardian||Not homing
|-
|Pea Shooter ||300||.1 ||12 || 120||Strike   Guardian     Recon       Engineer||Default weapon
|-
|}

=== Special ===
https://raw.githubusercontent.com/ZeroK-RTS/Zero-K/master/unitpics/commweapon_napalmgrenade.png https://raw.githubusercontent.com/ZeroK-RTS/Zero-K/master/unitpics/commweapon_disruptorbomb.png https://raw.githubusercontent.com/ZeroK-RTS/Zero-K/master/unitpics/commweapon_sunburst.png

Special weapons have a long reload time and must be manually aimed with the 'D' key. They are only affected by stackable modules. They are orange and can only be put on the level 4 weapon slot.

{|
! Name !! Range !! Reload time !! Damage !! DPS !! Commander !! Special Notes
|-
|Cluster bomb ||360 || 30 || 300x8 (2400)|| 80 ||  Guardian     Recon|| Bomblets spread (like a shotgun)
|-
| Concussion shell||450 || 25 ||750 || 30 ||    Recon|| Has Impulse (Tosses some units)
|-
| Disintigrator ||200 ||30 ||1400 || 46.67 ||Strike   Guardian|| Damage varies on unit size
|-
|Disrupter bomb ||450 ||25 ||350+2100 || 14+84 ||Strike     Recon       Engineer|| Has large AOE (512)
|-
| Hellfire grenade||450 || 25||200 || 8 ||  Guardian     Recon|| Sets an area on fire (45s,40dps+3s burning)
|-
| Multistunner||360 || 25||550/800 x 16 (8800/12800) ||352/512 ||Strike     Recon       Engineer|| Affected by flux amplifier. Max EMP time: 8s [upgraded: 12s]
|-
| SLAM||700 ||30 || 1512|| 50.4 ||  Guardian|| High vertical arc
|-
|}
Key: EMP Damage, Slow Damage

= Commander Chassis =
There are 4 types of commander chassis to choose for a battle.

You can configure custom commanders based on these chassis on your user page; you must be logged in to the Zero-K website and go to: https://zero-k.info/My/Commanders. These custom commanders may be selected at the beginning of the game in multiplayer matches. You will still need to upgrade them as usual, but the upgrade options are filled in to your preferences.

== Common attributes ==
The commander you start the game with produces 4 metal and 6 energy per second, via a unique Vanguard economy module. Any resurrected commanders who have lost this module produce only 0.4 metal and 0.4 energy per second. They all provide a sight distance of 500 and a sonar of 500. Chassis other than the Engineer Commander have 10 build power and 120 build range and the Engineer commander has 12 build power and 250 build range.

== Chassis list ==
Note that '''attributes on level 1 and level 2 are equal'''. Morphing to level 2 provides no bonus other than the weapon and module slot.

=== Strike Commander ===
https://raw.githubusercontent.com/ZeroK-RTS/Zero-K/master/unitpics/commstrike.png 
* All rounder
* Decent health and speed
* Can use the most weapon types
* Auto-regen bonus

{|
! Base Attributes !! Level 2 !! Level 3 !! Level 4 !! Level 5
|-
|HP: 2500 Speed: 40.5 Autoheal: 5||HP: 3000 Autoheal: 12.5||HP: 4000 Autoheal: 20||HP: 5000 Autoheal: 27.5||HP: 6000 Autoheal: 35
|-
|}

=== Guardian Commander ===
https://raw.githubusercontent.com/ZeroK-RTS/Zero-K/master/unitpics/commassault.png 
* Best HP
* Medium speed
* Gains more HP from increased levels than other chasis do
* Able to use most non-exotic weapons

{|
! Base Attributes !! Level 2 !! Level 3 !! Level 4 !! Level 5
|-
|HP: 3000 Speed: 40||HP: 3800 ||HP: 4900 ||HP: 6000 ||HP: 7200 
|-
|}

=== Recon Commander ===
https://raw.githubusercontent.com/ZeroK-RTS/Zero-K/master/unitpics/commrecon.png 
* Lowest HP
* Highest Speed (for a commander)
* Jumpjets
* Uses light weapons

{|
! Base Attributes !! Level 2 !! Level 3 !! Level 4 !! Level 5
|-
|HP: 1600 Speed: 43.5 Can Jump||HP: 2100||HP: 2600||HP: 3100||HP: 3600
|-
|}

=== Engineer Commander ===
https://raw.githubusercontent.com/ZeroK-RTS/Zero-K/master/unitpics/commsupport.png 
* Lowest speed
* Low HP
* Gains buildpower with levels
* Increased build range (250 compared to 120 for others)
* Fewer direct damage weapons

{|
! Base Attributes !! Level 2 !! Level 3 !! Level 4 !! Level 5
|-
|HP: 2000 Speed: 36 Build Power: 12||HP: 2500 Build Power: 14||HP: 3000 Build Power: 16||HP: 3700 Build Power: 18||HP: 4500 Build Power: 20
|-
|}

= Exact effects of attribute modifiers =
Attribute modifiers are applied in this order:
* Commander Chassis absolute statistics
* Percentage modifiers both from modules and chassis
* Absolute modifiers

Percentage modifiers from commanders and stackable modules are additive, not cumulative. Five +10% speed modules multiply a commander's speed by 1.5 instead of by 1.1^5 = 1.61.

Percentage modifiers from weapon boosters and converters are cumulative and applied before other percentage modifiers. Think of them as changing the intrinsic stats of the weapon, rather than adding a bonus.

{{Navbox manual}}

Commander

2018-05-21T12:52:14Z

Darloth3: Corrected nanolathe boost, reformat module list.

<div style="float:right;">__TOC__</div>
= Warning: portions of this page are out of date =

The commander system was substantially revamped in winter 2016. This page has only partially been updated to the new system.

= Commander intro =
Your commander can be configured with a variety of modules to suit your play-style.

After the update, modules are added only at the game and are all unlocked, and you do not need to level up to get any modules.

To keep the game balanced commander modules cost metal ingame and are not all applied at the start of the game. Commanders start at level 1 with a free peashooter and no modules but they can morph an unlimited number of times (but you'll eventually run out of modules after which it is pointless to morph). At Morph 1 (Level 2), commanders gain a single weapon. At morph 3 commanders gain a second weapon which can either be a second regular weapon or a special weapon. If a weapon slot is left empty the commander will be given a free peashooter in its place. Some weapons will replace any other weapons (e.g I get shock rifle, it will replace the first weapon I got)

Each morph level gives a commander more health, more modules or weapons. Morphs have a base cost and additional cost based on the value of the modules or weapons that it will gain when the morph is complete. You can pre-configure your commander buildouts only through level 6 but you can upgrade any number of times in-game.

Unlike regular units, your commander is not disabled while morphing.

= Modules and weapons =

== Number of slots per level ==

Commanders start at level 1. The number of modules and weapons increases with levels.

{|
! Commander level !! 1 !! 2 !! 3 !! 4 !! 5 !! +
|-
| Base [[File:Ibeam.png|20px]] cost || -     ||25 || 100 || 600 || 200 || +100
|-
| Total Weapon slots || 0 || 1 || 1 || 2 || 2 || +0
|-
| Total Module slots || 0 || 1 || 3 || 5 || 8 || +3
|-
|}

Equipping weapons and modules costs additional metal.

== Module types ==
Modules have cyan names in the unlock list, although their icon color depends on their nature. They fall into four categories.

=== Stackable ===
https://raw.githubusercontent.com/ZeroK-RTS/Zero-K/master/unitpics/module_ablative_armor.png https://raw.githubusercontent.com/ZeroK-RTS/Zero-K/master/unitpics/module_autorepair.png https://raw.githubusercontent.com/ZeroK-RTS/Zero-K/master/unitpics/module_high_power_servos.png

These modules are able to stacked as many times as they allow, 8x for some and 10x for drones. Stacking them repeatedly will create a powerful commander, even though their bonuses as quite minor. (10% range/damage/speed for those modules) These are cyan.
This type of module is the one that should be used the most, and because of their versatility, it is useful if you intend on getting commanders which do many things, or a single buff commander that is fast, invisible and deals lots of damage. Some of these modules will subtract speed or HP, and should be used with caution as too much will leave the commander a sitting duck.

Modules:
* '''Advanced targeting system:''' +10% range for all weapons. -2.5% speed.
* '''Damage booster:''' +7.5% damage for all weapons. -2.5% speed.
* '''High density plating:''' +1600 HP,-10% speed. Requires Ablative armor plates.
* '''Ablative armor plates:''' +600 HP
* '''Companion drone:''' +Weak automatically reconstructed attack drone
* '''Battle drone:''' +Upgraded autoconstructed drone with slowing laser, requires Companion drone first.
* '''Carrepairer's nanolathe:''' +4 Buildpower.
* '''High power servos:''' +8% speed.
* '''Autorepair system:''' +10HP/sec -100 HP[/list]

=== Support===
https://raw.githubusercontent.com/ZeroK-RTS/Zero-K/master/unitpics/module_fieldradar.png https://raw.githubusercontent.com/ZeroK-RTS/Zero-K/master/unitpics/module_areashield.png https://raw.githubusercontent.com/ZeroK-RTS/Zero-K/master/unitpics/module_jammer.png

Support modules are not stackable. They can provide large expensive bonuses such as a shield, cloaking, jamming or a cloaker. There are also cheap ones such as resurrect and inbuilt radar or an area shield/cloak. These are cyan as well.

=== Weapon Boosters ===
https://raw.githubusercontent.com/ZeroK-RTS/Zero-K/master/unitpics/weaponmod_standoff_rocket.png https://raw.githubusercontent.com/ZeroK-RTS/Zero-K/master/unitpics/weaponmod_autoflechette.png https://raw.githubusercontent.com/ZeroK-RTS/Zero-K/master/unitpics/weaponmod_high_frequency_beam.png

These modules are expensive but give a large bonus to a few specific weapons but can only be applied once. They are a space effective way to spend a module slot but make sure you have the weapon that they affect. They are purple.

== Weapon types ==
There are 2 types of weapon, special and normal. Both weapon types are affected by the stackable range and damage modules. Weapon names are in red.

=== Normal ===
https://raw.githubusercontent.com/ZeroK-RTS/Zero-K/master/unitpics/commweapon_beamlaser.png https://raw.githubusercontent.com/ZeroK-RTS/Zero-K/master/unitpics/commweapon_rocketlauncher.png https://raw.githubusercontent.com/ZeroK-RTS/Zero-K/master/unitpics/commweapon_gaussrifle.png

These are auto-targetting normal weapons that behave the same was as any other unit. They can be affected by weapon boosters and weapon converters given that it is the right weapon. They are all affected by stackable modules. They are red.

{|
! Name !! Range !! Reload time !! Damage !! DPS !! Commander !! Notes
|-
|Beam Laser||330||||||150||Strike   Guardian     Recon       Engineer||
|-
|Flame thrower||270||0.16 ||10 || 60||  Guardian     Recon|| Sets units on fire for 15s(15 DPS) pierces units Does more damage against larger units
|-
|Heatray||300||0.1 ||45 ||450 ||  Guardian|| Damage falls off with range
|-
|Machine Gun||285||0.16 ||30 ||180 ||Strike   Guardian     Recon||
|-
|Light particle beam||310||0.34 ||55 || 165||Strike     Recon       Engineer||
|-
|Lightning Rifle||300||1.66 ||220+550 || 132+330 ||Strike     Recon       Engineer|| EMP duration: 1s
|-
|Missile launcher||415||1 ||80 || 80||Strike       Engineer|| Homing
|-
|Riot cannon||275||2 ||220.2 || 110.1||  Guardian||
|-
|Shotgun||290||2 ||32x12 (384) || 192||Strike     Recon       Engineer||
|-
|Rocket launcher ||430||3 ||360 || 120||  Guardian||Not homing
|-
|Pea Shooter ||300||.1 ||12 || 120||Strike   Guardian     Recon       Engineer||Default weapon
|-
|}

=== Special ===
https://raw.githubusercontent.com/ZeroK-RTS/Zero-K/master/unitpics/commweapon_napalmgrenade.png https://raw.githubusercontent.com/ZeroK-RTS/Zero-K/master/unitpics/commweapon_disruptorbomb.png https://raw.githubusercontent.com/ZeroK-RTS/Zero-K/master/unitpics/commweapon_sunburst.png

Special weapons have a long reload time and must be manually aimed with the 'D' key. They are only affected by stackable modules. They are orange and can only be put on the level 4 weapon slot.

{|
! Name !! Range !! Reload time !! Damage !! DPS !! Commander !! Special Notes
|-
|Cluster bomb ||360 || 30 || 300x8 (2400)|| 80 ||  Guardian     Recon|| Bomblets spread (like a shotgun)
|-
| Concussion shell||450 || 25 ||750 || 30 ||    Recon|| Has Impulse (Tosses some units)
|-
| Disintigrator ||200 ||30 ||1400 || 46.67 ||Strike   Guardian|| Damage varies on unit size
|-
|Disrupter bomb ||450 ||25 ||350+2100 || 14+84 ||Strike     Recon       Engineer|| Has large AOE (512)
|-
| Hellfire grenade||450 || 25||200 || 8 ||  Guardian     Recon|| Sets an area on fire (45s,40dps+3s burning)
|-
| Multistunner||360 || 25||550/800 x 16 (8800/12800) ||352/512 ||Strike     Recon       Engineer|| Affected by flux amplifier. Max EMP time: 8s [upgraded: 12s]
|-
| SLAM||700 ||30 || 1512|| 50.4 ||  Guardian|| High vertical arc
|-
|}
Key: EMP Damage, Slow Damage

= Commander Chassis =
There are 4 types of commander chassis to choose for a battle.

You can configure custom commanders based on these chassis on your user page; you must be logged in to the Zero-K website and go to: https://zero-k.info/My/Commanders. These custom commanders may be selected at the beginning of the game in multiplayer matches. You will still need to upgrade them as usual, but the upgrade options are filled in to your preferences.

== Common attributes ==
The commander you start the game with produces 4 metal and 6 energy per second, via a unique Vanguard economy module. Any resurrected commanders who have lost this module produce only 0.4 metal and 0.4 energy per second. They all provide a sight distance of 500 and a sonar of 500. Chassis other than the Engineer Commander have 10 build power and 120 build range and the Engineer commander has 12 build power and 250 build range.

== Chassis list ==
Note that '''attributes on level 1 and level 2 are equal'''. Morphing to level 2 provides no bonus other than the weapon and module slot.

=== Strike Commander ===
https://raw.githubusercontent.com/ZeroK-RTS/Zero-K/master/unitpics/commstrike.png 
* All rounder
* Decent health and speed
* Can use the most weapon types
* Auto-regen bonus

{|
! Base Attributes !! Level 2 !! Level 3 !! Level 4 !! Level 5
|-
|HP: 2500 Speed: 40.5 Autoheal: 5||HP: 3000 Autoheal: 12.5||HP: 4000 Autoheal: 20||HP: 5000 Autoheal: 27.5||HP: 6000 Autoheal: 35
|-
|}

=== Guardian Commander ===
https://raw.githubusercontent.com/ZeroK-RTS/Zero-K/master/unitpics/commassault.png 
* Best HP
* Medium speed
* Gains more HP from increased levels than other chasis do
* Able to use most non-exotic weapons

{|
! Base Attributes !! Level 2 !! Level 3 !! Level 4 !! Level 5
|-
|HP: 3000 Speed: 40||HP: 3800 ||HP: 4900 ||HP: 6000 ||HP: 7200 
|-
|}

=== Recon Commander ===
https://raw.githubusercontent.com/ZeroK-RTS/Zero-K/master/unitpics/commrecon.png 
* Lowest HP
* Highest Speed (for a commander)
* Jumpjets
* Uses light weapons

{|
! Base Attributes !! Level 2 !! Level 3 !! Level 4 !! Level 5
|-
|HP: 1600 Speed: 43.5 Can Jump||HP: 2100||HP: 2600||HP: 3100||HP: 3600
|-
|}

=== Engineer Commander ===
https://raw.githubusercontent.com/ZeroK-RTS/Zero-K/master/unitpics/commsupport.png 
* Lowest speed
* Low HP
* Gains buildpower with levels
* Increased build range (250 compared to 120 for others)
* Fewer direct damage weapons

{|
! Base Attributes !! Level 2 !! Level 3 !! Level 4 !! Level 5
|-
|HP: 2000 Speed: 36 Build Power: 12||HP: 2500 Build Power: 14||HP: 3000 Build Power: 16||HP: 3700 Build Power: 18||HP: 4500 Build Power: 20
|-
|}

= Exact effects of attribute modifiers =
Attribute modifiers are applied in this order:
* Commander Chassis absolute statistics
* Percentage modifiers both from modules and chassis
* Absolute modifiers

Percentage modifiers from commanders and stackable modules are additive, not cumulative. Five +10% speed modules multiply a commander's speed by 1.5 instead of by 1.1^5 = 1.61.

Percentage modifiers from weapon boosters and converters are cumulative and applied before other percentage modifiers. Think of them as changing the intrinsic stats of the weapon, rather than adding a bonus.

{{Navbox manual}}

Commander

2018-05-21T12:46:11Z

Darloth3: Commanders cannot be produced from the strider hub. Corrected sonar range.

<div style="float:right;">__TOC__</div>
= Warning: portions of this page are out of date =

The commander system was substantially revamped in winter 2016. This page has only partially been updated to the new system.

= Commander intro =
Your commander can be configured with a variety of modules to suit your play-style.

After the update, modules are added only at the game and are all unlocked, and you do not need to level up to get any modules.

To keep the game balanced commander modules cost metal ingame and are not all applied at the start of the game. Commanders start at level 1 with a free peashooter and no modules but they can morph an unlimited number of times (but you'll eventually run out of modules after which it is pointless to morph). At Morph 1 (Level 2), commanders gain a single weapon. At morph 3 commanders gain a second weapon which can either be a second regular weapon or a special weapon. If a weapon slot is left empty the commander will be given a free peashooter in its place. Some weapons will replace any other weapons (e.g I get shock rifle, it will replace the first weapon I got)

Each morph level gives a commander more health, more modules or weapons. Morphs have a base cost and additional cost based on the value of the modules or weapons that it will gain when the morph is complete. You can pre-configure your commander buildouts only through level 6 but you can upgrade any number of times in-game.

Unlike regular units, your commander is not disabled while morphing.

= Modules and weapons =

== Number of slots per level ==

Commanders start at level 1. The number of modules and weapons increases with levels.

{|
! Commander level !! 1 !! 2 !! 3 !! 4 !! 5 !! +
|-
| Base [[File:Ibeam.png|20px]] cost || -     ||25 || 100 || 600 || 200 || +100
|-
| Total Weapon slots || 0 || 1 || 1 || 2 || 2 || +0
|-
| Total Module slots || 0 || 1 || 3 || 5 || 8 || +3
|-
|}

Equipping weapons and modules costs additional metal.

== Module types ==
Modules have cyan names in the unlock list, although their icon color depends on their nature. They fall into four categories.

=== Stackable ===
https://raw.githubusercontent.com/ZeroK-RTS/Zero-K/master/unitpics/module_ablative_armor.png https://raw.githubusercontent.com/ZeroK-RTS/Zero-K/master/unitpics/module_autorepair.png https://raw.githubusercontent.com/ZeroK-RTS/Zero-K/master/unitpics/module_high_power_servos.png

These modules are able to stacked as many times as they allow, 8x for some and 10x for drones. Stacking them repeatedly will create a powerful commander, even though their bonuses as quite minor. (10% range/damage/speed for those modules) These are cyan.
This type of module is the one that should be used the most, and because of their versatility, it is useful if you intend on getting commanders which do many things, or a single buff commander that is fast, invisible and deals lots of damage. Some of these modules will subtract speed or HP, and should be used with caution as too much will leave the commander a sitting duck.
Modules:
Advanced targeting system +10% range for all weapons.-2.5% speed.
Damage booster +10% damage for all weapons.
High density plating +1600 HP,-10% speed. Requires Ablative armor plates.
Ablative armor plates +600 HP
Companion drone +Weak attack drone
Battle drone +Upgraded drone, requires Companion drone first.
Carrepairer's nanolathe +5 Buildpower.
High power servos +10% speed.
Autorepair system +10HP/sec -100 HP

=== Support===
https://raw.githubusercontent.com/ZeroK-RTS/Zero-K/master/unitpics/module_fieldradar.png https://raw.githubusercontent.com/ZeroK-RTS/Zero-K/master/unitpics/module_areashield.png https://raw.githubusercontent.com/ZeroK-RTS/Zero-K/master/unitpics/module_jammer.png

Support modules are not stackable. They can provide large expensive bonuses such as a shield, cloaking, jamming or a cloaker. There are also cheap ones such as resurrect and inbuilt radar or an area shield/cloak. These are cyan as well.

=== Weapon Boosters ===
https://raw.githubusercontent.com/ZeroK-RTS/Zero-K/master/unitpics/weaponmod_standoff_rocket.png https://raw.githubusercontent.com/ZeroK-RTS/Zero-K/master/unitpics/weaponmod_autoflechette.png https://raw.githubusercontent.com/ZeroK-RTS/Zero-K/master/unitpics/weaponmod_high_frequency_beam.png

These modules are expensive but give a large bonus to a few specific weapons but can only be applied once. They are a space effective way to spend a module slot but make sure you have the weapon that they affect. They are purple.

== Weapon types ==
There are 2 types of weapon, special and normal. Both weapon types are affected by the stackable range and damage modules. Weapon names are in red.

=== Normal ===
https://raw.githubusercontent.com/ZeroK-RTS/Zero-K/master/unitpics/commweapon_beamlaser.png https://raw.githubusercontent.com/ZeroK-RTS/Zero-K/master/unitpics/commweapon_rocketlauncher.png https://raw.githubusercontent.com/ZeroK-RTS/Zero-K/master/unitpics/commweapon_gaussrifle.png

These are auto-targetting normal weapons that behave the same was as any other unit. They can be affected by weapon boosters and weapon converters given that it is the right weapon. They are all affected by stackable modules. They are red.

{|
! Name !! Range !! Reload time !! Damage !! DPS !! Commander !! Notes
|-
|Beam Laser||330||||||150||Strike   Guardian     Recon       Engineer||
|-
|Flame thrower||270||0.16 ||10 || 60||  Guardian     Recon|| Sets units on fire for 15s(15 DPS) pierces units Does more damage against larger units
|-
|Heatray||300||0.1 ||45 ||450 ||  Guardian|| Damage falls off with range
|-
|Machine Gun||285||0.16 ||30 ||180 ||Strike   Guardian     Recon||
|-
|Light particle beam||310||0.34 ||55 || 165||Strike     Recon       Engineer||
|-
|Lightning Rifle||300||1.66 ||220+550 || 132+330 ||Strike     Recon       Engineer|| EMP duration: 1s
|-
|Missile launcher||415||1 ||80 || 80||Strike       Engineer|| Homing
|-
|Riot cannon||275||2 ||220.2 || 110.1||  Guardian||
|-
|Shotgun||290||2 ||32x12 (384) || 192||Strike     Recon       Engineer||
|-
|Rocket launcher ||430||3 ||360 || 120||  Guardian||Not homing
|-
|Pea Shooter ||300||.1 ||12 || 120||Strike   Guardian     Recon       Engineer||Default weapon
|-
|}

=== Special ===
https://raw.githubusercontent.com/ZeroK-RTS/Zero-K/master/unitpics/commweapon_napalmgrenade.png https://raw.githubusercontent.com/ZeroK-RTS/Zero-K/master/unitpics/commweapon_disruptorbomb.png https://raw.githubusercontent.com/ZeroK-RTS/Zero-K/master/unitpics/commweapon_sunburst.png

Special weapons have a long reload time and must be manually aimed with the 'D' key. They are only affected by stackable modules. They are orange and can only be put on the level 4 weapon slot.

{|
! Name !! Range !! Reload time !! Damage !! DPS !! Commander !! Special Notes
|-
|Cluster bomb ||360 || 30 || 300x8 (2400)|| 80 ||  Guardian     Recon|| Bomblets spread (like a shotgun)
|-
| Concussion shell||450 || 25 ||750 || 30 ||    Recon|| Has Impulse (Tosses some units)
|-
| Disintigrator ||200 ||30 ||1400 || 46.67 ||Strike   Guardian|| Damage varies on unit size
|-
|Disrupter bomb ||450 ||25 ||350+2100 || 14+84 ||Strike     Recon       Engineer|| Has large AOE (512)
|-
| Hellfire grenade||450 || 25||200 || 8 ||  Guardian     Recon|| Sets an area on fire (45s,40dps+3s burning)
|-
| Multistunner||360 || 25||550/800 x 16 (8800/12800) ||352/512 ||Strike     Recon       Engineer|| Affected by flux amplifier. Max EMP time: 8s [upgraded: 12s]
|-
| SLAM||700 ||30 || 1512|| 50.4 ||  Guardian|| High vertical arc
|-
|}
Key: EMP Damage, Slow Damage

= Commander Chassis =
There are 4 types of commander chassis to choose for a battle.

You can configure custom commanders based on these chassis on your user page; you must be logged in to the Zero-K website and go to: https://zero-k.info/My/Commanders. These custom commanders may be selected at the beginning of the game in multiplayer matches. You will still need to upgrade them as usual, but the upgrade options are filled in to your preferences.

== Common attributes ==
The commander you start the game with produces 4 metal and 6 energy per second, via a unique Vanguard economy module. Any resurrected commanders who have lost this module produce only 0.4 metal and 0.4 energy per second. They all provide a sight distance of 500 and a sonar of 500. Chassis other than the Engineer Commander have 10 build power and 120 build range and the Engineer commander has 12 build power and 250 build range.

== Chassis list ==
Note that '''attributes on level 1 and level 2 are equal'''. Morphing to level 2 provides no bonus other than the weapon and module slot.

=== Strike Commander ===
https://raw.githubusercontent.com/ZeroK-RTS/Zero-K/master/unitpics/commstrike.png 
* All rounder
* Decent health and speed
* Can use the most weapon types
* Auto-regen bonus

{|
! Base Attributes !! Level 2 !! Level 3 !! Level 4 !! Level 5
|-
|HP: 2500 Speed: 40.5 Autoheal: 5||HP: 3000 Autoheal: 12.5||HP: 4000 Autoheal: 20||HP: 5000 Autoheal: 27.5||HP: 6000 Autoheal: 35
|-
|}

=== Guardian Commander ===
https://raw.githubusercontent.com/ZeroK-RTS/Zero-K/master/unitpics/commassault.png 
* Best HP
* Medium speed
* Gains more HP from increased levels than other chasis do
* Able to use most non-exotic weapons

{|
! Base Attributes !! Level 2 !! Level 3 !! Level 4 !! Level 5
|-
|HP: 3000 Speed: 40||HP: 3800 ||HP: 4900 ||HP: 6000 ||HP: 7200 
|-
|}

=== Recon Commander ===
https://raw.githubusercontent.com/ZeroK-RTS/Zero-K/master/unitpics/commrecon.png 
* Lowest HP
* Highest Speed (for a commander)
* Jumpjets
* Uses light weapons

{|
! Base Attributes !! Level 2 !! Level 3 !! Level 4 !! Level 5
|-
|HP: 1600 Speed: 43.5 Can Jump||HP: 2100||HP: 2600||HP: 3100||HP: 3600
|-
|}

=== Engineer Commander ===
https://raw.githubusercontent.com/ZeroK-RTS/Zero-K/master/unitpics/commsupport.png 
* Lowest speed
* Low HP
* Gains buildpower with levels
* Increased build range (250 compared to 120 for others)
* Fewer direct damage weapons

{|
! Base Attributes !! Level 2 !! Level 3 !! Level 4 !! Level 5
|-
|HP: 2000 Speed: 36 Build Power: 12||HP: 2500 Build Power: 14||HP: 3000 Build Power: 16||HP: 3700 Build Power: 18||HP: 4500 Build Power: 20
|-
|}

= Exact effects of attribute modifiers =
Attribute modifiers are applied in this order:
* Commander Chassis absolute statistics
* Percentage modifiers both from modules and chassis
* Absolute modifiers

Percentage modifiers from commanders and stackable modules are additive, not cumulative. Five +10% speed modules multiply a commander's speed by 1.5 instead of by 1.1^5 = 1.61.

Percentage modifiers from weapon boosters and converters are cumulative and applied before other percentage modifiers. Think of them as changing the intrinsic stats of the weapon, rather than adding a bonus.

{{Navbox manual}}