Afterlight modding tips, where to find stuff, hints, how-to, etc. Options

[ShadoWarrior]

SECTION I: GENERAL INFORMATION ON AFTERLIGHT MODDING
The tools that you can use to browse the contents of the Aftershock data files can be used for Afterlight. They can be found at StrategyCore. (direct links to them are in the Aftershock modding guide mentioned below)

A good starting place to learning how to mod Afterlight is ShadoWarrior's Guide to Modding Aftershock for Beginners.

I also recommend that you read Rising Phoenix's Anatomy of a Weapon text file.

Those of you who are modelers are advised to check out the MEAAOV UFO EDIT utility.

ALTAR has provided a BIN-to-TXT tool to convert a file format from binary to text and backwards. Useful for modding 3D models in the game. Documentation describing and explaining the structure of game configuration files, their values and variables is also available. Both the tool and the docs can be obtained from ALTAR's official Afterlight site, on the Fans page.

Afterlight's game data files are spread across 4 files:

• gamedata.vfs 317 MB (332.664.956 bytes) - contains data and config info.
• mod_gamedata_local.vfs 229 MB (240.602.172 bytes) - contains fonts and sound files.
• mod_gamedata_scenes_1.vfs 1,13 GB (1.222.639.500 bytes) - contains maps.
• mod_gamedata_scenes_2.vfs 908 MB (952.662.388 bytes) - contains maps.

total folder size: 2,58 GB (2.780.180.004 bytes)

Almost all the important stuff (modding-wise) is in gamedata.vfs. Text descriptions for all text displayed within the game can be found in pack.txt within the game's LocalizationPack.vfs file. As with most things in Afterlight, the contents of pack.txt and other game data files is markedly different than it was in Aftershock. To the best of my knowledge, no mods for Aftershock will work for Afterlight, and some of the things that were done for Aftershock cannot even be done for Afterlight. While ALTAR did export much more of what used to be internal code in Aftershock, some other things they decided to hard-code. (I suspect because they didn't want modders touching those things like we did for Aftershock.)

SECTION II: WHERE TO FIND STUFF

• In directory \game\scripts\strategic is a script file called newgame.lua which contains some startup parameters for new games. If you want to change which people begin in which bays/shops/labs, change them in local function HumansInBaseInit(). Who has what gear at the beginning can be changed in local function SquadInit().

SECTION III: TIPS
There is a problem with removing or renaming some attributes in configurations files. In addition there are usually problems with adding new instances of:

• EffectType.name
• VisiblityType.name
• MovementType.name
• EquipType.name
• Situation.name
• Material.name
• SniperTarget.hitEffectType
• Weapon.handlingType
• Race.name
• Subrace.name
• TutorialWindow.name

• DmgType.name ... do not change but you can add new one
• WeaponMode.name ... do not change but you can add new one
• EnemyUnitType.name ... do not change but you can add new one
• EquipHandlingGroup.name ... do not change but you can add new one
• TegnologyOriginType.name ... do not change but you can add new one

This thread will remain closed so that it doesn't get cluttered up by Q&A.
PM me with hints or questions, or ask them in other threads, and I'll update this thread as appropriate.

This post has been edited by ShadoWarrior: Feb 22 2007, 08:29 PM

[TYR]

Hello and welcome to my first tutorial for AL.

Please note that this is an intermediate level tutorial, it is highly recommended that you do the basics first before you start this.

For Vfstool handling check out Shadowarrior's tutorial and Afterlight Modding Tips FIRST.

If you are already familiar with the Vfstool and the basic file structure handling you may proceed as I do not want to answer unnecessary questions like "how does the meshexporter work". I will describe it shortly but if you have troubles as I said there are basic descriptions available already so I will concentrate on the further steps.

How to export a model and why we need it

Okay so let's start right away. I assume you extracted the gamedata.vfs already and have stored it in a separate folder. We call this folder EX-Folder here. In this folder you should have placed the meshconverter tool, which has been provided kindly by ALTAR. You can download it here.

