Issues with HODOR 2.0 (Shader.map entry for innateSS)

Hello everyone!

Since its latest update, @EchoRed, @pascal76680, @PayDay and I from Phoenix Interactive started using the new version of HODOR 2.0. Unfortunately, we’re having issues with our models, and our content doesn’t work anymore.

Basically, the main issue is that HODOR can’t locate the SHADER.MAP entry for innateSS - MAT[hw2Shader]_SHD[innateSS].

Here’s the full log:

-- Scan Path: D:\Program Files (x86)\Steam\steamapps\common\Homeworld\HomeworldR
M\Data\subsystem\tau_research_module
DAE->HOD: Loading D:\Program Files (x86)\Steam\steamapps\common\Homeworld\Homewo
rldRM\Data\subsystem\tau_research_module\DAE\tau_research_module.DAE
DAE->HOD: Creating Homeworld2 Multi Mesh File - Version 512
Parsing SHADERS.MAP
DAE->HOD: Unable to locate SHADER.MAP entry for innateSS - MAT[hw2Shader]_SHD[in
nateSS] - using generic!
DAE->HOD: Creating STAT[hw2Shader] with Shader[innateSS]
DAE->HOD: Generating Scene Data LOD[0]
DAE->HOD: Generating Animation Channels

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Scan Complete!

HODOR doesn’t crash but the game encounters an issue with the new .HOD files, which results in a CTD.

Starting Level: DATA:\LevelData\Multiplayer\demoSSC\2p_abydos.level 
 HOD Trace: data:SubSystem\TAU_RESEARCH_MODULE\TAU_RESEARCH_MODULE.hod 
 HOD Trace: data:SubSystem\TAU_MIDWAY_SHIELD\TAU_MIDWAY_SHIELD.hod 
 Unknown mesh group type (1) -- FATAL EXIT -- basicmesh/602:! --stack trace--       
 Display: (0, 0, 100, 100) - (8, 31)

As you can see, the game doesn’t recognize the “mesh group type”. We could probably philosophy on the meaning of this haha, but in all seriousness we have the same issue each time we use HODOR to port our content.

PS: Of course, our DAEs are not corrupted :wink:

2 Likes

I was also suffering from exactly the same problem.
This is a pretty serious problem.
We hope that it is quickly resolved.

2 Likes

In Addition to this :

Tau_research_module DAE doesn’t have any issue with the editor.
Tau_Midway_shield.hod is an invisible shield subsystem… and has the same issue with HODOR.

Would it be possible @BitVenom to add a verification in HODOR, in order to check if the HOD would work in game ?

2 Likes

Have you tried “InnateSS” - I have a feeling some people found it was case sensitive in the past…

1 Like

InnateSS is a custom shader right? The HODOR update replaces the SHADER.MAP file, if you’ve not added any custom shaders back into it @Erayser then that may be a contributing factor? I added “shipAnim” back in to the file as we’re using it for bussard animations.

I’ve been running DAEs through the new HODOR tonight as well, and I got some promising results so far, all of my not-ship HODs like FX, subsystems, missiles etc ran through it fine. I can’t actually launch STC yet to confirm that all’s well though as I still have hundreds of HODs that the old RODOH won’t convert.

I did find that there were some crashes around animation information though. Is there a way we can get any more useful information out of HODOR for you @BitVenom?

My HODOR also says it’s unable to locate the entry for innatess.

But the subsystem in game looks fine. Green and see through like it should.

