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

[lo-fi]

Yeah, anything is possible really

Edited June 24, 2015 by lo-fi

[Gaalidas]

I noticed a bit of a delay on the color being changed on the video. Is that with one camera per part, or one for the whole vessel?

Another thing I'd like to see is eliminating the sudden switch of the colors on the particles that are already in the air. It looks like it applies the color for all frames of the animation at the same time. If it could perhaps only apply to each frame in a sequence synced to the frame rate of the animation, that would look a lot better. For now, I would likely diminish the effect so that it doesn't show so much. That's also why I was looking into a size shrinkage for each effect so it would fade out quicker. He end result of my tests wasn't so great though.

[Tyren]

hmm i dont care if the thrown up particles change instantly with the ground color. Usually you dont have that much difference in landscape colors anyway, so imho its fine as shown.

- - - Updated - - -

Kerbin is an exception, switching from gray to green in an instant. It doesnt matter on the other bodies or biomes, me thinks.

[lo-fi]

Oh, I've been messing about with all kinds of stuff. I think that was set to update every twentieth render frame, which is the cause of the delay.

There are emitter options for fade, aren't there? I'll have a poke at it next time I'm in front of the PC.

[Gaalidas]

The closest I ever got to a fade was the size/grow parameters which supposedly allows for the effect to grow over the length of the animation. I thought maybe a negative value for the grow would result in a shrink. Didn't get to test much really.

The sudden change might not be totally necessary, but it still annoys me

Edited June 25, 2015 by Gaalidas

[*Aqua*]

Does it care about gravity and particle type? Fine sand and low gravity would cause bigger and longer lasting dust clouds I believe.

[lo-fi]

We're a little limited by bodging a stock effect, so that's just how they are. Looks like the fade out, such as it is, is built into the effect. So it is....

Anyway, I've got some interesting tools for measuring performance, so I'll be doing a little testing of both methods.

[Tyren]

I thought about this for a while now...the stock effects kick in by checking the biome an engine f.ex. applies collision to with its exhaust particles...so it should be possible to define the effect appearance by biomes or biome types...i guess...dunno...maybe...^^

[lo-fi]

That's exactly what the existing code does

[lazaruz76]

I don't know lo-fi, I kinda like the delay you have. Makes me think of bits and pieces being stuck to the tracks (or wheels) falling off after you made the transition from one surface to another.

[Tyren]

Yeah, imho it should be possible to define the mentioned particle parameters too.

Just like HotRockets with exhaust per engine does, you should be able to set the dispersion, height, growth and fade of the particle blobs per biome. I am 100% sure i dont know how, though.

[Gaalidas]

Does it care about gravity and particle type? Fine sand and low gravity would cause bigger and longer lasting dust clouds I believe.

That's why I want to define some more parameters in the biome definitions file I have (a config file it gets all the color data from) so that we can define a base size/strength/whatever per biome to be used as a baseline for all the other calculations.

In other news... in case you haven't heard, I am awesome. No, really... it's totally true this time. The voices said so, and they never lie. Specifically, I have fixed the KF conversion of the ERS wheel's treads where both tire treads show up for either side, causing flickering and general messiness of the model. All I had to do was load it up in blender (the one wheel I've tried lately that could be imported) and look in the hierarchy for the object names for the wheels. There's actually two objects for each wheel direction, and they are labeled by their intended direction. I simply added those object names to the mirror module, and tested it a few minutes ago. Works perfectly. I'll update the wheel config repository a little later. I'm too tied up with other work right now.

[lo-fi]

If you can handle Blender, you'll be able to work with Unity! Good work, its something I've been meaning to do for ages.

[Tyren]

That's why I want to define some more parameters in the biome definitions file I have (a config file it gets all the color data from) so that we can define a base size/strength/whatever per biome to be used as a baseline for all the other calculations.

In other news... in case you haven't heard, I am awesome. No, really... it's totally true this time. The voices said so, and they never lie. Specifically, I have fixed the KF conversion of the ERS wheel's treads where both tire treads show up for either side, causing flickering and general messiness of the model. All I had to do was load it up in blender (the one wheel I've tried lately that could be imported) and look in the hierarchy for the object names for the wheels. There's actually two objects for each wheel direction, and they are labeled by their intended direction. I simply added those object names to the mirror module, and tested it a few minutes ago. Works perfectly. I'll update the wheel config repository a little later. I'm too tied up with other work right now.

Tell us something new.^^ Cant wait for it, i crushed one of my chairs while bouncing up and down in excitement.

