Is that build 6800?
Correct, but remember I had to do that janky setup using those two files from the previous build.
I’ve got version 6800(?). I’ll do some wider testing for you when I am home again
Extra testing completed!
When I open other ships, they look like this:
Which is bizarre, as the Detroyat that I’m rigging for Major Stress shows up fine, except for the yellow stripes
When I save a ship from DAEnerys to DAE which I had entered HOLD_PARAMS data into it is stripped out
You’ll be pleased to know though that adding and manipulating joints, markers and NavLights are now easier than ever!
I just heard of these parameters a week ago or so, so DAEnerys ignores them right now, because it doesn’t even know what to do with them.
@radar3301 We will need a good way to implement these parameters without having to hardcode them… any ideas?
Sorry for all the inconveniences and stuff, I hope we can fix all of that for the next release. But I can’t give you any dates yet, because I can’t really work much on it currently…
That’s very nice to hear.
I have no idea what these are… Anyone care to point me in the right direction?
They are used to change shader uniform values by material and by HOD.
Asteroid_3 from the Workshop examples, it has some.
MAT[material_name]_ PARAM[param_name]_ Type[RGBA]_ Data[r,g,b,a]
HODOR’s logic is built to be more flexible - but at the moment only cares about RGBA & 4 values. So if the param on the shader uses fewer, that’s fine. It it needs more, probably need to break it out into multiple params!
If you know what surface the material named is using, you might have parsed the surf file to know what properties it exposes, so you could make a visual editor.
@PayDay: The least hardcode-y way I can think of:
When navigating through the joint hierarchy, if the parser encounter a node named “HOLD_PARAMS”, create a “copy” or reference to that node, then skip it. Then on export/save, check to see if that variable has been set, and if it has, write that node.
@BitVenom: That’s actually not a bad idea. Yes, the surface files do get parsed. Also, omg…
To be honest, I was more thinking of parsing them and making them editable with a GUI tab.
(WYSIWYG) with the shaders…
No inconvenience, I am actually a bit slow at helping you guys by running through rigging a ship and testing for you
This would be fantastic! I don’t know if there’s any way to recognise if a shader asks for PARAMS and pop up the option at that point? I don’t see the shipAnim shader rendered in DAEnerys, is this likely to happen? I’m curious
Honestly, it should be… not sure what is happening…
b6800 doesn’t have the new manifest yet.
Well, that would do it…
I finally got around to parsing .big archives, so (@PayDay permitting), I’m about to do away with the need to extract .big archives.
Yaay! So the user chooses the HWRM directory and it extracts the needed data?
But keep in mind that the ability to choose mod directories has to stay.
Just spent ages chasing a HODOR crash because this:
<image id="IMG[trp_platform]_FMT[DXT1]-image" name="IMG[trp_platform]_FMT[DXT1]">
should have been this:
<image id="IMG[trp_platform_DIFF]_FMT[DXT1]-image" name="IMG[trp_platform_DIFF]_FMT[DXT1]">
Any chance DAENerys could warn about that?
@PayDay Small Bug Report.
I had a .dae file with joints and everything except for the collision mesh. I imported the collision mesh without any issue and saved the new .dae. However, when I opened the new .dae, several weapon joints had their orientation angles messed up.
Are the weapon joints messed up even if you just load and straight save the file?
Nope. After I realized where the problem was in my workflow, I corrected the values and saved through DAEnerys, followed by a successful result in-game post HODOR.