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

[Lyneira]

Thanks. Yeah, the punctuation is my fault! Think I've got a fix, will issue update later.

I think I changed the max height of the surface repulsors, though the others should be the same as they used to be. It's baked into the model and hard coded I'm afraid, so not really anything you can do with the config IIRC. You'll find that the damping changed the bounciness more than the strength, though setting a large value for strength will also help. Race Kerbol looks very cool; please do keep us updated!

Thanks for your suggestions! After a bunch more tweaking and testing I think I've struck a good new balance for the craft.

Offsetting them down as far as possible without looking detached got me a little bit of extra height, I made them physicsless in return to avoid drag and CoM issues with the racer. I brought the spring strength from 2.4 up to 4 and set damping to max which seems to have done a wonderful job of making the craft both safe to fly and have very little bounce.

I think it's actually safer than before despite the reduced overall height! I've issued a new release now where the current 3 scenarios should be properly playable again with the current Kerbal Foundries.

Edited August 16, 2015 by Lyneira
Grammar

[lo-fi]

Brilliant. I'll try and take some time out to play!

[Gaalidas]

I might have the same thing happening, no idea if it's just KF or not - this install has BD Armory plus a load of other stuff. I launched from KSC and took some KF wheels and tracks to the dirt runway and left them as debris (just KF and stock parts), switched back to KSC, launched a new ship and flew out to the debris at dirt runway. At 2.5km out framerate dropped to single figures along with lots of red in the debug log. I reverted the flight and exited KSP at that point. Here are the logs, I'll test some more with less other mods if you need.

http://www./KSP_Logs_b.zip

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.

[lo-fi]

Thanks Darren, I missed your post in thread first off. Something nasty going on in those logs, and I've managed to replicate. Something is really, really, REALLY broken. Not entirely sure what yet, as they're some obscure error messages.

EDIT: I just can't narrow this down. I've stripped everything out of the install, removed the camera and water slider modules and cleared MM cache. Seems to be an issue with debris parts, but I'm at a total loss to explain why

Edited August 16, 2015 by lo-fi

[AccidentalDisassembly]

FYI - Thread title says latest version is 1.9d. KerbalStuff download says 1.9b​.

[lo-fi]

Thanks, needs resetting.. I did release an updated version until I found another set of bugs it didn't fix. I'm having a rather unhappy time chasing a huge, enormous, gaping great big bug in the dust code that I can't believe didn't come out in testing. Ho hum :/

EDIT: For some reason, defining the dust module in the config sends everything haywire. Just that causes all that pain! Letting the repulsor module add it in with the same parameters works just fine. How odd...

EDIT2: Yep, that seems to cure it. Need to nail it down properly, then I can hopefully issue a fix tomorrow. How very, very odd.

EDIT3: Overhauling how dust and water slider are added. We can do this better.

Edited August 17, 2015 by lo-fi

[Gaalidas]

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.

[lo-fi]

At this point, none of it makes any sense :/

[smjjames]

Did something change with the download? Because KF is further up in KerbalStuff's recently updated mod list, but theres no changelog.

Edit: Oh, you had released a version, but it got pulled because bugs.

Edited August 17, 2015 by smjjames

[Gaalidas]

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

[lo-fi]

No, indeed! I have some ideas, but I've definitely narrowed it down to that. I only added the ability of the repulsor module to add the dust module in if it wasn't in the config as a safetly net against the old MM patch not applying correctly. Weirdly, it's also that which is causing the random camera movement when using repulsors too. It's all most odd.

[Gaalidas]

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.

Edited August 17, 2015 by Gaalidas

[Spooglecraft]

What happens when you crash into the ocean with repulsors:

[lo-fi]

Yeah, that's a bug we're working on fixing. I'm afraid it didn't come up in testing. Though it looks like you're using 1.9a, rather than b, which should at least fix that.

Gaalidas, I'll get back to you on the random camera movement. You'll see in the videos.

This first one, DustFX is defined in the configs for the repulsors. You'll note the repulsor debris in the distance, just out of physics range:

Not pretty...

Second video with DustFX removed from the configs. The repulsor module adds it in, having not found an instance:

Note that the debris comes into physics range and nothing bad happens? Yep. No idea. This is all using the 1.9b release .dll, by the way. I've tried removing the safety net of adding the dust module in, just in case, by some miracle, it was being added twice. No dice. Even tried moving its placement in the config. Nothing works, apart from letting the repulsor module add it in. I've not tested with wheels or tracks, but given that it's the same module, I'm sure that's the same problem.

Edited August 17, 2015 by lo-fi

[sjpc302]

Sounds exactly the same as mine actually.

Here is my output log. Unfortunately I had to try and simulate the crash again since my game crashed later (fairly regular modded ksp crash) and it seems the game only keeps one log. It took unusually long to crash, and it may be a different crash than the others because it didn't leave a dated file in my ksp folder but for some reason it didn't crash as normal. Anyway, since the crash doesn't always happen anyway it might not matter (?) which type of crash it was, but rather the events leading up to it.

https://drive.google.com/open?id=0B33yfQn7iBpccFpjRlhXRVZIQ0E

[lo-fi]

Cheers, the more info on this one the better. Finally homing in on it!

[sjpc302]

Yeah, I definitely seems like I have the same problem as Darren and that you found. I'll include a log from a crash I managed to cause, though it may be different that the others because it made no dated file in the ksp folder (and I guess it's not really needed anymore).

Should I just wait for the next update to fix it of is there something I should do now?

https://drive.google.com/open?id=0B33yfQn7iBpccFpjRlhXRVZIQ0E

[lo-fi]

Are you happy modifying config? If so, remove the DustFX{} sections from the KF parts you know you can use to reproduce the problem and let us know how it goes. It should all still work as it did, but the lag (and probably induced crash) will be gone.

[sjpc302]

I'll give it a shot. Worst case scenario and I mess everything up I can just reinstall.

[smjjames]

What happens when you crash into the ocean with repulsors:

http://i.imgur.com/91GAa1G.png

I had that happen to me when my hovercraft tried to turn while going at high speed on a river, one of the repulsors caught the waters edge (I think, it happened very fast), and my craft did what high speed racing boats do when they hit rapid unplanned disassembly.

[lo-fi]

Cool, thanks. Just so I'm clear with what I mean, you'll see something like:

EFFECTS
{
	WheelEffect
	{
		AUDIO
		{
			channel = Ship
			clip = KerbalFoundries/Sounds/wheel
			volume = 0.0 0.0
			volume = 0.1 0.2
			volume = 1.0 1.0
			pitch = 0.0 0.3
			pitch = 1.0 1.0
			loop = true
		}
	}
}


MODULE:NEEDS[TweakScale]
{
	name = TweakScale
	type = KFWheelSmall
}


MODULE
{
	name = KFDustFX
	maxDustEmission = 7
}
}

Remove the entire block:

MODULE
{
	name = KFDustFX
	maxDustEmission = 7
}

The repulsors will have a lew extra lines in, but as long as you catch everything between and including the curly brackets, that'll do it.

[lo-fi]

Also, Gaalidas, I know you were looking for a bit more control over the particles. I found this excellent tutorial, which I thought you might want to take a look over:

http://www.unity3dstudent.com/2010/10/beginner-b23-particle-systems/

Looks like we're not using the colour animator values to their full potential, and could probably make some more improvements there. Explains a load of the other stuff quite nicely too, I thought.

[Gaalidas]

Sweet. More stuff for me to get massive headaches over. I look forward to it... I think...

- - - Updated - - -

I had that happen to me when my hovercraft tried to turn while going at high speed on a river, one of the repulsors caught the waters edge (I think, it happened very fast), and my craft did what high speed racing boats do when they hit rapid unplanned disassembly.

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

Cool, thanks. Just so I'm clear with what I mean, you'll see something like:

The repulsors will have a lew extra lines in, but as long as you catch everything between and including the curly brackets, that'll do 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.

Edited August 17, 2015 by Gaalidas

[lo-fi]

Not a lot of stuff gets defined in the configs for the dust anyway, so it's just a matter of passing the values via the repulsor or wheel modules. No big deal really. This seems to happen even if you comment out the dust call from the repulsor module - just having the dust module present seems to send things potty, though I still have no idea why. You get errors about part highlighter and a few other things that look totally unrelated. Looks like other mods have struggled with this (FAR, from a little gooling), but no firm fix was found. The new setup seems to be working OK so far...

[Gaalidas]

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.

Edited August 17, 2015 by Gaalidas