Jump to content

lo-fi

Members
  • Posts

    2,419
  • Joined

  • Last visited

Everything posted by lo-fi

  1. 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.
  2. On that note, Alpha 1.7 just went live. Please see the release notes as there have been some hefty changes behind the scenes in the plugin.
  3. 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?
  4. 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.
  5. 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.
  6. 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.
  7. I just cant help myself. It's simply not in my nature to leave well alone!
  8. Kerbalstuff thankfully keeps old mod releases, so the worst would be a fresh download of 1.6d, but still.... I would rather know things work than not. Just working through some of the edge-case bugs I've caused myself, but considering the scope of it, I'm very pleased.
  9. 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!
  10. Cheers I'd love to get it all released before I go, but not unless I'm pretty darn sure I haven't left a load of stuff broken!
  11. 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.
  12. 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.
  13. ProbablyTM. Though it's not long now before I'm off on holiday until the end of the month so I'm running out of time to get the next update out!
  14. 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.
  15. The new microwaves are absolutely going to do your head in I'm afraid.. The price of progress!
  16. 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!!
  17. Interesting about the AG settings, I'll have to give that a go myself. Certainly the first I've seen of them on Eve!
  18. 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
  19. Me either. I saw some cool designs using balloons to reduce the dv needed to get off the surface, which seemed like a great idea.
  20. It's obviously been so long since I launched anything with a rocket motor rather than wheels I've forgotten what the KSP solar system is like I was thinking of Eve!
  21. They do look wicked when they are spinning fast! Love this experimental stuff, its so much fun Can't wait to get the next release out
×
×
  • Create New...