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

[Gaalidas]

I thought you'd already made your own LookAt. Or were you just expanding on the stock LookAt?

Oh, well. Vector maths are as familiar to me as deep-sea diving is to a desert-dwelling lizard. I know the name, but that's about it. Okay, so the analogy doesn't work too well, considering a desert-dwelling lizard doesn't know what deep-sea diving is... but you get the idea.

I've actually had a moment of inspiration... or rather, I've started doing what you told me to do earlier when I was looking to grab the tweakScaleCorrector value from the other modules. I figure if you can search the parts for colliders and such, I can probably do that too. So, I began mucking about with some copies of your code in a TestDustFX module to see what I could do. I still don't know how I'm going to make DustFX use a list of colliders instead of just a single one as it's built to handle now, nor if/how I'll be able to average the effect between the multiple colliders if the part has more than the single one, assuming I can get it to differentiate between the colliders that are simply a part of the whole "part" and which of those are actively scraping the ground. At this time I think it's just emitting the particles at the wheel's collider when the part, as a whole, is scraping the surface. I can't claim to understand all of it's inner workings though.

Good stuff on the model nodes and such. I just hope your parts won't require any wonky scaling done once made into MODEL nodes. I had a nasty experience when optimizing my local install of the Endurance mod, where all the parts in the Ranger craft ended up too small, but the attach nodes were all in the positions they would be in as if the part was full size. That really sucked.

- - - Updated - - -

By the way, what the heck is that "BV" track you mentioned? I'm not familiar with it, or at least not that reference.

[lo-fi]

Yeah, though I was using the Unity LookAt method, which gives wonky results in our application working in local space rather than local space. Check out the diffs on KFLookAt, you'll see what I mean. It used to flip stuff over beyond certain rotations. Not any more!

KFModuleWheel always keeps a list of colliders. If wheelList isn't declared public, there's no problem doing so. I can show you how to read the hit info - you'll no doubt go nuts with all the slip and force info available

No scaling needed - it just works. I'll continue when I get time, but it's not difficult. BV is a reference to the Bofors BV202, on which the tracks are modelled

[Tyren]

Hello lo-fi,

i am running 32bit Ksp on my 64bit win 8 platform for mod compatibility, but the tiny rover wheels dont work for me. They do not deploy even after setting the action groups correctly. It is afresh install of KSP without any other ground propulsion/gear mods.

[lo-fi]

Ah, OK. That does sound like a bug.. So do you mean you've started with the retracted, and they won't deploy? In which case, do they work OK if you launch with them deployed?

[Tyren]

Yeah, they do. Weird.

[lo-fi]

That'll be a bug with the retract / deploy. Will be fixed in the upcoming update.

[Gaalidas]

Wait a sec... so those wheels have a retracted state? I thought they simply appeared retracted until you launched with them...

Maybe I should actually launch the game and see what's been going on with the parts instead of simply updating the files and diving through code and ending up confused.

So, I did actually take a look at what you have available in that module, and it's a bit overwhelming actually because I still really don't understand how the original scraping and particle spawning code actually works in the original CollisionFX mod. Because of that, I really don't know how I would use any of that information. The furthest I've come to actually using anything is simply by expanding the equations used already with more multipliers and whatnot. I'm still digging between my various headaches (this stuff really screws my brain up) so who knows what I'll come up with. That's why I really wanted to integrate this with your mod. The more heads working on this stuff, the better. I'm good enough to be dangerous., and by that i mean I could easily break everything at any moment, but I'm still not experienced enough to call myself a programmer.

All that and I should be working on my ASP.NET final project instead of KSP mods.

Edited June 3, 2015 by Gaalidas

[lo-fi]

I may have left the config option in by mistake...

From memory, what it does is find the closest collision on a given part and emit from there. It doesn't actually do anything wheel collider specific, they just count as collisions. What I propose, is to use the list of wheel colliders exposed in KFModuleWheel - or generate another one - and use their groundhit info (as well as slip, speed, ground force etc.) to aggregate an average ground contact point from which to emit the effect. In other words, use wheel collider specific data - not as hard as it sounds. Going to be very cool. I'd *love* a way to make tyre/tread tracks get left on the ground too.

EDIT: Crikey, this stuff is interesting. Needs a major overhaul for what I had in mind...

EDIT2: Updated to produce the effect from an average position of the contact points. This pleases me.

Also, do we have permission from PizzaOverlord to use/bastardise his code like this, and what license was it?

Edited June 3, 2015 by lo-fi

[Gaalidas]

