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!

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

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.

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.

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.

I got carried away and mavericked up a UI slider so you can change how much dust is produced in-game. Was far easier than I thought! Note the smooth transitions between the biomes:

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 updated when trying things yesterday. It goes haywire (index out of range spam) if you try to copy a scaled part, and seems to forget to scale things. The probe core in that pic was .625m diameter when I launched it first time...

Ah, of course, the welding does the same thing. In other news: Also, I see TweakScale is broken again... - - - Updated - - - I think you're forgetting that RPM depends on a wheels diameter... No, the speed on the flat shouldn't be capped by the RPM limit; looks like I forgot to set it correctly for the inverting track

At the rev limit they're deemed to be spinning too fast for the motors to create any meaningful torque, so it's more of a feature than a bug. The brakes will still work maxRPM in the config is what you're looking for. Did I get the value wrong?

While watching it, I had an idea that might improve the framerate for videos... Has anyone ever tried making a module that forces a parts physical significance to 1? I believe that will prevent it from making a physics joint, an just parent itself to whatever it's attached to. Loads of those structural panels, for example, would probably work with the treatment. If it works as I think it does, that would certainly calm the overworked physics engine down....

I don't know about you guys, but that just made the whole thing worth it!!! Incredible. Absolutely incredible. Thank you for posting

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. That's what this log entry is about: FieldAccessException: Cannot set a constant field at System.Reflection.MonoField.SetValue (System.Object obj, System.Object val, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Globalization.CultureInfo culture) [0x00000] in <filename unknown>:0 at System.Reflection.FieldInfo.SetValue (System.Object obj, System.Object value) [0x00000] in <filename unknown>:0 at ProtoPartSnapshot.Load (.Vessel vesselRef, Boolean loadAsRootPart) [0x00000] in <filename unknown>:0 at ProtoVessel.LoadObjects () [0x00000] in <filename unknown>:0 at Vessel.Load () [0x00000] in <filename unknown>:0 at Vessel.Update () [0x00000] in <filename unknown>:0 KSP is trying to set a variable that's been declared constant. It's leads to this, because the config setup routine has just got borked by the reflection error: NullReferenceException: Object reference not set to an instance of an object at Part.ModulesOnStart () [0x00000] in <filename unknown>:0 at Part+.MoveNext () [0x00000] in <filename unknown>:0 (Filename: Line: -1) NullReferenceException: Object reference not set to an instance of an object at Part.ModulesOnStart () [0x00000] in <filename unknown>:0 at Part+.MoveNext () [0x00000] in <filename unknown>:0 I think the lesson here is not to action things because the compiler thinks they're a good idea without some serious thought first, but at least we've got to the bottom of it and learned something. All the compiler sees is that that variable will never get changed by our code - which is true - but it doesn't have a clue that KSP is going to come along and try to mess with it later via reflection because it's marked with the KSPField attribute. Thank $%^* that's over. EDIT: Or was that a carry over from CollisionFX that got turned into a KSPField? Who knows. I'm just glad it's done with

Yeah, I thought I was working in my dev branch, not the master, so a bunch of other stuff got mixed in. And, of course, with unmerged changes, it won't let you swap branches, so I ran with it. I'll check it out later, I have quite a comprehensive testing scenario going on

There's actually some clever plugin trickery that makes the track treads point the correct direction by flipping the texture on the side that's going "backwards". You'll find the long, small and maybe some others have a similarly directional texture, though it's a bit more subtle. If it is just that RBI, I can maybe figure that out quickly enough.

The plugin should fix the lag issues with debris parts we've had such a serious problem with. I'm not going to have time to look into that strange orientation thing for a good while I'm afraid - sorry. Does it happen with other tracks, or just that rbi model?

That's certainly interesting. I wonder what it is about that particular combination of root part orientation that does that.... Most odd. - - - Updated - - - Alright, for those that are interested in doing so, give this updated plugin a go. If you can't figure out what to do with it, you don't want to be messing with it.

Ah. You've somehow managed to fox the direction detection. Nobody has managed to do that for ages!! Don't forget that KSP doesn't have mirror symmetry, It's rotational. So I have to figure out which 'way' tracks or wheels are supposed to be going based on the orientation in relation to the command pod, which isn't actually as easy as it sounds. Try controlling from a different command pod or docking port. - - - Updated - - - Nope. I gave up with having pants looking textures after the conversion and went with sharing/reducing size instead. Feel free to convert them yourself, though. Vehicle is just the rover body that comes with the mod, plus HD versions of the large wheels I've been working on. - - - Updated - - - Something further.... This annoyed me, and it's definitely to do with a KF module: FieldAccessException: Cannot set a constant field at System.Reflection.MonoField.SetValue (System.Object obj, System.Object val, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Globalization.CultureInfo culture) [0x00000] in <filename unknown>:0 at System.Reflection.FieldInfo.SetValue (System.Object obj, System.Object value) [0x00000] in <filename unknown>:0 at ProtoPartSnapshot.Load (.Vessel vesselRef, Boolean loadAsRootPart) [0x00000] in <filename unknown>:0 at ProtoVessel.LoadObjects () [0x00000] in <filename unknown>:0 at Vessel.Load () [0x00000] in <filename unknown>:0 at Vessel.Update () [0x00000] in <filename unknown>:0 This led to: NullReferenceException: Object reference not set to an instance of an object at Part.ModulesOnStart () [0x00000] in <filename unknown>:0 at Part+.MoveNext () [0x00000] in <filename unknown>:0 (Filename: Line: -1) NullReferenceException: Object reference not set to an instance of an object at Part.ModulesOnStart () [0x00000] in <filename unknown>:0 at Part+.MoveNext () [0x00000] in <filename unknown>:0 Which is what appeared to be borking the startup routines and spamming everything. Removing the "const" prefix that had crept into some of the variables in various classes seems to have fixed that. Now all that's left is to figure out which module is springing an NaN, but I'm pretty confident I know what that is....

Also, I just made a mess of a Git merge. Think I over-wrote a previous commit... Sorry!

I have no idea what you're on about?

Funny you should say that about stopping stuff working if the part is debris... I've just implemented that! Great minds.... Odd about the action groups!

I saw the TS error too. It looks like that part gets instantiated or the startup stuff rerun over and over again, which I don't understand. I've not messed with the light, but that's only setup if it's a repulsor.

That I've no idea about. We're probably governed by what particle shaders Squad have decided to give us. I've got to admit, my ageing PC with an ATI 5770 handles just about as much dust as I can feed it. I'm quite impressed.

That's interesting info, thanks. I will look into it, the camera interaction can certainly be improved in DX9 mode too. - - - Updated - - - Also, did someone say graphics card destroying plumes of dust? I changed a few of the calculations around The fix is coming on well; it's all looking good so far. Or at least as a duct tape job until we figure out what the underlying cause is..

I just can't figure it out The logs are obtuse, the modules doesn't do anything that I can see that's remotely related to the error message, and I'm stuck. The vessel modules I've abandoned in favour of adding partmodules as before; they're just too much of a liability There are a few ways around the dust module configuration issue that setting it up like this causes. Granted, it would be great to get it actually fixed, but I don't have infinite time to throw at it. Creating a config subnode in the repulsor or wheel module would work, but I'd favour having some a scalar factor which sets dust size and whatnot, rather than fiddling with a thousand variables in the config. That's something broken, Kweller. Send me an output_log and I'll be able to tell you what. What happened there was the module activated the wheel colliders, then got stopped because of an error which prevents all the control input and visible stuff working.