I don’t think the anim is the problem. I think it’s in the game.
@Nathanius (@PayDay): rom_ENT_resourcecontroller.DAE crashes because the keyframe interpolation type is a BEZIER curve, but there are no in/out-tangents specified on the rotation channels (DAEnerys ignores the in/out tangent values when the interpolation type is LINEAR).
Also, it appears RODOH completely, utterly, and absolutely killed your animations. I’ll have to either wait until PayDay finishes updating the exporter to include animations, or you can try using the MAD files from the old HODs (try that first, and let me know how it goes).
(yes, I know those words all mean the same thing)
I’ve been using the old *.mads so far, well aware that RODOH munches the old anims for me… The old anims still have the problem with half the warp stuff being played though
Unfortunately I don’t know enough about animating with MAX to know the difference between the two types of curves, rest assured I’ll be a heavy user of Daenerys’ animation feature once it’s all sorted!
I didn’t think it needed any rotation information though? It’s only movement keyframes that I’m capturing…
Yes, one of the pitfalls of CFHodEd MAD animation support → unnecessary keyframe injection.
OK. The old mad files played just fine in HW2. Now all of a sudden they don’t play correctly. This means the game has changed and it’s a problem with the new game. Any amount of research or editing will not change the outcome. Bottom line: The game cannot handle the old mad files…
That’s why I’m politely nagging for DAEnerys to import old MADs so they can be translated into the new format
It already supports animation exporting…
I know, but I don’t think the problem is in the mad files. I think it’s in the game…
Huh… I tried it, and it didn’t seem to work… I’ll try again…
Well, there’s actually no difference in the file format. That isn’t to say that the game may interpret the file differently than before…?
I’m sorry if it’s not what you mean, I didn’t read the whole topic, but there are changes between RM 1.0 and 2.0 .mad files. I’ve checked for example Hgn_Interceptor and the first obvious change is a much larger size for 1.0 file, there are also many changes in the content.
Very busy heading towards the Gearbox holiday week off (aka my week to work on my current project with nobody around, and some HW pokery)…
MAD file format didn’t change. We still load old MAD files. I am 99.9% sure of this. HODOR is smarter than the old MAD tools though, and is better at nuking bad channels, dupe strings, etc - so an old MAD file saved will likely be smaller.
As for why a certain MAD file doesn’t work - if it was made with something like CfHodEd, it could be just about anything… If I get time, I will look. But then again, every time I get free time, if I spend it looking at one person (or Mods) issue, I am not working on stuff that gets a patch out in the future. It is a hard balance to find.
Once again, and perhaps I didn’t stress this enough, there’s no difference in the format, as BitVenom confirmed. I never said there weren’t any changes in the data, and more than once, I’ve brought up the
and duplicated keyframes issue.
I’m planning on taking a massive stab at animations this coming week, just to see what is and isn’t allowed by the engine, unless BitVenom answers my questions before I ask them.
@PayDay I thought you were one of the folks who had grabbed our asset pack, but I may be thinking of someone else. Here’s a subset with just the frigates, two of which cause the error in question and two of which do not.
Anything anyone can get you please, don’t hesitate to ask
I’m hoping it doesn’t because that means we have control over whether it’s broken or not… if there’s something in the game that has changed which means certain kinds of animations (like, inexplicably, my warp animations) don’t work then that will be a longer wait for a fix
These two frigates have some GLOW and SPEC textures assigned that are not in
library_images, causing Assimp to throw an error because it could not find them…
Seems like RODOH exports navlight parameters in separate child nodes… should DAEnerys parse them?
EDIT: Given all the problems with Assimp, I’m thinking of scrapping that alltogether and writing an own importer too…
With the blender importer I try to take the sub nodes for navlight parameters and put them back into the one node. That’s really just because the blender toolkit uses lamps though. I’m pretty sure HODOR can process the sub nodes…
Okay, I’ll add the processing to DAEnerys.
This was done (and works with HODOR on ANY node) to help keep the names of nodes shorter in instances where they overflow the max len allowed by any given software. HODOR just looks for Params, and if it can’t find one the importer is looking for, it checks for a SUB_PARAMS (or whatever, that’s from memory), and the child nodes of that.