pizzaoverlord has never even responded to any of my messages or posts in his CollisionFX thread (which is buried under a boatload of threads by now). I seem to remember you telling me his license allowed for, at the very least, my DustFX plugin. The thing is, at this point there is not a lot left of his original code. Yes, it looks freakishly similar, but I've had to re-write a lot of it in the various iterations since the original. Unfortunately, the only way I found to make it work turned out to be more or less identical to the original. I suppose there's only one way to really get the right effect sometimes.

So, the grounded hit thing was what I was just looking at 10 minutes ago. I started to try and grab this information for use in my test module, but started feeling that headache coming on and decided to take a break. I look forward to seeing how you did it though. As long as you don't break the color definitions and such, I'm happy. Speaking of which, most of the non-Kerbin definitions in the DustColorDefinitions config are based on the average color of the planet's appearance from orbit, grabbed from various sources including screenshots from the tracking center. If you end up taking any of your creations to other worlds, I'd welcome any adjustments to those color definitions in the config. The config, which originated from the first time xEvilReaperx helped with the project, (I think he generated it from the game's internal information, I'm not sure how really) contains all the planetary names and biomes in it already with these placeholders. The alpha channel for those colors is what I'm using to affect how thick the dust particles appear. I'm basing that on what the material appears to be (as in how tough it would likely be. The harder the surface, the more transparent the particle color, thus the lower alpha value.) Otherwise it's just an RGBA color.