To have the meshconverter work properly, you have to have it in your ex-folder as it will fail to convert the file you want to extract properly if not. Note that on some files you will have to have the scenes.vfs folders extracted as well, this counts for all items that store further data like animations, including aliens, humans, and even some special weapons which have their own animation like the "bossgun" or the gatlingun.

Now let's convert a model and I will tell you why we need it. You can either convert files manually or use the binconverter, or the tool written by stucuk implemented in his ufo editor package. I rather do it manually though, it's more fun that way and besides I want you guys to learn it so you better do it manually

So let's pick a model we want to export, they are stored under items\models in your ex-folder. I already have selected a model for you so don't bother with it, let's start our command console window application via start cmd. Switch to your ex-folder and convert the file with meshconverter bt items\models\wu_h_ancient_rifle.txt ancient-rifle-ex.txt .

This will extract the file we have specified and adds it to our ex-folder under the given name ancient-rifle-ex.
Here's an important note: Think of a proper naming in advance and stick to it. I call my extracted files always with an -ex and my import files with an -imp, so I will know later what it is because we will mess up the ex-folder pretty quick but more on it later.

Now we have converted the binary file into a textfile. Just leave it where it is now, although you can view it in the ufo editor, or convert it there to .obj format to view or modify it in a 3d tool. Note that it is not supported yet to save files properly with ufo edit yet, (saving only works from obj. -> textfile direction) it will screw up the data, and therefor reconverting the file to bin format will fail! Instead we do the "Bodysnaptrick" as I call it.

The BODYSNAP trick

I assume you already made your own model ? If not we can modify an existing one, however we cannot export/import it directly, instead we have to use an existing converted modelfile as a body. UFOEDIT only supports .obj format atm so you have to export the model you have made to this format. Load it with ufoedit. A popup window will appear and asks how to map the texture. Click on FLIP Y axis, as the engine has a different coordinate system which will mess up your texture if you dont flip it. Also you can vertically flip your texture in Photoshop but don't do both. You can preview your model with texture in UFOedit, but the important part is you can save it to AM format. [DO NOT SAVE AS AS/AL] I said saving does not work before, yes but we only want to save our vertices data therefor the tool already does the job, however we cannot store any other data YET.

Now we have 2 files, 1 is the converted original and the 2nd our .obj file that we converted to textformat.
Open up both in your favorite texteditor aka notepad
Now select your made modelfile and select all numbers including VERTS 00000
down to the last line of the number block you see PRIMITIVE_GEOMETRY_GROUPS 1 or something similar. Copy paste it into the original file, make sure you overwrite all data from VERTS to the line GENERIC_ATTRIBS. Now do the same for COUNT and copy paste this into the original file. We now have bodysnapped our new model into the original file. Why do we do this ?

Because the file holds some more data like helpers, texture infos, and more complex ones refer to animationfiles and bones, however this is not possible to edit yet.
Now save the file but don't overwrite the original as you can use it again and again as your body, save the new file under "mynewweapon"-imp.txt, so you will know later what it is. Store it in your
ex-folder\items\models folder. Now you can close the file we have copy pasted our modeldata from but keep the newweaponfile file open....

How to edit helpers

Load it into ufo edit.

Click on the rider model and select show helpers. Now you will see some Pivots as they are also called, these little helpers define some special connection points for the game engine. Now what do we need them for ? Weapon files always have 5 helpers, you can select and highlight them with the drop-down menu, the first is called point-f which indicates the starting point for the muzzle-flash of the weapon, the second is called muzzle, it defines the length of the muzzle-flash, scope and underbarrel mark the points where the add-ons are mounted, and eject defines the eject point of the bullet case.

As you may see these points do not correspond correctly with your model. Well that alone is not a problem but it may look weird when you add add-ons. So we have to fix them. NOTE: you cannot save in ufoedit yet properly so we have to edit them manually. However we can already move them around in ufo edit and find the right spot. As seen on the picture.


When you are done open your mynewweapon-imp.txt if you have it closed and edit the helper data manually. The helpers are stored at the top of the file, each helper as actually a parent helper below, its the position of the model itself, only edit the first one! The values are a bit cryptic so you can always view into the editor to see its original value and figure it out which is XYZ, as these are stored in a 4x4 grid, like rotation and 3d coordinates.

