Spring - User contributions [en]

User:Sdbryan

2013-04-08T05:16:36Z

Sdbryan: Created page with "I am '''Bryan Dunsheng See''', from Malaysia."

I am '''Bryan Dunsheng See''', from Malaysia.

CEG-Format

2011-02-06T04:29:43Z

Sdbryan:

'''Source:''' https://spring.clan-sy.com/svn/spring/trunk/rts/Sim/Projectiles

== Overall Format ==

A CEG file contains one or more CEGs. Each CEG follows this format:

<code><pre>
[ceg_name] {
useDefaultExplosions = 0;
[spawner_name_0] {
class=CClassName;
[properties] {
property0 = value0;
property1 = value1;
//and so on...
}
condition0 = 1;
condition1 = 0;
count = 1;
}

[spawner_name_1] {
//each spawner follows that format
}

[groundflash] {
//groundflash is a special name; it always generates a groundflash
flashsize=16;
flashalpha=1;
circlegrowth=1;
circlealpha=0;
ttl=8;
color=1,1,1;
}
}
</pre></code>

=== useDefaultExplosions ===
If this is set, the CEG will use the default explosion (based on damage and area of effect) in addition to any spawners you define.

=== Spawners ===
A CEG can contain any number of spawners. The name of the spawners don't really matter, as long as it's not "groundflash", which has a special meaning. You can think of each spawner as being one component of the overall explosion.

==== Class ====
Each spawner has a class that determines what kind of graphical effect it creates. Spring has a number of standard classes that you can choose from. See [[CEG-Classes]] for details.

==== Properties ====
Depending on what class a spawner is, it will have a set of properties that allow you to fine-tune what the spawner displays. Again, see [[CEG-Classes]] for details.

