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

[Gaalidas]

I bet it is a bit hilariously crazy watching the ol' pong ball bounce between us. I was just noting yesterday that I do believe my posts are getting longer.

[Tyren]

Yeah somewhat

[Gaalidas]

so, lo-fi, I noticed you started work on making the resource consumption more modular... however I have some code that I'm going to merge in which adds a lot more modularity to it. it also renamed the field for the resource consumption in the configs, which I have refrained from committing to the part configs, but is all ready to be committed at any time. Basically, I made all referenced to "charge" or "electric" into a more generic "resource" format. Everything defaults to the standard ElectricCharge, of course.

[lo-fi]

ROFL! That's hilarious, Tyren.

I think it's good having the development discussion open and on view, though. Let's people see just what goes into making a mod, and, of course, keeps the information flowing for future use.

New parts are anything but aesthetically pleasing right now! As usual I'm behind with the texturing... The showcase album does desperately need updating, though.

EDIT: Ah, that's a pain! I take it you had another method in mind? I was just going to leave a text field defaulted to EelectricCharge that could be be changed either manually or with an MM patch.

Also: >3000 posts!!!!!

Edited June 22, 2015 by lo-fi

[Tyren]

Yeah i appreciate it, for me being new in modding it is quite interesting to see how complex mods are issued...i am no fan of the 'easy first' method, better some brain griller to learn from.

[lo-fi]

