-
Posts
2,419 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Everything posted by lo-fi
-
Hmmm, that's an interesting problem. Anything nasty in the log? Hierarchy looks fine, as does the config, though it's tricky to be absolutely sure without seeing the positions of the transforms. The worst that will happen with the FXModules is they don't work or you get objects pointing odd directions. They don't even seem to null-ref if the object names are wrong, unlike other modules.
-
Of course, I'll package up shortly. There are (what looks like) dependency loops even in the stock stuff and my large wheels also use a similar setup. https://www.dropbox.com/s/a31ho9nd8pyky6q/SkylonGearTorqueArmDemo.unitypackage?dl=0 EDIT: Apologies if it doesn't bring the model into the scene, Unity can be a bit funny about that when the prefab is broken before export. I had to cheat because the torque arms transforms were not aligned correctly and I couldn't be bothered to sort out in 3ds and re-export, so I added a couple of dummy GO's, of which both the mesh and end objects are children. Post your config and a screen grab showing your Unity hierarchy?
-
Ah, assumption is the mother of all (redacted)-ups, and all that It won't work in 3ds (yes, it does complain about a loop - I assume the same in Blender), but KSP works fine. This is because of the serial nature in which things are processed, which gives limitations in itself (the first constraint is always 1 physics frame behind the second), but it's absolutely suffer-able for our purposes here. Agreed the position constraint has its limitations , though my only ask over what it does now would be that relative position is maintained to the target rather than snapping to the same position. It's quite manageable with a few tricks, though, and I find it very useful.
-
Why? They work just fine for me in far more complicated hierarchies. And why are you even using ConstrainPosition here? Just child the torque arms to the lower and upper part of the strut respectively. Constrain position is only particularly helpful if you want to translate an object with the position of another but not inherit rotation, or vice-versa. Otherwise it's a pointless waste of resources and a very unwieldy way to configure things. Now, ignore the fact that half the mesh has the normals mangled and the animation may not be exactly as it should be and watch the torque arms: The only thing in the config driving this is as follows: MODULE { name = FXModuleLookAtConstraint CONSTRAINLOOKFX { targetName = DLBEnd rotatorsName = DLT } CONSTRAINLOOKFX { targetName = DLTEnd rotatorsName = DLB } } DLTEnd and DLBEnd are empty gameobjects used as targets. They are children of each torque arm placed at the end of each where the pin would be. It's simple: each torque arm (DLB and DLT) is set to look at the object on the end of the other. With the usual caveats that they must have the Z axis orientated where you want them to 'look', of course. The piston is animated with the gear raise/lower. I saw no reason to use a lookat here, it only ever performs one pre-determined motion. I can bundle up the Unity stuff and the part, but it's configured to be driven by my plugin, not FS or stock, and it's Unity 422.
-
Some invaluable info there from nli2work. Knowledge many of us (myself included) probably take for granted. The point about modeling with pivots aligned for how you want the parts to move is a very good one. I would second that if you do this with a weather eye on how it will be set up in unity it removes the need to rejig the hierarchy, which saves a lot of work. It also means you don't break the prefab, so if you update the model the changes are still automatically updated from the fbx, dae, blend or whatever automatically in Unity. I go so far as to add dummy objects before export - a good example would be the torque arms that need a GameObject on the ends for the LookAt to point towards. Sounds like you're very close to getting this nailed, though.
-
I've been meaning to take a look at the new TT wheels. The models are a bit contemporary for my taste, but they have some really nice features. The steering stuff has all changed now, spanner. No hierarchy changes needed - the new plugin will even drive the stock wheels if you replace modulewheel in the config. As long as you know the transform names, its easy to set-up existing stuff without re-rigging in Unity Looking forward to demonstrating!
-
That ought to happen even with the stock module, provided the grip settings are correct. The mesh rotation is bound to that of the collider.
-
Not quite sure what you mean?
-
I sort of got frustrated with setting up stock gear, thought 'I can do better' and got distracted into writing my own plugin. I'll have another look at stock at some point, see if I can make a reasonable tutorial. I didn't so much take over from Orbitus, I just thought of a different method whilst trying to help him with his plugin. We found that a lot of stuff that worked perfectly well in vanilla Unity just doesn't in KSP, so I think it's been left where it was. My plugin followed, but it doesn't really have anything in common and my swing beam method is just a cunning trick with standard tools in the config and rigging. Looks like nli2work has got you heading in the right direction, but do shout if I can help. I'll try and keep an eye on the thread.
-
No, not at all! I have it all working beautifully I thought you were going to use Firespitter, and my plugin is not quite as feature rich yet so I left you to it. What are you stuck on? Also, I keep meaning to do the youtube version of the wheel feed. Realised I missed a fair few bits out! If it's worth doing, its worth doing properly and all that.
-
Of course, but I'm about to totally change the code and part configs so it will have to wait until that is done and the next release happens. I appreciate the tracks in-particular are a bit daunting! It gets more-so with all the configurables in the new modules, so it will need documenting anyway. Hot water at the ready!! Oh, wait.... Sorry things have been a little quiet, we've all been hard at work behind the scenes creating and breaking stuff. Just about everything is about to change!!
-
Crazy, crazy planet. Code rebuild is coming along brilliantly. I've got one module which has all the functionality of ModuleWheel, plus all my tweakable and steering stuff. That module can drive tracks, wheels, hypnodrive and probably some other things I haven't thought of yet Lots of stuff will be jammed in the next release, it's going to be huge and hopefully worth the wait