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

[lo-fi]

Haha! IIRC, it's used to calculate the sound pitch as well. I also just realised that there should be an RPM readout on the parts, which has been disabled. Will be fixed in the next release.

[smjjames]

How do you determine what a balanced RPM is for the tracks and wheels? While it does work atm, having an RPM of 4,000 sounds rather absurd. It also seems to make it harder to control.

[lo-fi]

It depends on the size of the wheels and their power curve. I'll work out a better way one day! you'll find that a value of 1200 works quite nicely with that RBI model. It seems high, but don't forget that some of those road wheels are tiny! It's much easier when the RPM readout is active.

[Gaalidas]

See a few pages back... I've identified, fixed and given a full explanation. Down to one stupid little thing. So frustrating! It's fixed; now moving on. The dust works in the configs again. I had added a FIFO buffer into the dust, which takes away the sudden changes when the biome switches, as well as adding fixes for the dust camera making the dust look washed out and white. Ignore the commenting out of the KSPField's in the dust module; I was trying to narrow down what was causing the reflection error, which I was successful at in the end. I also found numerous bits I must have added in which weren't working as (presumably originally) expected, and have removed them. I can't see what effect the variance stuff is having, other than washing out the dust again?

And the step size thing is making no sense; what's that about? Be very, very careful if you're trying to change the step size of the sliders. There's some interaction with action groups that may lead to some unexpected consequences without further checking.

I totally missed that post, and so now I'm dealing with a compromise fix between the two "fixes" we both did, independently during the crisis the other day, that is giving me nullrefs that I cannot trace for some errant reason. The trouble I had, which led me to committing changes that fixed things back to how they should have been, was due to the fact that you did commit a change that included what appeared, at the time, to be like doing an ice-pick lobotomy on it. (Which, by the way, is incredibly easy to perform. If anyone wants a lobotomy, I'd be happy to experiment on them in my home. No guarantees over survival of the victim... err subject.) Anyway, that's all great. I just need to get a hold of that state of the source to work with so I can try to re-add my color variance to it.

By the way, I totally don't understand what you're trying to do with the dust size. The reason it's set with respect to "tweakScaleCorrector" is because it's supposed to scale with the size of the part. It's not clamped to an adjustable maximum because I wanted to make sure that there was a maximum that it could ever reach so we don't get rocket-booster-sized dust when TS reports an extreme scale value and sets our variable way too high. I already have the tweakScaleCorrector set to 1 if the part reports that it is a repulsor, since KFRepulsor doesn't use tweakScaleCorrector for anything, but setting that variable to 1 from the KFModuleWheel class as well completely circumvents any interaction with the TweakScale mod. Besides, the variable in the dust module that sets itself from tweakScaleCorrector (and is also named the same, which was only confusing for a few days when I first implemented that) automatically defaults to 1 before searching for any other value. Besides all that, when you renamed that variable to scaleCorrector (or something like that) it never got changed in the rest of the calculations and so you'd be left with it trying to multiply it's values by a nonexistent variable.

As for the slider for dust size and whatnot, I did that a long time ago so I could understand the different variables and what they did. That's how I got the information for the summaries about what represents what. I'm curious though... what does FIFO stand for?

EDIT: just watched the video... adding a slider to the GUI was totally not what I'd done before. That's awesome. That adds the possibility of all owing the end user to also limit the dust activity for more refined performance control.

