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

[Gaalidas]

Great Midred's corset... you didn't have to overhaul everything lo-fi. Way to over react. Your fix might improve things, but I was able to get it to work without any overhauling at all and without a need to remove any module configs. The code is a real mess now. Eesh.

[smjjames]

*ponders if theres a right way up*

*notices the text*

*checks big wheels*

*flips the upside down one*

*HAS EUREKA MOMENT! (okay, not really a moment, more like a proccess ending in 'HA!' when I saw that it fixed it)*

So, there actually IS a right way up (as far as KSP is concerned) for those inverting wheels.

[Gaalidas]

Yeah, they're not really inverting... or invertable so to speak... they just don't have an obvious correct orientation until you experiment on them.

Alright, lo-fi. I see that some of your overhauling will probably make things work better in the long run... except I really don't see why the vessel modules had to be made into part modules, and if that's a permanent change then we're going to have to put those modules into the part configs, or get other modules to add them dynamically. With the camera, that means we'll be spawning a camera for every part with that module on it which is going to really foul things up.

Either way, I've merged my changes in and restored the DustFX module to it's proper state now that the debris thing is solved, at least as far as I can tell. I really think my minimal changes were a better plan overall, but I defer to your expertise here. if your fix still includes removing the module from the part configs, then I must insist you try out my alternative fix. In my fix, the module was not only added if not present, but it was also removed when the "Debris" state was detected.

I'm unsure what your plan was with disabling most of the KSPFields in KFDustFX, but considering some of my recent enhancements rely on the module keeping it's Fields intact, I've restored them to working order.

Edited August 18, 2015 by Gaalidas

[smjjames]

Actually, no, that didn't fix it, also, moving a vehicle from SPH to VAB does wierd things with symmetry if you try and rotate something that was origionally mirrored.

You know, I wonder if the way I'm delivering them to the Mun is confusing the plugin in some way.

Edited August 18, 2015 by smjjames

[Gaalidas]

If it's being confused by the way you are delivering them, simply swapping back to the space center and back to the landed craft(s) should reset anything that would have been confused.

[lo-fi]

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

[lo-fi]

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

Edited August 18, 2015 by lo-fi

[Space Scumbag]

Here the video I was making. The Wheels and DustFX look awesome!

[riocrokite]

Here the video I was making. The Wheels and DustFX look awesome!

awesome work! dustFX rules

[lo-fi]

Here the video I was making. The Wheels and DustFX look awesome!

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

[Space Scumbag]

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

Thanks.

I'm planning to continue the story, that's why I am asking for motorcycle wheels.

And I hope you guys saw the movie, my videos spoiler everything.

[lo-fi]

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

[Space Scumbag]

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 already welded many parts together with the welding mod. The Doof Wagon for example. It does exactly what you describe. All physics calculations of a craft are reduced into a single one. The drawback is, it's just a giant part and explosions don't look great.

[smjjames]

Theres a bug going on with the wheels and tracks where if you go over the rev limit, trying to press 'S' or 'W' to reverse doesn't work. Also, how do I increase the rev limit of the RBI inverting (or invertable) tracks? Because they hit the rev limit really fast.

[lo-fi]

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?

[smjjames]

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?

Well, it depends on whether you intended to cap the speed around 13m/s.

Edit: Wierd, the maxRPM for the RBI tracks is twice that of the mole tracks, but those go faster......

Edited August 18, 2015 by smjjames

[lo-fi]

I already welded many parts together with the welding mod. The Doof Wagon for example. It does exactly what you describe. All physics calculations of a craft are reduced into a single one. The drawback is, it's just a giant part and explosions don't look great.

Ah, of course, the welding does the same thing.

In other news:

Also, I see TweakScale is broken again...

- - - Updated - - -

Well, it depends on whether you intended to cap the speed around 13m/s.

Edit: Wierd, the maxRPM for the RBI tracks is twice that of the mole tracks, but those go faster......

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

[Gaalidas]

Tweakscale can't be broken... nothing has changed. What are the symptoms?

[lo-fi]

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

[smjjames]

Screenshots showing what I described. Since my initial tests were with a craft that was already pretty heavy, I made a simpler rig that was as light as possible.

[Gaalidas]

So, I did another test today and ran into the exact same problem that we were trying to fix yesterday. I don't understand it considering I had it completely stable and I did a merger between your fix and mine so everything should be fine. I'm going to try and revert my local copy back to what it was before we did all this fiddling around and attempt to re-apply my own fix without any of your recent changes.

[smjjames]

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

That sounds like the usual bug with tweakscale and scaling root parts.

[lo-fi]

So, I did another test today and ran into the exact same problem that we were trying to fix yesterday. I don't understand it considering I had it completely stable and I did a merger between your fix and mine so everything should be fine. I'm going to try and revert my local copy back to what it was before we did all this fiddling around and attempt to re-apply my own fix without any of your recent changes.

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.

[lo-fi]

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:

[smjjames]

Decided to screw around with the max RPM setting for the inverting tracks and set them to 40,000.

On the Mun, it reaches the RPM limit around 30m/s, but I start losing control around that point anyway.

On Kerbin, I can reach an excess of 100m/s without hitting the RPM limit, which is over 223 mph or 360 kph. Setting torque to 2 on Kerbin just launches me off the ground.

It's probably an understatement that a 40,000 RPM limit is a little overpowered.

Edit: Set it to 4,000, which helps a little better, but still....

Edited August 18, 2015 by smjjames