Basically it should be every 3rd value so 3 6 and 9 for xyz, a little trick to make sure you change the correct is to leave the values behind them, when you change them in ufo edit to adjust a helper, as they where so you can find the corresponding value in the file new weapon file. Edit the xyz values in the new weapon file manually and then save the file by clicking ctrl-s. Later it will be possible by saving this via ufo edit, however again this is not implemented yet.

Game implemantation

Now we are almost done, if you use your own texture you have to edit the texture file paths as well, the game uses 4 diff, spec, bump and normals. You will only need diffuse however to make it look real good you will need the others as well, I'm still experimenting on it, it's a bit tricky, so using original textures on your model is much easier. Now you also have to store your new textures (if you made them) in the ex-folder\items\textures ,as the meshconverter will look for them. Convert the file back with
tb items\models\mynewmodel-imp.xt mynewmodel.txt. The new converted file will be stored in ex-data folder again. Place it properly with your textures in your modfilder according to the file structure and compile them into a mod.vfs file.


NOTE: To actually see the model ingame you have to give the file a name of a model which is actually stored in the equipment.txt and the entitiy.txt. For testing issues you can name it wu_h_ancient_rifle.txt for example. It will replace the model of the original fn2000 ingame, but still have the same stats and description. How we edit these I will explain in another tutorial

-

[Merlon]

Introduction
There's been some recent discussions about the colourscheme used in the game. It's a typical blue tool colour that if dropped in the Mars sands is easy to spot, but in our minds that goes for the enemy as well. So there's been quite a few questions on how to change it. What follows is a rough how-to with an example mod in the end.

Note that this is a work in progress and will be expanded over time. Please send a PM my way if you've spotted something I've overlooked or have suggestions for changes. Enjoy and happy modding!


Requirements

• First off you need a decent image editing program. Any imaging program capable of adjusting hue, saturation and lightness will do. The Gimp is a free and solid choice. If you're running windows you can find both the actual program and the required GTK+ 2 runtime library here, otherwise try http://www.gimp.org/.
• You also need access to the game textures. For this exercise use the one provided below or read the "Extracting textures" section for more info.
• Last, but not least you'll need a VFS-tool to package your finished mod. We'll get back to that later.

Getting Started
Open the following two images then save them to your drive, preferably in a directory made for this project.

(human_weapons_proj_diff.png)

(human_weapons_proj_mask.png)


Picture 1 is the texture used ingame on most human weapons, as such modifying the colourscheme is a lot easier than one might imagine. All we need to do is change the hue, saturation and lightness of the texture. Since the different parts of the texture are used in different locations ingame we need a mask to make our modification more accurate. After all, we don't want our change of the default blue colour to green to also change the magazine stripe (default: red) to purple! For this purpose I made picture 2, three wildly different colours hence easily selectable, for the 3 main areas of use for the texture.

Changing the hue
I will provide instructions for The Gimp in this section, other programs will likely have a similar approach.

First off, open the human_weapons_proj_diff.png image, then go to the file menu and choose "open as layer..." and select the human_weapons_proj_mask.png image (you can also drag and drop if you prefer). In the "layers, channels, paths [...]"-window make sure the mask layer is selected then click the "select regions by colour" icon on the toolbar (shift+o), now click the blue area of the mask texture to select only that part for the next step. In the layers window click the eye icon next to the mask layer to hide it, then select the background layer. Go to the "layer" menu then choose "colours" followed by "hue-saturation". Your screen should now look like this:


Adjust the hue until you get the colour you like. Use the saturation to adjust the richness of the colour. The lightness does exactly what it says... To get a colour like the one used in the example mod try hue: -168, lightness: 10, saturation: -20.

