lo-fi

The float issue is annoying. Both Zodius and myself have run into issues with placement. I'm not sure if its the exporter, ksp or ModuleWheel, but it's somewhat random to say the least. Traction for the big wheels... They're not really for low gravity - a bit big to be launching anywhere. Fun on Kerbin, however... I suspect some mod incompatibility for your control issues, I've not run into that or had it reported up to this point. I can't imagine what, though! Bung me and output_log if you get a few minutes? Glad you're enjoying the repulsors, I have yet to try the new engine with them.

Lovely piece of work, buddy 400m/s?? Keep an eye in the dev repo, I've been tweaking the repulsor dynamics. More height, better stability. Wheels will get an update too once I've got the Ackerman nailed. Initial tests show significant improvement in handling. The maths involved is.... challenging for my rusty skills. I've never done so much trig in my life! And thanks for testing in .24

Yeah, in working on a surface mount version that will mount like the linear RCS. Anyone tested with .24 yet?

Yeah, it's not difficult. Just needs a robust way to work. Almost nailed the Ackerman steering, btw, which makes the crab steer mode much better. Tracks are still proving tricky, though I'm waiting to hear back from squad about my big report on the tank steer mode.

When I tackle landing gear I'll post some details clarifying the process. I know how I want to set it up in Unity, I just haven't got round to modelling a part yet.

Really cool, I just saw your WIP thread! Was going to chime in later. Love the wheel and suspension design, that's a lovely piece of work.

I just registered and will be posting my mod later. Nice work - thank you!

Hello! Nice work. I used to play that game quite a bit, must have a copy lying around somewhere.. You're more than welcome to join us over here if it's something you're interested in: http://forum.kerbalspaceprogram.com/threads/84102-WIP-PARTS-PLUGIN-0-23-5-Kerbal-Foundries-wheelpack-anti-grav-repulsors Welcome to KSP modding

Ha! Wish you'd given me that tip before I embarked on this crazy journey Never trust a gnome. I learned that very early on in life I'll clear in a mo, sorry your messages have bounced! So it could be made to work Thank you yet again xEvilReeperx You were kind enough to help me through my initial hiccups and got me on the way, now I think you've just shown the way forward for walking on water! If you're happy, I'll grab the code and have a play to see what I can come up with for the repulsors. Absolute legend. If you have any more thoughts or come up with some refinements please let me know! Anyway, going back to what Gaalidas said earlier, I need to go create... Spending a lot of time communicating, which is great, and the feedback is fantastic, but it's keeping me from getting parts into KSP and improving the current ones. Can I ask the guys who've been helping me with testing to keep a weather eye on the thread and answer minor support queries (as you've kindly been doing) while I take a step back and get some serious mod-making done? I have quite a job-list: 1) I need to complete the reorganisation of all the project files and get some stuff updated for Justin and a few other people playing with textures, then hopefully this can truck along without too much input. 2) The repulsor class needs a re-write with a few new ideas and integration of the water code. Surface mount repulsors need making too, and all this pretty much hinges on developing my new method of working without ModuleWheel. 3) I've made a bit of a breakthrough with the tracks, but the next stage is going to take some time. These should be seriously fun to use and hopefully look just as good! 4) Landing gear and legs: I have some wicked ideas I need time to work on. 5) The crab-steer mode I've been working on with Zodius. This is really cool and deserves some time spent to make it easy to use. 6) Anti-roll needs another serious look with kujuman's latest findings. 7) Height adjustment needs a proper working method. I'm thinking action group and maybe a 'set all' button. So, like I said; I'm going to duck out temporarily, get my head down and churn out some parts Testing team, I'll be bunging parts into the dev repo when they're ready. Feel free to go nuts! Lo-Fi out! (for the moment).

Wow, seems like it's hit critical mass, I can't really keep up. People are talking about on Redit?? Busy for a few days IRL, and tidying up behind the scenes to speed the workflow. We do seem to have a really good bunch of people discussing and contributing Landing gear is on the list - I was going round Duxford museum on Sunday taking note of landing gear suspension designs. The air show was awesome too. Flush 'surface mount' repulsors will be available soon, they will mount like the linear RCS and come in a variety of sizes. I do have some ideas for a progressive 'cushion' effect too. Multiple wheels on one part is easy, spanner. See the tracks in dev as well. Speaking of which, having bypassed the tank steer mode of modulewheel, I now have properly controllable tracks. Rest of plugin now to write... Apologies to anyone I've not got back to, I seem to be doing more communicating than creation at the moment :/ That and my mailbox is full _again_.

