RODOH has cometh!

It has begun.

Syntax/function is pretty much like HODOR, except you don’t have to specify SHADERS_MAP (because this is converting the old stuff which has it’s own format).

A few notes:

  • OLD HOD files only. A new HOD will have the wrong layout, will either just not spit out a DAE, or will spit out one with lots of stuff missing/broken.
    – I tried to consider that people had been using normal maps before HW:RM - so some of the shaders (like ship) will also understand $normal.

  • RODOH only understands shaders that shipped with HW2:C - If your mod had custom shaders or crazy stuff, sorry - we can’t help you. You can give it a shot anyway - it may come out the other side just needing a bit of love.

  • If you’ve used the ‘new’ CfHodEd to make HW:RM compatible HOD files from old ones expect trouble. The mapping won’t work, and you will end up having to do a bunch by hand. If you still have your ‘pre Remaster’ HODs - batch convert those - then add back in any new surface maps (like REFL) that you’ve created that you had added via other tools.

  • When the HOD format changes it will be a BIG change - your old HOD files will not work in the engine, at all. Zero. The new files will be smaller, many elements will exist outside of the HOD (joints, markers, various meta data, etc). RODOH is being released to make it possible to get your ships and other HOD files out to DAE in a proper format so that it is easy to update them via HODOR to the new format. Other tools will not work. If you wait for hacked or other tools, it will be a very, very long wait and your Mod will not function in the mean time. There’s no specific timing for the format update to provide (we don’t comment on the timing of upcoming features) - but once it has happened we’ll talk about the new format, how to use it to patch ships, etc…

  • The resulting DAE files should work ‘as-is’ - but if HW2:C didn’t understand something we do in HW:RM (like _REFL, etc) - that file won’t exist. You can just create it and things will work fine, but RODOH doesn’t invent new data.

  • Badges are a fun one - we had some experimental ‘unbadge’ logic that made converting to the extra UV set with ‘base’ ship materials welded back in - but it was a TERRIBLE failure when it didn’t work, and that was 30-40% of the time. I’d rather that I not have to support a half-working feature. So, for HW2:RM badges, you’re on your own to edit your DAE to do badges ‘right’.

  • It is actually pretty easy to ‘batch’ scan convert with RODOH (and HODOR!) - if people want to see that, I can put together a guide… the one bad thing about batch work is just dealing with edge or failure cases inside a set of dozens or even hundreds of files…

Ask if you need anything or have issues!

6 Likes

THANKS!!!
It will be so helpful for us!

1 Like

Can somebody on your team give this a quick run? I did tons of testing here - but I’d much rather see some screens of ships that went Old HOD -> RODOH -> DAE -> HODOR -> New HOD, clean…

You’ll have some screens up for ST:C before Friday ends for me! (Or a report of something stopping me from getting it done)

If you have an ‘old’ file it’s like… 5 minutes of work :slight_smile: But please, if you have any trouble, PM me or just complain here, and I’ll be on it super fast…

I’m going to be giving this a shot. Is the batch mode you mentioned built in, or refering to external scripting of it?

It’s ‘built in’ - but that means (as with HODOR) that you write a script to set it up…

Lemme get an example and post it…

I am confused about hodor and rodoh…ive used them but i hate having to type all the commands to get it to work. Will there be a final version with a friendly GUI? Kinda like CFHODED but gearbox style…

Inside a file called Scan_Path.hodor

= -$$IN_SCAN=YOUR_PATH_HERE (or specify before this -script line)
= -echo=-- Scan Path: $[IN_SCAN]$[CR]
= -setmask=*.hod
= -dump
= -log
= -$CONVERT_IN=$[SCAN_ROOT]\$[SCAN_REL_PATH]\$[SCAN_FILE].$[SCAN_TYPE]
= -$CONVERT_OUT=$[SCAN_ROOT]\$[SCAN_REL_PATH]\DAE\$[SCAN_FILE].DAE
= -$SCAN_PARAMS=-do=convert
= -scan=$[IN_SCAN]
= -action=null
= -echo=Scan Complete!$[CR]
= -wait

So then once you’ve set your path (or you’ll specify it to HODOR direct) - you just say:

RODOH -script=Scan_Path.hodor

It will go off, find every .hod, feed it to ‘convert’ which will grab the files and process them. Easy peasy!

If you understand how HODOR/RODOH handle symbolics - you can also remove the IN_SCAN variable being set in the script, and just do it before you run the script:

RODOH -$$IN_SCAN=C:\My_Crazy_Old_HODs -script=Scan_Path.hodor

HODOR/RODOH are very, very powerful. I haven’t even covered how to use .csv files to set up custom params per-file in a big parsing list :wink:

1 Like

Hm. Intriguing, thanks for the help. Now, I have three old BG hods that are erroring and one that’s outright crashing RODOH, want to see them? :slight_smile:

Backgrounds aren’t going to work… so that’s probably the reason. RODOH doesn’t understand a ton of the stuff in those files.

Converting those to the ‘new’ background format is really easy though - the DAE scene is pretty bare (as you’ve probably seen in the Background examples).

One big thing - if any of you are on ‘other’ forums - it may make good sense to post about this there - because people are going to need to be using this to get ready…

Well, that’s slightly dissapointing(automation anywhere is helpful!) but understandable. It appears to be skipping most of them just fine, but outright crashes partwhy through the background list, with the last message being one about converting one of the backgrounds so I assume that’s the snag. I can work around of course, but thought you ought to know about unceremonious crashes.

Yeah, I imagine with the right bad data it is going to just eat it, hard. When it works, it works - when it doesn’t… well, it might not act nice :wink:

How’s it doing with non-backgrounds?

I cut out the backgrounds from the source directory, and it chewed through the hods and spat out ~2 gb of assorted files. Now I just have to get HODOR to do the return leg.

If you understand the language you can see that swapping that ‘scan path’ script for one that shifts things from DAE to HOD is very easy…

= -setmask=*.dae
= -$CONVERT_IN=$[SCAN_ROOT]\$[SCAN_REL_PATH]\$[SCAN_FILE].$[SCAN_TYPE]
= -$CONVERT_OUT=$[SCAN_ROOT]\$[SCAN_REL_PATH]\HOD\$[SCAN_FILE].HOD

So it’ll look for .dae files instead, and save into .HOD - viola.

That’s producing some results. And a looooot of messages. Lots of size mismatch alerts :frowning:

Yeah, that would be because the old logic had the shader channels in other images - so the sizes could vary. Recombined in the ‘new’ layout you may have a 256x256 Team trying to merge into a 512x512 Glow - which used to be fine, but isn’t now. Still, the DAE files should be solid, should load into Max or Blender - and should (once you fix the textures) - load into the game and work as we update the tools & format.

well, it produced working hods! There’s some weird darkness to them, that might be an artifact of using as-yet unconverted backgrounds. I’ll have to try using some of the stock backgrounds and see if that helps.I blitzed by steam screenshots with testing shots.

Thread in ‘other’ forum coughrelicnewscough pointing here has been posted.