Well, you're in good company; I dove in at the deep end too. A year ago, the only experience I had programming was tiny amount of C for micro controllers, and wheels were still largely an obscure mystery in KSP. I'd certainly never worked on a game, and I had no idea my desire to make suspension for wheels adjustable would lead here. Gaalidas is going through college (correct me if I'm wrong?) and feeling his way with c# too. The great thing about this stuff is that the penalty for failure is zero - unless you count lost time - so picking up something that's a little beyond your grasp isn't such a silly thing. There are some incredibly helpful people here too.

What you working on?

[lo-fi]

OK, anyone like playing with configs and have a grasp of how to use GitHub?

I've got a long list of jobs that need doing on the wheels and tracks that all require in-game testing for config tweaks. Got my hands full modelling and finishing bits up on the plugin! All the steering, torque, braking, rolling resistance and load curves need editing, as do weights, costs and descriptions.

Gaalidas, I think we ought to look at changing the method used for DustFX. Rather than detecting collisions using hooks into OnColliisionEnter etc. - which are prefect if you want to detect an object colliding with something in any fashion - we might be better served getting KFModuleWheel to drive the particle emission based on the hit info from the colliders (which it accesses anyway). That way we know it's a wheel collider creating the collision, and can tailor the effects much more effectively. Most of the work you've already done can stay as-is - we just need to hook into the DustFX module and call the emissions methods from KFModuleWheel, rather than the hooks into OnCollision*. Same goes for the repulsor module; which is nearly finished btw, and much more maintainable.

While I'm messing with that, and given your new found skills with confignodes, could you figure out a way to create a global config file? I'd like to have one master config file with options to turn off the orientation markers, settings for how many particle emitters to spawn - stuff like that. A little GUI would be nice, but I'm not going to delay the next release to write one. That'll have to wait for 2.0!

[Tyren]

I have several parts i look into, some first fuselage samples with quite odd shapes, embracing fuel tanks and recently some wheel types...

[lo-fi]

Excellent! Any pics of your work in progress?

[Tyren]

Nah, still playing around with model solutions. Id rather not show off before ive got something i can say to myself: 'not bad, dude.'

xD

[Gaalidas]

ROFL! That's hilarious, Tyren.

I think it's good having the development discussion open and on view, though. Let's people see just what goes into making a mod, and, of course, keeps the information flowing for future use.

New parts are anything but aesthetically pleasing right now! As usual I'm behind with the texturing... The showcase album does desperately need updating, though.

EDIT: Ah, that's a pain! I take it you had another method in mind? I was just going to leave a text field defaulted to EelectricCharge that could be be changed either manually or with an MM patch.

Also: >3000 posts!!!!!

My way of doing it was basically the same, but I made it more elaborate in that now the field in both modules is called "resourceConsumptionRate" instead of "chargeConsumptionRate" and there are some new fields such as "resourceName" and, for the modules with a status text, a "statusLowResource" string field which allows the status of "Low Charge" to be renamed per-part to something like "Low -insert_resource_name_here-" though... now that I think about it, I could probably eliminate that field and simply change the resource in that string to be equal to the resource name specified with something like (writing this in freehand):

string.Format("Low {0}", resourceName);

I might just look into that instead of the extra field, but I'd actually like to have a lot of those feedback type things to be more modular. This allows for modders in the future to make part packs based on this mod without having to write extra code to make up for our hard-coding. by the way, your latest commit totally messed up my change in the repulsor code where I changed the reference from "chargeConsumptionRate" to "resourceConsumptionRate" in the "effectPowerMax" calculation. Don't worry, I'll fix it.

I noticed that the repulsors no longer have support for that status stuff. You've commented out a bunch of code that used to update the status text. Are there plans to re-enable that functionality?

And yes, I was noting that we hit the 300 page level (if you're running the default posts-per-page settings) which is utterly insane for a non-release thread.

Edited June 22, 2015 by Gaalidas

[Tyren]

Refer to my signature and blame me

[Gristle]

Refer to my signature and blame me

What signature?

[Tyren]

yeah lol doesnt show up when posting with mobile phone...

- - - Updated - - -

What crap oO

[lo-fi]

That all sounds reasonable

Yeah, I'll get round to enabling the status stuff again. It wasn't working quite right anyway, so needs a re-write to suit the new methods.

The wheels also need a load readout, now there sensitive to load bearing.

Does more really go on in a release thread?? If so, what? I'll have to go take a look, I don't often stray to the full releases section!

[Tyren]

KSPI has 13k replies or somewhat along this line, there are plenty of 10kers there, too. But for a development thread this thingy here is pretty humongous^^

[lo-fi]

I wonder how many people lurk silently, watching the development madness as it unfolds....

Still chasing a pesky nullref in DustFX. It's stemming from this line in OnDestroy

			if (wheelImpact && !isImpactDataNull())
				WheelImpactSound.audio.Stop();

Now, wheelImpact has been set true by the MM patch, the details for which appear to be OK. In any case, it's a simple bool, so the culprit has to be isImpactDataNull() method. Except that's just a (somewhat redundant looking) wrapper for checking if the sound file string is null or empty.

Which leads me to believe there's something wrong with how WheelImpactSound is instantiated in the DustAudio() method. Or somewhere else, but the code is so convoluted I can't figure out why!

[Tyren]

Lets wait for the OUTPUT...

[lo-fi]

ARRRRGGGGGGHHHHH damn merge conflicts!!!!! Made a right mess this time

[*Aqua*]

I wonder how many people lurk silently, watching the development madness as it unfolds....

I always have some popcorn ready when looking into this thread. ^^

For bughunting it's never wrong to spam log messages everywhere until you find the culprit.

[lo-fi]

I guess you never know what's going to happen. Kinda cool knowing we're keeping people entertained while we go about our work....

Funnily enough, I've just been filling the offending module with just that! Though I think there's a subtle logic error (the code is full of funny double negative boolean checks), so it's going to be a pig to track.

[lo-fi]

Gaalidas, I've created myself a branch for the new DustFX stuff called DustFXDev. I'm slowly unpicking and simplifying the code - so far so good. Results shown here

What I'll do is hack all the methods down, then hand over to you for tweaking. That's all driven from KFModuleWheel, using the hit info from the wheel colliders. So much simpler you're not going to believe! The current method works just on speed, but I'll create one that works on slip and another for impact.

If you can leave the DustFX stuff in the master branch alone while I'm messing with this stuff it'll make it a lot easier merging it back. I'm only really working on DustFX.cs - the rest is absolutely fine as-is (I think)

EDIT: I can't see why the biome colours aren't working any more. Any ideas?

Edited June 23, 2015 by lo-fi

[Gaalidas]

The colors seem to be working for me, as far as I can tell. The colors are referenced using the config file that I uploaded which contains all the definitions, and are called up using a body/biome name, and lat/lon coords. I don't really understand much about how it really works, cause that part was written by xEvilReaperx and I barely managed to get it all working with the original CollisionFX code back when the color project was being worked on. I may have to compare the current code with the unchanged project that I have still under a separate folder from back before I merged with KF. By the way, I watched that video. Nice audio. The dust effects on static buildings such as the KSC (including its non-PQS grass and such) will always produce only the default color, which is supposed to be an extremely subtle gray color. In fact, more subtle than you've displayed in that video. I mean, real vehicles don't really produce much of an effect on the road unless they're spinning the tires. That would be an awesome thing to have in KSP by the way, some wheels just stopping completely when the brake is applied, others just spinning and producing massive amounts of dust (and generating lots of heat). Something for the future. The larger dust effects were meant for off-road applications, with the largest dust plumes being emitted on snow and sand, or when being repulsed at high speed.

I did a little testing today and found that, probably due to your changing of the modules and the methods they make use of, tracks such as the small ones no longer respond to the ride height adjustments. I also discovered that, when attached to something like the rollcage, they have an immense amount of torque. In fact, with a torque ratio of 1, which is the default, I could flip the craft just by moving forward slightly. That's not the biggest concern though, cause I was able to do an entire back flip (and landed on my head after it continued flipping after a complete flip) when I did the exact same thing but with the E-brake applied. That's right, those tracks were running at full speed, with the emergency brake on, even with the torque ratio set to 0.25! If you thought the mole tracks on an under-weight craft would flip you, you ain't seen nothing yet!

Also, the rollcage needs some work. First of all, I would not suggest using the JSI transparent pod stuff in the latest edition of RPM. The results are hilariously messed up. About 5 minutes into my test today, suddenly the dashboard prop grew to massive side, reoriented itself in a strange way, and from the outside of the craft it looked like I was using a giant concrete overpass section for a hood ornament. Not to mention all the interior indicators and stuff were all over the place. I also noticed the rollcage has some funky collision surfaces in which to attach things radially to it, and it contains a single stack node which is oriented towards the back of the pod but is located exactly in the dead center of the part. Weird stuff there. I'm unsure why RPM hasn't received an update to fix the transparent pod issues, but I do know they're rather unique to KSP 1.0.2 and the latest RPM update. Annoying stuff to say the least.

So, yeah... things need to be tweaked... a lot...

Anyway, sure, I'll leave the DustFX stuff alone for a few days at least. I was just thinking about the ways we could cut out the separate module and integrate it more cleanly with the KF modules. I didn't get a chance to test my first iteration of a possible water collider effect, but I'm sure it'll likely fail on the first go anyway.

- - - Updated - - -

I wonder how many people lurk silently, watching the development madness as it unfolds....

Still chasing a pesky nullref in DustFX. It's stemming from this line in OnDestroy

            if (wheelImpact && !isImpactDataNull())
                WheelImpactSound.audio.Stop();

Now, wheelImpact has been set true by the MM patch, the details for which appear to be OK. In any case, it's a simple bool, so the culprit has to be isImpactDataNull() method. Except that's just a (somewhat redundant looking) wrapper for checking if the sound file string is null or empty.

Which leads me to believe there's something wrong with how WheelImpactSound is instantiated in the DustAudio() method. Or somewhere else, but the code is so convoluted I can't figure out why!

I have no idea why this is happening to you, but that fix I created using that method to test the null-ness of the data was originally thought up when I was checking for more than just a few simple null cases. It's probably not as necessary now. the thing it, that fix was just thoroughly tested by me today and I got absolutely no exceptions with the above code. I'm thinking right now, however, we could just disable anything in the area of the impact audio. That's all impact is used for right now. CollisionFX uses it for stuff like spark effects too, I think, but those were not useful to me so I chucked them in the ol' proverbial trash bin. If we want to implement rough-impact sound effects for wheels, we'll do it in a much more efficient way.

- - - Updated - - -

I guess you never know what's going to happen. Kinda cool knowing we're keeping people entertained while we go about our work....

Funnily enough, I've just been filling the offending module with just that! Though I think there's a subtle logic error (the code is full of funny double negative boolean checks), so it's going to be a pig to track.

Before KerbalFoundries, that was me sitting back and watching the fun unfold. I've been browsing all these forums for at least a year longer than I've been registered. I found KF maybe a week after becoming a more active member... I think that's the timeframe anyway... it's all a bit of a blur right now. I agree though, multiple developers for a single mod can be down right entertaining at times.

EDIT: oh, by the way... is there a reason why the eye-coupler module is being called "KFCouplingEyeOLD" but is still referenced in the part config as "KFCouplingEye" which, obviously, will not function correctly?

OUTPUT...OUTPUT...OUTPUT...OUTPUT...

Edited June 23, 2015 by Gaalidas
OUTPUTOUTPUTOUTPUTOUTPUT

[Tyren]

There it goes Does the recent version,patch affect your adjustments? Ive seen a lot of changes for temperature management, dunno how much of effect there is to mods in general.

[lo-fi]

I've got a feeling they've changed the names in 1.0. I don't recall seeing landed at crawlerway before, for example. Also, dust used to change brown when driving off the slope at the side of the runway. Looks like it's not getting an expected name and defaulting, but I've not looked any further.

Unless you're looking for the NullRef you may well miss them. Only used to happen when deleting a part in the editor, or changing scene to space centre. Hoping it's fixed now anyway

You might as well ignore the experimental modules, they will be all over the place. I might start marking as such or you'll end up tidying stuff that will never see the light of day!