This tutorial assumes that you have a copy of your SWGEMU client in a folder C:\SWGEmu_Dev. It also assumes that you have a copy of Sytner’s IFF Editor (SIE) and know the basics of how to use it.
Assets : You should have the assets for the new weapon from your 3D artist. For this tutorial, download this file, created by Slayer: Banhammer Assets
Extract the folder into your SWGEmu_Dev/ folder, creating a subfolder called TRE-banhammer
in this particular example, we have a folder with 5 subfolders, all which would sit inside a TRE file (ignore the misc folder for now).
appearance contains the 3D mesh and appearance file for the weapon
clientdata contains the effects information for the weapons (in this case, electricity)
object contains the path and, in this case, the tangible object for the weapon
shader contains the shader information for the weapon
texture contains the image texture that wraps around the weapon mesh
Right, let’s start from the top of the tree, the actual tangible weapon. The thing that sits in the player’s inventory that they equip.
This is the file in SIE:
The DERV value points to the base object that this weapon is inherited from object/weapon/melee/2h_sword/base/shared_2h_sword_base.iff (it’s different in the above TRE because I forgot to update it)
The 004 element is to identify weapon effects used when the weapon is used to attack.
Nothing to change here.
The STOT-> DERV parameter also points to the base weapon for inheritance
The parameters under 0007 do not need changing
Don’t worry too much about all this, this is a quick intro into how some of the TRE file objects work.
Once again the SHOT node has a DERV node whose parameter points and the inherited object
Now, in the base SIE install, for some reason the template for SHOT->0008 doesn’t show the stuff we need, so down in the bottom right, here’s a little box with template info in it – paste in the following:
String[FieldName]
String[StringID]
String[StringVal]
and you’ll see this :
and then up above it it will split the data into something more editable
so once you’ve edited the template, the data above is ready for editing and you should change it to be like this :
The second XXXX field contains the string details for the weapon description, make it look like this:
You then need to scroll down the XXXX fields until you find the one called appearanceFilename
the value for this needs to be the path to your appearance file – it should be set already
a little further down is one called clientDataFile – this weapon has this entry because it has a special effect added to it and details of that effect sit in the cdf (client data file).
and that’s all you need to know about the object iff for now.
Now, as we saw in that iff, it points to :
- String files (I’ll explain them later)
- Appearance file – appearance/sr_admin_banhammer.apt
- clientdatafile – clientdata/weapon/client_melee_banhammer.cdf
if you go to new editor/new iff editor and open the appearance file you’ll see a very simple format file. This usually points to the Mesh (.msh) for the object, or sometimes to a Level Of Detail (.lod) file.
Here, it’s nice and simple and points straight to the mesh.
ok, so new editor/new iff editor again and open the mesh file appearance/mesh/sr_admin_banhammer.msh
in this file, for your sanity, ignore everything until you see the NAME node (MESH->0005->SPS->0001->NAME)
as you’ll see, the template doesn’t match the data, so down in the bottom right, it’s time to do a quick edit – replace the contents of the box with
String[Shader Name]
At the top you’ll now see
you don’t have to do this, as you’re not changing anything right now, but I’m trying to give you a little understanding of SIE
Further down you’ll see other NAME nodes (under 0002, 0003 and there would be more if there were more shaders)
So here we have 3 shaders
shader/hammer_grip_slar.sht
shader/all_metal_slar.sht
shader/all_metal_gold_slar.sht
You know the score by now, let’s go see what the shaders point to.
new editor/new iff editor
open shader/hammer_grip_slar.sht
Now, while doing this, I’ve noticed 4 shader files in the shader/ folder – I think one is redundant. Anyway, if you open one of the .sht files, you’ll find another tre structure with a NAME node on it.
This points to the texture used for that shader, in this case, texture/grip.dds
Each of the shader (.sht) files points to the textures required.
Don’t try and open the .dds files in SIE, it will just crash it. You need an editor, such as Adobe Photoshop (with the PS DDS Plugin) to open/edit/create these.
Finally, you can open the .cdf file from the clientdata folder and see that it points to a .cef file (client effect) which you don’t have in this TRE, as it’s an existing effect from the SoE TRE files.
So to recap, you have an object (often referred to as a TANO – tangible object) which refers to other files that it depends upon.
That was mostly unnecessary for getting the object into game, although you need to know the names of things.
There are some IFFs that are missing that you will need to update for the new object.
The String files.
Instead of passing names and descriptions of things between the client and server, and to enable localisation if you’re supporting multiple languages, it passed a StringID
eg, the objectName field in the object.
These need to be set up so that the client knows what to display.
So, referring back, you have
ObjectName – weapon_name – banhammer
weapon_name refers to the string file that contains the StringID banhammer
So, back to the Repo view in SIE
Down the list is a node called string
under that is one called en (English)
and if you click on en to the right you’ll find an iff called weapon_name
In the bottom pane you’ll see a list of the TRE files in which that iff can be found
you’ll want to extract the latest of these, in this case it’s the Patch12_00.tre entry, so right click that and click extract (1 files)
(ignore the fact that this image shows a different TRE name).
browse to your TRE-banhammer folder and click OK
Now it’s back to your IFF editor, so switch to the other SIE window, new editor/new STF editor and open file
then browse to your TRE-banhammer folder and you’ll see an new folder under it called string with one under that called en and in there is the weapon_name.stf that you’ve just extracted. Select it and click ok.
so to add one for the banhammer string ID, you enter it as shown and click the large blue + button to the right of it. Then click save.
If you remember, for the description, the String File was weapon_detail
so you repeat the above process to extract that file from the repo, edit it and give it a description, such as an Admin tool for removing problems, then clock save.
The final bit of IFF work is one that you will repeatedly forget and you’ll notice it when you get invisible objects in game.
it’s referred to as the CRC STRINGS file.
similar to regular strings, the client and server don’t pass full object paths and names to each other, they instead pass a checksum, which cuts down on data transmission and bandwidth.
These checksums are held in a file.
It’s important to always use the latest version of this file when creating your release TRE file or you’ll wipe out other objects that were in the newer file.
The search function is useless on this part of SIE.
Here’s how you go with that … new editor/new CRC editor
now you have 1 new object in your TRE-banhammer file, so click
Add From and Files
browse to your object folder and through the subfolders to your shared_banhammer.iff file, select it and click ok, then click save.
The final action is to create your new TRE file and add it to both the server and client configs.
In the REPO window of SIE, click the TCO/TRE builder menu option and choose create .tre from directory on disk
Browse to your TRE-banhammer folder and select that folder
Choose a folder (maybe Desktop?) to write your new TRE file to, name the file banhammer.tre and click Save.
On the server, edit the MMOCoreORB/bin/conf/config.lua file, make sure your TRE folder is the one that you copied the tre file to earlier, and add “banhammer.tre”, to the top of the tre file list, if it’s not already there.
When you restart your server now, use the command ./core3 reloadStrings to load the CRC String changes.
the object is now loaded into your server and can be accessed from the client, but there’s no information for it to do that – time for some LUA work