EDIT: Took a look at what you did and I'm impressed. Didn't take you long, and seems incredibly simple. I re-enabled the OnCollisionEnter section though, as it is used to enable a wheel-impact audio effect that the original mod had which I liked, but never really tested the implementation here. It needs to be enabled, have the user's volume jacked up, and get some wheels rammed into something. Because it is untested, I don't have a default sound effect even defined in the code, but if you look at the MM patch, I do define one (which I added to our sound folder, though I might have referenced the path wrong in the patch, I'll check after I get done writing this) for everything except the repulsors (and the patch which implements the dust on non-KF wheels too, since that also works... actually, I may have removed that now that KF specific values are being called for. I may add that as an extra park of the mod later.)

I guess I can cancel my test module now then, since you've managed it in record time. Did you get a chance to test the result in-game?

Edited June 4, 2015 by Gaalidas

[lo-fi]

I'll double check, but I think we're cool licensing.

Once I'd worked out what was going on, I spotted what I could tweak. It wasn't a lot of work. The collision info has a list or array of hits, and Pizza was only using the first entry. We can still streamline it a lot, I think, but it works well in-game as it is. I was thinking, maybe there's a way to sample the colour of what the parts are colliding with by using a camera. That way you could ditch the biome stuff and have it all calculated realtime. Would be very cool, and we can crib some stuff from the reflective windows plugin for clues how to do it.

I'm now quite happy with the LookAt, and I've improved the mirror code, so we're good to go with things like the BV and TT (Thunder Tank) tracks. I've decided on a consistent style I want to go with, so I'll complete those models as such. I'll also continue setting up the parts in on folder for texture sharing. It makes a lot of sense doing it that way. Any suggestions for what the collcage needs to complete it?

[Gaalidas]

Well, there is of course adding all that instrumentation using the complex JSI prop packs and such so we can basically control the universe from the seat of our mini-rover.

But I'm sure we could scale that list of features down. I'd settle for at least a monitor with it's accompanying buttons on the inside surface in front of the kerbal for some basic information. Other than that, it's not really meant to be a complete pod solution for off-road kerbal transit devices, is it? So, it's pretty feature complete. In the future, maybe some different color options using a texture switcher would be great. Maybe one with really dark bars to contrast with the brighter surfaces.

I like the idea of sampling like that. I still want some control over the density of the particles however, and currently I don't see anything to handle that. we have control over the strength and size of the effect, but it's still just an effect which limits us as far as density of the effect. Using an alpha channel to make it appear less dense by making it semi-transparent is my way of combating that problem, and I've been setting that based on what I think the surface would produce when scraping it with something. So, at the very least, we would likely need a list of biomes with their corresponding alpha values.

However, sampling the color of the surface being collided with would fix another problem I had, where there's a small patch somewhere between the KSC and the distant hills which is incorrectly flagged as part of either a tundra or pole region. This resulted in snowy-colored dust from green grass. I found it only once, but it's rather annoying and I really have no way of fixing it unless I can get color values from the field.

I know TextureReplacer merged in some of that reflection stuff, which I'll do some digging into later. I've already looked at that stuff anyway because there's a problem with how it handles the reflectivity of the region you want to reflect. Unless you specify a specific object in the part, it simply makes the whole part reflective and the higher the alpha channel, the less reflective it is. It uses the main diffuse of the part to do this, which makes texture replacement a real pain because you have to take into account the bleed-in from the model's default untextured color, which is a pure white. I wanted to see if there was a way to get it to reference a different texture, or alternatively treat the inverse of the current alpha handling instead. This would be a lot easier to deal with, since the reflective parts wouldn't need much done to them for texture since they're being overlayed with a reflection modified by a custom color shade (if specified). I didn't find any easy way to invert things or redirect them without having to recompile the shader. I don't speak shader-talk anyway.

EDIT: Something else to think about with the color sampling. The pro of doing this would be that making water spray when repulsing over water would be a lot easier, but the con is that the sampled color would be the color of the water when, in reality, water spray looks more like snow-dust than the blue that you would get from the sample.

Edited June 4, 2015 by Gaalidas

[lo-fi]

The particles start off none too dense at low speed, so there ought to be a way to tap into that. I'll have a look in a moment..

[Tyren]

[...]

EDIT: Something else to think about with the color sampling. The pro of doing this would be that making water spray when repulsing over water would be a lot easier, but the con is that the sampled color would be the color of the water when, in reality, water spray looks more like snow-dust than the blue that you would get from the sample.

Is it possible to let the water sampling grab a color brighter than the surface you collide? Light diffusing, water spray and so on would be covered with that.

[lo-fi]

Yeah, it ought to be. Nice idea This is all new to us, so a bit of a learning curve. I love the effect, though.

Surely this is where you want to be messing about for emission density?

kfdustFx.particleEmitter.maxEnergy = speed / (maxDustEnergyDiv * correctionvalue);
				kfdustFx.particleEmitter.maxEmission = Mathf.Clamp((speed * (maxDustEmissionMult * correctionvalue)), minDustEmission, (maxDustEmission * correctionvalue));
				kfdustFx.particleEmitter.Emit();

Edited June 4, 2015 by lo-fi

[Tyren]

I am pretty creative in my head, but my hands wont just do like i say. Glad i could help.

[Madrias]

Looking at the roll cage from a pod perspective and a driver's perspective, the panel directly in front has to go. That's right in the line of sight for driving. Otherwise, it looks perfectly functional.

Honestly, I think it'd be kinda cool if there was more we could do with the thin-struts-and-crossbars construction. It'd make very lightweight, reasonably strong vehicles, at least in real life. That, and I think we need some smaller lights (yes, I know, tweakscale does wonders for making adjustable lights, but the stock ones lack the heavy, rigid construction feel that the KF parts have.)

[lo-fi]

You sound frighteningly like Gaalidas. This worries me...

- - - Updated - - -

Looking at the roll cage from a pod perspective and a driver's perspective, the panel directly in front has to go. That's right in the line of sight for driving. Otherwise, it looks perfectly functional.

Honestly, I think it'd be kinda cool if there was more we could do with the thin-struts-and-crossbars construction. It'd make very lightweight, reasonably strong vehicles, at least in real life. That, and I think we need some smaller lights (yes, I know, tweakscale does wonders for making adjustable lights, but the stock ones lack the heavy, rigid construction feel that the KF parts have.)

Yes, that occurred to me too about the front panel. Didn't see it until I drove IVA. Any hints on props? I guess I should RPM, as I'm using JSI transparent? Nli2work's video tutorials are awesome if it's something you feel like having a bash at? Lights. Yeah, that'd be cool! Good to hear from you, by the way!

Edited June 4, 2015 by lo-fi

[*Aqua*]

Any suggestions for what the collcage needs to complete it?

Add some flat surfaces at the front, back and top to allow players attaching something upright. Nothing bugs us more that wierd attach angles. This nice rollcage cries for a nice skycrane on top of it.

Also I don't see a place where the logo will be displayed. Is it on the back?

[lo-fi]

Yeah, that makes sense. Hadn't even thought about the logo!

Woah. I just looked into setting up RPM MFD's. Scary, scary stuff.

Edited June 4, 2015 by lo-fi

[Madrias]

I can't get the hang of 3D editing, so I can't actually do the IVA thing. As for gauges...

Compass and Navball, front and center, high mounted on the lower plate. Speed next to it on the right, Altimeter and Radar Altimeter to the left side. Rise/Sink gauge (I can never remember the bloody name of this thing) next to the Altimeters.

Bare minimum:

Compass and Navball mounted front and center. Radar Altimeter and Speed on left and right sides respectively.

Depends on whether you want it to be a rough-and-ready design or something a touch more luxurious. Personally, I like the idea of the bare minimum layout, myself. Radar Altimeter could be replaced with the normal Altimeter, though you may need a Rise/Sink gauge if you do that.

As for how to accomplish the need for mounting surfaces, an upper structure could be assembled such that the top becomes flat, and a lower structure could flatten the back, bottom, and front and provide mounting surfaces for stack mounting.

I would love to have pieces that could attach to this roll cage (big surprise here) to make a tail structure and motor mount at the rear and front of the cage respectively. As well as a place to mount a wing on top and the standard tail surfaces on the tail boom. Would be the perfect replacement for that overly complicated cockpit design I had quite a while back. After all, having no sides makes for great visibility.

Edit: And how is it that I sound like Gaalidas? And why would that be a scary thing?

[Gaalidas]

You sound frighteningly like Gaalidas. This worries me...

- - - Updated - - -

Yes, that occurred to me too about the front panel. Didn't see it until I drove IVA. Any hints on props? I guess I should RPM, as I'm using JSI transparent? Nli2work's video tutorials are awesome if it's something you feel like having a bash at? Lights. Yeah, that'd be cool! Good to hear from you, by the way!

I'll take that as a compliment. I agree too, lights are a good idea. i especially appreciate cockpit-lighting for night driving, especially in a dim red hue (to better fit with the eye's natural night-sight which does not get ruined by red light.) setting up MFDs shouldn't be that messed up. You just need to place the props in the right spots and make sure they're doing everything they should be doing. You could probably take a stock cockpit patch as a template and just modify the locations to fit the spots in the rollcage. Page setup is only necessary if you want your own custom information displayed (which might be cool... a single page to display the current status of the suspension on the wheels/tracks on the craft, or show the height and power drain of the repulsors... but that can wait for a later update.) I wouldn't try to do anything like what you get in... say... RetroFuture (wide screen maps with overlayed square screens side by side that can show info while allowing a scansat map to run in the background, complete with controls for all three screens arranged on the outside, and controls dedicated to camera movement next to that, along with complete action group toggles and switches for jsut about everything you can possibly do with a ship.) and I would never recomment trying to do what Alexustas has done (custom readouts for fuel/power levels and drain rates, transparent HUD displays for rover orientation, speed, direction of movement, controls for every action group, plus controls for everything you might ever think to do in stock or any combo of about 50 different mods, plus stopwatch-like devices, time keepers, lights, bells, whistles, you name it.) That stuff can lead you to go completely nuts.