Answers…

  • InnateSS is a ‘no textures’ shader, so the message is harmless, generally. SHADERS.MAP is about building textures…

  • If you are seeing an ‘Unknown mesh group type’ in ‘basicmesh’ - Those are goblins. Remove/Merge those. Goblins aren’t legal in the HWRM engine any longer. This was clearly stated in the 2.0 patch notes.

  • There’s a built-in option to auto-merge them for you (not ideal, at all, but a quick fix) - if you use: -$HOD_SAVE_OPTS=MergeGoblins

  • If you are crashing when it says ‘Generating Animation Channels’ - that is likely because it has started saving the data to file and doing the compress/encode - and it runs out of memory. I’ll be working to improve this (by flushing anything not needed, etc) - but there’s a good chance at that point your HOD wouldn’t load in to HWRM any longer either. If you don’t think that’s the case, send me your DAE and files - or just DAE and info about the files (names + sizes).

  • HOD files can’t be more than 60MB, and can’t decompress to more than 200MB total, ever. We had to put hard limits to sizes for HOD files because the 2.0 version is MUCH tighter on RAM with all of the new systems/features - so HOD files have a fixed-size area they load/prep inside of, to prevent memory fragmentation.

  • Feel free to PM me with info and details if you have a problem DAE though.

3 Likes

Oh! And for those that suggest editing SHADERS.MAP - Don’t do that! If a new tool update is released, and we update that, it’ll nuke your edits.

Instead, just make your own .MAP files - same format. Place them in the same folder… It loads all of the ones that it can find. And yes, that means you can make a ‘blank’ entry for InnateSS if you don’t want to see the notice, etc…

2 Likes

I just wanted to not parse them anymore in my DAE Editor, but if it crashes like that, a message that you have to remove your goblins from the DAE would be awesome I guess.

Although that is not the problem with most of my HODs. They throw this error regardless of if they have goblins or not.

1 Like

Using the new HODOR, without Goblins, you are seeing that error? Send me a DAE?

1 Like

So my hods are now 5MB instead of 40MB.
What does it mean? Does it have its own mind with texture compressions? I think I remember reading something along these lines when it came to Mothership-sized textures.

1 Like

HODs are encoded/compressed now - instead of relying on the BIG file compression. This allows them to load much faster, etc. It also makes them quite tamper-proof, because the data inside is a big glob instead of IFF. Which also means your work is not going to be taken, edit, and re-used without your permission.

3 Likes

HW:@ hodor testing status: Mod crashing with an invalid texture format fatal exit,

invalid texture format
– FATAL EXIT –
image/2038:!
–stack trace–
Display: (0, 0, 100, 100) - (8, 31)

At some point in the past year I set all our texture formats in our daes to 8888, would that be causing this or is this error somewhere else?

MergeGoblins seems work …

But have other issue :slight_smile:

DESTINYHEAVYRAIL.hod
ERROR: No valid markers for event! Was: Weapon_T2_Muzzle – FATAL EXIT – rendermodel/177:! --stack trace–

He lost markers :frowning:

And i think this error will appear with other HOD …

If you have an idea, and if the solution is in 3dsmax, i will see with @EchoRed for this issue. ~

Yeah, game now complaints about missing markers. To be fair you’re supposed to have them, since the .event files refer to them.

Um - don’t use 8888 in your HOD files (except maybe backgrounds) - that is CRAZY bad for RAM/GPU.

But I don’t think that is the issue? The trace shown there is trying to validate a format - and 8888 isn’t illegal. Is that coming from a specific HOD when you use -traceHODs?

No markers were lost - HWRM is way more strict about ‘junk’ markers - because dozens of event connections were just defaulting to Root. Don’t use a marker in the events file that doesn’t actually exist…

2 Likes

Also note that HODOREST supports this as well. It will scan the same folder and give you a drop down to pick which *.MAP you want.

It’s also smart enough to read this other MAP file and use it to search for textures to determine the “newer” status.

Eh - it will use all of the map files, fyi - not just one. The ‘map’ file option effectively sets the primary one and base path, it still searches for others, regardless…

The original HW2C HOD file was 39mb, it ran through RODOH fine after I took out special characters in filenames etc (it was set up by Stargazer in German). The ship is the fed_TNG_Starbase, I sent it to you before but I’ll PM the relevant stuff again. Thank you!