Bringing the FXmod to HWRM 2.0: A letter (and diary) from the developers news

Hello fans,

It has been nearly 8 months since Gearbox Software rolled out the 2.0 patch for Homeworld:Remastered. With this patch came new possibilities, perspectives, but especially challenges for the series' modding scene. For a lot of people the 7th of June, 2016 will not be remembered as the day the 2.0 patch came out, but as the day on which they tried to launch some of their favorite modifications for Homeworld but instead were greeted by three words. A mere three words that carried with them perhaps a greater impact than the entirety of the 2.0 patch itself:

Error.
General Failure.

We are now more than half a year later. Amidst a number of discouragements for the modding community, such as the people (and assets) responsible for the 2.0 patch and much of the game's post-launch development overall being re-assigned to other games (which we perceived as Gearbox saying that we shouldn't expect any help from them anymore), we silently continued our work with whatever methods, tools, and (creative) solutions were available to us. Then, some days ago HW_Lover posted a message on our Steam page:

In order to make the mod run on current version, A LOT of things need to be done. We are finally close, so be patient.

Before anything else I want to say this. We are not there yet. There still is a tremendous amount of work to be done and bugs to filter out, and it will probably be a considerable amount of time before we can present a (completely) stable version of the FXmod again. However, we are getting closer. Whereas before we were reaching around in darkness, we now have our eyes fixated on the light that emanates from the exit of the tunnel. We know where to go, and although the distance to the exit is still considerable, we now have a path to follow.

To commemorate the release of a post-2.0 FXmod getting closer (and to give some insight into why it took so long) I have attached a "developer's diary" detailing the process of remastering the FXmod below. The contents below were written by lone_wolf, and reveal some of the many challenges the team behind the FXmod faces on a daily basis as they try to bring mod back to everyone. I want to give special thanks to Unlimited_X for forwarding my selfish request to the rest of the team, as well as lone_wolf for honoring it and jotting down these notes which I was able to edit into the article you see below.

---

Before we talk about remastering the FXmod there are a few things you need to know first:

• HOD: This is the file format of units in-game used by HW2/HWRM. So far there are 3 versions, let's call them HOD1, HOD2 and HOD3. HOD1 was used by HW2Classic, HOD2 was used by HWRM until v1.30, and HOD3 is used since HWRM v2.0. Both HOD1 and HOD2 are available in game until HWRM 2.0, which only accepts the HOD3 format.

Making a HOD is never easy. Not only do you need a model, but you also need all necessary information required for that model to function in-game, such as structure of turrets, position of FX to be played, animations... Making a HOD1 requires a program named maya3 as well as plugins offered by Relic. Making a HOD2/3 requires a DAE format made by 3DMAX, and then using the "HODOR" tool offered by GBX [Gearbox] to convert that DAE format to HOD2/3.

GBX also gave modders another tool, named "RODOH". As you can tell from its name, the function of this tool is to create DAE from HOD, and with that of course I mean, only HOD1. Theoretically, DAE created from HOD1 by the RODOH tool can then be transferred to HOD2/3 by the HODOR tool.

In fact, the RODOH tool was released in April 2015 because GBX was hoping that modders would transfer their HOD to DAE asap. HOD1 won't be supported forever, but when working with a DAE format, modders can create the supported HOD2/3 format at any moment. But when we try to use this stuff, somehow, we found that all DAE we created from our HOD1, are broken. Here is an example:

As you can see, the RODOH tool was useless to us. Thus, under this circumstance, our only option is to start from scratch to get our DAEs. For simple HODs, this may be doable, but it is impossible for us. Here is why:

A simple structure of a turret in 3DMAX looks like this:

This may not make a lot of sense to you, but I'm sure you can tell the differences between this structure and a structure of a turret we made ourselves, which looks like this:

This above structure is for a turret in our Gundam SEED mod. As you can see, this massive monster eventually became the moving limbs on those gundams.

