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.

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

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.

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.

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.

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

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

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.

The issue isn't what's currently passed from the DustFX module from the configs. The issue is with all the potential information that could be passed in. Remember when I explained the DustFX system a page or two back? That's a lot of potential for modifying how the DustFX module works on a per-part basis that will need a new way to be passed in if we are no longer able to define this module in the configs, and yet have no trouble defining as many other modules as we want. If it's working well, then so be it for the time being... but this really isn't an acceptable situation at all. Other mods may have similar troubles, but we don't see such game-stopping stuff happening with those either. What we should be looking at is why the module is still active on debris. I don't think we even need the wheel/repulsor modules doing anything if the part is debris. There's a lot that KF does based on the vessel modules, and a lot of shared information between the other part modules, which will likely go completely haywire when the vessel is an un-controllable debris object. EDIT: I've coded in a check for vesseltype.Drbris and told it to remove the offending module if that state is discovered when the parent module is started, which should take effect once the parts are made active due to being loaded into physics range (I think). If the module isn't on the part when that happens, then there should be no issue. I'll let you know what happens.

Sweet. More stuff for me to get massive headaches over. I look forward to it... I think... - - - Updated - - - That explains why I was having issues with my repulsor crafts jumping and rolling when transitioning. I actually never remembered to report that one, I just figured I was doing it wrong. I guess it's true what they say: "Once you become a developer, you are then incapable of properly testing a product no matter how much you try to break it." What I have to wonder is if this has more to do with the fact that the repulsor/wheel modules are calling for the dust themselves instead of letting the dust module handle it's own scenarios for when it should be active. One idea to fix the current setup though would be to add a check for whether or not the vessel is a valid command-ready vessel. If there was a way to detect debris, for instance, and disable the module when it is called for upon loading a debris object, then we might have a solution to the problem. Either way, it is going to be a really nasty issue if we have to rely on dynamically adding the module to each part since differently sized/shaped objects need to contain some specific parameters which is easily done by making them fields for use in the config. If we can't define the DustFX module in the configs, then we'll need to create a new module that we can define which contains the parameters to be accessed by the DustFX module. I'd be curious to see if we'd get these kinds of errors if we passed control back to the DustFX module as to when/if it should be emitting anything or not instead of having it called up from the wheel/repulsor modules. EDIT: Took a look at that link, interesting stuff I suppose. Not a lot of a surprise there however. A lot of that would require building a completely new effect in Unity rather than reusing one that's already loaded into the game. The color stuff has actually always been in there, we've just usually put the same color into each slot. I've not yet committed it, but I've been working on some variance to the colors for a future update.

Random camera movement? I have not experienced that at all, but then I don't use repulsors all that often. So, what if that safety measure is simply disabled? It's not really necessary anymore. All you really need to do is check for the modules existence on the part and, if not detected, simply not make the call for the dust to be emitted. Considering all the testing I did while we were nailing down the last of the repulsor dust effects, and I was trying to get around the errant biome syndrome (KSC tundra region), if there was a problem with random camera movement I'd surely have experienced that. I know that KSP itself has some parameters for camera movement in its settings, but beyond that and the IVA camera shaking mod, that's as far as random camera movement goes.

I guess I should have learned by now that KSP and the word "sense" don't really mix too well.

But only a "little bit" more important. Like a teeny weeny little bit. Now get back to work.

Hmm, if we need to add the module to the parts via code, then we're going to need to create another module for the sole purpose of being able to define part specific parameters for the dust module. I really don't see how this could be related to dust in any way though, unless this has to do solely with the code being asked to check if the module exists and add it if not found. It really doesn't make any sense though. Most modules are defined within the configs for the majority of parts.

I took a little bit of time to look through those logs and unfortunately I couldn't locate anything going wrong with KF directly. If the only constant is that there are KF parts on the ground, then I'd hazard a guess that there's another mod that's attempting to initialize something on those parts that it shouldn't be doing, or can't do when the part is in debris form. Either way, those errors and exceptions don't seem to be referencing the KF DLL or any of the classes, that I know of, contained within it. If another mod is doing something to those parts at run time, there's very little we could do to fix it. I'm seeing a lot of things that do concern me in that log that would affect the general stability of the game overall. Right off the bat we've got some warnings and errors related to empty config files, which used to cause instant crashes and, thankfully, don't do that anymore. That isn't to say they're not still a very bad idea. Other errors or exceptions seem to be related to engineering reports and issues with FSanimateGeneric and whatnot. I looked over every reference to the KF modules and found absolutely no glitches that I would know how to read. As such, I'm not convinced this issue has anything to do with KF directly and might be something that would occur with other parts of similar complexity as well, or could have to do with another mod trying to take readings on those parts and it isn't recognizing something due to the unusual ways some of the KF parts do what they do.