[lo-fi]

Doh! I just realised the wheel configs won't work without a previously unreleased version of the plugin. That, and they all need torque and rolling resistance updates. Oooops.

[Gaalidas]

Tell us something new.^^ Cant wait for it, i crushed one of my chairs while bouncing up and down in excitement.

That is just a teeny bit disturbing to visualize.

- - - Updated - - -

Doh! I just realised the wheel configs won't work without a previously unreleased version of the plugin. That, and they all need torque and rolling resistance updates. Oooops.

Yeah, everything is going to need updating. You just couldn't leave things alone could you? And now you have to pay for it.

Oh, slightly off topic... okay, actually it's really off topic... I was looking at the RPM mod today to try and find a fix for the transparent pod internal props going haywire and I think a few dev versions ago they finally nailed it down. I'm hoping for the best that it will fix the issues I had with the roll cage internals a while back.

Okay, back on topic! I updated the wheel config repository with the additional object names for the mirror module. Also, I noticed you uploaded a compiled DLL for the new DustFX stuff, but I'd really love to see what the code behind all that looks like. I'm looking forward to you updating the source.

[Tyren]

Well, i am simply heavy...our chairs are not meant for jumping around on them (and i ran into it earlier while playing tag with my son , could have something to do with it )...^^

BTT:

Is it possible to get a somewhat test ready version of this?

[lo-fi]

It's all in the dev branch of KF_plugin Awesome stuff! Yeah, I can't leave well alone...

The changes are principally:

KFModuleWheel: grabs hit info from the colliders, then calls a method in KFDustFX

KFDustFX: No longer triggers with OnCollisionEnter and OnCollisionStay

VesselTools: ModuleCameraShot has been created which takes care of the camera colour grabbing stuff. KFDustFX grabs the colour info from it, rather than the biome dictionary.

Edited June 25, 2015 by lo-fi

[lo-fi]

Also, I've just added a regenerated biome def file. The KFDustColorFileWriter class is a MonoBehaviour. It's there, but like a PartModule, it won't do anything unless it's called by something. Adding the [KSPAddon(KSPAddon.Startup.SpaceCentre, false)] attribute (?) to the class causes it to be run when entering the Space Centre, at which point it spits out a new file. It looks like the biome names are OK, but the original has some rounding applied. Given that, I suspect some kind of logic snafu in the code that deals with grabbing either the biome name, or the colour. It's defaulted in the code, so changing the defaults will allow you to prove that. Adding in some debug.log lines ought to be able to reveal the rest. I'd advise refactoring the code with the KF prefixes again to prevent issues with the CollisionFX classes of the same name.

[Gaalidas]

Actually, that's the beauty of it. I started, way back in the day, renaming everything from CollisionFX to DustFX. The original mod didn't have anything called DustFX. Either way, I will rename things back so they can all be identified as a part of the KF plugin.

So, you got it to regenerate a file, but will it override the old file if I make changes to it? The default file I believe simply spits out the color that the biome would be represented by in a biome map. That wouldn't necessarily match what's going on with the terrain.

[lo-fi]

Ah, of course!

I just got it to write out the new file for reference, and I'm glad it didn't overwrite the existing one. Was just to check the names really, as I knew you'd pondered how the writer worked a few posts back. I'm still sure the error lies in the logic, as there are many checks that set default colour, rather than spit errors out. Which is great, but not helpful finding the fault. Some debug statements printing what the plugin thinks its doing throughout the process ought to reveal the offending line. I know you want to learn, which is why I haven't gone too far at each step.

You get into the branch ok, and understand what I've done there? I'll add some comments when I get a few minutes

[xEvilReeperx]

I'm still sure the error lies in the logic, as there are many checks that set default colour, rather than spit errors out. Which is great, but not helpful finding the fault. Some debug statements printing what the plugin thinks its doing throughout the process ought to reveal the offending line.

They don't set color, they query the loaded definitions to see if it contains a value for the biome. The goal is NOT to throw any exceptions, but to return the most sensible default where possible if there is no entry. If there's a default set for that body, use that default. If there's no definition at all, use the global default (the cases where a default is returned is where I'd stick your camera color code if you wanted to integrate the two).

All of the "creation" logic happens in KFDustColorDefinitions.PersistenceSave. If you try and serialize KFDustColorDefinitions to disk and there are NO entries (presumably because no default file was used to create it), default entries will be created:

For every planet:

If planet has a BiomeMap:

Add a new entry for this planet, with planet default color set to global default color

For each uniquely-named biome on planet, add a biome color entry to planet that matches the color used for that biome

Naturally the result of this isn't going to be pretty since it's using the same colors the game uses to identify biomes which are unrelated to their actual color in most cases, but still useful in laying out a customizable ConfigNode to be hand-edited later

[edit] Rounding applied to what? The biome colors?

Edited June 26, 2015 by xEvilReeperx

[Gaalidas]

Ah, of course!

I just got it to write out the new file for reference, and I'm glad it didn't overwrite the existing one. Was just to check the names really, as I knew you'd pondered how the writer worked a few posts back. I'm still sure the error lies in the logic, as there are many checks that set default colour, rather than spit errors out. Which is great, but not helpful finding the fault. Some debug statements printing what the plugin thinks its doing throughout the process ought to reveal the offending line. I know you want to learn, which is why I haven't gone too far at each step.

You get into the branch ok, and understand what I've done there? I'll add some comments when I get a few minutes

I got into it alright... I didn't even know it was there before. It looks good. I'm ready to merge it back into the main branch whenever you feel it's ready. I intend to look into how we might use the biome definitions and the camera data together... if that's even necessary now. If these camera things don't hurt performance too much, then we might not really need the biome definitions at all, at least not for color. I would still want to use a biome definition file to specify material hardness and such, so that we don't look like we're carving bits of concrete out of the pavement when we roll over it, but don't look like we're rolling over pavement when tearing down the desert sands.

I could probably just pull out one of my old test rovers with over 32 wheels attached to the thing (per side, yes I am that insane) and see what happens to my frame rate.

I did see that you commented out the line that caused the file writer to activate. At least we don't have to worry about it overwriting the file every time we start it up. What would be nice is if it could populate the file with any planets/biomes that are not defined in the file, while leaving the defined ones alone, in case the end user tries to edit it manually and looses some of those definitions or breaks the format somehow. Anyway, I'm learning slowly what all that stuff does and will probably get the hang of it eventually. It's weird how my brain will make absolutely no sense of anything for the longest time, and then suddenly it's all clear as day. Just wish it would do that faster.

Edited June 26, 2015 by Gaalidas

[riocrokite]

I got into it alright... I didn't even know it was there before. It looks good. I'm ready to merge it back into the main branch whenever you feel it's ready. I intend to look into how we might use the biome definitions and the camera data together... if that's even necessary now. If these camera things don't hurt performance too much, then we might not really need the biome definitions at all, at least not for color. I would still want to use a biome definition file to specify material hardness and such, so that we don't look like we're carving bits of concrete out of the pavement when we roll over it, but don't look like we're rolling over pavement when tearing down the desert sands.

I could probably just pull out one of my old test rovers with over 32 wheels attached to the thing (per side, yes I am that insane) and see what happens to my frame rate.

I did see that you commented out the line that caused the file writer to activate. At least we don't have to worry about it overwriting the file every time we start it up. What would be nice is if it could populate the file with any planets/biomes that are not defined in the file, while leaving the defined ones alone, in case the end user tries to edit it manually and looses some of those definitions or breaks the format somehow. Anyway, I'm learning slowly what all that stuff does and will probably get the hang of it eventually. It's weird how my brain will make absolutely no sense of anything for the longest time, and then suddenly it's all clear as day. Just wish it would do that faster.

I can see really nice development guys, keep up good work:)

One question, does dust disable itself if one moves on (over) another in-game object? for example parking rover in deployable hangar or one of hangars from B9 HX parts?

[Gaalidas]

Excellent question. I have absolutely no clue. At its core, if CollisionFX caused sparks to fly when rolling over other non-static objects, then it's very likely that DustFX does as well. I am not completely sure of this, however, as I have done very little testing in non-planetary collisions. I have a feeling that it might not throw up dust on those objects though, since I seem to remember stripping some of the old CollisionFX code for detecting dynamic object collisions and such. I'll need to go dig through the old code vs. the new to know for sure without simply testing it. Dust really shouldn't be emitting from solid objects like those.

Hey lo-fi, I have a question. The camera color grabber uses tiny little screenshots, and I noticed something in the code that pertains to saving an image somewhere. Does this mean that, technically, the game is taking tons of miniature screenshots and possibly saving them to disk? If so, are these screenshots then building up in the screenshot output folder and clogging the disk? I ask this without having actually tried it out myself, I'm just curious.

Edited June 27, 2015 by Gaalidas