SWAT3 modding best practices

Too many mods cause unnecessary conflicts, cause have unnecessary dependencies or "just don't feel right" in some way. In this article I want to suggest some guidelines for modders that can help avoid complications when the mod is released.

The ideas are not presented in any order, except that the first is by far and away the most important!

Never ever make two mods with the same name

You'd be amazed at the amount of problems people have joining someone else's game because of a mod or mission mismatch when both players have the same files.

Only they don't. Because player A downloaded überbadass.zip last week but player B got the latest release (with the same filename) just today.

If you make ANY change whatsoever to a mod that's publically available, release the next version with a different filename. Even if you only change one file, even if you think no one had chance to download the old version before you put out the update, upload überbadassV2.zip or some other unique name. My preferred strategy is to call my mods mod-1.0.zip, mod-1.1.zip and so on. Use whatever works for you but NEVER reuse filenames for mods.

Always zip your mods inside a base directory

Instead of zipping all your files into one zip, place them all into a directory and zip that. If you use WinZip 8 you can right-click on the directory containing all the files and choose "Add to zip" to archive the whole lot in one go very easily.

The advantage to doing this is that it's cleaner and easier to manage. If someone wants to open up the mod to check out the documentation or study how you did the data files, he doesn't have to remember to create a directory for all the files himself. Furthermore, if your zip has the same name as the directory contained within it (plus the .zip extension of course) then those people who unzip the mod will (theoretically) remain compatible with those who do not.

Include a README

You should include a README.txt file inside your mod giving details on who you are, where to contact you and what your mod does. In the current climate it is also very prudent to state if you used parts of other people's mods, giving credit to them for their work and confirming that you obtained their permission. If your mod is original, do everyone a favour and mention very clearly whether or not you will allow people to reuse your work and on what conditions.

Do not reuse filenames

Though not as frustrating as giving your mod the same name as another which already exists, editing files without changing their names is still a major annoyance.

If you reskin an officer model by editing (say) SWT_VEST2.bmp, your modified vest will show up for ALL characters that use that image, not just your new one.

You should rename the file to something unique, use either the gsmhacking program or a hex editor to modify your model to reference the new filename and then rename the model as well. At the cost of a very slightly larger mod you will have eliminated possible conflicts with other mods.

Failure to follow this basic rule is even more damaging when it is maps, not mods, that are at fault. The Trailer Park and Safeguard maps are two very nice levels that you won't see anyone playing online. This is because their authors reused texture names from Sierra maps, causing the game to crash when the Sierra missions are played. As a result, newbies complaining about such crashes are simply told "Delete those two maps" and their authors' work has effectively been wasted.

Do not create artificial dependencies

Imagine your new officer model uses the Agent skins from Sierra's Agent Pack. Imagine also that you made a new face for the character and (following the advice in the previous paragraph) renamed the face bitmap. The rest of the model's textures - the suit, shades and shoes - don't need to be altered but if you leave the model as it is you force people to activate the Agent Pack to be able to use your mod.

If you really haven't modified the other files you could include them in the mod. This is better than nothing but still leaves the mod open to conflicts. The ideal solution is to rename the (unedited) files and hack the GSM.

Add to data files, don't replace them

The way SWAT3 handles mod data files is quite simple. When the game starts up it loads parameters from .dat files in the game directory. For example, the guns.dat file lists weapons available in the game. If the games finds a file called modguns.dat in a mod, it will add the guns listed in that file to its table of weapons. If however it finds a file simply called modguns.dat, it will replace the existing weapons table.

Sometimes this is what you want but ninety-nine times out of a hundred it certainly is not. By eliminating existing game data you create the possibility that the game will crash (because the engine expects to find settings which are not there) or that other mods will not work as expected.

Use modXXX.dat (or missionXXX.dat for missions) unless it is absolutely unavoidable.

Don't be lazy

So your new "deathmatch" skin looks great and, well, it doesn't matter if you can only use it DM or TDM because it wasn't really meant for co-op and ... yadda yadda yadda.

You add one line and the skin can be used in all game types.

Don't forget the UI and debrief shots for officers.

Don't forget the weapon preview, reticles and status icons for weapons.

Tidy up your mod before release

Before zipping up the mod and uploading it, check for any redundant files. Paint Shop Pro thumbnail files, that backup you made of the data file just before you changed a chunk of it, empty directories, the original Sierra bitmap that you later copied and edited; none of these things have any place in your mod.

Don't distribute your mod or map as an executable

SWAT3 data files are contained in zip archives. An executable that "installs" the actual zip is neither big nor clever.

Feedback

Send any comments to swat3@furrycat.net.