But as to your original request - yes, I can probably allow you to throw them into containers - the main issue will simply be making sure those containers have ZERO transform, as I’ll be forced to ignore them (can’t just randomly create shadow joints to account for the transform). I’ll probably add support for generic ‘no transform’ containers to resolve this (and for other house-keeping) something like HOLD[XXX] - where XXX is ignored, but if it isn’t zero transform HODOR can bitch at you with the name so you can resolve that. I don’t know when another RODOH/HODOR update is coming - I have root anim to deal with, plus a boatload of ‘weird’ DAE files to puzzle out (and some that just crash anything that moves).
Sorry about the root anims… and at least one of the weird DAE files 
my solution so far is to import the RODOH exported joints into my original max file… so not too helpful to anyone that didn’t do all of their work in max to begin with. It is slow, but I can fix some stuff along the way. Just time consuming, but beneficial over the long term.
@bitvenom I was thinking about the containers, and realized that in the case that markers, hardpoints or navlights would be part of an animated joint, the container idea wouldn’t work. unless someone has a good idea of how to make it work in those cases that is less onerous it probably isn’t a valid idea. My issue was more around dealing with it in max and sastrei pointed me to a workable solution to manage it.
I also have seen some weird issues in another RODOH export of an animated mesh where the JNT is moved to X:0 but keeps its other transforms and rotations through the animation. I can send along the original hod if you want it.
Actually, that would be fine - the container would need to have no local transform - it wouldn’t interfere with the structure or animations of it, anywhere.
Anytime you have weird issues, send me a PM (I am a bit behind) - drop me a ZIP with some before/after or details about the issue (in the event it’s not clear to me) - and I’ll look.
Uhm, I’m having a weird issue, Rodoh is no longer being recognized as a valid command. I remember there having been an exe(?) for Rodoh, and it’s no longer in my tool folder. I tried re-donwloading the toolkit, and verifying its cache, but the above didn’t change.
Am I doing something wrong or was RODOH functionality removed?
It wasn’t removed intentionally… lemme go see what’s up.
I just made sure I have the latest Toolkit from Steam - and RODOH.exe is absolutely there…
Anti-virus software quarantined it, perhaps?
Edited.
Confirmed anti-virus problem with avast.
Quick question - any reason RODOH seems to always give me DAE’s with the joints scaled to 39.37? I thought it was messiness on the part of the original HODders, but I’ve converted files from three mod’s now with different authors, and they all do the 39.37 thing.
I doubt that’s RODOH - I think your units on import don’t match the DAE, and so the tool you are using is doing a conversion? RODOH/HODOR avoid all scaling, as the engine doesn’t understand it, generally.
Ah, so it might be on 3DS Max’s end then. I have no problem blaming 3DS Max, lol.
Edit: confirmed, MAX has a scale factor in place on DAE import. No idea why, or even how to change it, but defnitely MAX’s fault.
Change your units on import - make sure they match the DAE. You’ll see no scale when they’re the same…
1 Like
Thanks Bit, that did it. I had to change units to “Centimeters” instead of “Automatic”.
Now I know why all my DAE files are screwed up.
1 Like
Remember that Max has system units and file units before it even gets to xforms and scale factors.
For sanity I set system and file to meters and then reset all xforms excessively, that way the exporter is getting a consistent value across all ships
3 Likes
That makes sense. HWR is 1 unit to 1 metre, should do the same with Max
I’m in the middle of mass batch converting with this stuff and I noticed that some of the ships aren’t being converted over, saying unknown type and unknown version, has anyone else run into this?