I know for certain that is the log from the dated crash logs KSP creates when it legitimately crashes rather than runs out of memory. The colorign might be due to the use of a PHP code box on the forums, or due to some sort of code recognition system in whatever text reader he's using going haywire.

What the.... I don't even know how to start trying to read that. Unfortunately, what's actually more useful is the KSP.log, or the output_log.txt from their regular locations, and not the one placed in those dated crash logs.

In OpenGL things don't always function like they should I'm afraid. Take Raster Prop Monitor for example, until recently you couldn't eve have semi-transparent HUD displays when under OpenGL. You'd just get a big black background. I might have to look at what they changed to make things compatible, but I'm unsure if that could even be related to this problem. When not using the camera option, even OpenGL users should be able to get correctly colored dust. This only means that any errant biomes, such as the KSC tundra zone, will be even more noticeable. There is also a slight change in how visible the particles are between the two modes which I was never able to fully equalize. The only thing I was aware of involving the camera and OpenGL from my very limited testing is that certain textures appear darker than they should in some situations. For instance, the grass that is attached to the KSC landscape showed up as a dark green, while the rest of the planetary grass was a light green. If the camera worked properly, you would definitely notice a change there.

I thought even mass relays required some form of compatible engine or at least an interface of some sort on the vessel to be used.

Funny you should mention that... CollisionFX was the base for my effects when I first started work on the (at the time independent of KF) DustFX mod. CollisionFX uses hard-coded color definitions, but still bases them on biomes which, due to the biome bug around the KSC, will still give bad results. I use a biome color definition file and an optional camera color sampler. I tried to share my findings with the CollisionFX author, but I've been unable to make contact in order to share it, so CollisionFX is still using hard-coded values. Either way, I still cannot fix a bug in the stock biome definition system. I am working on an optional state where it would use only the camera to sample colors, and totally ignore the definition file, which would not suffer from the errant biomes, but that's not quite ready yet. - - - Updated - - - Sadly, the individual toggle option never worked, so I removed it for the release. My suggestion would be to set up your battle fields in some other location.

So, if you have the camera option disabled, then you'll get this strange area around the KSC where it thinks it's in a tundra region, or it doesn't have a biome defined at all (I'm unsure which is correct) and it will revert to the tundra/default color (whichever is the case) which is more of a grey color in either case. There's really nothing I can do about that. This was one of the many reasons why we chose to attempt a camera color sampler. I must say, in that picture, I'm confused as to why there's no KF icon in your AppLauncher.

That explains it. Un-welded that would be a pain for KSP to hold together.

Hey, if you run in KSP 64-bit, good for you. (Keep in mind, KSP 64-bit is not the dsame as simply running kSP in a 64-bit operation system. It's two separate issues.) No one's telling anyone not to get it. The fact is that it's been tested with mods and without mods that KSP is simply not very stable in x64. It's not unstable in a consistent way, however, so one person might have perfect performance while the other crashes every time they do anything at all, and any variation between those two extremes. With this being the case, the first suggestion for issues with any mod will usually be to make sure you're not running in 64-bit. No one's forbidden to do so, but if you choose to do it then you also forfeit the possibility that the rest of us can diagnose a problem you are experiencing. That is simply how it is, and how it will be until either Squad or the Unity people can figure out a solution. Also, in my experience, high part count ships cause crashes no matter what bit rate you're running at. Even the people who post videos of high part count ships often have to speed up the playback to account for the temporal delay that KSP sets so that it can properly handle the physics of all those parts.

Indeed, can't view to video(s) right now, gotta go, but I look forward to viewing later.

I still think we need to cut the rover body up into a front, open-ended middle (with a shorter version of the middle for modular cargo bay construction), and a rear, but definitely not a priority right now. This mod is mostly about the "parts that move stuff over other stuff." Anything else provided is more or less an afterthought.