I set up the turret with all the barrels needed, and then copy the whole turret and all slaves attached with it.
I cant seem to get that toolkit working at all and when I export DAE from blender the DAE crashes Hodor, IM porting FBX in order to be able to correct dockpaths that rodoh removed names from, collectors and what not wont spawn because of It. @DKesserich any help or advice will be much appreciated, got over 400 hods to do X_X
What does the tree view for these things look like? And their materials? When getting started materials tend to kill things. Maybe try HOD-ing them with no textures and see if that works.
ive already mass batch converted to remastered so I got the hods already BUT, the ships that have dock paths for collectors and frigates are blank name wise, so they don’t spawn, when I try to convert from the DAE that rodoh made into FBX to put into blender and in order to edit the family list for it and convert bck to DAE, hodor crashes as a result and they don’t got textures when imported to blender.
Edit dock path families are blank when viewed in cold fusion for some of the paths.
Sanity checks: Make sure you’ve enabled the plugin, and that you’re using the new export option it adds rather than still using the dae export option that comes with blender.
that’s where I’m having problems its not the drop and go type of thing, tried enabling the plug in but its not working.
Well its working for me…i just Dropped it into the Addons file and it worked
Are you saying that the toolkit isn’t showing up in User Preferences->Addons at all, or that when you export with the Better Collada-HW option that HODOR is crashing on that DAE?
If the former: Can you post a screenshot of your Blender add-ons folder?
The folder structure should be [Your Blender Folder][Blender Version]\scripts\addons\HW_Toolkit[init.py, export_dae.py, and joint_tools.py]
If the latter: Can you maybe zip up a RODOH’ed DAE and textures and put them somewhere I can get them? I haven’t done any testing of the RODOH->Blender->HODOR chain, so I can’t even make a guess on what the issue might be there.
So, getting off my butt to fix some flawed ports… This ship is a HW2 hod that’s been RODOHed, then put through the autodesk fbx converter, than imported into blender. The dock paths are my first focus, since there’s some stuff about docking and launching that doesn’t work right when piped straight through HODOR.
First, I want to verify that the utilitydock’s syntax is valid. I am guessing that it happened because otherwise the node name would be too long, but I’d like to verify it. Second, the highlighted node… is the number on the end likely to cause any troubles? It seems like it might, and it’ll be a bit annoying to have to try to introduce subtle variances to avoid it. I’m hoping this is an issue someone else already has a good solution to.
Edit: On reflection a more full look at the hierarchy might be useful so, here:
The number suffix shouldn’t cause any problems, but the way I have the exporter working right now, actually having the Tolerance, Speed and Flags in the object name instead of as custom properties of the objects will. The way I set it up for dockpaths is that when you create new dock paths it makes the empties with custom properties for Speed and Flags, then when the exporter runs it checks for objects with ‘SEG[’ in the name, then gets the draw size, and the values of the Speed and Flags properties and appends them into the name of the node.
I didn’t put in any checking for those values already being in the name, and the exporter will error out and fail when it doesn’t find the Speed property.
This is actually the first time I’ve seen the SUB_PARAMS nodes, since I’ve never done any RODOHing of older HODs, so I assume syntax wise that those are correct, but for all I know the numerical suffix might be messing up HODOR.
My recommendation to LeviathansWrath was that if the only thing you’re doing is trying to fix the dock path node names in a DAE output from RODOH, it’s probably easier to edit the XML by hand then to try to put it through Blender and re-export it.
Well, something is screwy about how rodoh handles dock paths, as some of them make it through fine but not all of them. For instance my mothership never actually launches harvesters it builds. I’d opened in blender to try to figure out why this sort of problem is happening.
It’d be nice to have a way to convert rodohed dock paths into the format the toolkit eses, besides doing it manually, but I suppose that’s not critical at the moment.
Not a functionality breaker, but thought I’d mention that I’m not seeing spheres for dockpath nodes, they’re just being rendered like any other nodes. Blender 2.75 and toolkit version 1.1.2. Also, it’d be useful to have a reference of know-good flags in the interface.
Is this for imported dock paths, or new dock paths?
Imported dock path nodes won’t have sphere set as the draw option, new ones will (confirmed in 2.74, 2.75, and 2.76rc1)
New ones, made through the toolkit’s tools for them.
It appears to be somewhat context related. If I make a new clean file and set up a ship in it, dock path nodes are created with the sphere icon, if I add a dock path to a rohod’d ship file they don’t.
A small bug report for you: the exporter errors if I try to export with certain objects hidden in the blender scene. I haven’t doen an exhaustive test of what does and doesn’t cause errors, but the ROOT_COL object and children definitely do it. Sent me hunting other potential issues for a while before I nailed that one down.
Here I am again!
I’m going somewhat bonkers figuring this out, so I’m going to throw it up here and hope someone can tell me what’s going wrong, how to fix it, or how to avoid it in starting over from scratch.
I have a simple destroyer, and I want to set up it’s turrets. I’ve ported this mesh over from wings3d, and there’s been a lot of fumbling with both the toolkit and blender’s interface to try to figure out what’s going on. The turret orientations are wrong in game.
Not sure wtf I’m doing, I’ve resorted to comparing the blend with a rodoh’d hod that I know works decently well.
Okay, that looks good, which makes sense as the hull imports fine. On to the weapon position joint…
All good. Next the position joint’s mesh…
Okay, wat. The turret mesh’s axis (set to show local for both) are different, and the mesh is aligned properly but it’s origin is weird. That view shows it poorly, but the mesh origin is pretty much at the model origin. In writing this I hit along the way to fix the origin location, I’m not sure how to find it in menues but ctrl+shift+alt+c brings up the tool. However, the weirdness of the local coordinate system is still there, which I presume is how the cause of this result:
Somehow this weird axes orientation has wormed its way into the weapon joints under the position joints too. I’ve yet to hit on any way to correct that issue.
Have you already done a Ctrl+A on the joints/meshes to reset their local transforms?
Some of the posts I saw above seemed to suggest we’re not supposed to do that anymore, and doing it just re-breaks the meshs’ origins without fixing their local coordinate orientations.