Oh, and I forgot to talk about the other slider. So, I've tested that system a LOT and it seems to work without issue. I made a number of modifications to the current set of action group related methods and it's all quite stable. Basically, this lets you set the amount that will be added/subtracted from the ride height with every hit of the action group and/or when you side it with the ride-height slider (though, now that I talk about it here, I think I'll remove the change to the slider itself. That could get awkward.) I've already added clamps to the values so that if you're at, say rideHeight of 12, and pick an interval of 20, then it will try to increment the value by -20 and will clamp that value to the minimum (which is zero). Same with the maximum of course. I've fully integrated this into the repulsors and the wheels/tracks along with all the "apply" methods for both "apply to all" and "apply only to a single part" situations. This means it also works when using action groups to apply the settings across all wheels. However, to make things even easier to work with, it also checks the slider value on the update method and sets the new value for the action groups and slider on that update interval so that everything stays updated.

Now, I realize there's a lot that could go wrong in there, but I've tested it thoroughly (at least, I hope I have) and it all seems stable at the moment. However, now that I may have a working example of a GUI slider in action, I may remove all of that from there and make it into a KFPersistenceNanager variable with a slider which will then apply to all action-group related activity, but leaving the standard ride-height slider interval completely untouched. This seems like a better way to do it overall, reducing the number of sliders on each part's context menu.

The whole feature was created simply so I could make each press of the action group I set for "increase height" to increase by a larger or smaller number than the default +/- 5. I've also added preset levels for action groups, though I'm nowhere near being able to create user-specified presets like we can do in IR. In time all shall come to pass.

- - - Updated - - -

It's still going haywire, not fixed at all I'm afraid! Test conditions: Virgin install. repulsor gimbal, surface and normal, plus a few types of wheel as debris at the beach near the end of the runway. This means they're just just out of physics range when a new craft spawns. Drive into physics range, and all hell breaks loose, just as it did before.

EDIT: You know what caused all that trouble? This one little line:

[KSPField]
public const string dustEffectObject = "Effects/fx_smokeTrail_light";

Why would you declare a KSPField const??? It needs to be modifiable because it's got that attribute, which is why they're declared public. That's the entire reason for the bug, and the entire reason it didn't work when setup via the config. So frustrating.... The worst thing is it's not totally consistent.

Found the post!

That's really odd. CollisionFX doesn't have that field, it sets the effect in a hard-coded way. I have no clue how that became constant, because I know for a fact that no field should ever be constant. I'm guessing it's a left over situation from before it was a field at all. I made that a field when I discovered one of the other devs (probably you) had experimented with a different effect model. The only part which makes use of that field right now is the Mole track, due to it's massive size I set it to use the medium effect instead of the standard light effect. I really have no idea if it has any affect on the final output of the particles though. It was an experiment I never tested fully.

Okay, so we need to get our code synced up again. I use a separate development directory from the github synced directory on my system, so I'd like to get the master repository updated with your current working code and then I'll merge anything I've been experimenting with onto that.

This will go into the history books when future generations look up "major blunders made when overreacting to errors in code" since, as all of us KSP loyalists know, one day KSP will be the only physical simulation entertainment program in the world and we will be controlling our live (so to speak) spacecraft remotely from this platform. They will call us the founding fathers of modern physical simulation.

Or it'll all go south in a year or two and no one will remember any of this at all. I'm counting on the former ending.

Edited August 18, 2015 by Gaalidas

[lo-fi]

What I like about the slider is it's nice and easy. The GUI framework made it very simple to add in, so I went for it. You'll notice that I've worked the scale stuff a little differently since adding in the slider, which should now make more sense, I hope? The dust now scales with the slider, the field partSizeFactor, and the tweakscale coefficient of the part. It's all bundled up into one neat calculation waiting for the dust modules to pick up as needed.

I've got the step value thing now. I'm afraid there are some problems...

Put four repulsors on a craft.

Change the step value on one of them.

Use the action groups to change the height.

They all get way out of sync!

It kinda works as a mechanism with the UI slider; not so much for the AG's. And it's kinda complicated in an already technical system, which I'm a little worried about. The preset action groups are great, though, I really like that.

I'm quite aware that there are potentially people out there with games that are really broken by that debris bug, so I'd like to issue an update pronto! I know you were working on something too, but the last commit last night wouldn't build and still error'd, so I've disabled the features I'm not so sure about and left the code intact for hacking at another day.

All seems stable now as far as I've been able to test. Time will tell.

[Gaalidas]

What I like about the slider is it's nice and easy. The GUI framework made it very simple to add in, so I went for it. You'll notice that I've worked the scale stuff a little differently since adding in the slider, which should now make more sense, I hope? The dust now scales with the slider, the field partSizeFactor, and the tweakscale coefficient of the part. It's all bundled up into one neat calculation waiting for the dust modules to pick up as needed.

I've got the step value thing now. I'm afraid there are some problems...

Put four repulsors on a craft.

Change the step value on one of them.

Use the action groups to change the height.

They all get way out of sync!

It kinda works as a mechanism with the UI slider; not so much for the AG's. And it's kinda complicated in an already technical system, which I'm a little worried about. The preset action groups are great, though, I really like that.

I'm quite aware that there are potentially people out there with games that are really broken by that debris bug, so I'd like to issue an update pronto! I know you were working on something too, but the last commit last night wouldn't build and still error'd, so I've disabled the features I'm not so sure about and left the code intact for hacking at another day.

All seems stable now as far as I've been able to test. Time will tell.

I had something in there to figure all that out, but I forget how it all worked now. I've scrapped some of that right now, but I'd really just like to integrate the entire setting with a GUI slider now that we have something to work with. That way I can keep it synced between all the parts. I'll leave the context slider interval alone (at +/- 5) and make the change only affect the action groups. I'll work on that later. My recent commit won't be entirely stable in that area, but it's not going to hurt anything.

I'm starting to breathe again now that I've got everything merged up and I just committed what I have right now. I've totally deprecated the unnecessary variable that simply stated whether or not the dust was activated in the KFDustFX module. That one was left over from when I was converting from CollisionFX in which there were parts of the module that would work even if the dust itself was not activated. I forget now what it was called, but it's gone now.

I need to take a nap now. I'm exhausted after all that work to get things back in order again.

Like I said, they will make legends out of days like these one day.

By the way, love the tests being done with maxRPM. I never tried setting it to anything insane like 40k. Must have been rather entertaining.

EDIT: One thing I've discovered from all of my testing and whatnot is that totally "breaking" a save is actually quite difficult. Granted, I've never tried any of this with a career save, but I've been running the same persistence since KSP version 0.23.5 without issue. Yes, I've had to manually edit a few things to keep everyone happy in it, and I recently added Val into it by starting a second save and copying over the necessary data from the roster, but nother was every "broken" by any of this stuff. If someone is having issues with lag due to a part like a repulsor, then updates the plugin with the fix, the parts seem to get updated with the new state of things when they are initialized and the game is back to normal more or less. What mostly contributes to "broken" saves is when a bug like this is encountered and the user simply deletes the entire mod, parts and all. Then things start to legitimately break.

Edited August 18, 2015 by Gaalidas

[sashan]

I've tested the tracks a bit more. I must say the behavior is very realistic. It slides when turning at high speed, jumps etc.

Few problems are there, anyways. WHen climbing steep slopes the suspension is always compressed 100%. ALso, it is quite easy to compress 100% during rapid movements etc. Maybe you can make its stiffness nonlinear, increasing near full compression?

The main problem is how it hadles small steps. Get long tank tracks, scale them up 50%, go to Island runway and try to drive over those building remains. Despite tracks being large enough they simply bump into those blocks. I don't know how to simulate it, but this problem deserves fixing. With KerbalKonstructs such objects become common.

Edited August 18, 2015 by sashan

[Gaalidas]

For that issue, my only idea is that we need some secondary colliders set up at angles in front/back of the main wheel collider that are set up to detect collisions that are above the main collider and let us bump the main collider up to match the new collider's level if the difference lies between a certain range that represents the height at which the wheel/track can grasp that object and pull the craft up/forward onto it.

But what do I know, I'm just a humble dust coder.

Those mole tracks should at least be able to climb over barricades that are below half the height of the part itself (if the weight distribution of the craft allows for it, anyway). If KK supported destruction events for things like fences or small walls, along with "destroyed" models for those objects, we might even be able to hook into that and make the tracks able to crush these small obstacles. On that note, one of these days we should see if it's possible to make really heavy craft with large, powerful tracks, able to destroy parts on smaller/weaker vehicles they drive over, if we ever get them to drive over other stuff at all. That would be awesome.

Edited August 18, 2015 by Gaalidas

[lo-fi]

I had something in there to figure all that out, but I forget how it all worked now. I've scrapped some of that right now, but I'd really just like to integrate the entire setting with a GUI slider now that we have something to work with. That way I can keep it synced between all the parts. I'll leave the context slider interval alone (at +/- 5) and make the change only affect the action groups. I'll work on that later. My recent commit won't be entirely stable in that area, but it's not going to hurt anything.

I'm starting to breathe again now that I've got everything merged up and I just committed what I have right now. I've totally deprecated the unnecessary variable that simply stated whether or not the dust was activated in the KFDustFX module. That one was left over from when I was converting from CollisionFX in which there were parts of the module that would work even if the dust itself was not activated. I forget now what it was called, but it's gone now.

I need to take a nap now. I'm exhausted after all that work to get things back in order again.

Like I said, they will make legends out of days like these one day.

By the way, love the tests being done with maxRPM. I never tried setting it to anything insane like 40k. Must have been rather entertaining.

EDIT: One thing I've discovered from all of my testing and whatnot is that totally "breaking" a save is actually quite difficult. Granted, I've never tried any of this with a career save, but I've been running the same persistence since KSP version 0.23.5 without issue. Yes, I've had to manually edit a few things to keep everyone happy in it, and I recently added Val into it by starting a second save and copying over the necessary data from the roster, but nother was every "broken" by any of this stuff. If someone is having issues with lag due to a part like a repulsor, then updates the plugin with the fix, the parts seem to get updated with the new state of things when they are initialized and the game is back to normal more or less. What mostly contributes to "broken" saves is when a bug like this is encountered and the user simply deletes the entire mod, parts and all. Then things start to legitimately break.

It's been a trying few days, hasn't it! I'm starting to bundle a few things up again now the dust (pun intended) has settled. I need a break too!

I've tested the tracks a bit more. I must say the behavior is very realistic. It slides when turning at high speed, jumps etc.

Few problems are there, anyways. WHen climbing steep slopes the suspension is always compressed 100%. ALso, it is quite easy to compress 100% during rapid movements etc. Maybe you can make its stiffness nonlinear, increasing near full compression?

The main problem is how it hadles small steps. Get long tank tracks, scale them up 50%, go to Island runway and try to drive over those building remains. Despite tracks being large enough they simply bump into those blocks. I don't know how to simulate it, but this problem deserves fixing. With KerbalKonstructs such objects become common.

Great to hear! No dice with adaptive springs I'm afraid. To update that, you either need to disable the collider or have it leave contact with anything, either of which isn't practical. The wheel colliders are what they are, and that's that I'm afraid. Something I would love to have more control over, but there it is.

I know exactly what you mean, and it's a tricky problem to tackle. It's mostly, again, a wheel collider limitation. They're only one dimensional raycasts designed for arcade driving games (IMHO), so put them in a situation outside that and the simulation starts to break down, which is a shame. There are limits to how far you can bodge things :/

[sashan]

Well, there should be some way around that... Can you at least add a very slidy collider there that would move dynamically with front wheel? THis way we would be able to push the vehicle onto the obstacle using rear wheels at least.

[Gaalidas]

argh, I tried to do a final sync with github and it's failing on me... again due to some conflict. I see something like "guiActive = true" turned to false. That specific thing that was made false should not be made false because it's a label. I added a label above the slider because the text on the slider keeps getting truncated too much. I wanted to at least have something above the slider to tell what the slider is supposed to be doing.

I really need a break now. I'm going to loose my mind.

[sashan]

Just found a mod that fixes editor icons. IMO must have. http://forum.kerbalspaceprogram.com/threads/101632-1-0-x-Part-Icon-Fixer-Tweaks

[smjjames]

I'm going to do a wild guess because they don't have enough gripping area or the gripping area isn't contacting the collider?

Disclaimer: I have no clue what I'm talking about here.

[lo-fi]

Lol. Welcome to my world when it fails because you've removed a line space in a module I'm working on They're deactivated because they're not working quite right yet. Don't sweat it. I meant to ask: What's with the Equals(this, that) when == works perfectly well and is 10^99999999999999 times more readable? Drives me absolutely potty!

Pretty blunt tools to work with, Sashan. You can't add a plain collider because KSP does something weird with physics materials, so you can't make frictionless colliders. It's a right royal pain!

[sashan]

Hm, weird, considering we have (almost!) frictionless Kerbals.

HAve you tried adding one more "ghost" wheel there?

[smjjames]

They're also doing a total revamp of the wheels in Unity5, so, some improvements may have to wait for whatever options Unity5 brings about.

Also, I think he meant that second part as a reply to me rather than sashan.

Um, there seems to be a problem with brakes, they don't seem to be working too well, I think, with the inverting tracks, unless being upside down poses a problem there.

Edit: I'm also on the Mun, so......

Edited August 18, 2015 by smjjames

[lo-fi]

Hm, weird, considering we have (almost!) frictionless Kerbals.

HAve you tried adding one more "ghost" wheel there?

I know, right!! frictionless Kerbals, but everything else sticks like velcro.... Extra colliders are possible, but not always much use

They're also doing a total revamp of the wheels in Unity5, so, some improvements may have to wait for whatever options Unity5 brings about.

Also, I think he meant that second part as a reply to me rather than sashan.

I do need to get around to messing with U5. I'm hopeful!

[sashan]

Btw, I don't know if it is just me, but my parts slid epretty happily. I have better buyoancy installed tho, not sure if it affects only water or land as well, but water can be skimped pretty easily with it.

[lo-fi]

Tentative 1.9f release. Not on KerbalStuff because of all the updating people CKAN etc. and there are some quite major changes to fix that bug. If a few people report OK, I'll post.

[Darren9]

I put it straight into my modded install (deleted old first), and it seemed to be good, I dropped some repulsors and wheels as debris and flew around in and out of load and packing ranges. I was getting some bad occasional lockups though, just the whole thing stopped dead for over a second followed by a large chunk of text to the debug log which I haven't noticed without the KF debris around. I'll test it some more on a clean install, and here's the logs just encase they're useful.

http://www./KSP_Logs_H.zip

[lo-fi]

Thanks, that's quite a log! If you can give me some idea what got pasted into the log during the lag it would be really handy. Even what colour would help!

[Darren9]

I can, it was this, but, I had a plane that I'd delivered the KF debris with parked near it made of Procedural Parts/B9-PWings, BD landing gear and various other things. I removed it and went out in one of the stock planes and didn't get any noticeable stops/slowdowns. It looks like it was that contraption and not KF

Javascript is disabled. View full album

There's still a lot of yellow and the orange "wheel collider not......" that gets everywhere but if I didn't have the debug window open then nothing I'd notice. I took some screens of that just encase and another huge log but I think this could just be me piling up all the dodgy-est mods rather than your fix not working.

Javascript is disabled. View full album

http://www./KSP_Logs_J.zip

[lo-fi]

Thanks dude, the rest there is quite easily explained. "Wheel collider rigid body bla bla bla" is normal and harmless; the rest is either me being a little too verbose with the logging, or the update having moved the module indexes around. Crossing fingers nothing else comes up!

[Gaalidas]

Lol. Welcome to my world when it fails because you've removed a line space in a module I'm working on They're deactivated because they're not working quite right yet. Don't sweat it. I meant to ask: What's with the Equals(this, that) when == works perfectly well and is 10^99999999999999 times more readable? Drives me absolutely potty!

Pretty blunt tools to work with, Sashan. You can't add a plain collider because KSP does something weird with physics materials, so you can't make frictionless colliders. It's a right royal pain!

Well, if you'd just bow to my superior formatting and get in line with the rest of the peons of this world.... ugh, there I go again revealing my plans for world domination... never mind, move along, nothing to see here.

I'm sorry, I'm just super nuts about efficiency and consistency. It's a sickness.

As for the module index stuff... KSP is super nutty about things like that. MM usually takes care of re-indexing stuff and making it work right, so if you're not running the latest MM updates then you'll get some strange errors in the log from time to time.

[lo-fi]

Haha! I did wonder if that was an OCD thing In some situations you have to use the other method. In most of this, not so much. Though I've kinda got used to it now.