==== Conditions ====
These determine under what conditions the spawner will run. The available conditions are "air" (at least 20 elmos above ground/sea level), "water", "ground", "unit" (hits a unit), and "nounit" (doesn't hit a unit). There is an "underwater" condition, but it doesn't actually work at time of writing. If you set the condition to true (e.g., "water = 1;"), the spawner will run if the explosion takes place under that condition. If you set more than one condition, the spawner will run if ''any'' of them are true. If you want a spawner to run only if two or more conditions are ''all'' true, you have to do a little trick with the CExpGenSpawner class.

==== Count ====
The count determines the number of times the spawner will run.

=== groundflash ===
If you name a spawner "groundflash," it will always generate a groundflash. A groundflash has the following properties:

*flashsize (float): The radius of the groundflash.
*flashalpha (float in [0, 1]): How transparent the groundflash is. Generally, the higher, the brighter.
*circlegrowth (float): A groundflash can have an additional circle that expands outwards. This controls how fast the circle grows.
*circlealpha (float in [0, 1]): How transparent the circle is.
*ttl (int): How long the groundflash lasts.
*color (float3): The color of the groundflash.

Suggested Use: A short groundflash (~8 frames) is good for any explosion that gives off light. You can also use a longer groundflash to suggest the ground is glowing from heat.

=== Data Types ===
CEGs use the following data types:

*float: Most properties are floats.
*int: Used for counts and ttls.
*bool: Use for conditions, and some properties.
*float3: Used for vectors and colors. The components are floats, separated by commas. You can also use the keyword <code>dir</code>, which represents the direction fed to the CEG.
*string: Used for colormaps and texture names. In .lua you delimit a string by quotes; in .tdf you do not. Color maps consist of 2 or more groups of 4 numbers, each group representing a RGBA color. Textures are the names you define in gamedata/resources.tdf or gamedata/resources.lua.

You can use [[CEG-Operators]] to define floats that are not fixed.

=== Units ===

All distances are in elmos; all time is in frames.

[[Category:CEG]]

Game and Unit development

2011-02-06T04:28:34Z

Sdbryan: /* Explosions (.tdf, .lua) */

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

=Game development=
This information is meant to help newcomers learn how to develop their own games for the Spring Engine.
==General==
*[[Game structure]] 
*[[Game specification|Game specification]] 
*[http://springrts.com/phpbb/viewtopic.php?t=6015 What do I need to create a game?]
*[[Simple Mod Tutorial|Simple Game Tutorial]]
*[[Freely available and reusable content|Freely available and reusable content for maps and games]]
*[[The Complete Guide To Making A Spring Game]]

=Modeling (.3do, .s3o)=
Spring supports different 3d representations: '.s3o' and '.3do'. The biggest difference between both formats is the workflow to create a new unit. There are exporter plugins for 'blender' and '3ds-max' so that texturing and modeling can be done using these.
In contrast: when you model an '.3do' you have to use 'UpSpring' currently.

The animation with can either be done using 'lua' or 'COB/BOS' is does not depend on either, see rigging/animation. For new units use 'lua' scripting.

==s3o modeling==
* [[Basic s3o unit making guide]] (using UpSpring)
* [[s3o using blender]] (not using UpSpring)
* [[Trouble-shooting s3o units]]

===Tutorials===
* [http://springrts.com/phpbb/viewtopic.php?t=10612 Wings UV Mapping Tutorial]
* [http://springrts.com/phpbb/viewtopic.php?f=9&t=12354 Saving polygons in Wings3d Tutorial]
* [http://springrts.com/phpbb/viewtopic.php?t=10503 Runecrafter's 3DS Max UV Mapping Tutorial]

===S3O Textures===
* [http://springrts.com/phpbb/viewtopic.php?f=57&t=22392 DDS Textures: How To]
* [http://springrts.com/phpbb/viewtopic.php?t=10947 Greeble Tutorial 1]
* [http://springrts.com/phpbb/viewtopic.php?f=9&t=12356 Greeble Tutorial 2]

==Models - 3do Files==
'''NOTE:''' 3do is an outdated model format used by OTA models (Balanced Annihilation, NOTA, etc.). 
(Note: UpSpring has some problems with empty objects and groundplates)
*use [http://springrts.com/phpbb/viewtopic.php?f=12&t=7208&p=126129&hilit=upspring#p126129 UpSpring] and [http://springfiles.com/1755 3doBuilder] to edit those files
*[http://user.supradigital.org/jcnossen/UpspringInstaller-1.54-EulerAngles.exe Click here to download UpSpring, our content support tool.]
* [http://springrts.com/phpbb/viewtopic.php?f=9&t=15106 Argh's UpSpring Easy Workflow Guide]
* [http://lassie.student.utwente.nl/vliet/springtut.pdf Maestro's tutorial of Upspring and textures- very outdated].

=Scripting/Animations (.cob, .bos, .lua)=
==Lua Animations==
To edit .lua files you need a text editor.
*[[Animation-LuaScripting]]
**[[Animation-LuaCallins]]
**[[Animation-LuaCallouts]]
**[[Animation-CobLuaDifferences]]

==COB Animations==
The binary '.cob' file format is obsolete and some '.cob' files might be copyrighed by cavedog. A '.cob' file can be decompiled to see what it is doing or if you have the source, that is a '.bos' file, you can compile it into a '.cob' file.

To edit .bos files you need a program/compiler. The most famous one is [http://jobjol.nl/1384 Scriptor]
*[[Animation-CobLuaDifferences]]
*[[Animation-CobOverview]]
**[[Animation-CobExamples]]
**[[Animation-CobAnimation]]
**[[Animation-CobCallins]]
**[[Animation-CobConstants]]
**[[Animation-CobThreads]]
**[[Animation-CobHitByWeaponID]]
*[[Units:LuaCOB]] - how to interface COB with LUA
*[[CEG_For_Units|Game Development:Calling basic CEGs from COB]]
* [http://springrts.com/phpbb/viewtopic.php?p=132943#132943 GPL-compliant sourcecode, scripting code examples, and other things.]

=UnitDefs (.fbi, .lua)=
*[[Units:FBI]]
*[[All_FBI-variable_values:_min,_max,_default,_type|Units:FBI (variable datatype list)]]
*[[Unit_Categories]]

=MoveDefs (movedefs.lua)=
*[[Units:MoveTypes]]

=WeaponDefs (.tdf, .lua)=
*[[Weapon Variables]] : This is the most up to date
*[[Units:WeaponMainDir]]
*[[Units:Weapons]] : Various informations about the weapontypes (uncompleted)
*[[Weapons:Antinukes]]: All about antinukes.

=Explosions (.tdf, .lua)=
*[[CEG]]
**[[CEG-Calls]]
**[[CEG-Format]]
**[[CEG-Classes]]
**[[CEG-Operators]]
**[[CEG-Miscellaneous]]
**[[CEG-OldInfo]]
*[[LUPS]]

=Misc=
*[[Units:Design]]
*[[Units:Textures]]
*[[Units:Buildpics]]
*[[Units:SideData TDF]]
*[[Units:Download TDF]]
*[[Units:FlankingBonus]]
*[[Mod Development:Armor|Game Development:Armor]]
*[[Mod Development:Cursors|Game Development:Cursors]]
*[[Mod Development:Archives|Game Development:Archives]]
*[[Mod Development:Sidepics|Game Development:Sidepics]]
*[[CustomUnitIcons|Game Development:Custom unit icons]]

=Legacy Porting Tools=
==Automated Game Creation==
* [[TA2Spring]] - Automatically adds and converts Total Annihilation unit packs (.ufo files, etc..) into Spring games (requires a base game for the game rules, XTA is recommended, it is probably not properly supported by current Spring)

[[Category: Unit_development]]
[[Category:Game development]]

CEG-Format

2011-02-05T18:28:42Z

Sdbryan: /* .LUA */

'''Source:''' https://spring.clan-sy.com/svn/spring/trunk/rts/Sim/Projectiles

= .TDF =

== Overall Format ==

A CEG file contains one or more CEGs. Each CEG follows this format:

<code><pre>
[ceg_name] {
useDefaultExplosions = 0;
[spawner_name_0] {
class=CClassName;
[properties] {
property0 = value0;
property1 = value1;
//and so on...
}
condition0 = 1;
condition1 = 0;
count = 1;
}

[spawner_name_1] {
//each spawner follows that format
}

[groundflash] {
//groundflash is a special name; it always generates a groundflash
flashsize=16;
flashalpha=1;
circlegrowth=1;
circlealpha=0;
ttl=8;
color=1,1,1;
}
}
</pre></code>

=== useDefaultExplosions ===
If this is set, the CEG will use the default explosion (based on damage and area of effect) in addition to any spawners you define.

=== Spawners ===
A CEG can contain any number of spawners. The name of the spawners don't really matter, as long as it's not "groundflash", which has a special meaning. You can think of each spawner as being one component of the overall explosion.

==== Class ====
Each spawner has a class that determines what kind of graphical effect it creates. Spring has a number of standard classes that you can choose from. See [[CEG-Classes]] for details.

==== Properties ====
Depending on what class a spawner is, it will have a set of properties that allow you to fine-tune what the spawner displays. Again, see [[CEG-Classes]] for details.

==== Conditions ====
These determine under what conditions the spawner will run. The available conditions are "air" (at least 20 elmos above ground/sea level), "water", "ground", "unit" (hits a unit), and "nounit" (doesn't hit a unit). There is an "underwater" condition, but it doesn't actually work at time of writing. If you set the condition to true (e.g., "water = 1;"), the spawner will run if the explosion takes place under that condition. If you set more than one condition, the spawner will run if ''any'' of them are true. If you want a spawner to run only if two or more conditions are ''all'' true, you have to do a little trick with the CExpGenSpawner class.

==== Count ====
The count determines the number of times the spawner will run.

=== groundflash ===
If you name a spawner "groundflash," it will always generate a groundflash. A groundflash has the following properties:

*flashsize (float): The radius of the groundflash.
*flashalpha (float in [0, 1]): How transparent the groundflash is. Generally, the higher, the brighter.
*circlegrowth (float): A groundflash can have an additional circle that expands outwards. This controls how fast the circle grows.
*circlealpha (float in [0, 1]): How transparent the circle is.
*ttl (int): How long the groundflash lasts.
*color (float3): The color of the groundflash.

Suggested Use: A short groundflash (~8 frames) is good for any explosion that gives off light. You can also use a longer groundflash to suggest the ground is glowing from heat.

=== Data Types ===
CEGs use the following data types:

*float: Most properties are floats.
*int: Used for counts and ttls.
*bool: Use for conditions, and some properties.
*float3: Used for vectors and colors. The components are floats, separated by commas. You can also use the keyword <code>dir</code>, which represents the direction fed to the CEG.
*string: Used for colormaps and texture names. In .lua you delimit a string by quotes; in .tdf you do not. Color maps consist of 2 or more groups of 4 numbers, each group representing a RGBA color. Textures are the names you define in gamedata/resources.tdf or gamedata/resources.lua.

You can use [[CEG-Operators]] to define floats that are not fixed.

=== Units ===

All distances are in elmos; all time is in frames.

= .LUA =
This uses the LUPS (Lua Particle System).

== Overall Format ==

A CEG file contains one or more CEGs. Each CEG follows this format:

<code><pre>
local ceg_name = {
useDefaultExplosions = 0,
[spawner_name_0] = {
class=CClassName,
[properties] = {
property0 = value0,
property1 = value1,
--and so on...
},
condition0 = 1,
condition1 = 0,
count = 1,
},

[spawner_name_1] = {
--each spawner follows that format
}

[groundflash] = {
--groundflash is a special name; it always generates a groundflash
flashsize=16,
flashalpha=1,
circlegrowth=1,
circlealpha=0,
ttl=8,
color=1,1,1,
},
}
</pre></code>

[[Category:CEG]]

CEG-Format

2011-02-05T18:25:43Z

Sdbryan:

General Resources

2010-10-19T13:24:10Z

Sdbryan: /* Sounds */

[[Engine_Development|Development]] < General Resources

=Textures=
[http://springrts.com/phpbb/viewtopic.php?t=7093&start=0 Texture Competition 0001 - Metal] 
[http://springrts.com/phpbb/viewtopic.php?t=7188&start=0 Texture Competition 0002 - Camo] 
[http://springrts.com/phpbb/viewtopic.php?t=7731 Texture Competition 0003 - Stone/Concrete] 
[http://www.cgtextures.com/ CG Textures]

=Code=
[http://springrts.com/phpbb/viewtopic.php?t=7457 GPL Code Repository] 
[http://springrts.com/phpbb/viewtopic.php?t=6569&postdays=0&postorder=asc&start=0 The Millionth Monkey Gets Its Typewriter - Movement Optimization]

=Sounds=
[http://freesound.iua.upf.edu/ Freesound] free sounds and samples, distributed under the [http://creativecommons.org/licenses/sampling+/1.0/ Creative Commons License]
[http://www.pdsounds.org/ Public domain sounds] sounds and samples distributed to the public domain

=Features=
[http://springrts.com/phpbb/viewtopic.php?t=4047 Compilation List of Features for Maps]

=Models=
[http://planet-wars.eu/ModelBase/Units.aspx Model Base]

[[Category: Art_assets]]
[[Category: Development]]

Simple Game Tutorial

2010-06-13T17:12:20Z

Sdbryan: /* Step 6:A couple Text Files */ Changed to lua files

Until I Finish [[Mod Development]] is the place to go.

This Tutorial Aims to get a person from knowing nothing about Spring to the point where they can create and edit mods.

Right now I am working from memory so you may want to correct me when I'm wrong, I will try to cross link from my summaries to the appropriate articles available in other places.

I will not go too deep into making 3do's because they are old and dumb... but I'll try to make note of the differences here.

I don't know anything about scripting right now, so that section is likely to be sparse when I write it, I hope that someone will expand on it.

=Book 1: The First Unit=

==Step 1:Planning==
Who cares about planning, you know what you're doing... just come up with an idea for a mod... I made a chess set... if you don't have a real idea and just want to make a model show up in the game... then yeah... this is the place to start... I'd do that if I were you.

Another good thing to do at this point is to creat a "working directory", and inside it create a directory with the name that your mod will have... after many headaches I decided it's best to put this in the root directory of your system so it's really easy to find when you are switching around back and forth between folders and keep having to find your files over and over again.

==Step 2:Getting The Tools==
You will need a bunch of stuff... here's the list (I assume you are using windows)

''Want:''
*[http://taspring.clan-sy.com/download.php Spring] - The main program, you will likely need this to test if you've screwed up
*A Tiny Map (2x2) - to test your mod fast (suggest [http://www.fileuniverse.com/?p=showitem&ID=2534 Simple Chess Map])

''Need:''
*'''Program listings can be found here:''' '''[http://taspring.clan-sy.com/wiki/Map%2C_Mod%2C_And_Unit_Development_Programs Map, Mod, And Unit Development Programs]'''
*3D Modeling Program - '''See above link'''
*Notepad - to edit all the miriad of text files
*A Graphical Editing Program - needs to handle RGBA TGAs (aka tga's with alpha channels), I suggest Photoshop if you have it, or The GIMP... needed for all of the texture making for UVmapping stuff... '''See above link'''
*Upspring 1.3 - To convert your models to the approprite s3o format (if you want to fight with 3do builder, then go ahead... a good trick is to get your model into upspring first and adjust all the hierachy, then save it as an 3do... but why bother?). '''See above link'''
*Scriptor - to make and compile your units "animation script"... or steal someone else's and make it work for your unit. '''See above link'''
*Compression Utility - (I suggest [http://www.7-zip.org/ 7zip] - even if you are using zip compression and not 7zip, it's still good to have)

==Step 3:Making a 3D Model==

Go into your 3D modelling program and make a 3D model, [http://taspring.clan-sy.com/w/images/b/b4/WingsCombine.PNG combine] all the objects and UV map the model, then separate it out into any parts that need to move independently of each other. Then Export the UV map as an Image File and Export the whole thing as a 3ds file. Put the original wings file, the UVMap image and the 3ds file into your working directory so you can find them later.

Wings 3D UV Mapping tutorial has been started here - [[Units:CreateModel]]

==Step 4:Fixing Your Images==

[[Basic s3o unit making guide|This Article includes a UVMapping Guide]]

Open up your UVMap in Photoshop (or whatever) go to the layer/chooser thingy and go to the Channels Tab, add a new layer (it should default to alpha) and fill it with 99% black so you can see your texture in upspring. If you want to can paint the UVmap and put white (1% black) on the alpha channel where you want your team colours to show up (you can use something between 1% and 99% to get a blend of your team colour along with the texture... for example 50% will give you your texture with 50% of the team colour mixed in...)

I don't know how to do glow maps... XXreminder for someone to create a Glowmapping tutorial... you don't acctually need one for the model to show up.

Save these images both in the working directory.

Save a copy of these images in tga format into <working directory>/<mod name>/unittextures

==Step 5:Upspring==

===Importing Your 3ds===
Open Upspring 1.3, go to file>load model and navigate to and open your 3DS model you exported, you should see the model in upspring as a 3d mesh. Go to the model tab and set the radius and height values to something other then zero... this defines where the health bar will show up, and more importantly, how big the collision sphere will be.

You will also need to use all of the other tools on those tabs to resize and rotate and move your model to the right place... wings makes models that are 90 degrees off and about 30 times smaller than most spring models... make sure you click the "apply transform" button after any changes that you actually want to show up in the game.

Also, you will want to make the hierachy work using the cut, paste, and add empty buttons. You will need an object called "base" that all the other objects are connected to... the "origin object"... sometimes you get lucky and wings exports it properly... usually not.

===Importing Your UV and Glowmaps===

Go to the textures tab and make your UV/texture/team-colour map as "texture1" and your UV/glow/reflectivity map as "texture2"... it should show up correctly in the preview pane.

===Exporting Your s3o===
Choose File>Save Model As then in the drop down select "s3o" and type an appropriate name. This model should be saved to your working directory, and a copy of it made to <working directory>/<mod name>/objects3d/

==Step 6: Lua files==

===UnitName.lua===


<pre>
unitDef = {
unitname = [[arm_spider]],
name = [[Weaver]],
description = [[Cloaking Construction Spider, Builds at 9 m/s]],
acceleration = 0.15,
bmcode = [[1]],
brakeRate = 0.15,
buildCostEnergy = 230,
buildCostMetal = 230,
buildDistance = 80,
builder = true,

buildoptions = {
},

buildPic = [[arm_spider.png]],
buildTime = 230,
canAttack = false,
canGuard = true,
canMove = true,
canPatrol = true,
canreclamate = [[1]],
canstop = [[1]],
category = [[LAND UNARMED]],
cloakCost = 1,
cloakCostMoving = 2,
corpse = [[DEAD]],

customParams = {
description_bp = [[Aranha e de construÃƒÂ§?o, ConstrÃƒÂ³i a 6 m/s]],
description_es = [[Ara?a de construcciÃƒÂ³n, construye a 6 m/s]],
description_fi = [[Rakentaja/kaikuluotainkiipeilij?, rakentaa 6m/s nopeudella]],
description_fr = [[Araign?e de Construction, Construit ? 6 m/s]],
description_it = [[Ragno do costruzione occultante, costruisce a 6 m/s]],
description_pl = [[Paj?k konstruktor, buduje z pr?dko?ci? 6m/s]],
helptext = [[The Weaver is a constructor that can climb over any obstacle and build defenses on high ground.]],
helptext_bp = [[Weaver ÃƒÂ© o construtor escalador camuflÃƒÂ¡vel de NOVA. Pode subir qualquer obstÃƒÂ¡culo, mas constrÃƒÂ³i mais devagar que construtores normais.]],
helptext_es = [[El Weaver es el constructor que puede treparse sobre qualquier obstÃƒÂ¡culo y construir defensas en terreno alto]],
helptext_fi = [[Weaver pystyy liikkumaan vaikeakulkuisimmassakin maastossa ja rakentamaan vaivatta my?s useimmille muille rakentajille saavuttamattomiin paikkoihin.]],
helptext_fr = [[Le weaver est un robot de construction tout terrain qui peut batir des d?fenses en terrain ?lev?.]],
helptext_it = [[Il Weaver ÃƒÂ© un costruttore che puo arrampicarsi su qualunque ostacolo e costruire difese nel terreno alto]],
helptext_pl = [[Weaver jest konstruktorem mog?cym wspina? si? po ka?dej powierzchni oraz posiadaj?cym mo?liwo?? maskowania si?]],
},

defaultmissiontype = [[Standby]],
designation = [[ARM-MLSPD]],
energyMake = 0.15,
energyUse = 0,
explodeAs = [[BIG_UNITEX]],
footprintX = 3,
footprintZ = 3,
iconType = [[builder]],
mass = 115,
maxDamage = 750,
maxslope = 16,
maxSlope = 72,
maxVelocity = 1.7,
maxWaterDepth = 22,
metalMake = 0.15,
movementClass = [[TKBOT3]],
noAutoFire = false,
noChaseCategory = [[TERRAFORM SATELLITE FIXEDWING GUNSHIP HOVER SHIP SWIM SUB LAND FLOAT SINK]],
objectName = [[ARMMLSPD]],
radarDistanceJam = 256,
seismicSignature = 16,
selfDestructAs = [[BIG_UNITEX]],
showNanoSpray = false,
side = [[ARM]],
sightDistance = 295,
smoothAnim = true,
steeringmode = [[1]],
TEDClass = [[CNSTR]],
terraformSpeed = 450,
threed = [[1]],
turninplace = 0,
turnRate = 1020,
workerTime = 9,
zbuffer = [[1]],

featureDefs = {

DEAD = {
description = [[Wreckage - Weaver]],
blocking = true,
category = [[arm_corpses]],
damage = 850,
featureDead = [[DEAD2]],
featurereclamate = [[smudge01]],
footprintX = 3,
footprintZ = 3,
height = [[40]],
hitdensity = [[100]],
metal = 92,
object = [[ARMMLSPD_dead]],
reclaimable = true,
reclaimTime = 92,
seqnamereclamate = [[tree1reclamate]],
world = [[All Worlds]],
},

DEAD2 = {
description = [[Debris - Weaver]],
blocking = false,
category = [[heaps]],
damage = 850,
featureDead = [[HEAP]],
featurereclamate = [[smudge01]],
footprintX = 3,
footprintZ = 3,
height = [[4]],
hitdensity = [[100]],
metal = 92,
object = [[debris3x3b.s3o]],
reclaimable = true,
reclaimTime = 92,
seqnamereclamate = [[tree1reclamate]],
world = [[All Worlds]],
},

HEAP = {
description = [[Debris - Weaver]],
blocking = false,
category = [[heaps]],
damage = 850,
featurereclamate = [[smudge01]],
footprintX = 3,
footprintZ = 3,
height = [[4]],
hitdensity = [[100]],
metal = 46,
object = [[debris3x3b.s3o]],
reclaimable = true,
reclaimTime = 46,
seqnamereclamate = [[tree1reclamate]],
world = [[All Worlds]],
},

},

}

return lowerkeys({ arm_spider = unitDef })
</pre>

Save this file as a lua file in <working directory>/<mod name>/units/

===modinfo.lua===

modinfo.lua is a lua file that defines a number of things that are used when loading a mod, most of the information is self explanitory but basically what you are doing is defining what is going to show up in whatever mod-selection interface you use as well as what other files need to be loaded into memory in order for your mod to work.

====Making a New Mod with your unit/units====
The following is an example of what will be in your modinfo.lua file if you are starting from scratch and making your own mod. This is also good when you are just testing one unit to see if it works.

<pre>
return {
-- The name is shown in the selection interface
game = "MyMod",
shortGame = "MM",
name = "My Mod",
shortName = "MM",
version = "4.0",
mutator = "Heroes",
-- These can be shown by the selection interface
description = "My Mod That I Made",
url = "http://www.theplacepeoplecangetthelatestversionofyourmod.com",
-- What kind of mod this is
-- 0 - Hidden (support mod that can't be selected, such as OTA_textures)
-- 1 - Normal, only one can be selected at a time
-- 2 - Addon, any number of these can be selected. Could be used
-- for single units for example.
-- others - perhaps mutators and addon races that can be
-- enabled in addition to xta for example?
modtype = "1",
-- Number of other archives this one depends on
depend= {
taenheter.sdz,
springcontent.sdz,
otacontent.sdz,
tatextures.sdz,
-- Number of other archives this one replaces
},
}
</pre>

====Adding Your Unit to an Existing Mod====
The following is an example of what will be in your modinfo.lua file if you are adding new units to an existing mod (in this case xta_se_v066.sdz), this is good for adding units to the build tree of an existing mod or adding a whole new team.

<pre>
-- Description of the mod control file recognized by spring:
return {
-- The name is shown in the selection interface
game = "XTASE_MyUnits",
shortGame = "XTASEMU",
name = "XTASEv0.66 with+My Units",
shortName = "XTASEMU",
version = "4.0",
mutator = "Heroes",
-- These can be shown by the selection interface
description = "xta_se_v066 with the cool tank I made",
url = "http://www.fileuniverse.com/exactlocationblahblahblah",
-- What kind of mod this is
-- 0 - Hidden (support mod that can't be selected, such as OTA_textures)
-- 1 - Normal, only one can be selected at a time
-- 2 - Addon, any number of these can be selected. Could be used
-- for single units for example.
-- others - perhaps mutators and addon races that can be
-- enabled in addition to xta for example?
modtype = "1",
-- Number of other archives this one depends on
depend= {
taenheter.sdz,
springcontent.sdz,
otacontent.sdz,
tatextures.sdz,
xta_se_v066.sdz,
-- Number of other archives this one replaces
},
}
</pre>

If you are not depending on OTA files, you will have to supply your own cursors.

There are some extra bits in these examples, but I work on the "better safe than sorry" principle... which is to wait for someone who knows what they are doing to fix my articles.

You will want to save this file as plain text in <working directory>/<mod name>/

===armorDefs.lua===

I'm not exactly sure how this works, but the file needs to exist, so either steal one from another mod and modify it... or just make a file that looks like this.

<pre>
local armorDefs = {
}
</pre>

You will want to save this file as a lua file in <working directory>/<mod name>/gamedata

===sidedata.lua===

Start by stealing the sidedata.lua file from your dependency mod if you have one, then edit it to include your units/side.

Basically this file is in the form:

<pre>
local sideData = {
[1] = {
name = 'Good Guys',
startunit = 'GG_comm',
},
}
</pre>

There are also additional "[X]" entries for each side/team/commander-choice available in the mod-selector you choose.

You will save this file as lua file in <working directory>/<mod name>/gamedata/

===moveDefs.lua===
This file determines the footprint of your units, the angle of slopes they can climb and in how deep water they can drive. It contains several entries, all in the following format:

<pre>
local moveDefs = {
KBOT1 = { -- This is the name. Unit files refer to this name.
footprintx = 1, -- This is how big the X dimension is of the footprint in Spring units probably?
footprintz = 1, -- This is how big the Y dimension is of the footprint in Spring units probably?
maxwaterdepth = 15, -- This is how big the Y dimension is of the footprint in Spring units probably?
maxslope = 36, -- The maximum angle of slopes this unit can climb.
crushstrength = 5, -- This determines if the unit/unit class can crush certain features
},
-- etc..
}
</pre>

===sounds.lua===
This file refers to all the sounds your units make, so Spring knows which sound file is linked to what action. It contains entries in the following format.

<pre>
local Sounds = {
SoundItems = {
IncomingChat = {
file = "sounds/nexuiz/talk.wav",
priority = 15,
preload = true,
},
MultiSelect = {
file = "sounds/ota/button9.wav",
priority = 15,
preload = true,
rolloff = 0.1,
},
MapPoint = {
file = "sounds/bzflag/teamgrab.wav",
priority = 15,
preload = true,
rolloff = 0.1,
},
FailedCommand = {
file = "sounds/openQuarz/pkup.wav",
gain = 0.75,
priority = 15,
preload = true,
in3d = false,
},
}
</pre>
}

==Step 7:Adding a Build Pic==

Add a 96x96 BMP to your <working directory>/<mod name>/unitpics/ folder named either "UnitName.bmp" or whatever you specified in the "BuildPic=" line of your fbi.

==Step 8:Adding a Side Pic==

Add a 16x16 BMP to your <working directory>/<mod name>/sidepics/ folder named "teamname.bmp" or whatever you specified in the "name=" line of your SIDEDATA.TDF for each side/team you have added.

==Step 9:Scriptor==

===Stealing a Script===
Open someone else's script in scriptor that works the way you want your script to work, look at the top where it's talking about "piece names"... then change those piece names to be the piece names of your unit and do a find/replace to make all the places where those pieces show up to be your pieces too. Compile it so its name is the same as the "UnitName=" value in your "UnitName.fbi".

XXreminder to someone to link to a proper scripting tutorial

Put the bos and cob files for your unit script in <working directory>/<mod name>/scripts

==Step 10:Compiling Your Mod==

You may want to check your mod directory and make sure it follows the structure defined [[Mod_Development:Archives|here]].

navigate to your <working directory>/<mod name> and select everything and choose "add to archive <mod name>.7z".

make a copy of this file called <mod name>v0.7z in your working directory so you don't screw anything up later, then make a copy of it called <mod name>.sd7 in the mods directory of spring.

An alternative, added in more recent versions is the ".SDD" folder, to use this, copy the entire <mod name> folder in the mods directory of spring and rename it as "<mod name>.SDD". The advantage to the ".SDD" method is that you can tweak settings and add files without recompressing your mod all the time. When it comes time to distribute your mod use ".sd7".

EXAMPLES:
If your mod is called JoesMod you will have a file called "JoesMod.sd7" or a folder called "JoesMod.SDD" in your spring mods directory.

==Step 11:Testing Your Mod==
Open Up your lobby client, pick your mod from the drop-down list of the games in host battle or singleplayer mode if your lobby supports it(if it doesn't show up you screwed up your modinfo.txt), choose your tiny map from the map list and press start. If it doesn't break and your unit shows up, you have created all the neccessary files... yay!

Gotchas:
*If it doesn't work, check you didn't zip the folder itself, but the contents, ie if you open mymod.sd7 with 7zip, you should see folders such as "unittextures" rather than a folder "mymod" containing unittextures.

[[Category:Mod development]]

Simple Game Tutorial

2010-06-13T17:08:29Z

Sdbryan: /* SOUND.TDF */ Changed to sound.lua

Until I Finish [[Mod Development]] is the place to go.

This Tutorial Aims to get a person from knowing nothing about Spring to the point where they can create and edit mods.

Right now I am working from memory so you may want to correct me when I'm wrong, I will try to cross link from my summaries to the appropriate articles available in other places.

I will not go too deep into making 3do's because they are old and dumb... but I'll try to make note of the differences here.

I don't know anything about scripting right now, so that section is likely to be sparse when I write it, I hope that someone will expand on it.

=Book 1: The First Unit=

==Step 1:Planning==
Who cares about planning, you know what you're doing... just come up with an idea for a mod... I made a chess set... if you don't have a real idea and just want to make a model show up in the game... then yeah... this is the place to start... I'd do that if I were you.

Another good thing to do at this point is to creat a "working directory", and inside it create a directory with the name that your mod will have... after many headaches I decided it's best to put this in the root directory of your system so it's really easy to find when you are switching around back and forth between folders and keep having to find your files over and over again.

==Step 2:Getting The Tools==
You will need a bunch of stuff... here's the list (I assume you are using windows)

''Want:''
*[http://taspring.clan-sy.com/download.php Spring] - The main program, you will likely need this to test if you've screwed up
*A Tiny Map (2x2) - to test your mod fast (suggest [http://www.fileuniverse.com/?p=showitem&ID=2534 Simple Chess Map])

''Need:''
*'''Program listings can be found here:''' '''[http://taspring.clan-sy.com/wiki/Map%2C_Mod%2C_And_Unit_Development_Programs Map, Mod, And Unit Development Programs]'''
*3D Modeling Program - '''See above link'''
*Notepad - to edit all the miriad of text files
*A Graphical Editing Program - needs to handle RGBA TGAs (aka tga's with alpha channels), I suggest Photoshop if you have it, or The GIMP... needed for all of the texture making for UVmapping stuff... '''See above link'''
*Upspring 1.3 - To convert your models to the approprite s3o format (if you want to fight with 3do builder, then go ahead... a good trick is to get your model into upspring first and adjust all the hierachy, then save it as an 3do... but why bother?). '''See above link'''
*Scriptor - to make and compile your units "animation script"... or steal someone else's and make it work for your unit. '''See above link'''
*Compression Utility - (I suggest [http://www.7-zip.org/ 7zip] - even if you are using zip compression and not 7zip, it's still good to have)

==Step 3:Making a 3D Model==

Go into your 3D modelling program and make a 3D model, [http://taspring.clan-sy.com/w/images/b/b4/WingsCombine.PNG combine] all the objects and UV map the model, then separate it out into any parts that need to move independently of each other. Then Export the UV map as an Image File and Export the whole thing as a 3ds file. Put the original wings file, the UVMap image and the 3ds file into your working directory so you can find them later.

Wings 3D UV Mapping tutorial has been started here - [[Units:CreateModel]]

==Step 4:Fixing Your Images==

[[Basic s3o unit making guide|This Article includes a UVMapping Guide]]

Open up your UVMap in Photoshop (or whatever) go to the layer/chooser thingy and go to the Channels Tab, add a new layer (it should default to alpha) and fill it with 99% black so you can see your texture in upspring. If you want to can paint the UVmap and put white (1% black) on the alpha channel where you want your team colours to show up (you can use something between 1% and 99% to get a blend of your team colour along with the texture... for example 50% will give you your texture with 50% of the team colour mixed in...)

I don't know how to do glow maps... XXreminder for someone to create a Glowmapping tutorial... you don't acctually need one for the model to show up.

Save these images both in the working directory.

Save a copy of these images in tga format into <working directory>/<mod name>/unittextures

==Step 5:Upspring==

===Importing Your 3ds===
Open Upspring 1.3, go to file>load model and navigate to and open your 3DS model you exported, you should see the model in upspring as a 3d mesh. Go to the model tab and set the radius and height values to something other then zero... this defines where the health bar will show up, and more importantly, how big the collision sphere will be.

You will also need to use all of the other tools on those tabs to resize and rotate and move your model to the right place... wings makes models that are 90 degrees off and about 30 times smaller than most spring models... make sure you click the "apply transform" button after any changes that you actually want to show up in the game.

Also, you will want to make the hierachy work using the cut, paste, and add empty buttons. You will need an object called "base" that all the other objects are connected to... the "origin object"... sometimes you get lucky and wings exports it properly... usually not.

===Importing Your UV and Glowmaps===

Go to the textures tab and make your UV/texture/team-colour map as "texture1" and your UV/glow/reflectivity map as "texture2"... it should show up correctly in the preview pane.

===Exporting Your s3o===
Choose File>Save Model As then in the drop down select "s3o" and type an appropriate name. This model should be saved to your working directory, and a copy of it made to <working directory>/<mod name>/objects3d/

==Step 6:A couple Text Files==

===UnitName.fbi===
For Reference visit [[Units:FBI]], but again, the easiest way to do this is to extract an existing mod and find the fbi for a unit that behaves similarly to the one you are trying to make and rename and modify it.

Some More Specific Information Not Clear in the "Units:FBI" article:

'''Name+" "+Description=Spring Display Name'''

So if you have the following settings:

Name=Tiger;
Description=Fast Attack C.A.T.;

The Tooltip will show "Tiger Fast Attack C.A.T."

'''BuildPic Defaults to UnitName.bmp'''

So if you leave out "BuildPic=filename.bmp;" Spring will look in /unitpics/ for a file called "UnitName.bmp" to use as your buildpic.

'''ObjectName'''

If you want to use an s3o object, you will need to specify with "ObjectName=UnitName'''.S3O;'''" otherwise it will look for "UnitName.3do". Also, you don't have to use "UnitName" as the filename and, in fact, multiple Unit's fbi files can reference the same 3D models. It is easier, however, for people to figure out what you are doing in your mod if you follow the standards.

Save this file as plain text in <working directory>/<mod name>/units/

===modinfo.lua===

modinfo.lua is a lua file that defines a number of things that are used when loading a mod, most of the information is self explanitory but basically what you are doing is defining what is going to show up in whatever mod-selection interface you use as well as what other files need to be loaded into memory in order for your mod to work.

====Making a New Mod with your unit/units====
The following is an example of what will be in your modinfo.lua file if you are starting from scratch and making your own mod. This is also good when you are just testing one unit to see if it works.

<pre>
return {
-- The name is shown in the selection interface
game = "MyMod",
shortGame = "MM",
name = "My Mod",
shortName = "MM",
version = "4.0",
mutator = "Heroes",
-- These can be shown by the selection interface
description = "My Mod That I Made",
url = "http://www.theplacepeoplecangetthelatestversionofyourmod.com",
-- What kind of mod this is
-- 0 - Hidden (support mod that can't be selected, such as OTA_textures)
-- 1 - Normal, only one can be selected at a time
-- 2 - Addon, any number of these can be selected. Could be used
-- for single units for example.
-- others - perhaps mutators and addon races that can be
-- enabled in addition to xta for example?
modtype = "1",
-- Number of other archives this one depends on
depend= {
taenheter.sdz,
springcontent.sdz,
otacontent.sdz,
tatextures.sdz,
-- Number of other archives this one replaces
},
}
</pre>

====Adding Your Unit to an Existing Mod====
The following is an example of what will be in your modinfo.lua file if you are adding new units to an existing mod (in this case xta_se_v066.sdz), this is good for adding units to the build tree of an existing mod or adding a whole new team.

<pre>
-- Description of the mod control file recognized by spring:
return {
-- The name is shown in the selection interface
game = "XTASE_MyUnits",
shortGame = "XTASEMU",
name = "XTASEv0.66 with+My Units",
shortName = "XTASEMU",
version = "4.0",
mutator = "Heroes",
-- These can be shown by the selection interface
description = "xta_se_v066 with the cool tank I made",
url = "http://www.fileuniverse.com/exactlocationblahblahblah",
-- What kind of mod this is
-- 0 - Hidden (support mod that can't be selected, such as OTA_textures)
-- 1 - Normal, only one can be selected at a time
-- 2 - Addon, any number of these can be selected. Could be used
-- for single units for example.
-- others - perhaps mutators and addon races that can be
-- enabled in addition to xta for example?
modtype = "1",
-- Number of other archives this one depends on
depend= {
taenheter.sdz,
springcontent.sdz,
otacontent.sdz,
tatextures.sdz,
xta_se_v066.sdz,
-- Number of other archives this one replaces
},
}
</pre>

If you are not depending on OTA files, you will have to supply your own cursors.

There are some extra bits in these examples, but I work on the "better safe than sorry" principle... which is to wait for someone who knows what they are doing to fix my articles.

You will want to save this file as plain text in <working directory>/<mod name>/

===armorDefs.lua===

I'm not exactly sure how this works, but the file needs to exist, so either steal one from another mod and modify it... or just make a file that looks like this.

<pre>
local armorDefs = {
}
</pre>

You will want to save this file as a lua file in <working directory>/<mod name>/gamedata

===sidedata.lua===

Start by stealing the sidedata.lua file from your dependency mod if you have one, then edit it to include your units/side.

Basically this file is in the form:

<pre>
local sideData = {
[1] = {
name = 'Good Guys',
startunit = 'GG_comm',
},
}
</pre>

There are also additional "[X]" entries for each side/team/commander-choice available in the mod-selector you choose.

You will save this file as lua file in <working directory>/<mod name>/gamedata/

===moveDefs.lua===
This file determines the footprint of your units, the angle of slopes they can climb and in how deep water they can drive. It contains several entries, all in the following format:

<pre>
local moveDefs = {
KBOT1 = { -- This is the name. Unit files refer to this name.
footprintx = 1, -- This is how big the X dimension is of the footprint in Spring units probably?
footprintz = 1, -- This is how big the Y dimension is of the footprint in Spring units probably?
maxwaterdepth = 15, -- This is how big the Y dimension is of the footprint in Spring units probably?
maxslope = 36, -- The maximum angle of slopes this unit can climb.
crushstrength = 5, -- This determines if the unit/unit class can crush certain features
},
-- etc..
}
</pre>

===sounds.lua===
This file refers to all the sounds your units make, so Spring knows which sound file is linked to what action. It contains entries in the following format.

<pre>
local Sounds = {
SoundItems = {
IncomingChat = {
file = "sounds/nexuiz/talk.wav",
priority = 15,
preload = true,
},
MultiSelect = {
file = "sounds/ota/button9.wav",
priority = 15,
preload = true,
rolloff = 0.1,
},
MapPoint = {
file = "sounds/bzflag/teamgrab.wav",
priority = 15,
preload = true,
rolloff = 0.1,
},
FailedCommand = {
file = "sounds/openQuarz/pkup.wav",
gain = 0.75,
priority = 15,
preload = true,
in3d = false,
},
}
</pre>
}

==Step 7:Adding a Build Pic==

Add a 96x96 BMP to your <working directory>/<mod name>/unitpics/ folder named either "UnitName.bmp" or whatever you specified in the "BuildPic=" line of your fbi.

==Step 8:Adding a Side Pic==

Add a 16x16 BMP to your <working directory>/<mod name>/sidepics/ folder named "teamname.bmp" or whatever you specified in the "name=" line of your SIDEDATA.TDF for each side/team you have added.

==Step 9:Scriptor==

===Stealing a Script===
Open someone else's script in scriptor that works the way you want your script to work, look at the top where it's talking about "piece names"... then change those piece names to be the piece names of your unit and do a find/replace to make all the places where those pieces show up to be your pieces too. Compile it so its name is the same as the "UnitName=" value in your "UnitName.fbi".

XXreminder to someone to link to a proper scripting tutorial

Put the bos and cob files for your unit script in <working directory>/<mod name>/scripts

==Step 10:Compiling Your Mod==

You may want to check your mod directory and make sure it follows the structure defined [[Mod_Development:Archives|here]].

navigate to your <working directory>/<mod name> and select everything and choose "add to archive <mod name>.7z".

make a copy of this file called <mod name>v0.7z in your working directory so you don't screw anything up later, then make a copy of it called <mod name>.sd7 in the mods directory of spring.

An alternative, added in more recent versions is the ".SDD" folder, to use this, copy the entire <mod name> folder in the mods directory of spring and rename it as "<mod name>.SDD". The advantage to the ".SDD" method is that you can tweak settings and add files without recompressing your mod all the time. When it comes time to distribute your mod use ".sd7".

EXAMPLES:
If your mod is called JoesMod you will have a file called "JoesMod.sd7" or a folder called "JoesMod.SDD" in your spring mods directory.

==Step 11:Testing Your Mod==
Open Up your lobby client, pick your mod from the drop-down list of the games in host battle or singleplayer mode if your lobby supports it(if it doesn't show up you screwed up your modinfo.txt), choose your tiny map from the map list and press start. If it doesn't break and your unit shows up, you have created all the neccessary files... yay!

Gotchas:
*If it doesn't work, check you didn't zip the folder itself, but the contents, ie if you open mymod.sd7 with 7zip, you should see folders such as "unittextures" rather than a folder "mymod" containing unittextures.

[[Category:Mod development]]

Simple Game Tutorial

2010-06-13T17:01:01Z

Sdbryan: /* MOVEDATA.TDF */ Changed to moveDefs.lua

Until I Finish [[Mod Development]] is the place to go.

This Tutorial Aims to get a person from knowing nothing about Spring to the point where they can create and edit mods.

Right now I am working from memory so you may want to correct me when I'm wrong, I will try to cross link from my summaries to the appropriate articles available in other places.

I will not go too deep into making 3do's because they are old and dumb... but I'll try to make note of the differences here.

I don't know anything about scripting right now, so that section is likely to be sparse when I write it, I hope that someone will expand on it.

=Book 1: The First Unit=

==Step 1:Planning==
Who cares about planning, you know what you're doing... just come up with an idea for a mod... I made a chess set... if you don't have a real idea and just want to make a model show up in the game... then yeah... this is the place to start... I'd do that if I were you.

Another good thing to do at this point is to creat a "working directory", and inside it create a directory with the name that your mod will have... after many headaches I decided it's best to put this in the root directory of your system so it's really easy to find when you are switching around back and forth between folders and keep having to find your files over and over again.

==Step 2:Getting The Tools==
You will need a bunch of stuff... here's the list (I assume you are using windows)

''Want:''
*[http://taspring.clan-sy.com/download.php Spring] - The main program, you will likely need this to test if you've screwed up
*A Tiny Map (2x2) - to test your mod fast (suggest [http://www.fileuniverse.com/?p=showitem&ID=2534 Simple Chess Map])

''Need:''
*'''Program listings can be found here:''' '''[http://taspring.clan-sy.com/wiki/Map%2C_Mod%2C_And_Unit_Development_Programs Map, Mod, And Unit Development Programs]'''
*3D Modeling Program - '''See above link'''
*Notepad - to edit all the miriad of text files
*A Graphical Editing Program - needs to handle RGBA TGAs (aka tga's with alpha channels), I suggest Photoshop if you have it, or The GIMP... needed for all of the texture making for UVmapping stuff... '''See above link'''
*Upspring 1.3 - To convert your models to the approprite s3o format (if you want to fight with 3do builder, then go ahead... a good trick is to get your model into upspring first and adjust all the hierachy, then save it as an 3do... but why bother?). '''See above link'''
*Scriptor - to make and compile your units "animation script"... or steal someone else's and make it work for your unit. '''See above link'''
*Compression Utility - (I suggest [http://www.7-zip.org/ 7zip] - even if you are using zip compression and not 7zip, it's still good to have)

==Step 3:Making a 3D Model==

Go into your 3D modelling program and make a 3D model, [http://taspring.clan-sy.com/w/images/b/b4/WingsCombine.PNG combine] all the objects and UV map the model, then separate it out into any parts that need to move independently of each other. Then Export the UV map as an Image File and Export the whole thing as a 3ds file. Put the original wings file, the UVMap image and the 3ds file into your working directory so you can find them later.

Wings 3D UV Mapping tutorial has been started here - [[Units:CreateModel]]

==Step 4:Fixing Your Images==

[[Basic s3o unit making guide|This Article includes a UVMapping Guide]]

Open up your UVMap in Photoshop (or whatever) go to the layer/chooser thingy and go to the Channels Tab, add a new layer (it should default to alpha) and fill it with 99% black so you can see your texture in upspring. If you want to can paint the UVmap and put white (1% black) on the alpha channel where you want your team colours to show up (you can use something between 1% and 99% to get a blend of your team colour along with the texture... for example 50% will give you your texture with 50% of the team colour mixed in...)

I don't know how to do glow maps... XXreminder for someone to create a Glowmapping tutorial... you don't acctually need one for the model to show up.

Save these images both in the working directory.

Save a copy of these images in tga format into <working directory>/<mod name>/unittextures

==Step 5:Upspring==

===Importing Your 3ds===
Open Upspring 1.3, go to file>load model and navigate to and open your 3DS model you exported, you should see the model in upspring as a 3d mesh. Go to the model tab and set the radius and height values to something other then zero... this defines where the health bar will show up, and more importantly, how big the collision sphere will be.

You will also need to use all of the other tools on those tabs to resize and rotate and move your model to the right place... wings makes models that are 90 degrees off and about 30 times smaller than most spring models... make sure you click the "apply transform" button after any changes that you actually want to show up in the game.

Also, you will want to make the hierachy work using the cut, paste, and add empty buttons. You will need an object called "base" that all the other objects are connected to... the "origin object"... sometimes you get lucky and wings exports it properly... usually not.

===Importing Your UV and Glowmaps===

Go to the textures tab and make your UV/texture/team-colour map as "texture1" and your UV/glow/reflectivity map as "texture2"... it should show up correctly in the preview pane.

===Exporting Your s3o===
Choose File>Save Model As then in the drop down select "s3o" and type an appropriate name. This model should be saved to your working directory, and a copy of it made to <working directory>/<mod name>/objects3d/

==Step 6:A couple Text Files==

===UnitName.fbi===
For Reference visit [[Units:FBI]], but again, the easiest way to do this is to extract an existing mod and find the fbi for a unit that behaves similarly to the one you are trying to make and rename and modify it.

Some More Specific Information Not Clear in the "Units:FBI" article:

'''Name+" "+Description=Spring Display Name'''

So if you have the following settings:

Name=Tiger;
Description=Fast Attack C.A.T.;

The Tooltip will show "Tiger Fast Attack C.A.T."

'''BuildPic Defaults to UnitName.bmp'''

So if you leave out "BuildPic=filename.bmp;" Spring will look in /unitpics/ for a file called "UnitName.bmp" to use as your buildpic.

'''ObjectName'''

If you want to use an s3o object, you will need to specify with "ObjectName=UnitName'''.S3O;'''" otherwise it will look for "UnitName.3do". Also, you don't have to use "UnitName" as the filename and, in fact, multiple Unit's fbi files can reference the same 3D models. It is easier, however, for people to figure out what you are doing in your mod if you follow the standards.

Save this file as plain text in <working directory>/<mod name>/units/

===modinfo.lua===

modinfo.lua is a lua file that defines a number of things that are used when loading a mod, most of the information is self explanitory but basically what you are doing is defining what is going to show up in whatever mod-selection interface you use as well as what other files need to be loaded into memory in order for your mod to work.

====Making a New Mod with your unit/units====
The following is an example of what will be in your modinfo.lua file if you are starting from scratch and making your own mod. This is also good when you are just testing one unit to see if it works.

<pre>
return {
-- The name is shown in the selection interface
game = "MyMod",
shortGame = "MM",
name = "My Mod",
shortName = "MM",
version = "4.0",
mutator = "Heroes",
-- These can be shown by the selection interface
description = "My Mod That I Made",
url = "http://www.theplacepeoplecangetthelatestversionofyourmod.com",
-- What kind of mod this is
-- 0 - Hidden (support mod that can't be selected, such as OTA_textures)
-- 1 - Normal, only one can be selected at a time
-- 2 - Addon, any number of these can be selected. Could be used
-- for single units for example.
-- others - perhaps mutators and addon races that can be
-- enabled in addition to xta for example?
modtype = "1",
-- Number of other archives this one depends on
depend= {
taenheter.sdz,
springcontent.sdz,
otacontent.sdz,
tatextures.sdz,
-- Number of other archives this one replaces
},
}
</pre>

====Adding Your Unit to an Existing Mod====
The following is an example of what will be in your modinfo.lua file if you are adding new units to an existing mod (in this case xta_se_v066.sdz), this is good for adding units to the build tree of an existing mod or adding a whole new team.

<pre>
-- Description of the mod control file recognized by spring:
return {
-- The name is shown in the selection interface
game = "XTASE_MyUnits",
shortGame = "XTASEMU",
name = "XTASEv0.66 with+My Units",
shortName = "XTASEMU",
version = "4.0",
mutator = "Heroes",
-- These can be shown by the selection interface
description = "xta_se_v066 with the cool tank I made",
url = "http://www.fileuniverse.com/exactlocationblahblahblah",
-- What kind of mod this is
-- 0 - Hidden (support mod that can't be selected, such as OTA_textures)
-- 1 - Normal, only one can be selected at a time
-- 2 - Addon, any number of these can be selected. Could be used
-- for single units for example.
-- others - perhaps mutators and addon races that can be
-- enabled in addition to xta for example?
modtype = "1",
-- Number of other archives this one depends on
depend= {
taenheter.sdz,
springcontent.sdz,
otacontent.sdz,
tatextures.sdz,
xta_se_v066.sdz,
-- Number of other archives this one replaces
},
}
</pre>

If you are not depending on OTA files, you will have to supply your own cursors.

There are some extra bits in these examples, but I work on the "better safe than sorry" principle... which is to wait for someone who knows what they are doing to fix my articles.

You will want to save this file as plain text in <working directory>/<mod name>/

===armorDefs.lua===

I'm not exactly sure how this works, but the file needs to exist, so either steal one from another mod and modify it... or just make a file that looks like this.

<pre>
local armorDefs = {
}
</pre>

You will want to save this file as a lua file in <working directory>/<mod name>/gamedata

===sidedata.lua===

Start by stealing the sidedata.lua file from your dependency mod if you have one, then edit it to include your units/side.

Basically this file is in the form:

<pre>
local sideData = {
[1] = {
name = 'Good Guys',
startunit = 'GG_comm',
},
}
</pre>

There are also additional "[X]" entries for each side/team/commander-choice available in the mod-selector you choose.

You will save this file as lua file in <working directory>/<mod name>/gamedata/

===moveDefs.lua===
This file determines the footprint of your units, the angle of slopes they can climb and in how deep water they can drive. It contains several entries, all in the following format:

<pre>
local moveDefs = {
KBOT1 = { -- This is the name. Unit files refer to this name.
footprintx = 1, -- This is how big the X dimension is of the footprint in Spring units probably?
footprintz = 1, -- This is how big the Y dimension is of the footprint in Spring units probably?
maxwaterdepth = 15, -- This is how big the Y dimension is of the footprint in Spring units probably?
maxslope = 36, -- The maximum angle of slopes this unit can climb.
crushstrength = 5, -- This determines if the unit/unit class can crush certain features
},
-- etc..
}
</pre>

===SOUND.TDF===
This file refers to all the sounds your units make, so Spring knows which sound file is linked to what action. It contains entries in the following format.
[NAME] (The name of the unit class)
{
There are lots of different entries, I will list only the basic ones here for now.
select1=sound; (This entry determines what sound a unit makes if you click on it.
ok1=sound; (This entry determines what sound a unit makes if it does an action.
cant1=sound; (" " " " " " " " if it can't do an action.)
underattack=sound; (" " " " " " " " if it is attacked)
count5-count0=sound; (These 6 entries determine how the self-destruct countdown times sounds like.
canceldestruct=sound; (A unit makes this sound if you cancel the self-destruct procedure)
}

==Step 7:Adding a Build Pic==

Add a 96x96 BMP to your <working directory>/<mod name>/unitpics/ folder named either "UnitName.bmp" or whatever you specified in the "BuildPic=" line of your fbi.

==Step 8:Adding a Side Pic==

Add a 16x16 BMP to your <working directory>/<mod name>/sidepics/ folder named "teamname.bmp" or whatever you specified in the "name=" line of your SIDEDATA.TDF for each side/team you have added.

==Step 9:Scriptor==

===Stealing a Script===
Open someone else's script in scriptor that works the way you want your script to work, look at the top where it's talking about "piece names"... then change those piece names to be the piece names of your unit and do a find/replace to make all the places where those pieces show up to be your pieces too. Compile it so its name is the same as the "UnitName=" value in your "UnitName.fbi".

XXreminder to someone to link to a proper scripting tutorial

Put the bos and cob files for your unit script in <working directory>/<mod name>/scripts

==Step 10:Compiling Your Mod==

You may want to check your mod directory and make sure it follows the structure defined [[Mod_Development:Archives|here]].

navigate to your <working directory>/<mod name> and select everything and choose "add to archive <mod name>.7z".

make a copy of this file called <mod name>v0.7z in your working directory so you don't screw anything up later, then make a copy of it called <mod name>.sd7 in the mods directory of spring.

An alternative, added in more recent versions is the ".SDD" folder, to use this, copy the entire <mod name> folder in the mods directory of spring and rename it as "<mod name>.SDD". The advantage to the ".SDD" method is that you can tweak settings and add files without recompressing your mod all the time. When it comes time to distribute your mod use ".sd7".

EXAMPLES:
If your mod is called JoesMod you will have a file called "JoesMod.sd7" or a folder called "JoesMod.SDD" in your spring mods directory.

==Step 11:Testing Your Mod==
Open Up your lobby client, pick your mod from the drop-down list of the games in host battle or singleplayer mode if your lobby supports it(if it doesn't show up you screwed up your modinfo.txt), choose your tiny map from the map list and press start. If it doesn't break and your unit shows up, you have created all the neccessary files... yay!

Gotchas:
*If it doesn't work, check you didn't zip the folder itself, but the contents, ie if you open mymod.sd7 with 7zip, you should see folders such as "unittextures" rather than a folder "mymod" containing unittextures.

[[Category:Mod development]]

Simple Game Tutorial

2010-06-13T16:54:42Z

Sdbryan: /* SIDEDATA.TDF */ Changed to sidedata.lua

Until I Finish [[Mod Development]] is the place to go.

This Tutorial Aims to get a person from knowing nothing about Spring to the point where they can create and edit mods.

Right now I am working from memory so you may want to correct me when I'm wrong, I will try to cross link from my summaries to the appropriate articles available in other places.

I will not go too deep into making 3do's because they are old and dumb... but I'll try to make note of the differences here.

I don't know anything about scripting right now, so that section is likely to be sparse when I write it, I hope that someone will expand on it.

=Book 1: The First Unit=

==Step 1:Planning==
Who cares about planning, you know what you're doing... just come up with an idea for a mod... I made a chess set... if you don't have a real idea and just want to make a model show up in the game... then yeah... this is the place to start... I'd do that if I were you.

Another good thing to do at this point is to creat a "working directory", and inside it create a directory with the name that your mod will have... after many headaches I decided it's best to put this in the root directory of your system so it's really easy to find when you are switching around back and forth between folders and keep having to find your files over and over again.

==Step 2:Getting The Tools==
You will need a bunch of stuff... here's the list (I assume you are using windows)

''Want:''
*[http://taspring.clan-sy.com/download.php Spring] - The main program, you will likely need this to test if you've screwed up
*A Tiny Map (2x2) - to test your mod fast (suggest [http://www.fileuniverse.com/?p=showitem&ID=2534 Simple Chess Map])

''Need:''
*'''Program listings can be found here:''' '''[http://taspring.clan-sy.com/wiki/Map%2C_Mod%2C_And_Unit_Development_Programs Map, Mod, And Unit Development Programs]'''
*3D Modeling Program - '''See above link'''
*Notepad - to edit all the miriad of text files
*A Graphical Editing Program - needs to handle RGBA TGAs (aka tga's with alpha channels), I suggest Photoshop if you have it, or The GIMP... needed for all of the texture making for UVmapping stuff... '''See above link'''
*Upspring 1.3 - To convert your models to the approprite s3o format (if you want to fight with 3do builder, then go ahead... a good trick is to get your model into upspring first and adjust all the hierachy, then save it as an 3do... but why bother?). '''See above link'''
*Scriptor - to make and compile your units "animation script"... or steal someone else's and make it work for your unit. '''See above link'''
*Compression Utility - (I suggest [http://www.7-zip.org/ 7zip] - even if you are using zip compression and not 7zip, it's still good to have)

==Step 3:Making a 3D Model==

Go into your 3D modelling program and make a 3D model, [http://taspring.clan-sy.com/w/images/b/b4/WingsCombine.PNG combine] all the objects and UV map the model, then separate it out into any parts that need to move independently of each other. Then Export the UV map as an Image File and Export the whole thing as a 3ds file. Put the original wings file, the UVMap image and the 3ds file into your working directory so you can find them later.

Wings 3D UV Mapping tutorial has been started here - [[Units:CreateModel]]

==Step 4:Fixing Your Images==

[[Basic s3o unit making guide|This Article includes a UVMapping Guide]]

Open up your UVMap in Photoshop (or whatever) go to the layer/chooser thingy and go to the Channels Tab, add a new layer (it should default to alpha) and fill it with 99% black so you can see your texture in upspring. If you want to can paint the UVmap and put white (1% black) on the alpha channel where you want your team colours to show up (you can use something between 1% and 99% to get a blend of your team colour along with the texture... for example 50% will give you your texture with 50% of the team colour mixed in...)

I don't know how to do glow maps... XXreminder for someone to create a Glowmapping tutorial... you don't acctually need one for the model to show up.

Save these images both in the working directory.

Save a copy of these images in tga format into <working directory>/<mod name>/unittextures

==Step 5:Upspring==

===Importing Your 3ds===
Open Upspring 1.3, go to file>load model and navigate to and open your 3DS model you exported, you should see the model in upspring as a 3d mesh. Go to the model tab and set the radius and height values to something other then zero... this defines where the health bar will show up, and more importantly, how big the collision sphere will be.

You will also need to use all of the other tools on those tabs to resize and rotate and move your model to the right place... wings makes models that are 90 degrees off and about 30 times smaller than most spring models... make sure you click the "apply transform" button after any changes that you actually want to show up in the game.

Also, you will want to make the hierachy work using the cut, paste, and add empty buttons. You will need an object called "base" that all the other objects are connected to... the "origin object"... sometimes you get lucky and wings exports it properly... usually not.

===Importing Your UV and Glowmaps===

Go to the textures tab and make your UV/texture/team-colour map as "texture1" and your UV/glow/reflectivity map as "texture2"... it should show up correctly in the preview pane.

===Exporting Your s3o===
Choose File>Save Model As then in the drop down select "s3o" and type an appropriate name. This model should be saved to your working directory, and a copy of it made to <working directory>/<mod name>/objects3d/

==Step 6:A couple Text Files==

===UnitName.fbi===
For Reference visit [[Units:FBI]], but again, the easiest way to do this is to extract an existing mod and find the fbi for a unit that behaves similarly to the one you are trying to make and rename and modify it.

Some More Specific Information Not Clear in the "Units:FBI" article:

'''Name+" "+Description=Spring Display Name'''

So if you have the following settings:

Name=Tiger;
Description=Fast Attack C.A.T.;

The Tooltip will show "Tiger Fast Attack C.A.T."

'''BuildPic Defaults to UnitName.bmp'''

So if you leave out "BuildPic=filename.bmp;" Spring will look in /unitpics/ for a file called "UnitName.bmp" to use as your buildpic.

'''ObjectName'''

If you want to use an s3o object, you will need to specify with "ObjectName=UnitName'''.S3O;'''" otherwise it will look for "UnitName.3do". Also, you don't have to use "UnitName" as the filename and, in fact, multiple Unit's fbi files can reference the same 3D models. It is easier, however, for people to figure out what you are doing in your mod if you follow the standards.

Save this file as plain text in <working directory>/<mod name>/units/

===modinfo.lua===

modinfo.lua is a lua file that defines a number of things that are used when loading a mod, most of the information is self explanitory but basically what you are doing is defining what is going to show up in whatever mod-selection interface you use as well as what other files need to be loaded into memory in order for your mod to work.

====Making a New Mod with your unit/units====
The following is an example of what will be in your modinfo.lua file if you are starting from scratch and making your own mod. This is also good when you are just testing one unit to see if it works.

<pre>
return {
-- The name is shown in the selection interface
game = "MyMod",
shortGame = "MM",
name = "My Mod",
shortName = "MM",
version = "4.0",
mutator = "Heroes",
-- These can be shown by the selection interface
description = "My Mod That I Made",
url = "http://www.theplacepeoplecangetthelatestversionofyourmod.com",
-- What kind of mod this is
-- 0 - Hidden (support mod that can't be selected, such as OTA_textures)
-- 1 - Normal, only one can be selected at a time
-- 2 - Addon, any number of these can be selected. Could be used
-- for single units for example.
-- others - perhaps mutators and addon races that can be
-- enabled in addition to xta for example?
modtype = "1",
-- Number of other archives this one depends on
depend= {
taenheter.sdz,
springcontent.sdz,
otacontent.sdz,
tatextures.sdz,
-- Number of other archives this one replaces
},
}
</pre>

====Adding Your Unit to an Existing Mod====
The following is an example of what will be in your modinfo.lua file if you are adding new units to an existing mod (in this case xta_se_v066.sdz), this is good for adding units to the build tree of an existing mod or adding a whole new team.

<pre>
-- Description of the mod control file recognized by spring:
return {
-- The name is shown in the selection interface
game = "XTASE_MyUnits",
shortGame = "XTASEMU",
name = "XTASEv0.66 with+My Units",
shortName = "XTASEMU",
version = "4.0",
mutator = "Heroes",
-- These can be shown by the selection interface
description = "xta_se_v066 with the cool tank I made",
url = "http://www.fileuniverse.com/exactlocationblahblahblah",
-- What kind of mod this is
-- 0 - Hidden (support mod that can't be selected, such as OTA_textures)
-- 1 - Normal, only one can be selected at a time
-- 2 - Addon, any number of these can be selected. Could be used
-- for single units for example.
-- others - perhaps mutators and addon races that can be
-- enabled in addition to xta for example?
modtype = "1",
-- Number of other archives this one depends on
depend= {
taenheter.sdz,
springcontent.sdz,
otacontent.sdz,
tatextures.sdz,
xta_se_v066.sdz,
-- Number of other archives this one replaces
},
}
</pre>

If you are not depending on OTA files, you will have to supply your own cursors.

There are some extra bits in these examples, but I work on the "better safe than sorry" principle... which is to wait for someone who knows what they are doing to fix my articles.

You will want to save this file as plain text in <working directory>/<mod name>/

===armorDefs.lua===

I'm not exactly sure how this works, but the file needs to exist, so either steal one from another mod and modify it... or just make a file that looks like this.

<pre>
local armorDefs = {
}
</pre>

You will want to save this file as a lua file in <working directory>/<mod name>/gamedata

===sidedata.lua===

Start by stealing the sidedata.lua file from your dependency mod if you have one, then edit it to include your units/side.

Basically this file is in the form:

<pre>
local sideData = {
[1] = {
name = 'Good Guys',
startunit = 'GG_comm',
},
}
</pre>

There are also additional "[X]" entries for each side/team/commander-choice available in the mod-selector you choose.

You will save this file as lua file in <working directory>/<mod name>/gamedata/

===MOVEDATA.TDF===
This file determines the footprint of your units, the angle of slopes they can climb and in how deep water they can drive. It contains several entries, all in the following format:

[CLASS#] (Replace # with numbers, so you get entries CLASS0, CLASS1 etc.)
{
name=KBOT; (This is the name. FBI files refer to this name.)
footprintx=1; (This is how big the X dimension is of the footprint in Spring units probably?)
footprintz=1; (This is how big the Y dimension is of the footprint in Spring units probably?)
maxwaterdepth=5; (This is in how deep water the unit/unit class can walk.)
maxslope=36; (The maximum angle of slopes this unit can climb.)
crushstrength=10; (This determines if the unit/unit class can crush certain features)
}

===SOUND.TDF===
This file refers to all the sounds your units make, so Spring knows which sound file is linked to what action. It contains entries in the following format.
[NAME] (The name of the unit class)
{
There are lots of different entries, I will list only the basic ones here for now.
select1=sound; (This entry determines what sound a unit makes if you click on it.
ok1=sound; (This entry determines what sound a unit makes if it does an action.
cant1=sound; (" " " " " " " " if it can't do an action.)
underattack=sound; (" " " " " " " " if it is attacked)
count5-count0=sound; (These 6 entries determine how the self-destruct countdown times sounds like.
canceldestruct=sound; (A unit makes this sound if you cancel the self-destruct procedure)
}

==Step 7:Adding a Build Pic==

Add a 96x96 BMP to your <working directory>/<mod name>/unitpics/ folder named either "UnitName.bmp" or whatever you specified in the "BuildPic=" line of your fbi.

==Step 8:Adding a Side Pic==

Add a 16x16 BMP to your <working directory>/<mod name>/sidepics/ folder named "teamname.bmp" or whatever you specified in the "name=" line of your SIDEDATA.TDF for each side/team you have added.

==Step 9:Scriptor==

===Stealing a Script===
Open someone else's script in scriptor that works the way you want your script to work, look at the top where it's talking about "piece names"... then change those piece names to be the piece names of your unit and do a find/replace to make all the places where those pieces show up to be your pieces too. Compile it so its name is the same as the "UnitName=" value in your "UnitName.fbi".

XXreminder to someone to link to a proper scripting tutorial

Put the bos and cob files for your unit script in <working directory>/<mod name>/scripts

==Step 10:Compiling Your Mod==

You may want to check your mod directory and make sure it follows the structure defined [[Mod_Development:Archives|here]].

navigate to your <working directory>/<mod name> and select everything and choose "add to archive <mod name>.7z".

make a copy of this file called <mod name>v0.7z in your working directory so you don't screw anything up later, then make a copy of it called <mod name>.sd7 in the mods directory of spring.

An alternative, added in more recent versions is the ".SDD" folder, to use this, copy the entire <mod name> folder in the mods directory of spring and rename it as "<mod name>.SDD". The advantage to the ".SDD" method is that you can tweak settings and add files without recompressing your mod all the time. When it comes time to distribute your mod use ".sd7".

EXAMPLES:
If your mod is called JoesMod you will have a file called "JoesMod.sd7" or a folder called "JoesMod.SDD" in your spring mods directory.

==Step 11:Testing Your Mod==
Open Up your lobby client, pick your mod from the drop-down list of the games in host battle or singleplayer mode if your lobby supports it(if it doesn't show up you screwed up your modinfo.txt), choose your tiny map from the map list and press start. If it doesn't break and your unit shows up, you have created all the neccessary files... yay!

Gotchas:
*If it doesn't work, check you didn't zip the folder itself, but the contents, ie if you open mymod.sd7 with 7zip, you should see folders such as "unittextures" rather than a folder "mymod" containing unittextures.

[[Category:Mod development]]

Simple Game Tutorial

2010-06-13T16:46:29Z

Sdbryan: /* Armor.txt */ Changed to armorDefs.lua

Until I Finish [[Mod Development]] is the place to go.

This Tutorial Aims to get a person from knowing nothing about Spring to the point where they can create and edit mods.

Right now I am working from memory so you may want to correct me when I'm wrong, I will try to cross link from my summaries to the appropriate articles available in other places.

I will not go too deep into making 3do's because they are old and dumb... but I'll try to make note of the differences here.

I don't know anything about scripting right now, so that section is likely to be sparse when I write it, I hope that someone will expand on it.

=Book 1: The First Unit=

==Step 1:Planning==
Who cares about planning, you know what you're doing... just come up with an idea for a mod... I made a chess set... if you don't have a real idea and just want to make a model show up in the game... then yeah... this is the place to start... I'd do that if I were you.

Another good thing to do at this point is to creat a "working directory", and inside it create a directory with the name that your mod will have... after many headaches I decided it's best to put this in the root directory of your system so it's really easy to find when you are switching around back and forth between folders and keep having to find your files over and over again.

==Step 2:Getting The Tools==
You will need a bunch of stuff... here's the list (I assume you are using windows)

''Want:''
*[http://taspring.clan-sy.com/download.php Spring] - The main program, you will likely need this to test if you've screwed up
*A Tiny Map (2x2) - to test your mod fast (suggest [http://www.fileuniverse.com/?p=showitem&ID=2534 Simple Chess Map])

''Need:''
*'''Program listings can be found here:''' '''[http://taspring.clan-sy.com/wiki/Map%2C_Mod%2C_And_Unit_Development_Programs Map, Mod, And Unit Development Programs]'''
*3D Modeling Program - '''See above link'''
*Notepad - to edit all the miriad of text files
*A Graphical Editing Program - needs to handle RGBA TGAs (aka tga's with alpha channels), I suggest Photoshop if you have it, or The GIMP... needed for all of the texture making for UVmapping stuff... '''See above link'''
*Upspring 1.3 - To convert your models to the approprite s3o format (if you want to fight with 3do builder, then go ahead... a good trick is to get your model into upspring first and adjust all the hierachy, then save it as an 3do... but why bother?). '''See above link'''
*Scriptor - to make and compile your units "animation script"... or steal someone else's and make it work for your unit. '''See above link'''
*Compression Utility - (I suggest [http://www.7-zip.org/ 7zip] - even if you are using zip compression and not 7zip, it's still good to have)

==Step 3:Making a 3D Model==

Go into your 3D modelling program and make a 3D model, [http://taspring.clan-sy.com/w/images/b/b4/WingsCombine.PNG combine] all the objects and UV map the model, then separate it out into any parts that need to move independently of each other. Then Export the UV map as an Image File and Export the whole thing as a 3ds file. Put the original wings file, the UVMap image and the 3ds file into your working directory so you can find them later.

Wings 3D UV Mapping tutorial has been started here - [[Units:CreateModel]]

==Step 4:Fixing Your Images==

[[Basic s3o unit making guide|This Article includes a UVMapping Guide]]

Open up your UVMap in Photoshop (or whatever) go to the layer/chooser thingy and go to the Channels Tab, add a new layer (it should default to alpha) and fill it with 99% black so you can see your texture in upspring. If you want to can paint the UVmap and put white (1% black) on the alpha channel where you want your team colours to show up (you can use something between 1% and 99% to get a blend of your team colour along with the texture... for example 50% will give you your texture with 50% of the team colour mixed in...)

I don't know how to do glow maps... XXreminder for someone to create a Glowmapping tutorial... you don't acctually need one for the model to show up.

Save these images both in the working directory.

Save a copy of these images in tga format into <working directory>/<mod name>/unittextures

==Step 5:Upspring==

===Importing Your 3ds===
Open Upspring 1.3, go to file>load model and navigate to and open your 3DS model you exported, you should see the model in upspring as a 3d mesh. Go to the model tab and set the radius and height values to something other then zero... this defines where the health bar will show up, and more importantly, how big the collision sphere will be.

You will also need to use all of the other tools on those tabs to resize and rotate and move your model to the right place... wings makes models that are 90 degrees off and about 30 times smaller than most spring models... make sure you click the "apply transform" button after any changes that you actually want to show up in the game.

Also, you will want to make the hierachy work using the cut, paste, and add empty buttons. You will need an object called "base" that all the other objects are connected to... the "origin object"... sometimes you get lucky and wings exports it properly... usually not.

===Importing Your UV and Glowmaps===

Go to the textures tab and make your UV/texture/team-colour map as "texture1" and your UV/glow/reflectivity map as "texture2"... it should show up correctly in the preview pane.

===Exporting Your s3o===
Choose File>Save Model As then in the drop down select "s3o" and type an appropriate name. This model should be saved to your working directory, and a copy of it made to <working directory>/<mod name>/objects3d/

==Step 6:A couple Text Files==

===UnitName.fbi===
For Reference visit [[Units:FBI]], but again, the easiest way to do this is to extract an existing mod and find the fbi for a unit that behaves similarly to the one you are trying to make and rename and modify it.

Some More Specific Information Not Clear in the "Units:FBI" article:

'''Name+" "+Description=Spring Display Name'''

So if you have the following settings:

Name=Tiger;
Description=Fast Attack C.A.T.;

The Tooltip will show "Tiger Fast Attack C.A.T."

'''BuildPic Defaults to UnitName.bmp'''

So if you leave out "BuildPic=filename.bmp;" Spring will look in /unitpics/ for a file called "UnitName.bmp" to use as your buildpic.

'''ObjectName'''

If you want to use an s3o object, you will need to specify with "ObjectName=UnitName'''.S3O;'''" otherwise it will look for "UnitName.3do". Also, you don't have to use "UnitName" as the filename and, in fact, multiple Unit's fbi files can reference the same 3D models. It is easier, however, for people to figure out what you are doing in your mod if you follow the standards.

Save this file as plain text in <working directory>/<mod name>/units/

===modinfo.lua===

modinfo.lua is a lua file that defines a number of things that are used when loading a mod, most of the information is self explanitory but basically what you are doing is defining what is going to show up in whatever mod-selection interface you use as well as what other files need to be loaded into memory in order for your mod to work.

====Making a New Mod with your unit/units====
The following is an example of what will be in your modinfo.lua file if you are starting from scratch and making your own mod. This is also good when you are just testing one unit to see if it works.

<pre>
return {
-- The name is shown in the selection interface
game = "MyMod",
shortGame = "MM",
name = "My Mod",
shortName = "MM",
version = "4.0",
mutator = "Heroes",
-- These can be shown by the selection interface
description = "My Mod That I Made",
url = "http://www.theplacepeoplecangetthelatestversionofyourmod.com",
-- What kind of mod this is
-- 0 - Hidden (support mod that can't be selected, such as OTA_textures)
-- 1 - Normal, only one can be selected at a time
-- 2 - Addon, any number of these can be selected. Could be used
-- for single units for example.
-- others - perhaps mutators and addon races that can be
-- enabled in addition to xta for example?
modtype = "1",
-- Number of other archives this one depends on
depend= {
taenheter.sdz,
springcontent.sdz,
otacontent.sdz,
tatextures.sdz,
-- Number of other archives this one replaces
},
}
</pre>

====Adding Your Unit to an Existing Mod====
The following is an example of what will be in your modinfo.lua file if you are adding new units to an existing mod (in this case xta_se_v066.sdz), this is good for adding units to the build tree of an existing mod or adding a whole new team.

<pre>
-- Description of the mod control file recognized by spring:
return {
-- The name is shown in the selection interface
game = "XTASE_MyUnits",
shortGame = "XTASEMU",
name = "XTASEv0.66 with+My Units",
shortName = "XTASEMU",
version = "4.0",
mutator = "Heroes",
-- These can be shown by the selection interface
description = "xta_se_v066 with the cool tank I made",
url = "http://www.fileuniverse.com/exactlocationblahblahblah",
-- What kind of mod this is
-- 0 - Hidden (support mod that can't be selected, such as OTA_textures)
-- 1 - Normal, only one can be selected at a time
-- 2 - Addon, any number of these can be selected. Could be used
-- for single units for example.
-- others - perhaps mutators and addon races that can be
-- enabled in addition to xta for example?
modtype = "1",
-- Number of other archives this one depends on
depend= {
taenheter.sdz,
springcontent.sdz,
otacontent.sdz,
tatextures.sdz,
xta_se_v066.sdz,
-- Number of other archives this one replaces
},
}
</pre>

If you are not depending on OTA files, you will have to supply your own cursors.

There are some extra bits in these examples, but I work on the "better safe than sorry" principle... which is to wait for someone who knows what they are doing to fix my articles.

You will want to save this file as plain text in <working directory>/<mod name>/

===armorDefs.lua===

I'm not exactly sure how this works, but the file needs to exist, so either steal one from another mod and modify it... or just make a file that looks like this.

<pre>
local armorDefs = {
}
</pre>

You will want to save this file as a lua file in <working directory>/<mod name>/gamedata

===SIDEDATA.TDF===

Start by stealing the sidedata.tdf file from your dependency mod if you have one, then edit it to include your units/side.

Basically this file is in the form:

[SIDE0]
{
name=Good Guys;
nameprefix=GG;
commander=UnitName1;
}
[CANBUILD]
{
[UnitName1]
{
canbuild1=UnitName2;
canbuild2=UnitName3;
canbuild3=UnitName4;
canbuild4=UnitName5;
canbuild5=UnitName6;
}
}

...with additional "[SIDEX]" entries for each side/team/commander-choice available in the mod-selector you choose, additional "[UnitName]" sections for each factory of construction unit, and additional "canbuildx=UnitName" entries to all factory/con-units that can build each unit.

You will save this file as plain text in <working directory>/<mod name>/gamedata/

===MOVEDATA.TDF===
This file determines the footprint of your units, the angle of slopes they can climb and in how deep water they can drive. It contains several entries, all in the following format:

[CLASS#] (Replace # with numbers, so you get entries CLASS0, CLASS1 etc.)
{
name=KBOT; (This is the name. FBI files refer to this name.)
footprintx=1; (This is how big the X dimension is of the footprint in Spring units probably?)
footprintz=1; (This is how big the Y dimension is of the footprint in Spring units probably?)
maxwaterdepth=5; (This is in how deep water the unit/unit class can walk.)
maxslope=36; (The maximum angle of slopes this unit can climb.)
crushstrength=10; (This determines if the unit/unit class can crush certain features)
}

===SOUND.TDF===
This file refers to all the sounds your units make, so Spring knows which sound file is linked to what action. It contains entries in the following format.
[NAME] (The name of the unit class)
{
There are lots of different entries, I will list only the basic ones here for now.
select1=sound; (This entry determines what sound a unit makes if you click on it.
ok1=sound; (This entry determines what sound a unit makes if it does an action.
cant1=sound; (" " " " " " " " if it can't do an action.)
underattack=sound; (" " " " " " " " if it is attacked)
count5-count0=sound; (These 6 entries determine how the self-destruct countdown times sounds like.
canceldestruct=sound; (A unit makes this sound if you cancel the self-destruct procedure)
}

==Step 7:Adding a Build Pic==

Add a 96x96 BMP to your <working directory>/<mod name>/unitpics/ folder named either "UnitName.bmp" or whatever you specified in the "BuildPic=" line of your fbi.

==Step 8:Adding a Side Pic==

Add a 16x16 BMP to your <working directory>/<mod name>/sidepics/ folder named "teamname.bmp" or whatever you specified in the "name=" line of your SIDEDATA.TDF for each side/team you have added.

==Step 9:Scriptor==

===Stealing a Script===
Open someone else's script in scriptor that works the way you want your script to work, look at the top where it's talking about "piece names"... then change those piece names to be the piece names of your unit and do a find/replace to make all the places where those pieces show up to be your pieces too. Compile it so its name is the same as the "UnitName=" value in your "UnitName.fbi".

XXreminder to someone to link to a proper scripting tutorial

Put the bos and cob files for your unit script in <working directory>/<mod name>/scripts

==Step 10:Compiling Your Mod==

You may want to check your mod directory and make sure it follows the structure defined [[Mod_Development:Archives|here]].

navigate to your <working directory>/<mod name> and select everything and choose "add to archive <mod name>.7z".

make a copy of this file called <mod name>v0.7z in your working directory so you don't screw anything up later, then make a copy of it called <mod name>.sd7 in the mods directory of spring.

An alternative, added in more recent versions is the ".SDD" folder, to use this, copy the entire <mod name> folder in the mods directory of spring and rename it as "<mod name>.SDD". The advantage to the ".SDD" method is that you can tweak settings and add files without recompressing your mod all the time. When it comes time to distribute your mod use ".sd7".

EXAMPLES:
If your mod is called JoesMod you will have a file called "JoesMod.sd7" or a folder called "JoesMod.SDD" in your spring mods directory.

==Step 11:Testing Your Mod==
Open Up your lobby client, pick your mod from the drop-down list of the games in host battle or singleplayer mode if your lobby supports it(if it doesn't show up you screwed up your modinfo.txt), choose your tiny map from the map list and press start. If it doesn't break and your unit shows up, you have created all the neccessary files... yay!

Gotchas:
*If it doesn't work, check you didn't zip the folder itself, but the contents, ie if you open mymod.sd7 with 7zip, you should see folders such as "unittextures" rather than a folder "mymod" containing unittextures.

[[Category:Mod development]]

Simple Game Tutorial

2010-05-23T05:08:14Z

Sdbryan: /* modinfo.tdf */ Changed to modinfo.lua for the latest version of Spring 0.81.2

Until I Finish [[Mod Development]] is the place to go.

This Tutorial Aims to get a person from knowing nothing about Spring to the point where they can create and edit mods.

Right now I am working from memory so you may want to correct me when I'm wrong, I will try to cross link from my summaries to the appropriate articles available in other places.

I will not go too deep into making 3do's because they are old and dumb... but I'll try to make note of the differences here.

I don't know anything about scripting right now, so that section is likely to be sparse when I write it, I hope that someone will expand on it.

=Book 1: The First Unit=

==Step 1:Planning==
Who cares about planning, you know what you're doing... just come up with an idea for a mod... I made a chess set... if you don't have a real idea and just want to make a model show up in the game... then yeah... this is the place to start... I'd do that if I were you.

Another good thing to do at this point is to creat a "working directory", and inside it create a directory with the name that your mod will have... after many headaches I decided it's best to put this in the root directory of your system so it's really easy to find when you are switching around back and forth between folders and keep having to find your files over and over again.

==Step 2:Getting The Tools==
You will need a bunch of stuff... here's the list (I assume you are using windows)

''Want:''
*[http://taspring.clan-sy.com/download.php Spring] - The main program, you will likely need this to test if you've screwed up
*A Tiny Map (2x2) - to test your mod fast (suggest [http://www.fileuniverse.com/?p=showitem&ID=2534 Simple Chess Map])

''Need:''
*'''Program listings can be found here:''' '''[http://taspring.clan-sy.com/wiki/Map%2C_Mod%2C_And_Unit_Development_Programs Map, Mod, And Unit Development Programs]'''
*3D Modeling Program - '''See above link'''
*Notepad - to edit all the miriad of text files
*A Graphical Editing Program - needs to handle RGBA TGAs (aka tga's with alpha channels), I suggest Photoshop if you have it, or The GIMP... needed for all of the texture making for UVmapping stuff... '''See above link'''
*Upspring 1.3 - To convert your models to the approprite s3o format (if you want to fight with 3do builder, then go ahead... a good trick is to get your model into upspring first and adjust all the hierachy, then save it as an 3do... but why bother?). '''See above link'''
*Scriptor - to make and compile your units "animation script"... or steal someone else's and make it work for your unit. '''See above link'''
*Compression Utility - (I suggest [http://www.7-zip.org/ 7zip] - even if you are using zip compression and not 7zip, it's still good to have)

==Step 3:Making a 3D Model==

Go into your 3D modelling program and make a 3D model, [http://taspring.clan-sy.com/w/images/b/b4/WingsCombine.PNG combine] all the objects and UV map the model, then separate it out into any parts that need to move independently of each other. Then Export the UV map as an Image File and Export the whole thing as a 3ds file. Put the original wings file, the UVMap image and the 3ds file into your working directory so you can find them later.

Wings 3D UV Mapping tutorial has been started here - [[Units:CreateModel]]

==Step 4:Fixing Your Images==

[[Basic s3o unit making guide|This Article includes a UVMapping Guide]]

Open up your UVMap in Photoshop (or whatever) go to the layer/chooser thingy and go to the Channels Tab, add a new layer (it should default to alpha) and fill it with 99% black so you can see your texture in upspring. If you want to can paint the UVmap and put white (1% black) on the alpha channel where you want your team colours to show up (you can use something between 1% and 99% to get a blend of your team colour along with the texture... for example 50% will give you your texture with 50% of the team colour mixed in...)

I don't know how to do glow maps... XXreminder for someone to create a Glowmapping tutorial... you don't acctually need one for the model to show up.

Save these images both in the working directory.

Save a copy of these images in tga format into <working directory>/<mod name>/unittextures

==Step 5:Upspring==

===Importing Your 3ds===
Open Upspring 1.3, go to file>load model and navigate to and open your 3DS model you exported, you should see the model in upspring as a 3d mesh. Go to the model tab and set the radius and height values to something other then zero... this defines where the health bar will show up, and more importantly, how big the collision sphere will be.

You will also need to use all of the other tools on those tabs to resize and rotate and move your model to the right place... wings makes models that are 90 degrees off and about 30 times smaller than most spring models... make sure you click the "apply transform" button after any changes that you actually want to show up in the game.

Also, you will want to make the hierachy work using the cut, paste, and add empty buttons. You will need an object called "base" that all the other objects are connected to... the "origin object"... sometimes you get lucky and wings exports it properly... usually not.

===Importing Your UV and Glowmaps===

Go to the textures tab and make your UV/texture/team-colour map as "texture1" and your UV/glow/reflectivity map as "texture2"... it should show up correctly in the preview pane.

===Exporting Your s3o===
Choose File>Save Model As then in the drop down select "s3o" and type an appropriate name. This model should be saved to your working directory, and a copy of it made to <working directory>/<mod name>/objects3d/

==Step 6:A couple Text Files==

===UnitName.fbi===
For Reference visit [[Units:FBI]], but again, the easiest way to do this is to extract an existing mod and find the fbi for a unit that behaves similarly to the one you are trying to make and rename and modify it.

Some More Specific Information Not Clear in the "Units:FBI" article:

'''Name+" "+Description=Spring Display Name'''

So if you have the following settings:

Name=Tiger;
Description=Fast Attack C.A.T.;

The Tooltip will show "Tiger Fast Attack C.A.T."

'''BuildPic Defaults to UnitName.bmp'''

So if you leave out "BuildPic=filename.bmp;" Spring will look in /unitpics/ for a file called "UnitName.bmp" to use as your buildpic.

'''ObjectName'''

If you want to use an s3o object, you will need to specify with "ObjectName=UnitName'''.S3O;'''" otherwise it will look for "UnitName.3do". Also, you don't have to use "UnitName" as the filename and, in fact, multiple Unit's fbi files can reference the same 3D models. It is easier, however, for people to figure out what you are doing in your mod if you follow the standards.

Save this file as plain text in <working directory>/<mod name>/units/

===modinfo.lua===

modinfo.lua is a lua file that defines a number of things that are used when loading a mod, most of the information is self explanitory but basically what you are doing is defining what is going to show up in whatever mod-selection interface you use as well as what other files need to be loaded into memory in order for your mod to work.

====Making a New Mod with your unit/units====
The following is an example of what will be in your modinfo.lua file if you are starting from scratch and making your own mod. This is also good when you are just testing one unit to see if it works.

<pre>
return {
-- The name is shown in the selection interface
game = "MyMod",
shortGame = "MM",
name = "My Mod",
shortName = "MM",
version = "4.0",
mutator = "Heroes",
-- These can be shown by the selection interface
description = "My Mod That I Made",
url = "http://www.theplacepeoplecangetthelatestversionofyourmod.com",
-- What kind of mod this is
-- 0 - Hidden (support mod that can't be selected, such as OTA_textures)
-- 1 - Normal, only one can be selected at a time
-- 2 - Addon, any number of these can be selected. Could be used
-- for single units for example.
-- others - perhaps mutators and addon races that can be
-- enabled in addition to xta for example?
modtype = "1",
-- Number of other archives this one depends on
depend= {
taenheter.sdz,
springcontent.sdz,
otacontent.sdz,
tatextures.sdz,
-- Number of other archives this one replaces
},
}
</pre>

====Adding Your Unit to an Existing Mod====
The following is an example of what will be in your modinfo.lua file if you are adding new units to an existing mod (in this case xta_se_v066.sdz), this is good for adding units to the build tree of an existing mod or adding a whole new team.

<pre>
-- Description of the mod control file recognized by spring:
return {
-- The name is shown in the selection interface
game = "XTASE_MyUnits",
shortGame = "XTASEMU",
name = "XTASEv0.66 with+My Units",
shortName = "XTASEMU",
version = "4.0",
mutator = "Heroes",
-- These can be shown by the selection interface
description = "xta_se_v066 with the cool tank I made",
url = "http://www.fileuniverse.com/exactlocationblahblahblah",
-- What kind of mod this is
-- 0 - Hidden (support mod that can't be selected, such as OTA_textures)
-- 1 - Normal, only one can be selected at a time
-- 2 - Addon, any number of these can be selected. Could be used
-- for single units for example.
-- others - perhaps mutators and addon races that can be
-- enabled in addition to xta for example?
modtype = "1",
-- Number of other archives this one depends on
depend= {
taenheter.sdz,
springcontent.sdz,
otacontent.sdz,
tatextures.sdz,
xta_se_v066.sdz,
-- Number of other archives this one replaces
},
}
</pre>

If you are not depending on OTA files, you will have to supply your own cursors.

There are some extra bits in these examples, but I work on the "better safe than sorry" principle... which is to wait for someone who knows what they are doing to fix my articles.

You will want to save this file as plain text in <working directory>/<mod name>/

===Armor.txt===

I'm not exactly sure how this works, but the file needs to exist, so either steal one from another mod and modify it... or just make a file that looks like this.

// [UNITNAME]- Good Against Lazer/Bad Against Nukes
[UNITNAME]
{
}

You will want to save this file as plain text in <working directory>/<mod name>/

===SIDEDATA.TDF===

Start by stealing the sidedata.tdf file from your dependency mod if you have one, then edit it to include your units/side.

Basically this file is in the form:

[SIDE0]
{
name=Good Guys;
nameprefix=GG;
commander=UnitName1;
}
[CANBUILD]
{
[UnitName1]
{
canbuild1=UnitName2;
canbuild2=UnitName3;
canbuild3=UnitName4;
canbuild4=UnitName5;
canbuild5=UnitName6;
}
}

...with additional "[SIDEX]" entries for each side/team/commander-choice available in the mod-selector you choose, additional "[UnitName]" sections for each factory of construction unit, and additional "canbuildx=UnitName" entries to all factory/con-units that can build each unit.

You will save this file as plain text in <working directory>/<mod name>/gamedata/

===MOVEDATA.TDF===
This file determines the footprint of your units, the angle of slopes they can climb and in how deep water they can drive. It contains several entries, all in the following format:

[CLASS#] (Replace # with numbers, so you get entries CLASS0, CLASS1 etc.)
{
name=KBOT; (This is the name. FBI files refer to this name.)
footprintx=1; (This is how big the X dimension is of the footprint in Spring units probably?)
footprintz=1; (This is how big the Y dimension is of the footprint in Spring units probably?)
maxwaterdepth=5; (This is in how deep water the unit/unit class can walk.)
maxslope=36; (The maximum angle of slopes this unit can climb.)
crushstrength=10; (This determines if the unit/unit class can crush certain features)
}

===SOUND.TDF===
This file refers to all the sounds your units make, so Spring knows which sound file is linked to what action. It contains entries in the following format.
[NAME] (The name of the unit class)
{
There are lots of different entries, I will list only the basic ones here for now.
select1=sound; (This entry determines what sound a unit makes if you click on it.
ok1=sound; (This entry determines what sound a unit makes if it does an action.
cant1=sound; (" " " " " " " " if it can't do an action.)
underattack=sound; (" " " " " " " " if it is attacked)
count5-count0=sound; (These 6 entries determine how the self-destruct countdown times sounds like.
canceldestruct=sound; (A unit makes this sound if you cancel the self-destruct procedure)
}

==Step 7:Adding a Build Pic==

Add a 96x96 BMP to your <working directory>/<mod name>/unitpics/ folder named either "UnitName.bmp" or whatever you specified in the "BuildPic=" line of your fbi.

==Step 8:Adding a Side Pic==

Add a 16x16 BMP to your <working directory>/<mod name>/sidepics/ folder named "teamname.bmp" or whatever you specified in the "name=" line of your SIDEDATA.TDF for each side/team you have added.

==Step 9:Scriptor==

===Stealing a Script===
Open someone else's script in scriptor that works the way you want your script to work, look at the top where it's talking about "piece names"... then change those piece names to be the piece names of your unit and do a find/replace to make all the places where those pieces show up to be your pieces too. Compile it so its name is the same as the "UnitName=" value in your "UnitName.fbi".

XXreminder to someone to link to a proper scripting tutorial

Put the bos and cob files for your unit script in <working directory>/<mod name>/scripts

==Step 10:Compiling Your Mod==

You may want to check your mod directory and make sure it follows the structure defined [[Mod_Development:Archives|here]].

navigate to your <working directory>/<mod name> and select everything and choose "add to archive <mod name>.7z".

make a copy of this file called <mod name>v0.7z in your working directory so you don't screw anything up later, then make a copy of it called <mod name>.sd7 in the mods directory of spring.

An alternative, added in more recent versions is the ".SDD" folder, to use this, copy the entire <mod name> folder in the mods directory of spring and rename it as "<mod name>.SDD". The advantage to the ".SDD" method is that you can tweak settings and add files without recompressing your mod all the time. When it comes time to distribute your mod use ".sd7".

EXAMPLES:
If your mod is called JoesMod you will have a file called "JoesMod.sd7" or a folder called "JoesMod.SDD" in your spring mods directory.

==Step 11:Testing Your Mod==
Open Up your lobby client, pick your mod from the drop-down list of the games in host battle or singleplayer mode if your lobby supports it(if it doesn't show up you screwed up your modinfo.txt), choose your tiny map from the map list and press start. If it doesn't break and your unit shows up, you have created all the neccessary files... yay!

Gotchas:
*If it doesn't work, check you didn't zip the folder itself, but the contents, ie if you open mymod.sd7 with 7zip, you should see folders such as "unittextures" rather than a folder "mymod" containing unittextures.

[[Category:Mod development]]