[1.0.x] [V1.9f] Kerbal Foundries wheels, anti-grav repulsors and tracks

[Geschosskopf]

I just wanted to share this and say thank you. I couldnt have made this without this mod and many others. Thanks you!

Outstanding work there! I especially liked the schene of the Kerbal jumping with the explosive spears. How many takes did that need?

[Gaalidas]

Bad times ahead :/

I've run into that unity package during my own research - he does seem to know his stuff. The problem here will be that everything will get tied into the stock modules to implement the workarounds in that package. Now, I would either have to implement the same sort of fixes myself (if I'm even able) or just use the stock modules. Which means none of the more advanced KF features any more. Neither way will allow the tracks to survive

Thanks for the info, I'll be keeping a close eye.

Leave it to these crazies to attempt to further fix something and end up breaking it more than before, and ruining our ability to make it all better.

[DarthWall]

Hey, any news about the magnetic/gravitacional RCS? This days I was playing with a little craft fully of RCS thrusters and infinite RCS fuel, and... is awesome to control a craft like the ones of sci-fi movies. And, since this mod already have those repulsors...

[NoMrBond]

Thanks for the info, I'll be keeping a close eye.

If Ferram could get the 'mod is handling this' flag for aero so that FAR could bypass the stock system you may be able to manage the same for wheels, wheeloids and things wheelish

I suggest firing a PM to one of the devs (if not HarvesteR himself), the earlier in their own wheel dev you can let them know, the more likely it is they can accommodate your case

[lo-fi]

A little more research reveals that all the bitching is more or less because people can't configure the new colliders properly. I'll grab unity 5 and play around to get a head start. Rumour is also that they've fixed the broken grip model, which is actually really good news.

[riocrokite]

A little more research reveals that all the bitching is more or less because people can't configure the new colliders properly. I'll grab unity 5 and play around to get a head start. Rumour is also that they've fixed the broken grip model, which is actually really good news.

nice, really cool that you keep your finger on the pulse

edit: I played with wheel resistance and mass modifier a bit and can't fix situation when wheels /tracks accelerate FASTER when vehicle is heavier (even 10x heavier vehicle accelerates as fast as lighter one).

[lo-fi]

I've never found that: Heavier rovers accelerate slower, as I recall. Or at least that was always the case with my mining rig... Otherwise, it's a physics bug, but would be quite a fundamental one. The colliders apply a force, the force acts against the mass of the vessel. I'll do a little testing myself.

Edit: well that's odd! I may have to go back and check on some older versions, I swear it never used to behave like that. Yes, I can reproduce what you're talking about. That's a pretty major physics bug right there!

Edited May 28, 2015 by lo-fi

[Gaalidas]

I know that there are some strange things done when the tracks/wheels are also scaled up to accommodate the heavier and larger craft, but if you're using the standard scale I would expect the heavier one to accelerate and handle more like an obese pregnant yak with a lame foot. I keep meaning to find a few places where I am unsure why you did what you did when the wheels are scaled up, but at the moment I forgot my references in the code and I'm too lazy right now to dig them up. That, and I have yet to test my local tweaks in my latest recompile of the mod. maybe I'll get around to doing that later and can finally merge the changes needed to integrate DustFX fully with KF. All that needs to be figured out after that is how I might make use of the "tweakscalecorrector" field to modify the base dust effects without having to merge the dust effects with the KFWheel module itself.

hmm... I wonder how hard it would be to grab the value of that variable from outside of that module and use it in mine... must do some research later... after my Statistics quiz. -shudder-

EDIT: Nailed it! (both the quiz and the variable grabber). Turns out all I had to do was instantiate the KFModuleWheel class and point a getter towards the variable I wanted. Hopefully that will grab the value for the current part properly. Needs testing I suppose.

Edited May 29, 2015 by Gaalidas

[Hookswords]

Outstanding work there! I especially liked the schene of the Kerbal jumping with the explosive spears. How many takes did that need?

Only a couple. It was a matter of dialing in the distance the car had to be behind the war rig. I was driving both of them with Burn together, but they have different take off accelerations.

[lo-fi]