What was I talking about again? oh right... the rollcage. Yeah, I'd say either set up a single monitor (or several small monitors with just a few functional buttons each) or just give it the basic IVA controls. I'd also export a version of the part which can just have a control seat attached inside of it, without any form of IVA of it's own, for the non-JSI users out there who might still want that part. I wouldn't exactly change the geometry of the part like the others are suggesting. For that, I would make separate and completely new pods. This thing looks fine on it's own. As for the crazy angles, yeah those are annoying, but you sacrifice a lot of style to get things fitting together perfectly. You just have to decide what's more important in this case. There are already a good number of mods uot there with flat, boxy surfaces for your perfect attachments.

I guess my point is this: put some stuff in there to at least help us navigate, then worry about making it really awesome later after we've had a chance to mess with it ourselves. No one says it has to be fully functional in its first release.

- - - Updated - - -

Yeah, it ought to be. Nice idea This is all new to us, so a bit of a learning curve. I love the effect, though.

Surely this is where you want to be messing about for emission density?

kfdustFx.particleEmitter.maxEnergy = speed / (maxDustEnergyDiv * correctionvalue);
                kfdustFx.particleEmitter.maxEmission = Mathf.Clamp((speed * (maxDustEmissionMult * correctionvalue)), minDustEmission, (maxDustEmission * correctionvalue));
                kfdustFx.particleEmitter.Emit();

Okay, so I admit I have little understanding about what each of those parameters actually does. I wonder how hard it would be to set up a GUI slider (context menu), available in flight, where I could tweak some of those values in real time to get a sense for what does what? That would sure help me figure out how to better control the effect than simply relying on alpha transparency of the color. This would sure be great, because I kinda like the effect better when it's almost completely transparent so it appears more like dust than bits of ground being ripped up. I could then control the density separately.

Might be a good time to resurrect the test module and do some code copying from some of your other modules with in-flight modifiable parameters.

EDIT (final edition, I hope): To answer a long standing question, YES my posts are getting longer. In the next few months I'm going to have to start adding a table of contents and insert page numbers into my posts. You think I'm kidding? Just look at the progression during all 280+ pages of this thread. Be afraid.

Edited June 5, 2015 by Gaalidas
I'm such a rambler sometimes