Another example is about animations. A simple animation of Balcora Gate rotating (regular HW2) looks like this:

Now, the animation sequence for the frontal cannon of the Kadeshi Needleship is our FXmod looks like this:

Every single line in this refers to a single moving piece -- it can be a cooling fan or whatever is supposed to move on the needleship during the cannon's activation sequence.

As you can see, none the HODs we made in the past decade is simple. In fact, it would take us at least another decade to make these all over again from scratch. This is why re-doing these is not a viable option, and we had to rely on Gearbox to provide the necessary (working) tools.

Fixing HODs; Triangle "Strip" & "List"

At first, we were expecting that GBX would update their RODOH tool and solve our problems, and since HWRM v1.30 still supported the HOD1 format, we never began to create DAEs the hard way.

Then in June 2016, HWRM updated to 2.0. All of our existing HODs were killed, but we still expected RODOH to be updated.

During the endless waiting, we came to realize that we might be on our own. We began to study the differences between our HODs and the HODs other people used and were working fine. And we found something within the same month the 2.0 patch came out: Forums.gearboxsoftware.com

As it turns out, the RODOH tool cannot handle "Triangle Strip" correctly; only "Triangle List" is legal. This meant that we have to re-create our HODs in Maya3, and set them to "Triangle List". This made things simpler, but not by a lot as there were other complications.

As you may know, we (9CCN) are an open team; people come, make stuff, and leave again as their real-life commitments take over or they lose interest in the game. So, you can imagine how hard it is for us to find the raw/source files for everything we created. In one word, the progress was slow.

About two months ago, in January 2017, during a chat with UX [Unlimited_X; a fellow fxmod modder and 9ccn mod team member, ed.], we talked about the formats of 3D models, and UX then said that all .obj formats are "Triangle List". I suddenly remembered the existence of a third-party tool called CFHODED which can export .obj files out of HOD1/2 formats, so it somehow transfer those "Triangle Strip" models to "Triangle List"!

CFHODED is an open-source tool, so we easily found the project on Github and began our analysis. The solution was four lines of code:

How simple is that? Yet, it indeed took us more than a year to figure it out.

In case a fellow Homeworld modder or someone else reading this is interested, we made a simple tool to do this which you can find here: Forums.gearboxsoftware.com

Finally, our HODs were fixed, and we can create DAEs with RODOH, then transfer them to HOD3 format.

New Horizon, New Problems

But all of this was just step 1 to making our FXmod compatible with HWRM 2.0. Soon after the HOD issue was solved we ran into other problems, this time with our models:

Case A: Textures

The engine of our Taiidan carrier had suddenly collided with the textures used by our Taiidan frigates, and the Turanic outpost was suddenly textured by one of the turanic subsystems! So this begs the question: How can textures of ship A show up on ship B?

After testing them again and again, this is what we found: if we put the Taiidan carrier into the Kushan's starting fleet, then it will look normal. The reason for this is that, in HWRM v2.0, if textures in different units share a same name, then the game will only load one of them to save memory.

So we had to script another tool to give every of our textures a unique name:

Case B: FX / "markers"

Another problem involves the FX used in our mod. The position of FX to be played in HOD is called "marker". Before the 2.0 patch the game will ignore markers that do not exist; but after the 2.0 patch the game will crash every time it detects a missing marker.

Unfortunately, many of our units have such markers copied from other units or ignored when the model updates. So the result is that the game just crash and crash and crash...

So basically this is what we are doing everyday now:

Launch the game -> start a skirmish -> wait for the game to crash -> check log file and find out which marker on which unit caused it -> fix it -> launch the game again -> repeat...here is one example:

Present & (near) Future

All major problems we encountered have been explained to you by now, and we are finally about to fix them all soon. But the struggle is not over yet, we still have tons of other problems:

For instance, something about this turret on the Kadeshi Fuel Pod does not seem not right...

and just what happened to their legs!

There is light at the end of the tunnel now. But, we will still need time to fix all these issues, one by one.