I know that there are some strange things done when the tracks/wheels are also scaled up to accommodate the heavier and larger craft, but if you're using the standard scale I would expect the heavier one to accelerate and handle more like an obese pregnant yak with a lame foot. I keep meaning to find a few places where I am unsure why you did what you did when the wheels are scaled up, but at the moment I forgot my references in the code and I'm too lazy right now to dig them up. That, and I have yet to test my local tweaks in my latest recompile of the mod. maybe I'll get around to doing that later and can finally merge the changes needed to integrate DustFX fully with KF. All that needs to be figured out after that is how I might make use of the "tweakscalecorrector" field to modify the base dust effects without having to merge the dust effects with the KFWheel module itself.

hmm... I wonder how hard it would be to grab the value of that variable from outside of that module and use it in mine... must do some research later... after my Statistics quiz. -shudder-

EDIT: Nailed it! (both the quiz and the variable grabber). Turns out all I had to do was instantiate the KFModuleWheel class and point a getter towards the variable I wanted. Hopefully that will grab the value for the current part properly. Needs testing I suppose.

Look at KFWheel. you'll see it finds the isntance of KFModuleWheel in the part and references some variables from there.

Testing reveals that there is a major physics bug as far as wheels are concerned. Vehicle mass does not affect acceleration. I have no idea where to start with this one, and it's well beyond my scope to fix, so I'm simply going to quietly ignore it.

[riocrokite]

Look at KFWheel. you'll see it finds the isntance of KFModuleWheel in the part and references some variables from there.

Testing reveals that there is a major physics bug as far as wheels are concerned. Vehicle mass does not affect acceleration. I have no idea where to start with this one, and it's well beyond my scope to fix, so I'm simply going to quietly ignore it.

Hmmm, it might be unity bug:

http://forum.unity3d.com/threads/wheelcollider-not-affected-by-rigibody-weight.268328/

http://forum.unity3d.com/threads/weight-of-my-car-problem.267942/

Yah it will be interesting to see how it behaves in new version.

[lo-fi]

Hmmm. There is a mass property of the wheel colliders, which _does_ affect acceleration. Passing the vessel mass to this would be problematic when dealing with changing fuel loads, docking, lithobraking, etc. I really don't want to be checking the vessel mass every frame! Not an easy problem.

[ShadyAct]

I like the experimental rover body.

[Gaalidas]

Look at KFWheel. you'll see it finds the isntance of KFModuleWheel in the part and references some variables from there.

How did I not notice that before? I'm such a noob sometimes.

[shdwlrd]

The small and medium tracks are over heating and exploding when I try to launch them into orbit. They will stay at the same temperature as the part that they are attached to until about 25000m. From 25000m to 32000m their temperature will rise extremely quickly and explode at about 33000m. You can put them in a service bay, cargo bay, put a fairing around them, or leave them exposed. The result is the same. The only other mod I have installed is MJ. Tested with a clean refresh from Steam.

[lo-fi]

I've made enough noob mistakes myself....

By the way, I've just updated the ERS wheel to include the retract mode, as well as fixing the tyre tread. Also started a new thread here to gather some ideas. New potential collaboration with a veteran modder on the horizon... watch this space

[Gaalidas]

Really? A veteran you say? I didn't think they still made those... Last one I found was locked away in a cabinet at the back of an antique store. You know the ones, which those signs that say "Completely Not-Stolen Legitimately Illegitimate Antiques, made just for you on a daily basis!"

Awesome stuff with the ERS wheel though. I'll see if any updates need to be done to the MM patch version of it. Great news on the DustFX scene too. I have successfully split the module into two versions: Wheel/Track and Repulsor. The repulsors don't seem to make any use of tweakScaleCorrector, so I stripped out most of what I was doing with that and replaced it with a modification based on the ride height of the part. The one thing that worries me about that, however, is that I'm only grabbing the value when the part is initialized... but I've got a few ideas on how to update that. I may need to move the setter for that variable into the method that defines the dust color, which is updated quite often and should be active enough to catch changes in Ride height during the flight.

Of course, all of this lacks any proper testing due to my OCD when it comes to building rovers. if I'm not completely happy with it, it doesn't get launched.

The only other thing I would like to implement that was part of CollisionFX is something specific to the screw and skids. Those parts, when moving over especially-hard materials, have the potential to throw up sparks due to the fact that they're not exactly rolling over the terrain, but rather scraping along. I'm gonna have to do some digging to see if pizza-whatever-his-name-is ever got the sparks to only fire off when colliding with non-planetary-collider surfaces.

I've also been experimenting (well, I experimented with the config, haven't actually tried it yet) of adding the FSbuoyancy module to the screw so that they actually float in addition to your propeller module. I hate to do anything that would add a dependency to that part though.

