Disclaimer
I take no responsibility if this software harms your computer in any way. You're
on your own from here. Do feel free to contact me, though, in case you have problems. You may freely distribute
this release as long as no fee is charged. I own all rights to WDG Explorer and its components such as this documentation.
If you want to rip something from it, you have to ask me first. WDG Explorer is a tool that can be used to open
mods made by others and use them as a base to build your own mods. This is illegal unless the author has explicitly
permitted you to do this. You may look at the contents of other peoples' wdg files for inspiration but you are
not allowed to copy any of the data without the author's permission.
The author of this program cannot be held responsible if users of this program use it to violate US or international
copyright laws.
WDG Explorer is a developer tool for creating Warzone 2100 mods. It can view and extract the contents of wdg files, so you can modify these files and put together your own wdg files using Pumpkin's MakeWDG.exe. This app is still in beta version, so don't expect too much. The user interface still has rough edges.
The "Files" tab
The "Files"
tab displays the contents of the open file. If the "Passthru entries" option is checked, passthru files are also displayed.
In that case, the files that can be extracted will be displayed in bold text.
If you are wondering why some of the filenames are a bit weird, read the Filenames
section.
The "Type"
column is used by Warzone to determine how the file is used in the game.
The "Directory" isn't really important, because there are no folders in a wdg file. It refers to the location that the Pumpkin wrf files will say it is when you recompile the file. This is stored in the Files.txt file.
On the WDG tab, information is displayed about the entire archive:
Warzone uses the internal ID to determine which files have priority.
Higher numbers will overwrite lower ones. For your own mods, the ID needs to be above Pumpkin's patches. The November
patch had ID 11. IDs can be any unsigned 32-bit integer, that means numbers from 0 to 4,294,967,295.
Maps compiled with EditWorld have an ID of 20,000. Be aware of conflicts with other mods that exist. Just picking
a high ID is no way to solve incompatibilities because they will only make other people's mods malfunction. Instruct
users to disable all other wdgs in the ModSwitcher, or wait for the ModSwitcher version that supports automatic
compatibility negotiation.
Internal name - The internal
name is a bit like the internal ID. It must not be longer than 16 characters and it's usually the same as the filename.
Changing the internal name does not have any effect in the game - it's only used to keep track of dependencies
in the "required wdgs" list.
There are some restrictions when choosing this name - stick to the characters a-Z.
IMPORTANT!!!!!!!
When making a new version of your wdg file that for some reason will be compatible with more files (master text
files used) and/or incompatible with more files (more files included), it's a good idea to change the internal
ID or the internal name. This is because the ModSwitcher's automatic compatibility negotiation feature allows mod
makers to explicitly define that their mod is compatible or incompatible with certain other mods. The way to identify
the other mod is the internal ID and the internal name. If two mods are have been defined as compatible and one
of them is in a new version that's incompatible, it is not possible to define different compatibility rules for
the two mods. So: When adding a new file to your mod, give it a different ID
The File menu
New - Option for creating a new wdg file isn't available yet. Maybe it will never be added, because it's really easy to just compile it with the MakeWDG program...
Add file(s) - Not implemented yet - same case as the New command
Extract.. - Opens the Extract dialog. Select the files you want extracted first.
The View menu
WDG Explorer can view all the passthru entries in a wdg, but it's not much use since they can't be extracted. When this is selected, the passthru entries are in normal font while the files compiled in the wdg are bold.
Turning this option on will increase performance when opening large files like warzone.wdg, but only during the opening process.
The Tools menu - I use this menu myself, but I
deactivate it for releases. It just contains tools for making Files.txt and Types.txt from some Pumpkin source
files they gave to the N.E.W.S.T. team.
The source of wdg files is contained in a directory structure before compiling, although the actual wdg doesn't contain any directory information. When you are planning to put the wdg back together again, use this option to restore the folders. If the wdg file was compiled with different folders, this option will not preserve them - they will go back to the default.
In WDG files, the file names of the source files are small hex sequences, like
a checksum on the file name. The names are not actually stored in the file, so the WDG Explorer can only find them
by looking up the hex value in a database called files.txt.
Some of the filenames cannot be converted into strings, so they are displayed as a $ followed by a hex number.
This is due to the way Warzone stores filenames. Future versions of WDG Explorer might be able to present the user
with a number of possible filenames for unknown files.
Files.txt contains all the filenames Pumpkin gave to the N.E.W.S.T. team. There are some files in the warzone.wdg
that aren't included in here. These are wrf files from the original campaign and subtitles for the videos - not
something you will need to modify. I have the filenames for these files but I just prefer to spend my spare time
developing the program rather than converting all these files - it would be an awful lot of work.
Not all hex filenames can be converted into normal filenames when they are not in the database. On map files, it
can guess the names by reading a bit from them, and on other files, it can find the extension based on a query
in the Types.txt file.
Known bugs
There are many. But since this program has a very specific purpose, I am prioritizing the engine over the user interface - which means it is pretty unpolished.
These limits are just hard-coded into the program to save memory, but they can be changed if you tell me to.
N.E.W.S.T. project and ModSwitcher
http://rtsempire.net
StrategyXtreme forums
http://strategyxtreme.com/forums
Pumpkin Studios
http://www.pumpkin.co.uk
Warzone official homepage
http://Warzone2100.com - Official
Homepage (
- still exists and is currently updated.) (
- still exists and is currently updated.)
The Hunting Grounds
http://www.geocities.com/TimesSquare/Tower/7381/index2.htm (- still exists but is not
an updated site.)
Maynard's Cyber House
http://www.iso.net/~maynard
Since WDG Explorer is in beta, you are a beta tester.
If you find any bugs, please help me sort them out.
bones0@hotmail.com
or
Bones0 on MSN Messenger
or
61422551 on ICQ
Version history (released versions in bold)
0.81 will be the only version to be released for a while. I'm busy working with the compatibility auto-negotiation feature for Sputnick's ModSwitcher.
0.81
While WDG Explorer can take WDG files apart, it can't put them back together again. This section will instruct you on how to use Pumpkin's MakeWDG program.
Like the Quake games keep their data in .pak files, Warzone 2100 uses the wdg format.
All data the game uses is contained in these files (with a few exceptions) so when you do a mod, you will have
to make files in this format. These files are compiled by the program MakeWDG.exe that comes with EditWorld - or
you can make them yourself with a hex editor if you are a nutcase and you have read Appendix C way too thoroughly
;).
The MakeWDG program reads instructions from .wrf files telling it what files to compile, where to find them and
what types they are. When it has created a wdg file, just put it into your Warzone 2100 root folder and they will
be loaded on game start.
This tutorial will teach you how to make a basic mod for Warzone. The mod will give all players VTOL trucks in multiplayer/skirmish and it will modify the text in the game menus. It assumes that you have no previous experience with moding for Warzone, but that you know how to get around in Windows files and folders.
Before you begin the tutorial, I recommend that you clean out your Warzone root
folder of anything you don't need. All wdg files that are not the Pumpkin ones (those have names like dates or
months i.e. May28.wdg or Oct.wdg, plus NewTech and NewMaps) should be renamed to .wzw. That will make the files
appear unchecked in the ModSwitcher if you use that program to launch Warzone. You can keep your maps but I recommend
you remove the mods. You can put them back afterwards and your mod might be compatible with them, but this way
you don't need to start troubleshooting when making your first wdg file.
You need to make sure that you have the contents of Warzone_wrf.zip (41 files with wrf extension). You will also
need the MakeWDG.exe program (located in your main Warzone folder after installing EditWorld), and you will also
- of course - need WDG Explorer. I recommend that you install the latest - and final - patch: v1.10. It can be
found along with EditWorld on www.pumpkin.co.uk (or rtsempire.net or warzone2100.com).
Step 2: Getting the files
Making mods for Warzone 2100 always involves extracting the source files you need
to modify, making the changes and putting them back together. The source files are extracted from Pumpkin's wdg
files with WDG Explorer, so start by launching this program.
You will need to modify the files Names.txt, Templates.txt and Strings.txt. I only know that it's these files because
I have experience with moding - if you are new, you will have to figure out pretty much yourself what each file
does - with the help of my Source Files Reference.
You will always want to get the most recent version of a source file, so when you are looking for it, start with
the latest patch (nov.wdg) and move down until you find it - if it's nowhere else, you will find it in Warzone.wdg.
Start by opening nov.wdg. There, you will find Names.txt and Templates.txt. Extract these two files to an empty
temporary folder on your hard drive - this will be the folder in which you will put the wdg together. You extract
them by selecting them (click the first one, then CTRL+click the next one) and selecting Extract from the toolbar
or the Archive menu. Choose to extract the selected files and to make subdirs - for your convenience.
To find Strings.txt you would normally have to go backwards through the patches (oct.wdg, sept30.wdg, etc...) until
you find it, but I can tell you that you will only find it in warzone.wdg. Open this file (takes a while) and extract
the Strings.txt file to the same location with the same settings as before.
Now you should have a folder on your hard drive that contains a "stats"
folder with Templates.txt and a "messages\strings" folder with Names.txt and Strings.txt.
First, we will change the menus. Open Strings.txt in Notepad or a similar program and search for the string
/* Frontend Strings */ .
You will see that below it are all the strings used in the in-game menu. The text between /* and */ are just comments
- lines that will not be read by the game. /* starts a comment and */ ends it. You can also use // to make a comment
that will last for the rest of the line it's on.
Modify any strings you like in here, but don't break anything. You may only change the text between quotes and
you must remember to leave the quotes. The six first strings on the list below
/* Frontend
Strings */ are the ones you will see in the main menu, so you can modify them to make
some more sense - or to make no sense. Save the changes when you are done.
The VTOL trucks require you to create a new unit template. Units are created with
entries in Names.txt, Templates.txt and AssignWeapons.txt, but since your unit won't have a weapon, you aren't
going to mess with AssignWeapons.txt this time.
You can start with Names.txt, which is the simplest to edit. If it's too big for Notepad, Wordpad works fine. In
this file, you will define the two names your unit will have. You can look at the other names to see what I mean.
You can type in the entry for the VTOL truck anywhere, but it's good custom to do it in the bottom of the file.
It's also a good idea to put in a comment for your mod.
You will end up with something like this:
/* Added for Tutorial Mod v1.0 */SK-VTOL-Truck "VTOL truck" |
The first name should be limited to letters A-Z, dashes, and numbers. It must not
be longer than 20 characters. This is the unique identifier of the unit and it must be called exactly the same
in Templates.txt when we get to that.
The second name is the one that will be displayed to the player. It can be just about anything.
Exit and save the changes.
Now it's time to edit the Templates.txt file. You will need to go to the bottom and append the following line:
SK-VTOL-Truck,625,Body1REC,ZNULLBRAIN,Spade1Mk1,ZNULLECM,5,V-Tol,ZNULLREPAIR,DROID,DefaultSensor1Mk1,0 |
I won't explain why this line adds a VTOL truck, but if you compare it to some
of the other lines in the file, you should see how it's made. The reason it pops up on the player's design screen
and VTOL factory screen is the player number. All number 5 templates will be available to the player.
Save and exit, and you are ready to move to the next step.
Compiling might not be the easiest part, but you only have to learn it once - it's
almost the same process every time you make a WDG.
You start by finding out what wrf files to use. Wrf is a special Warzone format that can be edited with Windows
Notepad. It describes the files that go into your WDG. You shouldn't make wrf files yourself, because the game
expects the Pumpkin ones. Create a subfolder to the temporary location you extracted the files to. Name this folder
"wrf".
Now you need to open the folder that has the contents of Warzone_wrf.zip and start looking for the right files.
Before you get the experience that tells you what wrf files to use, you will need to look for the files that contain
the filenames of the files in your mod. The easiest way is to bring up the Windows search feature and tell it to
look for all files in that folder that contain the files you have included.
Search for "*.wrf", Containing text: "Templates.txt"
This will bring up forcedit2.wrf and Stats.wrf. Since we won't be changing the force editor, just copy Stats.wrf
into your newly created wrf folder. Performing the same searches on Names.txt and Strings.txt will lead you to
frontend.wrf. Copy that one too. Use as few wrf files as possible to decrease the size of the wdg. For this tutorial
those two wrf will suffice.
Now copy the MakeWDG.exe file from your Warzone game folder to your new wdg folder.
If you don't have this program, get EditWorld (see step 1). Make sure it's not the TMLink MakeWDG.exe. It has to
be the Pumpkin one. You can tell by looking at the file icon - the TMLink has an icon, and the Pumpkin file does
not. If you don't know what I'm talking about here, never mind ;). Just copy the file.
MakeWDG needs to be called with a command line to produce anything. The easiest way to pass it this command line
every time is a .bat file. Fire up Notepad and write the following line:
MakeWDG -v -o "Tutorial.wdg" -x 50000 Tut -s 11 nov -s 0 warzone -a multiplay\maps\*.*
-a addon.lev -a wrf\multi\*.wrf -w wrf\*.wrf > result.txt |
How this works is explained elsewhere in this document, but it basically creates your wdg file and a log file you don't need to care about. Save this file with the .bat extension in your new wdg folder next to MakeWDG and everything else, then double-click it. When it's done, you will have a brand new WDG file to put in your Warzone folder. Start Warzone and the first thing you will notice is changes in the menu and everything else you have edited in the Strings.txt. Start a skirmish game and you will be able to build VTOL trucks with the right factory!
Most of the information in here requires that you have experience with WDG compiling - you can use it as a reference. Make sure you have completed the tutorial if you are new to making mods.
The concept
ModSwitcher will soon incorporate an automatic system for deciding whether two Warzone mods are compatible. Previously
(v1.0) the compatibility info was hard-coded into the exe file, which meant that a new version of ModSwitcher had
to be made with every mod. This new enhancement allows mod-makers to tell ModSwitcher which other mods they are
compatible with. If the mods do not contain this info, it is generated automatically.
The system consists of a wdg reader component that finds out what files a wdg have been compiled with, and a text
file that is put into the WDG at compile-time, which contains all the exceptions.
The WDG reader
The WDG reader will be a part of ModSwitcher from mid or late March 2000.
It looks at the list of files in the wdg (Names.txt, Functions.txt, Research.txt, etc). If two wdg files both contain
a file with the same name, they are considered incompatible. Therefore, when compiling a wdg, you should !!ONLY
INCLUDE FILES YOU HAVE CHANGED!! Including the other files will make ModSwitcher consider your mod incompatible
with just about every other mod out there, plus it will make the WDG file much bigger for no reason.
Compatible.txt
To take care of the exceptions that will come up, you can put a file with the name "compatible.txt" (case
is unimportant) into the WDG when you compile it. You must put it in a file called compatible.wrf.
This file contains information to override the decisions of the ModSwitcher's WDG reader. It is often the case
that two mods have been made with a "master text file" for Names.txt and/or some other files, and then
they've been tested to be compatible. In that case, we need to tell the WDG reader that the two files go together.
In other cases, we may have a mod (for example a single player challenge map) that is designed to be played with
the unmodified Warzone game. This map will have all other mods deactivated. The compatible.txt is a plain ANSI
file that follows this format:
<type: 0=auto, 1=all, 2=none>
<+ or - : compatible or incompatible> <IntID> <IntName>
<+/-> <IntID2...> <IntName2...>
desc
<Description goes here.>
<It can be multiline, and it will continue for the rest of the compatible.txt file.>
The first line is the "type of compatibility". It specifies the base that the compatibility list will be constructed from. It can have the three following values:
0 = The WDG reader will automatically detect compatibility.
1 = It is compatible with all other files
2 = It is compatible with no other files
Apart from this value, you can list below the mods that this file is known to be
compatible or incompatible with. These lines start with a + or -, specifying respectively whether the mod is explicitly
defined as compatible or incompatible with your wdg. Of course, it makes no sense putting + lines in a type 1,
or - lines in a type 2. Such lines will be ignored.
Next is the internal ID and the internal name of the mod in question. Note that the internal name is
not the same as the filename. You can find the internal name and ID of any file
using the WDG Explorer.
You can not use wildcards (like Citadel*), so if you have to type in all versions of a mod if they have different
IDs or names. This is to make sure mod-makers don't just take the easy way and end up making their mod incompatible
with mods that they would otherwise be compatible with.
The description must always have "desc" on the line before it, then
you can type anything
This will be the description shown in the ModSwitcher when the player highlights the mod, so you should start it with one or two simple lines like: "This mod will enable scavenger tech for multiplayer and skirmish". After that, you can make the file just about as big as you want it, describing the mod in detail. Just keep in mind that the player might be browsing through 20 mods when going past yours, so it should start out by getting to the point.
Example:
0+ 76 AllMyMaps+ 77 AllMyMaps- 999999 CitadeldescThis is a sample description |
The compatible.wrf would look like
/* * Compatible.wrf * * Compatibility information for ModSwitcher * */directory ""file MISCDATA "compatible.txt" |
The ability to use this file allows mod-makers to release mods that are easy to
use without the user having to guess what mods can work together, or read a huge readme to get it all working.
It also demands a certain standard from mod authors. Any mod released publicly will be expected to have been tested
with most mods available, so Warzone won't crash or give error messages when using mods together.
MakeWDG is usually called with the command line I wrote in the tutorial:
MakeWDG -v -o "MyMod.wdg" -x 50000 MyMod -s 11 nov -s 0 warzone -a multiplay\maps\*.*
-a addon.lev -a wrf\multi\*.wrf -w wrf\*.wrf > result.txt |
If you, like Pumpkin did, have the source files in their own subfolder such as "data", use this batch file:
@cd "data"..\makewdg -v -o "..\MyMod.wdg" -x 50000 MyMod -s 11 nov -s 0 warzone -a
multiplay\maps\*.* -a addon.lev -a wrf\multi\*.wrf -w wrf\*.wrf >
..\result.txt |
The program makes a wdg.tmp file that is safe to delete. I like to put that command at the end of the batch file:
@del wdg.tmp |
The @ before commands just means that they are not shown in the DOS window.
The command line breaks down in some sections:
|
-v |
Run verbosely. It gives details as it compiles. Optional. You don't need this but it's very handy when finding out what went wrong during a compile |
|
-o |
Sets the output filename. You will obviously want to change this. |
|
-x |
Names the new wdg internally. Read the WDG Tab section in the program documentation for more info on the ID and the name. |
|
-s |
Specifies the files it needs to run. Use this to require a certain patch in order to run.
If the specified file is not present, the user will get an error message when launching the game. In the example
I required the 1.10 patch that comes with the file nov.wdg. Note that this is not the filename but the internal ID and name. Case is important. Be careful when requiring another mod to be installed. If the gamer has a new version of that mod, it might have a higher ID than the one you required and then Warzone won't launch with your mod. |
|
-a |
Compiles miscellaneous data into the wdg. This is mostly used when adding maps, since you probably won't be changing the game script loaders found in wrf\Multi. Even if your mod doesn't add maps, you can just leave the argument there - it does no harm :). |
|
-w |
States the wrfs to compile. There's really no reason to change this, unless you name your wrf folder something else. |
|
> |
Writes the outputs generated by -v to the filename specified so that you can review any errors produced. |
Much of this information was ripped from Skorpion's inactive Warzone site. Thanks :)
In addition to plaintext files, Warzone also uses these 3 formats its own way:
These are image files that can be edited with any imaging program
such as Paint Shop Pro or Photoshop.
In Warzone, the files must be 256-color with a special palette. I saved the palette as a .pal file and put it in
the WDG Explorer folder so you can use it to create Warzone bitmaps. If you know how, you can extract the palette
from any of the pcx files found in Warzone WDGs.
These are normal Windows sound files that can be saved with all
sound programs.
All files must be PCM 22050 Hz, 16 Bit, Mono. When adding new waves to be played from script, you will also need
to give them an entry in audio.cfg. This file contains information on its format so I won't describe it here.
This is a special graphics format used by Warzone. The N.E.W.S.T. team asked Pumpkin's Alex about this format and here is his answer - the way the format is built:
PIE 2 // Just the type - always type 2 I think
TYPE 200 // What type the pie file is, must be one of the following - not all are supported - look
// at existing files to see ones in use:- (Numbers are in hex)
Textured 0x200
Textured Animating 0x4000
Textured (with PSX methods) 0x8000
Made by the bsp tool (for software sorting) 0x10000
Mostly, they're all type 200
TEXTURE 0 page-whatever 256 x 256 // What texture page it uses and how big it is.
LEVELS 1 // keep this at one - other levels aren't changeable by you without source (altered state objects).
LEVEL 1 // start of description for level one
POINTS 4 // How many vertices it has
-131 0 -131 // the vertices themselves - this shape is a square (one axis invariant)
131 0 -131 //
131 0 131 //
-131 0 131 //
POLYGONS 1 // How many polygons (one here - the square, 4 points)
200 4 3 2 1 0 0 0 129 0 129 129 0 129
First number is polygon type, one of:-
FLAT SHADED 0x100
TEXTURED 0x200
WIREFRAME 0x400
TRANSPARENT 0x800
GOURAUD 0x1000
NO CULL 0x2000
OUTLINE 0x4000
FIXED_VIEW (ignore) 0x8000
Next number describes how many points ply has (4) and next (in this case 4, namely 3 2 1 0) numbers are the vertices
that make up the poly. If it were a triangle the second number would be 3 and there would only be 3 numbers describing
the vertices. The next (in this case 8) numbers are the texture coordinates.
Some PIEs have connectors - you cannot use these - they are for weapon mounts only - again you'd need source...:-(
Animation files you can attach to pie files. How about making a
cyborg dance :)
The format is outlined in the Pumpkin ani files. These are plaintext files that can be edited with Windows Notepad.
Requires some experimentation to get an animation right...
The wrf files you use to compile your mods are also stored in the WDG, but in a
special binary format. See Appendix C, section 6 if you are really curious. The wrf files tell Warzone which files
to load at certain parts of the game. The filenames of these wrf files are hard-coded into the engine, so you should
not make wrf files with your own names, just use the Pumpkin ones.
So when the game starts it will load the files in frontend.wrf, when you start the force editor it will load forcedit2.wrf
and so on. You can't really tell excactly when the different wrf are loaded, just experiment. Some files are mentioned
in more than one wrf. The Templates.txt, for example, is both in stats.wrf and forcedit2.wrf. If you make a mod
like the one from the tutorial that just changed the in-game templates, you don't need to mess with the force editor.
If you, on the other hand, made a mod that put some custom units in the force editor, you would need to load that
unit in both wrf because it would be in the game and the force
editor.
Always use as few wrf files as possible, because if the file is mentioned in two wrfs, it will be written twice
in the wdg, taking up much more space than with one file. Also, you should only include the files you have actually
modified. This is both to preserve space and to ensure compatibility with other
mods.
Even though you are not including all the files that are mentioned in the wrf
you use, you should not remove entries from wrf files. The game expects these files to be there, and when they
are missing it will look for them in subfolders to the game folder. This can be useful when you want to place a
file in your Warzone folder for editing. The folders it will look in are the same folders that are mentioned in
the wrf, so if Weapons.txt is missing, it will look for "your WZ folder\stats\Weapons.txt". There is
just the problem that when you remove a file from a wrf, it will screw up all the files that come after it. You
will also need to put those files in your WZ folder, unless you figure out how to just play with one line... tell
me!
You can add new files to wrfs no problem. Just remember to put it in the right wrf, so it goes into memory at the right time - for instance don't put .txt files in vidmem.wrf, because it will be put in the user's video memory.
This section describes what the syntax of the source files you will need to edit. I can't add all the files at once, so please be patient - I add new files when I have time.
This file describes all weapons in the game, both those on your units, on your hardpoints, and on the scavengers.
The format is:
WeaponName, techLevel, buildPower, buildPoints, weight, hitPoints, systemPoints, body, GfxFile, mountGfx, muzzleGfx,
flightGfx, hitGfx, missGfx, waterGfx, trailGfx, shortRange, longRange, shortHit, longHit, firePause, numExplosions,
numRounds, reloadTime, damage, radius, radiusHit, radiusDamage, incenTime, incenDamage, incenRadius, directLife,
radiusLife, flightSpeed, indirectHeight, fireOnMove, weaponClass, weaponSubClass, movement, weaponEffect, rotate,
maxElevation, minElevation, facePlayer, faceInFlight, recoilValue, minRange,
lightWorld, effectSize, surfaceToAir, numAttackRuns, designable
|
WeaponName |
Component Name found in Names.txt and all other files that refer to this weapon. This is the Name ID format. You choose this name yourself when making a new weapon. |
|
techLevel |
Technology level of the component |
|
buildPower |
Power required to build the component |
|
buildPoints |
Time modifier for building the component |
|
weight |
Component's weight |
|
hitPoints |
Component's hit points. This is usually 1. |
|
systemPoints |
Space the component takes in the droid (NOT USED) |
|
body |
Component's body points - how strong it is. |
|
GfxFile |
The PIE to draw for this component (can be zero) |
|
mountGfx |
The turret mount to use (can be zero) |
|
muzzleGfx |
The muzzle flash |
|
flightGfx |
The ammo in flight |
|
hitGfx |
The ammo hitting a target |
|
missGfx |
The ammo missing a target |
|
waterGfx |
The ammo hitting water |
|
trailGfx |
The trail used for in flight (can be zero) |
|
shortRange |
Max distance to target for short range shot. In world units. |
|
longRange |
Max distance to target for long range shot In world units. |
|
shortHit |
Chance to hit at short range (0-100) |
|
longHit |
Chance to hit at long range (0-100) |
|
firePause |
Time between each weapon fire |
|
numExplosions |
The number of explosions per shot |
|
numRounds |
The number of rounds per salvo |
|
reloadTime |
Time to reload the round of ammo (salvo fire) |
|
damage |
How much damage the weapon causes |
|
radius |
Basic blast radius of weapon |
|
radiusHit |
Chance to hit in the blast radius (0-100) |
|
radiusDamage |
Damage done in the blast radius |
|
incenTime |
The time the round burns |
|
incenDamage |
Damage done each burn cycle |
|
incenRadius |
Burn radius of the round |
|
directLife |
How long a direct fire weapon is visible |
|
radiusLife |
How long a blast radius is visible |
|
flightSpeed |
speed ammo travels at |
|
indirectHeight |
how high the ammo travels for indirect fire |
|
fireOnMove |
indicates whether the droid has to stop before firing (NO/YES/PARTIAL) |
|
weaponClass |
the class of weapon - (KINETIC/EXPLOSIVE/HEAT/MISC) |
|
weaponSubClass |
the subclass to which the weapon belongs (CANNON/MORTARS/MISSILE/ROCKET/ ENERGY/GAUSS/FLAME/HOWITZERS/ MACHINE GUN/ELECTRONIC/A-A GUN/SLOW MISSILE/ SLOW ROCKET/LAS_SAT/BOMB/COMMAND/EMP) This associates it with the upgrades available in Functions.txt |
|
movement |
which projectile model to use for the bullet (DIRECT/INDIRECT/HOMING-DIRECT/ HOMING-INDIRECT/ERRATIC-DIRECT/SWEEP) |
|
weaponEffect |
which type of warhead is associated with the weapon (ANTI PERSONNEL/ANTI TANK/ BUNKER BUSTER/ARTILLERY ROUND/FLAMER/ANTI AIRCRAFT) This changes the damage it does to different propulsions and structures - see WeaponModifier.txt and StructureModifier.txt |
|
rotate |
amount the weapon(turret) can rotate 0 = none, 180 = all the way |
|
maxElevation |
max amount the turret can be elevated up (in degrees) |
|
minElevation |
min amount the turret can be elevated down (in degrees) |
|
facePlayer |
flag to make the (explosion) effect face the player when drawn (YES/NO) |
|
faceInFlight |
flag to make the inflight effect face the player when drawn (YES/NO) |
|
recoilValue |
used to compare with weight to see if recoils or not |
|
minRange |
Min distance to target for shot |
|
lightWorld |
flag to indicate whether the effect lights up the world (YES/NO) |
|
effectSize |
size of the effect 100 = normal, 50 = half etc |
|
surfaceToAir |
indicates how good in the air (0 = SHOOT_ON_GROUND, <= 50 = SHOOT_IN_AIR, >=51 = BOTH) |
|
numAttackRuns |
number of attack runs a VTOL droid can do with this weapon |
|
designable |
flag to indicate whether this component can be used in the design screen (0=FALSE, 1=TRUE) |
Refers to: WeaponModifier.txt/StructureModifier.txt
Referred to in: assignWeapons.txt, StructureWeapons.txt, WeaponSounds.txt, Research.txt, ResultComponent.txt, RedComponents.txt,
Names.txt
This file describes all bodies used in the game, including those for cyborgs and scavengers
The format is:
BodyName,techLevel,bodySize,buildPower,buildPoints,weight,bodyPoints,GfxFile,systemPoints,weaponSlots,powerOutput,kineticArmor,heatArmour,flameIMD,
designable
|
BodyName |
Component Name found in Names.txt and all other files that refer to this body. This is the Name ID format. You choose this name yourself when making a new body. |
|
techLevel |
Technology level of the component |
|
bodySize |
This can be LIGHT, MEDIUM, HEAVY or SUPER HEAVY. |
|
buildPower |
Power required to build the component |
|
buildPoints |
Time modifier for building the component |
|
weight |
Component's weight. Makes it slower. |
|
bodyPoints |
Component's body points - how strong it is. |
|
GfxFile |
The PIE to draw for this component |
|
systemPoints |
Space the component takes in the droid (NOT USED) |
|
weaponSlots |
Increasing this will make a body able to carry more than one weapon... if the engine supports
it, since they didn't use it in the game. You should also be able to make a body with no weapons... again, I haven't tried this... |
|
powerOutput |
The engine horsepower. Increase it to make a heavy body faster. |
|
kineticArmor |
Resistance to normal weapons, like bullets |
|
heatArmour |
Resistance to burning weapons |
|
flameIMD |
The .pie graphics file that will be rendered when the body is hit or burning. |
|
designable |
1 means that you can use it on the design screen, 0 means that you can not. |
Refers to: - none -
Referred to in: Templates.txt, BodyPropulsionIMD.txt, Research.txt, ResultComponent.txt, RedComponents.txt, Names.txt
Propulsion.txt
All propulsions used in the game, even legs for cyborgs and scavengers
The format is:
PropulsionName,techLevel,buildPower,buildPoints,weight,hitPoints,systemPoints,bodyPoints,GfxFile,Type,MaxSpeed,designable
|
PropulsionName |
Component Name found in Names.txt and all other files that refer to this propulsion. This is the Name ID format. You choose this name yourself when making a new propulsion. |
|
techLevel |
Technology level of the component |
|
buildPower |
Power required to build the component |
|
buildPoints |
Time modifier for building the component |
|
weight |
Component's weight. Makes it slower. |
|
hitPoints |
This is 1 for ground propulsions and 0 for VTOLs |
|
systemPoints |
Space the component takes in the droid (NOT USED) |
|
bodyPoints |
Component's body points - how strong it is. |
|
GfxFile |
The PIE to draw for this component |
|
Type |
The type of propulsion as found in PropulsionType.txt |
|
MaxSpeed |
Speed value |
|
designable |
1 means yes, 0 means no. |
Refers to: PropulsionType.txt
Referred to in: Templates.txt, BodyPropulsionIMD.txt, Research.txt, ResultComponent.txt, RedComponents.txt, Names.txt
Since bodies have different sizes, a propulsion can be assigned a graphics file
for each body - so tracks will look different on the Vengeance and the Bug.
There must be a line here for each possible combination of body and propulsion, or else the propulsion will be
invisible in the game (like with the VTOL/Scorpion combination in the latest patches).
The format is:
BodyName,PropulsionName,leftGfx,rightGfx,ID
|
BodyName |
The component name of the body as found in Body.txt |
|
PropulsionName |
The component name of the propulsion as found in Propulsion.txt |
|
leftGfx |
The graphics file to render for the left leg/wheel/whatever. |
|
rightGfx |
The graphics file to render for the right leg/wheel/whatever. This can be 0 if the left propulsion takes up all the space (like on Hover). |
|
ID |
A unique ID for this body/propulsion combination. Just make one up if you are making your own new entries. |
Refers to: Body.txt, Propulsion.txt
Referred to in: - none -
Contains info on the different classes of propulsion
The format is
PropulsionType,GroundFlag,PowerRatio
|
PropulsionType |
The name of the propulsion type |
|
GroundFlag |
This can be either GROUND or AIR, indicating if it's flying |
|
PowerRatio |
The Power Ratio Modifier here works together with the body's power output to make a vehicle fast. higher numbers are faster. |
Refers to: - none -
Referred to in: Propulsion.txt, PropulsionSounds.txt, TerrainTable.txt
This table controls how fast different propulsions move over different terrain types
The format is:
TerrainType,PropulsionType,SpeedFactor
|
TerrainType |
This is a number that belongs to a specific terrain surface in EditWorld. Possible values
are: 0 = SAND 1 = SANDY BRUSH 2 = BAKED EARTH 3 = GREEN MUD 4 = RED BRUSH 5 = PINK ROCK 6 = ROAD 7 = WATER 8 = CLIFF FACE 9 = RUBBLE 10 = SHEET ICE 11 = SLUSH |
|
PropulsionType |
This matches an entry in PropulsionType.txt. It's a number, not a text string. It refers
to the entry you get in PropulsionType.txt if you count from the top, starting with 0. So Wheeled is 0, Tracked is 1, Jump is 8, etc. |
|
SpeedFactor |
Modifies how fast the propulsion goes over the terrain type. |
Refers to: PropulsionType.txt
Referred to in: - none -
This file contains all the pre-built templates (droid designs) that will be used in the game for both campaign and skirmish
The format is:
DroidName,DroidID,Body,Brain,Construction,ECM,PlayerID,Prop,Repair,DroidType,Sensor,TotalWeapons
|
DroidName |
Pick a name, any name. Just make sure to keep it consistent in all files that refer to this template. |
|
DroidID |
Unique ID number for the droid. It doesn't really matter what you type here. |
|
Body |
The component name of the body as found in Body.txt. Default=ZNULLBODY |
|
Brain |
The name of the brain as found in Brain.txt. This only applies to commanders. Default=ZNULLBRAIN |
|
Construction |
The name of the construction unit as found in Construction.txt. Default=ZNULLCONSTRUCT |
|
ECM |
Name of ECM as found in ECM.txt. This is not used for droids - only for the repair center. Default=ZNULLECM |
|
PlayerID |
The player number - from 0 to 7 |
|
Prop |
The component name of the propulsion as found in Propulsion.txt |
|
Repair |
The repair turret (if there is one). Found in Repair.txt |
|
DroidType |
This can be DROID, PERSON, CYBORG, TRANSPORTER, CYBORG_SUPER, CYBORG_CONSTRUCT or CYBORG_REPAIR. Default=ZNULLDROID |
|
Sensor |
Found in Sensor.txt. Default=ZNULLSENSOR. For normal non-sensor droids use DefaultSensor1Mk1 |
|
TotalWeapons |
The number of weapons (not repair turrets, spades etc.) on the droid. This can be more than 1 if the body supports it. |
Refers to: Body.txt, Brain.txt, Construction.txt, ECM.txt, Propulsion.txt, Repair.txt,
Sensor.txt
Referred to in: AssignWeapons.txt, Names.txt
The files contain many standards that are underlined in this document. Clicking them brings you to the right topic here
Some (but not all) files can contain comments. If you know Java(Script) or C(++),
you already know how to use comments. If not, read on...
To make lines inactive, or to embed small explanations that clarify your code, use comments. They can be either
one-line comments, where you type // and the rest of the line will be ignored, or multi-line comments where you
type /* and everything will be ignored until a */ statement is encountered.
To connect the units and components between the different stat txt files, each
one must have a name ID. This is a string that is unique for the unit. It mustn't be longer than 20 characters,
and it can only consist of letters (a-Z), numbers (0-9) and dashes (-).
I don't really know if it's case sensitive so just keep the case, or try it and write me a mail telling me if it's
case sensitive or not...
This represents the tech level of a component. It can have one of the following
values:
Level One, Level Two, Level Three, Level One-Two, Level Two-Three, Level All
When used in stats, this has nothing to do with multi-player and skirmish. In fact,
there is really no reason to call it player number - it's more of a player type ...
It can have the following values:
| 0 | Special units and cyborgs from the campaign |
| 1 | New Paradigm vehicles |
| 2 | The Collective vehicles |
| 3 | Nexus vehicles |
| 4 | Force Editor vehicles |
| 5 | Designs available to the player in Multi-player (though some must be researched first) |
| 6 | Skirmish templates for the AI |
| 7 | Scavenger vehicles |
All times are in 1/100th of a second, except for those in scripts (.slo/.vlo), they are 1/10 sec.
128 world units is one square on the map.
This section explains how a WDG file is built when you look at its hex values.
It assumes that you are familiar with hex editing and it is primarily intended for application developers who want
to make apps that access WDG files.
In this document, 0x before a number means that it is hex. So 0x14 is 20 as decimal.
Offset values start counting from 0x0, so the byte at offset 0x4 is the fifth byte in the file.
Most numbers in the wdg are unsigned long integers - 4 bytes. As in most binary files, the bytes are reversed when
they are stored, so for example the value 0xa56f3c1 is actually stored as C1F3560A. If you use a hex editor to
take the WDG files apart, you will want to look for the C1F3560A number.
Names
MakeWDG converts file names to 3.5-byte (the last nipple is always 0) hex sequences,
like a checksum on the file name. The names are not actually stored in the file, so the WDG Explorer can only find
them by looking up the hex value in a database. They are reversed, like the numbers. A name like "IMGPAGE"
would be converted to e1c45f5 and stored as F5451C0E.
I've been trying to make sense of those codes for a while and it seems that MakeWDG starts out by converting all
characters to lower-case. It then converts them to hex values and subtracts 0x20 from them. It then runs through
them from right to left and puts the nipples (a nipple is 4 bits - one hex digit) in groups of two. These are all
added, creating the checksum.
When there is more than six characters, some of the nipples aren't in the checksum - I haven't completely figured
the system out yet. The left-most nipple and the right-most nipple are never in a group - they can be extracted
intact from the WDG.
I will write something more detailed on this when I figure it out.
The WDG file's sections
This describes the function of every single byte in a WDG file.
The first 4 bytes say WDG5.
In warzone.wdg they say WDG4 and the sections 3 and 4 are missing.
The number at 0x4 expresses the number of wrf files used to compile this wdg.
0x10 bytes from offset 0x8 contain the internal name as ASCII. The characters not
used by the name have 0x0 values.
The internal ID is stored at 0x18.
The number at 0x1C says how many WDGs are required.
From 0x20 the names and IDs of the wdg files required are stored in 0x14 byte sequences:
| Name: | 0x10 bytes, stored as in section 3 | |
| ID: | 0x4 bytes |
| Name: | 0x4 bytes | |
| Offset: | 0x4 bytes, the byte offset in the wdg file where the files from this wrf are listed | |
| File count: | 0x4 bytes, the number of file entries in the wrf file, including passthru entries |
The number of wrf files was in section 2.
It usually ends with a MISCDATA entry although no such wrf was used. This is used for maps.
That concludes the header of the WDG
Section 6: File list
There's a file list for each wrf used. It's position and length can be found in section 5. Each entry is a 0x14 byte sequence:
| Type: | 0x4 bytes, the type of the file as defined in the wrf when compiling. This is the CRC-style format. | |
| Filename: | 0x4 bytes | |
| Offset: | 0x4 bytes, the byte offset of the file in the section 7 data block. This is 0xFFFFFFFF for passthru entries. | |
| File size: | 0x4 bytes, this is the file's size in bytes + 1. The extra byte is there because MakeWDG appends a byte with the value 0x0 to the end of each file. This is 0xFFFFFFFF for passthru entries. | |
| Software flag: | 0x1 byte, special entry for some texpages. There are three possible values: 0x2 (hardware), 0x1 (software), and 0x0 (N/A). For the in-game graphics, there are two sets: one with transparencies and one without. This is probably read in the filename by MakeWDG, as all hardware entries have "hard" in their file name and all software entries have "soft". This is set even on pass-thru entries. | |
| Texture page: | 0x1 byte, a unique ID of the texture page. This is a number used by all texpages where the filename starts with page-xx. Two texpages can have the same number if their software flag is different. Like the software flag, MakeWDG reads this attribute from the filename. On non-texpages it's 0xFF. This is set even on pass-thru entries. | |
| End: | 0x2 bytes, this is always 0x0000 |
Section 7: File data
The raw data contained in each file is contained here, completely intact -- except
that there's an extra 0x0 byte at the end of each file.
Like section 6, the data is grouped with each wrf file.
After each section 7 there's a section 6, again followed by a section 7, until the last wrf.
A simple wdg file could be constructed like this:
Section 1
Section 2
Section 3
Section 4
Section 4
Section 4
Section 5
Section 5
Section 6
Section 6
Section 6
Section 7
Section 7
Section 7
Section 6
Section 6
Section 7
Section