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!

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!

Excellent! Any pics of your work in progress?

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!

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?

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!!!!!

Cheers dude, I got it. I've converted the APU to the newer ModuleEnginesFX. Not sure about the sound - maybe needs a little more mashing in Audacity before it's acceptable, but it's better than the inane screech of the jet sound effect. I noticed you did some culling of zeros in the configs! I've done a bit of messing with the tangents on the floatcurves, and found the "auto" mode to be pretty satisfactory for simple curves like we're using. Not specifying the entry and exit angles for each point activates that mode, which id why I started changing. Also in need of update in the configs is weight, cost, and a few other bits I can't remember - Riocrokite was kind enough to produce a spreadsheet that we'll have to dig out. There'a also the rolling resistance curves, which are only applied to the medium wheels and medium tracks properly IIRC. I'll have to come up with a generic set of number that works well for tracks and wheels so at least they can be plugged into the configs for tweaking at a later date. Still seems like there's a lot to do, but keep ticking jobs off the list.

Tell you what, I'll do another modding live stream on Wednesday and explain how it all works It looks so simple, but this is a far cry from how any other wheels functions - I've used some crazy bodges! Don't worry, Gaalidas. The correct check is if (!wheelImpact || Equals(wheelImpactSound, string.Empty)) return;

No, I've not messed with that for ages. Looks like it's failing to remove the OnPause and OnUnPause hooks, but I can't figure out why. Targeting .net 3.5. Pics of anything in-particular, Mekan1k? Ooooo, track versions might be tricky. There are limits to how much I can bodge the visual trickery! - - - Updated - - - DustFX is failing to stop the wheel impact sounds: void OnPause() { Debug.LogError("Enter OnPause"); isPaused = true; Debug.LogError("Set isPaused"); kfdustFx.particleEmitter.enabled = false; Debug.LogError("disabled particle emitter"); if (wheelImpact && (!Equals(WheelImpactSound, null) || !Equals(WheelImpactSound.audio, null))) WheelImpactSound.audio.Stop(); Debug.LogError("disabled sound"); } output_log says this: Game Paused! (Filename: C:/buildslave/unity/build/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56) Enter OnPause (Filename: C:/buildslave/unity/build/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56) Set isPaused (Filename: C:/buildslave/unity/build/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56) disabled particle emitter (Filename: C:/buildslave/unity/build/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56) NullReferenceException: Object reference not set to an instance of an object at KerbalFoundries.KFDustFX.OnPause () [0x00000] in <filename unknown>:0 at EventVoid.Fire () [0x00000] in <filename unknown>:0 at FlightDriver.SetPause (Boolean pauseState) [0x00000] in <filename unknown>:0 at PauseMenu.Display () [0x00000] in <filename unknown>:0 at PauseMenu.Update () [0x00000] in <filename unknown>:0 (Filename: Line: -1) So it's happy up until the debug statement Debug.LogError("disabled particle emitter"); then bugs out trying to stop the wheel impact sound. Is that something you've played around with? I can't recall doing so myself. Now, I think I've found the culprit: void DustAudio() { if (!wheelImpact || Equals(WheelImpactSound, null) || Equals(wheelImpactSound, string.Empty)) return; <SNIP> Something you can look into? I've got so much to do!!