Getting the details right
The text on the image (MTeK) looks a bit dull, let's select it and increase its lightness value. We'll use the wand for this (press Z or choose the icon on the toolbar), but first deselect your current selection by clicking anywhere within the grey area around the image. To make selection of the image easier increase the threshold to about 30 then click the MTeK text. All the text should now be selected, if it isn't, then clicking on the unselected parts with the shift-key down will add them to the selection. Conversely you could end up with too big a selection, to rectify this go to the history tab on the layers window (an arrow icon) and click on any of the last saved states to go back and try again with a lower threshold (Ctrl+Z rewinds history one step). With the text selected open the hue-saturation window again and increase the lightness by for instance 30, or change the colour entirely!

Ok, your texture is now ready, so let's get rid of the mask layer (drag to recycle bin) and save our work.

Converting to DirectDraw Surface (DDS) format
To be able to use your newly created texture ingame we'll have to first convert it into dds format. This is most easily done by saving to the format in your imaging software. Here's a plugin for photoshop and a plugin for The Gimp that allows you to do that. The filename is important in this step, name it "human_weapons_proj_diff.dds" and make sure you save in DXT1c format with generate mipmaps on.

If your program doesn't support this and a plugin isn't available, there's an alternative. Download nVidia's dds utilities. Save your modified image to the same folder, then open a command prompt there and run the following command line: "nvdxt -dxt1c -file human_weapons_proj_diff.png". This will convert it to a .dds-file.

Getting it ingame
To get your newly created texture ingame you need a vfs-tool. There are several available, one is even included with the game, although it is inside a vfs hence you need the tool to get it (doh!). Visit ShadoWarrior's Guide to Modding Aftershock for Beginners, scroll down a bit and get one of the vfs tools linked there.

Make a new directory, ie: "myminimod", then make the following directory tree within: items->textures->humans. Place your modified human_weapons_proj_diff.dds file into the innermost "humans" directory then make the vfs as seen in the above linked guide.

Congratulations, your mod is now ready for testing.

Extracting textures
To modify other textures you need to extract the complete gamedata.vfs file. See the above mentioned guide by ShadoWarrior for instructions. Here are some locations of interest within the archive:
data\interface\textures\items for interface pictures.
data\items\textures\humans for item textures
data\units\textures\humans for armour and heads

Example desert colourscheme
Here's an example mod I made changing some of the armour, weapon and dronetexture to a more sand/gold-themed texture. Interface pictures remain blue and unchanged.

Get the "Example desert recolour mod" here. Put in game folder to install.

This mod changes the following files and hence is incompatible with other mods doing the same:
items\textures\humans\human_weapons_proj_diff.dds
items\textures\humans\human_drons_diff.dds
units\textures\humans\light_battle_diff.dds
units\textures\humans\male_medium_battle_diff.dds
units\textures\humans\male_light_basic_diff.dds
units\textures\humans\male_light_transport_diff.dds

Download this document
PDF (304kB), Acrobat 5.x and up
DOC (809kB), Word 97/2000/XP

[ShadoWarrior]

As best I've been able to tell from comparing files and such, patch 1.5 does not update any of the game's data (.vfs) files, so all pre-patch mods should continue to work fine after you patch the game. If anyone discovers any issues with the patch and a mod, please report it in this thread.

Have fun!

[PetteriB]

During the development of my Advanced Missions Mod, I have studied the map files pretty intensively and decided it would be best to share my findings with fellow modders

The map files are contained inside mod_gamedata_scenes_1.vfs and mod_gamedata_scenes_2.vfs. Below is a list of descriptions for all files that are used for a single map:

map_name.arm
A database dump of the areas in the map. Areas are places in the map that have some special meaning, for example UFO entry area, enemy spawn points, mine fields etc. Since this is one of the easiest map related files to edit, I'll describe its contents a bit more closely.

The file starts with:

CODE

AreasManager RECORD
  areas PARRAY 12

areas define the total number of areas the area definition file contains.

Each area definition starts with:

CODE

    PTR 1
    Area RECORD
      id STR "entry"
      fields ARRAY 171

id defines the name of the area and fields is the total number of squares the area contains.

Each square is defined as depicted below:

CODE

        Field RECORD
      id SFieldId RECORD
        x INT 9
        y INT 176
        posInList INT 0
      END_OF_SFieldId
      pos -525 7825 0
        END_OF_Field

