-
Posts
2,419 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Everything posted by lo-fi
-
No drama! There is one snag: I have to rig it again because Unity crashed out before I saved. I have the .mu, but that's really not much help! I've got the actual main gear model now though, so I'll get it fully rigged and bundled up for you to poke around with. My method is at least simple, so long as you follow a few rules when putting the hierarchy together. The plugin is far from finished, but contains the bits you're interested in (though the heavy lifting is all done in .cfg calls) and you can probably teach me a thing or two about the animation stuff! Actually, do you use GitHub? I've found it makes life so much easier on projects like this.
-
Alpha 1.3 out now! Track update, repulsor update, surface repulsors released. Download in OP from KerbalStuff. This modding malarkey is knackering! So much to think about, and then I forgot to update the configs for the wheels with weight and cost adjustments. Thanks I'd never heard of Robocraft before
-
Haha @Gaalidas You're too kind, Sir! Anyway, going to take a step back this evening and re-test all the parts that are waiting to be rolled into the next release. Tracks and repulsors are going to get a major overhaul, so this one will be savegame breaking. Sorry! Time to actually play some KSP, rather than fire it up, have a part do something spectacularly stupid on the runway, then close the game because you can't just reload the plugin after recompile. I hope you're ready, Jeb!
-
I'm sorry to say, nowhere Not because it's not possible, just because I've been busy with other stuff. It's probably two whole evenings work getting the longer set modelled, the track skinning set up just right (this is far from quick or easy), rigged in Unity, then forged into a workable parts. I wish I had more time! On the other hand, the plugin is in a much better state and I'm much happier with it
-
It's 'on the (long) list', as it were, but it's going to be a while until I get around to it. My plugin doesn't currently support two tracks on the same part and I'm on two minds about whether to do so - this limits which of the existing parts I can recreate anyway. I'm hesitant to add in dual track support because it adds in a lot of complexity, which = lots of opportunity for bugs. The smaller ones I can probably adapt given enough time.
-
Cool! As ever, shout if I can help at all. I'll keep an eye on the thread. I've been getting a little side-tracked myself (though into something sort of related). I've created a stand-alone plugin that detects which side of the vessel a part is placed and activates a left or right handed mesh appropriately. I'm fed up with seeing people struggle with what they think is 'mirror' symmetry, when, in actual fact, it's rotational symmetry. Will be very easy to use - all you need to do is bundle both the left and right handed meshes into one part, each within a named GameObject (left and right seem most appropriate, though I'l leave it to the modeller to choose) and the plugin will work its magic activating one side or the other as appropriate. 'Symmetry' clones automatically get the opposite mesh activated, so asymmetric parts are now possible without actually having two separate parts (that then aren't placeable with symmetry mode). I believe I mentioned I had this idea while I was chatting in the last livestream. This should be particularly helpful with landing gear A dedicated Dev thread will appear shortly and code will be completely permissively licensed.
-
Thank you. It gives me something meaningful to work with while I'm developing my plugin, so really helpful. I normally model stuff that has a lookAt in the correct starting position as the LookAt script doesn't work its magic until flight, so it's all left looking disconnected in the editor otherwise. Perfectly fine how it is for the moment, though. Cheers. I like simple solutions
-
I'm still working through getting the YouTube and reference materials sorted for the last one, then I'll set another. I'm thinking maybe the week after next.
-
You're very welcome, it's a pleasure As I was saying in another thread, we've got some really good momentum going with people sharing ideas and information about wheel related stuff, so I try to encourage and contribute myself as much as possible. rescaleFactor is definitely the way to go, though don't forget that the defaullt is 1.25! Scale doesn't change things like stack nodes and a whole bunch of other stuff. Both can be useful, though rescaleFactor is normally more so. I've just got some code running to detect which side a part is on and enable or disable certain objects within it accordingly. It's a long way from finished, but will enable you to put both the left and right handed model into one part and have the plugin activate the correct set of mesh depending on which side of the vessel the part has been placed on. I have to figure out how to hook into the editor attach functions, but this will just take some time. I'll get you to test out when it's ready if you're happy to do so? Night!
-
They're dev-team only at the moment, though I think are now ready for the next alpha. I've been bug-whacking/distracted by doing cool landing gear stuff, so I'm a little later releasing them than I'd like. I've just spent an evening battling a Blender export and about ready to tear my hair out, so getting back to business as usual will be quite welcome tomorrow! I keep diving off in different directions to look at other stuff that interests me, but every time I do I learn something I can use to improve my existing work. It's good, even if it makes things a little slow Bear with me. I'll organise the .zip using accepted mod convention if I remember!
-
If it makes you feel any better, I've just spent and evening battling stuff that's been exported from Blender with the transforms completely wrecked. Looks fine in 3ds, exports like a whole weird bunch of madness. Would be quicker to re-model, I think! A temporary workaround is possible: Create your two parts with stack nodes. Create a part that surface attaches and 'mirrors' correctly with a stack node that your handed parts will latch onto. Doesn't get you much further forward, but it's an easy way to get things reliably in the right place I must get around to making my 'mirror' plugin...
-
I'm afraid 'mirroring' in KSP is not mirror symmetry, it is rotational symmetry as you seem to be finding out. The only way to make handed parts like you've created that will place correctly with the symmetry mode will be with some clever Unity rigging and a custom plugin. I don't mean to be discouraging, but not a lot of sense in you beating your head against this one when you could be making more cool stuff I'm going to play around with some code to enable this at some point (someone told me procedural parts have something workable), but the stock game simply won't do what you want It's a shame, I know! Brilliant work, though!
-
Nice work, Steph! @Cpt. K: Just took a peek over here and found the render in the OP: http://forum.kerbalspaceprogram.com/threads/72802-Main-Landing-Gear-Rigging-Animating Yep, the hydraulics will be fine - very simple to set up. Regarding the nose gear alignment issues, I can see why you've had a challenge getting the proportions right. I've found so many different variants on the theme I wouldn't know which to go with myself! I think (actually I'm sure) the conceptual artists don't think about the finer points of the mechanical geometry provided it looks about right for that particular drawing. Currently the bay doors are too short or the gear is too long depending on how you want to look at it. :/ Is the nose gear you posted also modelled in the fully compressed state?
-
Good work:) Landing lights and everything!
-
I don't blame you! I did the same myself before tackling the animation stuff - I went out to the workshop and overhauled a carburetor this afternoon. I hope my research at least gets you heading in the right direction Such is the way with ambitious projects, but it wouldn't be fun if it was easy, would it
-
After having spoken to you in Orbitus' thread, my Unity crashed (which is the first time it's ever done so) and my entire rigged main gear disappeared. Annoying, but gives me a push to put it back together with a proper model if you'd like to send over. I'll rig it up and hand back over with source, plugin, parts and Unity package so at least you'll have something workable until Orbitus gets his method working. It gives options either way and adds an open-source landing gear module to the mix.
-
Because the wheelcollider starts out at the top of its travel and moves down from there. The SuspensionTraverse GameObject gets moved downwards by ModuleWheel as the collider travel extends up to its limit, and in the classic setup, all your movable stuff is hung off that GO. The 'neutral' position is ill defined by the spring strength, the weight upon it and the length of the suspension travel, so this would be rather hard to model for.
-
Feel free to send me a link as-is, be good to have something to work with. I can probably set up either way though, so you might as well model up in your preferred layout even if you send that later on and I re-rig it Suspension compressed is always the best way to start with it in Unity anyway, so that's a bonus. I'll continue in your Skylon thread to save cluttering Orbitus' with something that's not directly related. Haha. Yes, it made them sad Sorry, I may not have explained very clearly: It's not the wheelcolliders that are the problem, or their hierarchical position. You'll find if you remove the wheelcolliders you will still have the same issue(!). The problem you've got is caused by positions of GameObjects (or tranaforms as you like) in the part, not their hierarchy or anything going on in your code. When I say underneath, I mean below in the Y axis! That's what's getting stuck on the runway. And thanks We've got some good momentum going at the moment with the wheel research, even if it's insanely frustrating at times! See above. I've identified the problem, I'm just not sure I can fix it without stripping it right back to the start. The runway seems to have a different physics material (which wheelcolliders ignore anyway - another clue). Off the runway, the troublesome GO's drop through the terrain and the part is left supported on the good-old mesh colliders in the legs (or the wheel mesh if you left that in). I spent hours playing about last night before I had the idea for my alternative method, and I've been through a lot of this with the rover wheels - though some of this is new and very interesting information, much as it's causing you severe aggravation!!
-
I've cheated a little bit, I use two wheelcolliders. One is placed directly at the end of the suspension strut and this governs the movement of the strut via a gameobject called (by convention) SuspensionTraverse. There is a second wheelcollider that's placed behind the first, with double the suspension travel and above by half that travel. This has a SuspensionTraverse2 object that's moved by the code as usual, except this one moves no mesh directly. It moves the swingarm via a lookat to SuspensionTraverse2. The first collider governs the rotation of the front wheels mesh, the second the rear. The rear collider has much lighter springing than the primary, as the weight should be carried by the central collider, which is simulating all the wheels being on the ground, and thus compressing the suspension proper. I figured if we both attack it from different angles the least we gain is a better understanding. Code is in my dev repo (did I give you access already?), though being updated fast with wheel rotation, steering, animation etc. and I'll pass back rigged models when I've finished messing about. I've learned a lot doing this, I have piles of notes to put in my advanced rigging tutorial, as well as some stuff I can use to improve my existing modules I removed most of the superfluous mesh for clarity, will bung back in when I'm done testing. Edit: to answer your question about what's different with the colliders: Nothing, except I have no transforms below them. Testing with your module revealed a few things: The colliders calculate rotation, even if it's not them holding the model off the ground (or they're not actually enabled). The clues are: Brakes. Call the braketorque to the log and you'll see the brakes are not being applied even when the model seems glued to the runway. Rotating the wheelcolliders away from the floor leaves the part firmly planted on the floor (though now appearing to float). This is a dead give-away, which lead me to messing with transform placement in the model. I can get the colliders to do their job correctly so long as there are no transforms below their level in the part and they are enabled. I came to the firm conclusion that it's not a collider issue, but a topology issue I'm afraid. At very least, the tranform position of the master parts needs fixing (this is easy), but your CONTACT object also causes the issue and this seemed instrumental to your simulation working as it stands. I'm puzzled why you've got a separate raycast when you can use the racast from the collider, though? This might be a potential solution as (I think) you could do away with your CONTACT object and all will be good in the world. I could well be missing something fundamental, though
-
Thank you, I appreciate it Is your main gear model available please? I'll have my gear module working this afternoon, would be cool to test with the actual models and I'll package it all up to pass back. I'm going to open source everything once I've got to full release phase with my parts and I'll be encouraging more people to do the same! We've got some really good knowledge sharing going on at the moment, I want to keep that going.
-
That's another thing I missed in the tutorial: Wheel rotation axis. You've obviously figured it out, though. Don't worry, my first model didn't even look as good as that and I made all those mistakes myself That's the right way to go about it IMHO: start small and work your way through. Browsing round, I think there are a fair few people who launch in, make something really cool, then get frustrated when they can't rig it into something workable in-game.