Jump to content

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

lo-fi

By lo-fi
in KSP1 Mod Development

 Share

What to work on next?  

1,282 members have voted

  1. 1. What to work on next?

    • More wheels
      123
    • More tracks
      453
    • Rover bodies
      241
    • Landing gear
      137
    • Landing legs
      108
    • Something completely different
      193

Recommended Posts

Feradose

Feradose

Posted
Posted

So I was fiddling around with wheel settings in SPH. Large wheels to be exact. And did a test try on runway.. And my craft was floating, using its wheels. I can't explain this or tell you what I did, but I know the wheels didn't touch the ground, CoM share on wheels had effect (it nosed up) and it had no steering animation/friction.

Link to comment
Share on other sites
lo-fi

lo-fi

Posted
  • Author
Posted

I just can't figure it out :huh: 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.

Link to comment
Share on other sites
lo-fi

lo-fi

Posted
  • Author
Posted

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?

o6nNYPe.png

eaAhRuA.png

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

Link to comment
Share on other sites
sashan

sashan

Posted
Posted

Can you make them reflect light instead of emitting it? CUrrently particles in KSP are bright regardless of sun angle... Rocket smoke actually glows at night. Same here. :(

Other than that, it looks just like my RC car riding on stone dust. :P SOmething like this (same as mine). Btw, idea for wheel set. :P It's called E-Revo.

maxresdefault.jpg

Link to comment
Share on other sites
lo-fi

lo-fi

Posted
  • Author
Posted

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.

Link to comment
Share on other sites
Gaalidas

Gaalidas

Posted
Posted (edited)

Okay, I'm still aprsing my log from all the other errors I was getting from other mods (which I've since deleted because I'm tired of dealing with their... uhh... poo) but so far it looks like the offender could be linked to the light effect for the repulsors, which is currently governed by the DustFX module.

I'm also seeing some of this: "Duplicate TweakScale module on part [KF.RepulsorGimbal]" which I don't understand at all. Tweakscale doesn't get added by MM to any of our parts, and it doesn't add itself via code to anything, so it really shouldn't be duplicating itself.

Here's the specific error related to the lights and KFRepulsor:

NullReferenceException: Object reference not set to an instance of an object
    KerbalFoundries.KFDustFX.RepulsorLight (Boolean enabled, Single squish)
    KerbalFoundries.KFRepulsor.FixedUpdate ()

I'm also seeing this from when I was adding them to my craft:

NullReferenceException: Object reference not set to an instance of an object
    KerbalFoundries.KFRepulsor.OnStart (StartState state)
    Part.ModulesOnStart ()
    Part+.MoveNext ()

Every other instance of an exception, in relation to KF, was directly related to the lights on the repulsor module and specifically in the update method of the KFRepulsor class.

This tells me that the culprit must be related to the lighting system, and not necessarily the dust system as a whole.

Edited by Gaalidas
Link to comment
Share on other sites
lo-fi

lo-fi

Posted
  • Author
Posted

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.

Link to comment
Share on other sites
Gaalidas

Gaalidas

Posted
Posted
Just noticed that OpenGl actually works with camerafx. It just shifts colors closer to white. Can you see into it? IMO it would be fairly wasy to darken dust.

Yes, we could darken the dust, but then DX9/11 users would get dust that's too dark. I don't know of any way to detect what rendering mode the user is in that would let us change the particles like that.

- - - Updated - - -

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.

I forgot to add that all my testing is with a code change that basically stopped the DustFX module being added if the vessel type was currently of type "Debris" in which case it would also attempt to remove the partmodule "KFDustFX" from the part. So, technically the module shouldn't even be on the part once it becomes debris and/or is activated in the scene as debris. that might be why the light call is bugging out, but the number of errors I was getting relating to that were minuscule compared to spammed nullrefs that we usually see. It really doesn't explain the sudden extreme slowdown. In my case, RoboBrakes and BetterBuoyancy were freaking out, which I've decided to do away with for the time being.

Another interesting thing to note was that I was unable to select the repulsor part when trying to create action groups, but had no issue when moving the part around otherwise. Really strange.

Link to comment
Share on other sites
smjjames

smjjames

Posted
Posted

Hey Lo-Fi, I'm having some wierd problems with symmetry and the inverted tracks and having more than one pair of inverted tracks on a craft. I'm not sure if the fact that I have a probe core on top is confusing it, but when I made the video, the root is the inline probe core.

I'll post up link of the video when it's ready, youtube is slow as heck.

Link to comment
Share on other sites
Doughy

Doughy

Posted
Posted (edited)

is there any chance of this being converted to DDS textures in the future?

That's interesting info, thanks. I will look into it, the camera interaction can certainly be improved in DX9 mode too.

- - - Updated - - -

http://i.imgur.com/o6nNYPe.png

http://i.imgur.com/eaAhRuA.png

.

and also where is that vehicle from??

Edited by Doughy
Link to comment
Share on other sites
lo-fi

lo-fi

Posted
  • Author
Posted

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

is there any chance of this being converted to DDS textures in the future?

and also where is that vehicle from??

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

Link to comment
Share on other sites
smjjames

smjjames

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

I tried that and it didn't work. Actually, I figured out how I had triggered it, what I did was copy the front part forward of the inline command pod, turned it around so that it points backwards, and then placed it in back of the reactor. I think, or something like that.

Link to comment
Share on other sites
lo-fi

lo-fi

Posted
  • Author
Posted

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.

Link to comment
Share on other sites
lo-fi

lo-fi

Posted
  • Author
Posted

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?

Link to comment
Share on other sites
smjjames

smjjames

Posted
Posted

Pretty sure it's just that model. I haven't really tested with other tracks and haven't really had any problems. It's also less obvious with the other other tracks because they don't have the arrow shape on the track.

Link to comment
Share on other sites
lo-fi

lo-fi

Posted
  • Author
Posted

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.

Link to comment
Share on other sites
Gaalidas

Gaalidas

Posted
Posted (edited)

Hey, lo-fi, I don't know what you've been trying for a fix to the lag thing with repulsor debris, but with very minimal changes to how everything works in the previous build, I have the lag totally fixed I believe from testing the exact same situation as before: repulsors that are debris with a new craft loading into physics range. Absolutely no lag or log exceptions of any sort now. If you're not too attached to your own attempted fix, I'd be happy to commit my changes. This should allow us to keep the part config entries for DustFX intact.

My testing procedure was actually pretty hilarious. I had a repulsor craft rigged with decouplers and after getting up to a bit of speed I simply severed my limbs, so to speak, and ungracefully crashed, tumbled and came to a screeching and messy halt.

- - - Updated - - -

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.

And then there's the Screw where it's not just the texture that flips, but the entire mesh more or less, with it's screw threads that must be facing the right direction.

Edited by Gaalidas
Link to comment
Share on other sites
smjjames

smjjames

Posted
Posted

While I was trying to find out why I couldn't reproduce it in another save, I found a clue. Apparently having a part on it's side (the Honeybadger cargo pod from FTT has a clear top and bottom in it's texture, and I'm guessing in the model) and putting the parts on what would be the parts top and bottom confuses KF in some way while having the part the right way up works just fine.

Haven't tested other tracks just yet, just wanted to post on this.

With the pods like this, the glitch happens.

screenshot16_zpsklo68eym.png

Whereas, here, it doesn't.

screenshot17_zps9wqssg9e.png

Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...