I kind of had that thought, but I had no real idea how to implement it. Interested to see if you can come up with something.

I leave you guys alone for a few hours.... It works rather differently to my method... Which is basically just abusing the Unity physics objects and doesn't terrain follow as far as I know. Nice thought, though. I've got some on the way which will help, as they track the terrain ahead and behind as well as below. Glad you're having fun, I'm still playing with the dynamics and how far I can push it without resorting to writing my own collider.. As I thin I mentioned before, the repulsors were born out of my work with wheels and a silly forum conversation. I had _no_ idea how popular they (or any of the bits I've been playing with) would be, I just posted up with the wheels because I thought it was a goofy enough to be fun(ny)! There are some custom collider projects in Unity, but I've seen none that are ready to be pugged in and 'just work' and I'm not experienced enough to write from scratch yet. Higher ride is rather unstable on smaller craft, so I've limited until I've got the new versions out. All absolutely true. I honestly have no idea how water works in KSP, and it's not documented. There are some bits in the API that deal with buoyancy, but that doesn't really help with running wheelcolliders across it - I don't believe there is appropriate collision material, or it's set to a layer the wheelcolliders ignore. If someone knows enough to get me started, I might be able to look into it, but for the moment I'm stumped I have a feeling this would be a 'write a collider from scratch' job - see above. Again, though, if someone can light the way I'm happy to look into it. kujuman: I will get back you you re: anti roll. Requires a bit more thinking than after a few gins on a Monday night

That's perfect, thank you. I'll try out later and update the thread with what I find out about each of the functions I use.

Thanks, there are one or two things in there that are going to be really helpful! How do I actually go about hooking into them, though? I need to re-run a particular routine when and undock even happens, for example.

Ah, thank you! That makes sense of it. I wasn't looking at it quite the right way...

I've got some questions about the KSP update functions... By convention, I've been setting up my KSP modules like this: using System;using System.Collections.Generic; using System.Linq; using System.Text; using UnityEngine; namespace KerbalFoundries { [KSPModule("SmoothSteering")] public class SmoothSteering : PartModule { //Some stuff here } } Which works fine. But then I started looking into the update functions, and I found this post in the Help A Fellow Dev Thread: Some of the stuff in there looks really helpful, but it's only accessible if you specify [I]MyClassName[/I] : Part instead of MyClassName : PartModule Ok, but then you lose a lot of the functionality from PartModule. So, how do I use this (if I can)? The standard OnStart OnUpdate and OnFixedUpdate are usable, but you have to add a load of checks for which scene you're in and whether the vessel is currently focussed. It's not the biggest deal, but I reasoned that there must be a more elegant way of doing it through the KSP API. Am I looking at this all wrong, and if not, what have I missed? Thank you! I've managed to get further than I ever thought with what's been posted, I just get stuck and confused sometimes.

Just got a chance to look over this properly: Yes, that is strange.... I wonder if there's a good reason for that. It might explain the arbitrary nature of updates in KSP. I've noticed the value often gets updated if you drive around a bit, particularly off the side of the runway and back over. If you just sit there nothing ever happens. Maybe the simulation momentarily loses ground contact for a frame and that's when the update happens. I was hoping I could exploit this, but an enable/disablae wrecks everything. It took me a while thinking about this one, but it's actually wrong. The force method takes traction away from the outside wheel, as it tries to lift the lower side and push the higher side down and acts on the wheel as well. You might be tempted to think it would be a good thing, but result is rather variable (and strange!) turning characteristics. I'm not trying to build a simulation, but I hated the way things handled in KSP using that method. You need to increase the spring force on the outer side and lower it on the inner side for a dynamically effective method. This does apply a counter-rotational force to the vehicle, but the force acts upwards from the wheel contact with the ground in the opposite manner to applying a force to the whole vehicle as far as wheel contact is concerned. It's a subtle difference, but an important one... Thanks, that's because I messed up a sign in that equation. I don't think that will have made much of an impact as the roll equation outputs a differential, but it's worth fixing. Thank you for your efforts, but I have a nasty feeling this one may be intractable with the limitations we have in the wheelcolliders. I might do some testing in Unity and ask on the Unity forum to see what else I can dig up. Certainly useful as it's made me think things through more thoroughly. One other important thing you have highlighted is the list method which needs implementing.

Great, good to know about the 64 bit - thanks for that. We've discussed adding propelling forces, but consensus (and my firm opinion) is that its a stage too far. Nice effects ideas - some sort of hum would be good. Yes, they use electricity when on. But limited on how the physics objects work, so that's the dynamic for the moment. Someone would have to be really brave and write a custom collider to change much. You can already fly safely over craters on the Mun I'll add my hyper-RCS to the repo, it makes things a little easier. Though liquid fuel works rather well with a small engine.

That's kind of what I had in mind for effects.l I'll look at it when I have a few spare minutes

The list[] method seems to be how it's done in a lot of mods. I'm a C# newbie though (first project, first time I've touched the language or Unity), so I haven't quite figured out how to set up the list and have confidence it will work. The catch-all nature of the foreach loop is somewhat comforting too, as I know it's not something I can mess up easily while I'm worring about other things. It does need changing for performance, but the ability to reference an named collider is going to become important very soon too! Pointers greatly appreciated Yep, that's the one. So having established which wheel its partner is, each wheel stores its own suspension travel every physics frame (to be later queried by its partner) whilst also querying its partners (stored) travel and running the calculation itself. I have had it set up so each wheel queries its partners travel along with itself, rather than using a stored value, but there seemed to be no advantages in accuracy. The current method runs half the calculations, so that's what I went with. You'll find the anti-roll KSP field that displays the calculated value in the gui. Like I say, though, I can't implement without being able to dynamically update the .spring value, and that's the sticking point. The colliders just won't play ball no matter what I do - even a gui button which zeros the .spring value and passes back to the collider shows the same behaviour. Such a pity.. Just having some discussion and talking it through makes it clearer in my head, as well as leaving a little extra informal documentation for future mod-makers, so this is really helpful in lots of ways.

Love to see peoples creations, please do! You'll find someone (I forget who) already made a beautiful pod racer and posted a YouTube if you look back earlier in the thread. Glad you like the mod, early stages yet

I think I've got Ackerman correction well on the way, it's actually not difficult. An approximation, but so is most in real life. Not bad for a morning with a hangover. For anyone that's interested. http://www.rctek.com/technical/handling/ackerman_steering_principle.html Making no apologies for using the dev thread a bit like a blog, I'm hoping it may help out anyone looking through the sources in the future trying to figure out why I did what I did in the code and rigging. Code comments only go so far.

Hehe! Yeah, I kinda went there too.. I'm glad someone understands. Thanks, feel free. The code is in place to detect wheel pairs, that pretty solid. The catch is this: Anti-roll bars on vehicles connect the hubs each side via a sprung rod, suitably set up so it lets the wheels move up and down collectively but resists differential movement. Effectively it transfers some of the load from the loaded spring to the unloaded spring, so they behave as though the are weaker and stronger respectively. This can be modeled by calculating differential movement of the suspension either side and scaling the .spring parameter of the wheelcollider accordingly. Great! However... Updating an enabled collider does not result in the spring parameter being modified - it tends to sit there and ignore it, then it may or may not update 30 seconds later. I've seen it modeled (incorrectly) by simply adding forces to either side of the vehicle, but this gives some seriously weird dynamics because it unloads the wheel that should be doing the most work. Needless to say, I was not happy with it. I can hack a way to update the spring by disabling and enabling the collider, but this cannot be run in the update routine as it wrecks the rest of the simulation. I'm stuck! Thsnk you, any input would be most gratefully received.

I can't replicate, even on a clean install with the .zip downloaded from the repo (either dev or alpha). Check you've not got two versions of the plugin lurking, delete previous KF stuff and grab fresh from the repo.