INT x and INT y define the coordinates of a single square the area contains. posInList defines the level on which the field is located (0, 1 or 2). The pos definition supposedly is the accurate x y z location of the square, but according to my own experiences, it can be completely ignored since it doesn't seem to have any effect to the location or functionality of the individual squares.

Finally, the file ends with:

CODE

  END_OF_areas
END_OF_AreasManager

Note that the individual squares don't have to be connected to each other for the area to work. Also, if an area is set as a waypoint for an enemy unit, the unit will always move to the nearest square of the target area.

During the missions, ALT + A key combination reveals all areas in the current map. All valid squares are colored green, whereas invalid squares (incorrectly defined posInList, obstructed by scenery etc.) are either red or blue.

map_name.bin
A binary file which supposedly contains all models used in the map.

map_name.fld
A database dump of all the fields a.k.a squares in the map. Basically, this file defines which squares are passable by units and which aren't.

map_name.inf
A binary file with text "LOGIC FIELDS" found in the header.

map_name.lps
A simple config file defining light and day profile names.

map_name.mat
A database dump of material textures used in the map

map_name_nght.mat
A database dump of nighttime material textures used in the map

map_name.nit
A database dump of all nodes in the map. Nodes are used to determine where all the various map elements are placed (rocks, buildings, fences etc.)

map_name.optm
A binary file with text "OPTIMIZED_MESHES_ARRAY" found in the header.

map_name.shl
A config file defining lightning parameters such as direction, color, amount of fog etc.

map_name_nght.shl
A config file defining nighttime lightning parameters such as direction, color, amount of fog etc.

map_name#0.tga
map_name#1.tga
map_name#2.tga
Targa image files used for the minimap.

map_name_<random_hex_number>.bspt
A binary file with text "BSPTREEBOUNDBOX" found in the header.

map_name_settings.txt
A config file for general map settings such as background sounds, camera limits, light profiles etc.

map_name_0-_lights_day_0.dds
map_name_0_3d_lights_day_0.dds
map_name_0_3d_lights_day_1.dds
map_name_0_3d_lights_day_2.dds
map_name_0_3d_lights_day_3.dds
Daytime lightmap textures

map_name_0-_lights_nght_0.dds
map_name_0_3d_lights_nght_0.dds
map_name_0_3d_lights_nght_1.dds
map_name_0_3d_lights_nght_2.dds
map_name_0_3d_lights_nght_3.dds
Nightime lightmap textures



IMO, the most interesting thing about those files is the fact that the map elements appear to be separated from the terrain itself. So in theory, it is already possible to create new maps by rearranging their layouts. However, the way Afterlight handles the area passability introduces one problem. It appears that the field definition file (.fld) must be recalculated every time the map layout is changed and the sheer amount of information the file contains makes the task impossible without the proper utilities. Utilities, which Altar probably isn't going to release anytime soon for us modders to use

[MagerValp]

To edit the strategic map, you have to edit your savegame. You should make a backup of your savegames first, in case something breaks. The save files are vfs files, so you have to be comfortable with working with vfs files. If you're not, check out the tutorials in the modding forum.

1. Copy the savegame vfs to a work directory, and extract the contents.
2. Open <savegame>/strat_game in a text editor that supports UTF-16LE (Notepad works).
3. Find the section that starts with "territoryList CTerritories RECORD".
4. In that section you will find exactly 79 subsections that start with "CTerritory RECORD".
5. Each subsection has a stringId that corresponds to a territory name on the strategic maps. Note that the names in the savegame are in Latin, so you'll have to do some translation; e.g. "Scamander Vallis" is "Salamander Valley", and "Valles Marineris Occidens" is "West Mariner Valley".
6. Each territory has an attribute "(int&)owner INT" that indicates who the owner of that territory is. Martians own territories with the number "2", beastmen own territories with the number "5".
7. When you're done editing, delete the old vfs file and create a new empty vfs file with the same name as the old one.
8. Import the edited savegame into the vfs, and update the md5 sum.
9. Copy the edited vfs to the savegame directory, replacing the old one, and hope that you didn't screw anything up :)

Please note that editing the savegame might break the game, so make sure you have backups of all your saves.