EDIT: Oh, hey, a thought about the overheating problem. As a short term fix/hack you could simply double the maximum heat tolerance of the parts. In a more long term fix/hack... I wonder if an animation state could be added to the rest of the parts, taking the ERS wheels as an example, which would put the part in a "packed state" where the suspension would be put in a fully-contracted position and, as a nice side-effect, the part would then spoof the game into thinking they are fully shielded (something we'll have to do some coding work to achieve) as if they were under a fairing. This goes along with my long-standing idea that the repulsors (specifically the non-surface ones) need to have a fully-retracted state that causes the repulsion-pod (I'm making this up as I go along) pull up and rotate to face outwards to show that it is "turned off" which would also make it take up less horizontal space. I wish I could create an image of what I'm seeing in my head right now. It would sure make things easier.

- - - Updated - - -

The small and medium tracks are over heating and exploding when I try to launch them into orbit. They will stay at the same temperature as the part that they are attached to until about 25000m. From 25000m to 32000m their temperature will rise extremely quickly and explode at about 33000m. You can put them in a service bay, cargo bay, put a fairing around them, or leave them exposed. The result is the same. The only other mod I have installed is MJ. Tested with a clean refresh from Steam.

This is a problem we are looking into, as shown by my above posting. The issue isn't related to other mods, but rather with the mesh and the way it is handled in KSP, which is kinda weird, which causes the part to not get shielded properly because it thinks the part is sticking outside of the fairing.

EDIT2: So, lo-fi, moving my DustFX source files into the main source directory is going to conflict with my local copy, which I've put into a sub-directory to keep things organized. It really doesn't affect the compilation process or over complicate anything in the coding process, so I'd like to leave it separated like that if possible, at least until I finish tweaking and integrating it.

Edited May 31, 2015 by Gaalidas

[lo-fi]

I swear your posts are getting longer, Gaalidas!

That all sounds fantastic! The problem is with the track surface, being a skinned mesh, so no matter what you do with it, KSP will think it's ten times bigger than it actually it. Very annoying.

Did I move the source files? I wondered what happened there. I'll see what I can do to fix that.

Also, much change with other modules, and I'm gearing up to do the USI style texture sharing. Keep an eye for commits - you'll no doubt end up pointing out the mess I end up making!

Edited May 31, 2015 by lo-fi

[Gaalidas]

Hey, that's what I'm here for... amongst other things.

I'll try to upload my latest changes soon. On the plus side, the only change I've made to any of the files is adding a part info override, which can be overridden in the config file if necessary, and that's pretty much it. Anyway, yeah... the DustFX stuff got moved from their own directory to the main directory. In the next upload I make some of the files have a name change applied too, so that should sort everything out.

I'm just waiting for a chance to do a little testing before I commit the whole thing. I still want to make some additions to the whole system, and there are likely some tweaks and optimizations I can make to the whole thing now that I'm tying them directly to the KF wheels. Also, in the far future, I would like to see if there are other effect types that could replace what the dust is currently emitted from which might provide a more natural effect. We'll just have to see how that goes, and if any of this still works when the next major KSP update comes about.

I still think there's got to be a way to trick KSP into thinking that the tracks are, when placed in a "packed" state, that they are, themselves, a super-heat-resistant part that completely overrides anything that KSP wants to do to it. Sorta like the physics-less parts in the old days. It's not an ideal fix, but it would do the trick. I'll have to do some digging in the heat-system modules using ILSpy one of these days, see if there are any override parameters that have gone undocumented.

Edited June 1, 2015 by Gaalidas

[ZodiusInfuser]

There's some comments about wheel colliders in the latest Squadcast (around 8 minutes in): http://www.twitch.tv/ksptv/v/5591096

Edit: I should say it sounds rather positive.

Also, and idea when a new DLL for Kerbal Foundries will go out. It sounds like KSP 1.0.3 will be a while away yet, so I may try and get the Mecanum wheels out before it.

Edited June 1, 2015 by ZodiusInfuser

[lo-fi]

Cool, I'll check it out. Bet the stock modules are still pants, though.

I'm desperately trying to tie up loose ends, much as it looks like nothing is happening. Won't be long! I messed with so much, I need to check I haven't broken anything in the process. Sort of trying to get a few models done for the next release too. Also, on course for stream this week. I've chosen something to model - let's hope no more relatives kick the bucket beforehand this time :/

[Gaalidas]

