Home
Contents |
S30
Breaking News (11-5-05): The new model format that includes UV Mapping (that means stretching textures over multiple faces instead of the 1 texture per face) and other stuff is "here"! Our "experts" are still working out the kinks of exactly how to make it all work but a 3D Studio Plug-in and a 3DO-builder-like editing tool have been released. More details are available in this thread. For now, all the other information on this page remains valid as the old 3DO format is still supported.
Introduction
So you seriously want to make units, eh? From the mighty FAQ on TAU, here's the part about how to make third party TA units. The first part of this guide is for TA, so the part about maps, ai and .gaf are irrelevant in Spring, but otherwise it's the same. For information on making a complete mod for Spring you can look at Mod Development
Creating units for Total Annihilation
Don't be afraid, seeing the number of third party mods, TA can't be that difficult to mod. First thing is to get hpiview and hpipacker. with the HPI viewer you can now have a look of what's in the .hpi, .ccx, .gp3, .ufo, etc... You'll see that a lot of information is written in plain-text files easily modifiable with Notepad. After modifying, instead of repacking, you can just put the modified file in an appropriate subfolder of your TotalA folder.
First here a few places to look for help and tutorials
- TAU Unit Discusion Forums
- TA Designers has some tutorials, and most utilities.
- A unit design guide made by Maestro And Team S.TA.R..
- Furtive Fox left long ago Well, so I assume, but his site is still up with good tutorials, but in French.
- Maestro has nice tutorials hidden on his site, such as this Texture Guide.
- Nexus was planning to do some workshop & modding classes, maybe one day it'll happen.
- FileUniverse has nearly all known utilities and tutorials, but it can be overwhelming if you don't know what you're looking for.
- M.A.D. TA also host a few utilities and tutorials.
- Storm's Ultimate Help Topic (mostly offline)
To make a complete new unit you'll need the following:
- A 3D modeling software. Rhino3D and 3ds Max are the most popular amongst TA unit makers. But lightwave, wings3d - this is getting more popular as it is free and superb for TA / Spring Modelling. Its also very good for UV wrapping and can export to format used by the new Upspring program (as said by Guessmyname), hamapatch are also used. Blender is an open source option you wont have to buy.
- 3do builder, an utility to convert 3D models (import them as .lwo) to the the TA format (.3do), and textures them: 3DO Builder 2.02, 3DO Builder .exe 2.1 update (Warning, not only the v 2.1 update don't work under WinXP/Win2k, but trying it also prevents later use of v 2.02)
- GAF Builder. .Gaf contains all the 2D graphism, such as builpics, explosions, buttons, ....
- Scriptor : to write .bos script, compile them into .cob, uncompile .cob etc... It's THE scripting program.
For your debut, or for reference, also get those help files:
- TA Design Guide : the most complete and awesome reference guide I ever saw. Explain all script functions, all weapons .tdf tags, all units .fbi tags, and much more. A must have.
- Mastreo's Weapons Reference
- Wizzball's Rhino3D modelling Tutorial
- How to script a basic tank tutorial
Lastely, if there's something you need guidance on, the most effective way is to look at the original cavedog units. For instance, if you wonder how to script a transport, run HPIViewer, open Totala1.hpi, CCdata.cxx or rev31.gp3, browse inside /unitspics/ until your find the unit you want to know more about, write its codename down (for instance, Armtship), then go into /scripts/, extract the .cob, (.bos inside totala1.hpi are rumoured to be a tad wrong, a left over from early beta maybe), have a quick glance at the /units/ .fbi to spot specific tags, then run Scriptor and use it to uncompile the .cob into a .bos and read it.
There are a lot more modding tutorials and utilities out there. Some are useless due to better ones being available. Others I just haven't tried. I tried to list thoses I really used when making my first TA unit.
What is different in Spring
- Spring doesn't like it when the weapon start velocity isn't speficied (thanks smoth!)
- First, Spring doesn't read .gaf files. So:
- All /Textures/*.gaf must be transformed into /UnitTextures/tatex/*.bmp
To unpack a bunch of *.gaf into *.bmp, the easiest way is to get GAF Dump and to run GAFDump.exe -b (use a batch file, a modified shortcut, a dos console, or whatever else to add the -b parameter and run it where you *.gaf are).
- All /Textures/*.gaf must be transformed into /UnitTextures/tatex/*.bmp
How is this done? I can't get it to work. I'm using a shortcut with a -b on the end, like this: "C:\Documents and Settings\Andrew Jones\Desktop\GAFDump\GAFDump.exe" -b
- For the Build Pic, Spring does not use the 64x64 /Anims/*.gaf. Instead Spring use the 96x96 /UnitPics/*.pcx (the one that show in TA when you press F1 on a unit). Note that the FBI tag "BuildPic" allows you to specifiy another BuilPic.
- All 2D graphics such as explosions, trees and other features aren't used. The TA gui isn't used either obviously.
- About textures, also note that animated texture, and texture with color index 1 (dark red) transparency do not work in Spring.
- The sounds 'button9.wav', 'beep4.wav', and 'beep6.wav' are always required by spring, even if no unit files reference them. They can be replaced however.
- The following files in the /gamedata/ dir are unnecessary:
- help.tdf
- los.tdf
- translate.tdf
- version.tdf
- Sidedata.tdf only requires the following data:
[SIDE0]
{
name=ARM;//if changed, they won't work with the battleroom
commander=IMPCOM;//whatever you want
}
[SIDE1]
{
name=CORE;//if changed, they won't work with the battleroom
commander=REBCOM;//whatever you want
}
[CANBUILD]
{
}
- [CANBUILD] may contain your mod's buildtree. It works just as well as .gui or /download/ .tdfs for defining your build tree. Gnome personally prefers download tdfs, but to each his own.
- Buggi's MiniSpring does not handle build menu order well at all. It completely reorganizes things for no apparent reason regardless of the build menu method used (GUI, TDF, or CANBUILD). But on other hand, it fixes build menu conflicts while regular Spring does not.
- The "Duration" tag for laser weapons doesn't seem to have an effect in spring.
- Finding laser colors in Spring is slightly difficult, as not all the OTA colors correspond to the Spring ones.
- Laser transparency can now be defined in the weapon TDF using the intensity= tag. See "What is New in Spring" below for details on using this tag.
- Spring only supports a texture space of 2048x2048 pixels, all textures combined. It's best to use base two numbers for texture sizes, and to shoot as small as possible.
- Spring doesn't seem to have a max size on models - however, the collision models suck at large scale, and 3DOBuilder can only make a groundplate (the selection square, which Gnome believes the collision sphere is based off as well) up to 256x256 TA units in size (for reference, a Stormtrooper is 1x1). Also, other units bump into the large ones easily and move them around (Gnome thinks increasing the metal cost of the large unit will stop this, however). Pathfinding for these large units also sucks.
- Groundplates don't rotate with the unit, so if a unit is rectangular and pointing north/south when it is built, its groundplate will always point N/S regardless of the unit orientation.
- Spring doesn't crash when it encounters missing features
- Spring crashes when it encounters spaces in bad places. Such places include unit short names (ARMCOM is good, ARM COM is not) and tags in FBI/TDF files (Name=Commander; is acceptable, Name = Commander; is not).
- dont-shade piecename; doesn't work in Spring.
- Air transports can easily carry more than one unit at a time, without any special scripting tricks.
- Nothing in the /guis/ folder is required if your mod doesn't depend on OTA unit build trees (like the armcom1.gui etc stuff). You can still use guis to define that stuff, but none of the ones in taenheter.ccx are needed. Not even the .FNT files are.
- get PIECE_XZ(piecname); at the very beginning of a Create() will crash Spring. Just put a little sleep before to fix that.
- Spring enjoys calling AimPrimary near constantly. That can cause problem in aiming script that are supposed to be non-instant.
- In TA a wait-for... always sleep at least one tick, even if the piece isn't moving. In Spring I think (not fully sure) it doesn't do any sleep if the piece is not moving.
- In Spring the angle passed in AimPrimary(heading,pitch) are -180° +180°, while in TA they were 0 +360°.
- In Spring player 1 commander is 4999, player 2 commander is 4998, first unit build is 4997, then 4996, regardless of side, and each unit use the same pool, counting downward. While in TA player 1 commander is 1, player 1 units are 1 to 500, player 2 commander is 501, player 2 units are 501 to 1000, etc... Adapt to your own UnitLimit, but that's the idea. Make it hard to determine whose team a unit belongs to.
- The FBI field that Spring use to determine which units are considered aircraft by the toaironly=1; and OnlyTargetCategoryX=VTOL; weapons is not TEDClass=VTOL; like TA but instead Category=... VTOL ...;
weapon areSpring doesn't use the TEDCLASS but the CATEGORY
What is new in Spring
- Units can clear down trees and wreckages.
- The pushing strenght of a unit is determined by a tag such as CrushStrength=30;
- The resistance of a feature is determined by its mass calculated by Mass=0.4*Metal+0.1*Health. Save trees which have a mass of 20.
- You can control the color intensity (how translucent the laser appears) and the width of the laser by using the following tags in the weapon's .TDF file:
- intensity=0.9; // 0.9 is the engine default. 0 from 1. This is the alpha. It's how transparent the laser is.
- thickness=2; // 2 is the engine default. Used to make thinner and thicker lasers: it's the width of the laser.
- color=x; //the color of the laser. It is the hue, in 0-225.
- color2=x; //it is supposed to the saturation of the color of the laser. But it doesn't seem to work.
- Laser can be continous with an appropriate tags in the weapon's .TDF file. The tags are:
- beamlaser=1; //boolean. Must be set to 1 to use this laser type.
- beamtime=x; //how long the beam will fire before stopping and waiting for reloadtime ticks to fire again.
- color=x; //the color of the laser beam. Standard tag for any laser type. It is the hue, in 0-225.
- Note that continuous beam laser currently discard intensity and thickness. Hopefully that'll be fixed when you'll read this.
- Plasma shots repulsor are possible. Plasma weapons include Guardians, Big Berthas, and Flak Cannons. To create a repelling shield, use these tags in the repulsor's weapon .TDF file:
- PlasmaRepulser=1;// make it a shell repulser
- RepulseEnergy=200;// how much energy it costs to repel
- RepulseForce=0.8;// how strong the repulsor is. A low value will allow high velocity shells to pierce through more easily. A value of roughly 10 is strong enough to repel flak cannon shells in conjunction with a high repulsespeed.
- RepulseRange=1000;// the area covered by the shield
- RepulseSpeed=5;// how fast shells being repulsed will travel
Even if they do no damage, repulsor weapon must have a [DAMAGE] section. Currently, the repulsor weapon seem to ignore the weapon script functions (AimFromX(..), AimX(..), QueryX(..), FireX(..)).
- To make a unit leave tracks on the map, you must add five lines to the unit's .FBI file:
- leavetracks=1; //this is a boolean. It must be '1' for tracks to work at all.
- trackwidth=x; //how wide the tracks are. '50' will give roughly the right size for a Goliath tank track.
- trackoffset=x; //this is how far forward from the middle the track should be created. Experiment with it until you can't see the track being created.
- trackstrength=x; //this is how visible the track should be and how far it should stay on the ground. Some example values could be goliath=10, bulldog=8, stumpy=6, flash=4. TrackStrength must not be greater than 10.
- trackStretch=1; //this is how far the track is stretched on the forward direction (z axis) compared to the side direction (x axis). It can probably be left at 1
- tracktype=StdTank; //this refers to a picture in bitmaps/tracks, can probably be left at stdtank if you don't want one with thinner/thicker tracks compared to the tank width or another pattern of the tracks. Inside the picture the red channel refer to the brightness and the green channel to the alpha (how visible it is) of the track. Blue channel is unused.
- Planes can be made to drop flares with FBI tags such as:
- CanDropFlare=1;
- FlareReload=5;
- FlareEfficieny=0.3;
- FlareDelay=0.3;
- FlareDropVector=0 0 -1;
- You can specify what builpic to use, with a FBI tag such as:
BuildPic=MyUnit_Spring_Special_BP.bmp;
The picture must still be put into /UnitPics/, and can be any image format currenly supported by Spring:- *.bmp (up 16 millions color)
- *.pcx (only 256 colors but custom palette accepted)
- *.jpg
- *.dds (nvdia format used by map tiles)
- Using very special transport, buildings can be moved.
- Mobile units can build others mobile units.
- No weapon ID conflict, no unit limit, not unit size limit! (But size of all combined texture limit :( )
- Units have the option to fire weapons at a high trajectory using the new HighTrajectory tag in the unit .fbi file. Use the following values when applying this tag: (0=only low, 1=only high,2=choose)
- Spring allows the use of animation interpolation which is enabled with the tag SmoothAnim=1;. It is disabled by default. It is intended to make kbot walk animations that use move-now followed by sleep commands look smoother.
It works like this: When a move-now or a turn-now command is detected, it is saved to a list of delayed animations, instead of updating the piece coordinates directly. When the script is finished, if the script finished because of a call to sleep with a 30 < sleeptime < 300, these delayed animations are translated into interpolated ones for the duration of the sleep. Otherwise the values are updated directly.
The following checks are made to make sure these interpolatations are transparent: If a move/turn on the same piece and axis is done later during the same tick, the delayed animation is commited first. Also, an interpolation is not allowed to overwrite a turn or move in progress (unless it originated from a previous interpolation), if one is running the values are updated directly instead.