Cool. Yeah, we may have to do some testing. Trouble is, the latest .dll requires all the configs to be re-written, so I can't let it out into the wild as an interim update without being packaged with all the other stuff. You're always welcome to grab from the GitHub repo for testing, of course. Latest dev build resides in there, though code has been moved out to its own space to simplify things somewhat. I will get there eventually! Feels like everything is in pieces at the moment, what with the rolling resistance stuff, vessel mass being passed to the colliders (which has made some surprising differences to the dynamics) and a major re-organisation of the modules. There are lots of part configs to look after theses days too! XD EDIT: I ought to add that I've made some serious optimisations, though. Rather pleased with that. EDIT2: Zodius, I've added you into the KSP422 repo. The scenes, source files and everything for my Unity setup is in there, so you can grab rigs for whatever you need. Everything else is up to date. A few notes: Many of the modules now take lists. For example, KFLookAt and KFSuspension. In the case of KFLookAt, the format is: MODULE { name = KFLookAt targetName = Dummy002,Dummy003,Dummy004,Dummy005,Dummy006,Dummy007,Dummy008 rotatorsName = Strut02,Strut03,Strut04,Strut05,Strut06,Strut07,Strut08 activeEditor = true } The targets and rotators relate to each others index positions, so Strut02 looks at Dummy002, Strut08 looks at Dummy008. They look along Z+, rotate around X, and ONLY X - no need to worry about funny rotations if slightly off plane. KFSuspension works in a similar way - it accepts lists of WheelColliders: MODULE { name = KFSuspension colliderNames = WCL,WCR susTravName = SusTravInner susTravAxis = y } Only one suspension Traverse object is support per module declaration, though. This is because it's designed to average the travel of how ever many WheelColliders it's given and move the single susTrav object accordinly (this is how I got the swing axle to work). ONE THING TO NOTE (I know we've discussed it, but just in case you forget!) The names of objects are searched using StartsWith(). This might seem odd, but this is how I get asymmetric parts in KSP. I have handed parts inside one parts. The code destroys the unused one then the other modules get to go and find their objects. So for each hand, you have objects that might be called WC01Left and WC01Right, one of which gets destroyed before any objects are searched for. Of course, in the config in a MODULE looking for such an object, you'd just tell it to look for WC01 and whichever version is left after one hand being destroyed will get found. I know I won't have to spell out what happens if you have objects named WC, WC001, WC002 and you try finding WC... Just something to be careful of, but it opens up some really interesting part design possibilities.

I've got a couple of bits to tidy up and double check, but if you're OK with the Unity scene and the config to guide you, you can start right away. I'll get everything updating into Git for you. - - - Updated - - - Hehe. Never a dull moment here hope you're enjoying your holiday!

Riocrokite, I know this was something you were after: I re-wrote the suspension stuff to make this to happen. It's now more modular, making landing legs much easier when I get round to building some.

Gaalidas, DustFX is throwing Nullrefs all over the place: NullReferenceException: Object reference not set to an instance of an object at KerbalFoundries.KFDustFX.OnDestroy () [0x00000] in <filename unknown>:0 UnityEngine.Object:DestroyImmediate(Object, Boolean) UnityEngine.Object:DestroyImmediate(Object) :MoveNext()

The repulsor module was a mess from adding in the gimbal, and the retract routines had become an unmaintainable mess. For some reason, they had stopped consuming EC - I couldn't work out why, so I re-wrote. Still in progress. Thanks for the hint on the sounds, that does make sense. I knew it didn't work, but hadn't got as far as figuring out why. I know ho to set up the effects node, but how do I use that in the engine module? Just refer to it by names? What about the path? Why does this have to be so hard?!?!?! Hopefully nothing existing broken, but next will be 1.9

Yeah, the idea is to default it to stock EC but allow patching to others.

I am INVINCIBLE!!!!! Lots of cool new stuff about to happen and everything is in chaos. Usual prerelease status...

Hehe! Good luck with that one! Probably most useful on the spring field, as I very much doubt anyone runs out of damping adjustment. Changing how the ride height gets affected is probably best done internally, rather than messing with the slider ranges, and would be quite a challenge in itself. I'm in the middle or rewriting the repulsor modules, as well as the wheel modules. Please don't go correcting typos in the meantime - it plays havoc if I've forgotten to sync before firing up VS to mess with something quickly and then throws a few hundred sync conflicts at me!

That's perfect, thank you!

That would be nice, but I never figured out how to set the values for the tweakable sliders dynamically, which is why they're hard coded. There may be a way with KSPAPIext, but I hate dependencies, and it seems to get broken every release.

Sure, I'll bung it on the list, but can't guarantee I'll remember!

Got a major feeling a deja vu...

The more I think about it, and having carefully re-read that post a few times, I realise squad are pretty much trying to recreate what KF does anyway. The modular approach is pretty much what I've gone for, though it sounds like they're taking it further, and all the gumpf about steering, vessel mass and the colliders was true with the U4 stuff. I downloaded U5 last night so I can set up a sort of mock KSP environment with rigidbodies strapped together with joints and some colliders, which ought to tell me whether there really is anything to be concerned about. Either way, its going to cause a lot of work and many headaches.

We'll see soon enough :/

Yeah, I'll be tidying up to do a release so we can get the latest goodies out. I haven't downloaded U5 and played with the new colliders yet - it may all be a storm on a teacup, and all they're doing is recreating a load of stuff I already know how to tackle, but it's still worrying.

Yeah, I've posted a comment. Will wait and see! Though to be honest, I'm really not interested in using the stock modules. There's some subtle (and slightly crazy) stuff built into KF that allows the asymmetric designs like the mecanums and most of the upcoming tracks that is highly unlikely to see the light of day in a stock module. Life is so much easier when you have control; most of the KF stuff simply wouldn't exist if I hadn't been able to bend the plugin to the parts, rather than the other way around.