Those crazy relatives are always kicking buckets at the wrong times. It's all about communication... or the lack of it. if you intend to go to the farm, do us all a favor and present a timetable so we can plan accordingly. Eesh!

Anyway, as lo-fi has said, loose ends need to be tied up. I have a feeling my recent additions aren't helping with that either, but those will be tied up soon too. It's gonna be awesome though.

UPDATE: Alright, I did a merge to github. The bad news is that, in order to be sure that DustFX (more accurately called KFDustFX and KFRepulsorDustFX) and the old CollisionFX modules don't conflict, I had to implement the module using Module Manager. Considering nearly everyone who uses mods at all will already have it, I don't even consider this "bad news" necessarily. Eventually I would like to find a way to detect the presence of CollisionFX on the parts, those of which have the KFDustFX module as well, and disable the offending module when the part is initialized. This would eliminate the dependency on MM. Ideally, in the far future, being able to break free from the extra module and turn DustFX into a called method from the standard KF modules, which would allow me to eliminate the current collision detection techniques and simply re-use what the KF modules use themselves (water-spray when repulsing over the water, that would be awesome)... well, a guy can dream.

So, in conclusion, everything should would as it is (totally untested, but it's not really any major change from the original DustFX implementation, so everything should work like before) but I'm nowhere near being done tweaking it.

In other news, I've updated a number of mistyped module names in the wheel configs, and removed some previously-commented redundant/unnecessary modules. Also cleaned up the moved source files and restored the files in the DustFX sub-directory.

Edited June 1, 2015 by Gaalidas

[lo-fi]

Tell me about it. Most inconvenient!

Cool, I'm all synced up. You'll have to learn how to use reflection to find other modules without creating a hard dependency... I have no clue where to start.

A couple of thoughts on the dust: It looks wicked. Really pleased with it. but I noticed it seems to grab hold of one of the colliders on tracks and repulsors and display the effect from there. I wonder if there's a way to find all the collision points - rather than just the closest one - and average between them. Also, you can access a lot of the variables from KFModuleWheel, and I can make certain other things available. Wheel collider slip springs to mind, as this could be used to add more dust when slipping. Just ideas, but it seems like something worth enhancing. Also, we need some more sounds!!

I'm working on little bits (currently the LookAt module) that will enable the more esoteric parts to be sent live. I'm hoping to get at least the BV track finished and ready for release. Riocrokite has reminded me about the inflatable wheels idea too. Now I've got the retract animation stuff going properly, I'd like to have a go at making some too. Exciting times! Until Unity 5 turns everything straight to hell.

[Gaalidas]

Well, on the bright side, stock aerodynamics update was going to send everything to hell (or heaven, if you're a realist... in which case KSP is not the best fit for you) and it's turned out alright. Doesn't make me feel any better about it, but I don't have much of a clue what it means from the programmer perspective, so I'm keeping an open mind.

Those ideas sound great. I have absolutely no clue how to do that though. Keep in mind, everything I've overhauled is still, at its core, straight from CollisionFX. Whenever I break something completely, that old mod is still my go-to to figure out what I've done and get it working again. The whole collider detection stuff is some of the most confusing parts of the whole thing too, so I'd welcome your own mucking about with the code. My baby is really just the addition of an external config file to define colors/biomes/planets and all that. Previously it was hard-coded, which is simply not acceptable, and even then the code is really from xEvilreaperx. All I did was pester him for help and combine it with the original PQS detection stuff.

My only worry with emitting from multiple colliders in a sing part is that, when using many different wheel-type parts, you'll overload your performance with all the dust you'll be emitting. I would actually love it if you could somehow detect the collision that is furthest towards the rear of the part (pretty much dead center for a wheel, but would be pretty far back for a track) and emit from there. However, since tracks can throw up dust when turning in place, the effect would lose its cool factor in that instance. I'm actually not sure even the current system would detect movement during in-place turning with a track.

So, it's all quite the work in progress. I'd also like to see the particle stream itself done differently so that, upon changing biomes or surfaces that produce different colored particles, we don't get the entire particle effect changing all at once but only the new particles being produced by the collision. This would probably mean we'd need to start using a real particle emitter, instead of a simple smoke effect. I'm unsure if we could get the same results from a particle system though.

[lo-fi]

I'll cast an eye over it. Battling vector maths at the moment trying to make a working LookAt controller. It's not easy.... I've started moving all the parts into one folder and moving to model nodes too.