[lo-fi]

Was actually referring to Tyren sounding like Gaalidas, but you ninja'd that post in ahead of mine

Thanks, I'll stick some props in and see how it comes out. Will see what I can do about other parts to attach to it and making some sensible attachment points.

Sounds like a lot of work configuring the MFD's, so I'll probably grab some default ones from something else. If I even use them. Maybe it might be better to keep this simple..

I have no idea either, but an educated guess and knowing what mathf.clamp() does, tells me that the code is telling that instance of the emitter to emit a certain amount of particles within limits. Always refer to the Unity docs, they're really good. That's pretty much how I've figured out how to do all the stuff I've coded. Don't worry about the test module! I never do. Just break stuff, and don't commit it if it's really broken. You've always got the last commit to fall back on if you get totally lost. Adding a slider is easy, just copy one the the fields from KFModuleWheel or something. That's what I did from the critter crawler when I was starting out - it's pretty self explanatory how it all works, and all it does is modify a value.

[V8jester]

Sounds like a lot of work configuring the MFD's, so I'll probably grab some default ones from something else. If I even use them. Maybe it might be better to keep this simple..

Hey for the MFD's. Try talking to Alexstus about using the code from the ALCOR capsule. It's super clean code and, he has been working with Mihara to add in a few new features in RPM.

[Madrias]

Was actually referring to Tyren sounding like Gaalidas, but you ninja'd that post in ahead of mine

Thanks, I'll stick some props in and see how it comes out. Will see what I can do about other parts to attach to it and making some sensible attachment points.

Sounds like a lot of work configuring the MFD's, so I'll probably grab some default ones from something else. If I even use them. Maybe it might be better to keep this simple..

I have no idea either, but an educated guess and knowing what mathf.clamp() does, tells me that the code is telling that instance of the emitter to emit a certain amount of particles within limits. Always refer to the Unity docs, they're really good. That's pretty much how I've figured out how to do all the stuff I've coded. Don't worry about the test module! I never do. Just break stuff, and don't commit it if it's really broken. You've always got the last commit to fall back on if you get totally lost. Adding a slider is easy, just copy one the the fields from KFModuleWheel or something. That's what I did from the critter crawler when I was starting out - it's pretty self explanatory how it all works, and all it does is modify a value.

Ah. Forgive my moment of mild confusion, then.

Personally, if you could, make 2 versions of the rollcage? One with old-school simple gauges, one with the 'glass cockpit' RPM MFD's. I like MFD's, personally, but I'd love to make fully-open-cockpit old-school aircraft. As simple as it gets with gauges, ultra-high visibility, just generally a lot of fun.

[Gaalidas]

Was actually referring to Tyren sounding like Gaalidas, but you ninja'd that post in ahead of mine

Thanks, I'll stick some props in and see how it comes out. Will see what I can do about other parts to attach to it and making some sensible attachment points.

Sounds like a lot of work configuring the MFD's, so I'll probably grab some default ones from something else. If I even use them. Maybe it might be better to keep this simple..

I have no idea either, but an educated guess and knowing what mathf.clamp() does, tells me that the code is telling that instance of the emitter to emit a certain amount of particles within limits. Always refer to the Unity docs, they're really good. That's pretty much how I've figured out how to do all the stuff I've coded. Don't worry about the test module! I never do. Just break stuff, and don't commit it if it's really broken. You've always got the last commit to fall back on if you get totally lost. Adding a slider is easy, just copy one the the fields from KFModuleWheel or something. That's what I did from the critter crawler when I was starting out - it's pretty self explanatory how it all works, and all it does is modify a value.

Yup, I even loaded up the game (it didn't crash this time, woohoo!) and the sliders exist. However, I tried to use the KF ERS wheels as a testbed, and discovered that problem where they animate, but don't actually become usable properly. Also, the treads are still all screwy. I discovered an even bigger problem though, and one I thought I'd fixed. The only KF parts that can be scaled at this time are the repulsors. All the wheels/tracks/whatever are showing an empty line in the context menu where the TS slider should be, and my log is getting spammed with: "ItemPrefab for control type 'UI_ChooseOption' not found." The control type in question is in KSPAPIExtensions.dll, and I already checked the referenced version in TS against the version of the extension DLL I have in there, and it all fits, plus the extension DLL does have that control type in it. So, I've already posted to the TS thread hoping to shed some light on this obvious screw up that I cannot seem to make sense of.

So... I didn't get a chance to actually see if my sliders work or test anything out. In the end, trying to relaunch the flight scene with a different craft ended in a complete crash which I had to reboot my whole computer to recover from. Dang TweakScale.