Gaalidas

I'm loving that antenna... even considering I never use those, it's still a awesome thing to behold. Who knows, I could probably stick a scanner module on the part and use it for that. The DuoTetrahedron is just.... weird.... really weird....

It looks like he custom-built a two-man command seat and shaped it like a roll-cage. If that is a transparent pod, it's the most transparent transparent pod I've ever not-seen. "Cute" is a good description of it, too. As for ABS... honestly I want nothing to do with it at this moment. I'm having a heck of a time trying to get SharpDevelop to detect and compile for .net 3.5 instead of the only error-less option that i seem to have (version 4.0) so that my attempts at plugin writing aren't thwarted by the fact that KSP is built on and reacts best to version 3.5. It's not going well. Still, if the ABS-sorta-kinda-brake-pulsing plugin works pretty well, I may look into making it easier to integrate into a rover than having to put an ugly huge part on it. It'd be more "kerbal" to just stick a few super short-burning solid boosters (like those landertron mod thingers) on the front and fire them off when you need to stop moving. I think the landertron mod also had the ability to be re-fueled using tiny hex-cans on EVA, like reloading an old cannon by hand.

Your assumption is false, I wouldn't be using windows 8 if you paid me. It's too weird. I'm running Windows 7 ultimate. I also just attempted to install the SDK for 3.5 and it made absolutely no difference when trying to change the project into a 3.5 framework project. EDIT: I have tried everything I can think of from installing .net framework 3.5, 4.5, 4.0, etc and I am still being told that the SDK or Targeting Pack for .net 3.5 is required. I am told online that you cannot install it on Windows 7 because it's included, but it apparently is NOT included because I can't reference it or compile with it. When I search explicitly for ".net framework 3.5 SDK" on the microsoft download site, I am presented with several pages of search results containing everything except the freaking SDK for 3.5. I get 2.0, 4.0, 4.5, but NOT 3.5 even though I specifically entered "3.5" into the search area. No matter what, the only .net framework version that I can successfully use is 4.0, and only 4.0. Anything else and it fails to even build the project. This is going to drive me absolutely insane.

that is not what's really happening here. When I open a project that previously referenced framework 3.5, I see this: The reference assemblies for framework ".NETFramework,Version=v3.5" were not found. To resolve this, install the SDK or Targeting Pack for this framework version or retarget your application to a version of the framework for which you have the SDK or Targeting Pack installed. Note that assemblies will be resolved from the Global Assembly Cache (GAC) and will be used in place of reference assemblies. Therefore your assembly may not be correctly targeted for the framework you intend.However, upon trying to find the required SDK, I'm being told that installing this older SDK package is not recommended and I worry about it causing problems with other projects that use a different framework version. Besides, actually finding a proper download for these things is near impossible. Microsoft's own site says that a different package is recommended, but it doesn't link me to that package that it suggests, so I can't actually find it. I just don't undrstand why it's a problem here due to the fact that 90% of the other mods, all quite complicated pieces of work, in which I convert to framework 4.0, function perfectly, and yet this one will not even load properly with rather vague errors that do not exist when compiling or writing the code itself. The only thing that changes, that I can see, when changing the targeted framework version, is that a new reference gets added (Microsoft.CSharp) and the error about a missing reference SDK is removed. - - - Updated - - - That's interesting... but I think it might be a little beyond my scope for the time being. It would only really come into usefulness if the surface of a body was covered in custom landscape using models that are separate from the body surface in which I could match the dust color based on their apparent material type. At the KSC, however, I think the pavement and the grass is all part of the same false-landscape object, so I wouldn't necessarily be able to map only a slight barely-visible trail to the paved areas and a grassy/dirty trail to the grass areas. As it is, I'm just going to further tone down the default dust effect and let that take over when the collision with the actual planetary surface is lost. I may even, in the far future, re-implement the effects from CollisionFX (if I can get in touch with the original author for some cooperation) so that the tracks, for instance, can create some very subdued sparking when scraping against the pavement during tight turns. Good to have that option available, though. Right now, my best idea for how to make it all work, was simply to replace the switch I have currently with a call to the GetDustColor method which, I believe, takes a name for the body you're checking for the settings of, and pass the name of the body/biome that is found in the method that I currently have for figuring out what the vessel is colliding with. I'm really not knowledgeable enough with these things to rewrite the method for using a different detection method than what is used now. See, this isn't a completely original piece of work, but rather a re-purposing of CollisionFX, which was not authored by me.

Ah, so it's specific to 3.5? There are only a few recompiles of other mods that reacted badly to switching to 4.0. The reason is that when I load a project that uses 3.5, it tells me something is missing that it needs. By experimentation, I found that 4.0 got rid of that problem. I am unsure why it matters in these few cases, but in most other does not. I am unsure how I could rectify the situation of having to reference version 3.5. I actually haven't posted my source anywhere at this time. It doesn't even work fully yet, and it's very specifically aimed at the parts found in the Kerbal Foundries mod, so it's really not too useful outside of that context.

One question: by "max/minScale is obsolete" do you mean that it is now simply not necessary or that it is now not even functional? I worry about older configs not responding as expected... not that it's happening just yet, but then again I have yet to test all of my parts that have a tweakable scalability setting on them.

Nope, nothing counts but complete perfection. Today is not your day, and tomorrow doesn't look good either. ... No, honestly, lack of flippage would make you comparable to a god I believe. I think the issue with low gravity worlds is that while trying to stop, the reaction with the ground forces the craft to lift upward slightly. In high-gravity locations the craft will drop down immediately, and with an atmosphere you will also get drag from the air which forces the craft back down after this upward lift reaction occurs. On the Mun, however, there is no air-drag and the gravity is low enough that the craft lifts off the surface ever so slightly which decreases the effect that the grip of wheels would have on your forward momentum. This is not helped by the fact that brakes, in KSP, mean "lets slam down on them and try to stop as quickly as possible with no regard for safety." What you need is a braking system that slowly brings the craft to a stop so that the sudden jerking of the wheels doesn't cause miniscule airtime. I fear that with such low gravity, however, that might not help much. In this case, you may need some form of thrust to either help with braking, or simply increase the pressure on the wheels towards the ground. Alternatively, a dummy weight object might also help to keep things grounded, or a fuel tank which could be filled from a lander to add extra weight. I'm also testing an old mod right now that added a part which could be used to implement an ABS system to a rover. In this case, it simply pulses the brake when activated until the vehicle comes to a complete stop. It's not exactly the most ideal solution, but it's an interesting take on the problem.

Well, grind me up and feed me to the space monkeys... That's awesome. I just woke up and I'm so not ready to process that, but it looks like a cure from where I'm sitting. Thanks a bunch. UPDATE: alright, I'm a bit fresher now and hopping to it. I hope you don't mind, but I'm going to take the easy way out at the first and pretty much copy what you posted word for word and see where it takes me. This is what always messed me up in classes: they try to teach you by showing you how it starts and then giving you a problem that cannot be solved by what you have and expect you to figure it out. I learn better by taking apart a complete example of exactly what I need and morphing it into my own. That's why I normally will go to the end of my math book and start tearing apart the final questions of the entire class of thought and trying to make them function for me. It really bugs my teachers though, which could be absolutely hilarious and quite entertaining if is wasn't for the fact that they are deciding my future by grading my work. In this context, I had completed (or functional at least) mods to look at, some of which I didn't have the source for and had to cheat by using ILSpy (I'm so sneaky) but none of them really did what I was trying to do in a way that would make sense because they weren't handling the data I needed handled, and almost all of them were not just loading but also saving way too much information for my needs. Anyway, I think I'm going to get there now. EDIT2: Okay, so it's not liking something in there: [COLOR=#0000ff][B] public[/B][/COLOR] [COLOR=#ff0000]class[/COLOR] [COLOR=#004085]DustColorDefinitions[/COLOR] : [COLOR=#004085]IPersistenceLoad[/COLOR], [COLOR=#004085]IPersistenceSave[/COLOR] { [Persistent] [COLOR=#0000ff][B]private[/B][/COLOR] [COLOR=#004085]List[/COLOR]<[COLOR=#8b0000]BodyDustColorInfo[/COLOR]> [I]BodyDustColors[/I] = [U][COLOR=#008b8b][B]new[/B][/COLOR] [COLOR=#004085]List[/COLOR]<[COLOR=#8b0000]BodyDustColorInfo[/COLOR]>();[/U] [COLOR=#006400]//[COLOR=#006400](underlined above) C[/COLOR]annot implicitly convert type List<?> to List<BodyDustColorInfo>[/COLOR] [Persistent] [COLOR=#0000ff][B]private[/B][/COLOR] [COLOR=#004085][B]Color[/B][/COLOR] [I]DefaultColor[/I] = [COLOR=#004085][B]Color[/B][/COLOR].clear; [COLOR=#0000ff][B]private[/B][/COLOR] [COLOR=#004085]Dictionary[/COLOR]<[COLOR=#004085]CelestialBody[/COLOR], [COLOR=#8b0000]BodyDustColorInfo[/COLOR]> [I]_dustColors[/I] = [U][COLOR=#008b8b][B]new[/B][/COLOR] [COLOR=#004085]Dictionary[/COLOR]<[COLOR=#004085]CelestialBody[/COLOR], [COLOR=#8b0000]BodyDustColorInfo[/COLOR]>();[/U] [COLOR=#006400]//[COLOR=#006400](underlined above) C[/COLOR]annot implicitly convert type Dictionary<CelestialBody> to Dictionary<CelestialBody, BodyDustColorInfo>[/COLOR] [COLOR=#0000ff][B]public[/B][/COLOR] [COLOR=#004085][B]Color[/B][/COLOR] [COLOR=#191970][B]GetDustColor[/B][/COLOR]([COLOR=#004085]CelestialBody[/COLOR] body, [COLOR=#ff0000][B]double[/B][/COLOR] lat, [COLOR=#ff0000][B]double[/B][/COLOR] lon) { [COLOR=#8b0000]BodyDustColorInfo[/COLOR] biomeColors; [COLOR=#004085]BiomeDustColorInfo[/COLOR] dustColor; [COLOR=#0000ff][B]if[/B][/COLOR] (![I]_dustColors[/I].[COLOR=#191970][B]TryGetValue[/B][/COLOR](body, [U][COLOR=#ff1493][B]out[/B][/COLOR] biomeColors[/U])) [COLOR=#006400]//(underlined above) Cannot implicitly convert type ? to BodyDustColorInfo[/COLOR] [COLOR=#000080]return[/COLOR] [I]DefaultColor[/I]; var biome = [COLOR=#004085]FlightGlobals[/COLOR].ActiveVessel == [B]null[/B] ? [COLOR=#ff0000]string[/COLOR].[I]Empty[/I] : ([COLOR=#ff0000]string[/COLOR].[COLOR=#191970][B]IsNullOrEmpty[/B][/COLOR]([COLOR=#004085]FlightGlobals[/COLOR].ActiveVessel.[I]landedAt[/I]) ? [COLOR=#004085]ScienceUtil[/COLOR].[COLOR=#191970][B]GetExperimentBiome[/B][/COLOR](body, lat, lon) : [COLOR=#004085]Vessel[/COLOR].[COLOR=#191970][B]GetLandedAtString[/B][/COLOR]([COLOR=#004085]FlightGlobals[/COLOR].ActiveVessel.[I]landedAt[/I])); [COLOR=#000080]return[/COLOR] biomeColors.[COLOR=#8b0000]GetDustColor[/COLOR](biome); } [COLOR=#0000ff][B]public[/B][/COLOR] [COLOR=#ff0000]void[/COLOR] [COLOR=#191970][B]PersistenceLoad[/B][/COLOR]() { [I]_dustColors[/I] = [I]BodyDustColors[/I] .[COLOR=#191970][B]Where[/B][/COLOR](info => [COLOR=#004085]FlightGlobals[/COLOR].Bodies.[COLOR=#191970][B]Any[/B][/COLOR](b => b.[I]bodyName[/I] == info.[COLOR=#8b0000]Name[/COLOR])) .[COLOR=#191970][B]ToDictionary[/B][/COLOR]( info => [COLOR=#004085]FlightGlobals[/COLOR].Bodies.[COLOR=#191970][B]Single[/B][/COLOR](b => b.[I]bodyName[/I] == info.[COLOR=#8b0000]Name[/COLOR]), c => c); } [COLOR=#0000ff][B]public[/B][/COLOR] [COLOR=#ff0000]void[/COLOR] [COLOR=#191970][B]PersistenceSave[/B][/COLOR]() { [COLOR=#0000ff][B]if[/B][/COLOR] (![I]BodyDustColors[/I].[COLOR=#191970][B]Any[/B][/COLOR]()) { [COLOR=#008000]// generate default config[/COLOR] [I]BodyDustColors[/I] = [U][COLOR=#004085]FlightGlobals[/COLOR].Bodies.[COLOR=#191970][B]Where[/B][/COLOR](cb => cb.[I]BiomeMap[/I] != [B]null[/B]).[COLOR=#191970][B]Select[/B][/COLOR](b => [COLOR=#008b8b][B]new[/B][/COLOR] [COLOR=#8b0000]BodyDustColorInfo[/COLOR] { [COLOR=#8b0000]DefaultColor[/COLOR] = [I]DefaultColor[/I], [COLOR=#8b0000]Name[/COLOR] = b.[I]bodyName[/I], [COLOR=#8b0000]BiomeColors[/COLOR] = b.[I]BiomeMap[/I].[I]Attributes[/I] .[COLOR=#191970][B]GroupBy[/B][/COLOR](attr => attr.[I]name[/I]) .[COLOR=#191970][B]Select[/B][/COLOR]([COLOR=#000080]group[/COLOR] => [COLOR=#000080]group[/COLOR].[COLOR=#191970][B]First[/B][/COLOR]()) .[COLOR=#191970][B]Select[/B][/COLOR](attr => [COLOR=#008b8b][B]new[/B][/COLOR] [COLOR=#004085]BiomeDustColorInfo[/COLOR] {Color = attr.[I]mapColor[/I], Name = attr.[I]name[/I]}).[COLOR=#191970][B]ToList[/B][/COLOR]() }).[COLOR=#191970][B]ToList[/B][/COLOR]();[/U] [COLOR=#006400]//(the entire underlined segment above) Cannot implicitly convert type[/COLOR] [COLOR=#006400]List<?> to List<BodyDustColorInfo>[/COLOR] } } } So yeah, something not quite right in there. My guess is I need to be "using" something more than the standard set, or that there's an extra reference I need. EDIT3: I got it! Wow, that was a crazy one. So, it seems you named the first class "BiomeDustColorInfo" but proceeded to use "BodyDustColorInfo" in most of the second class. Switching out the name fixed every error I was getting. EDIT4: Okay, so let me speak directly from my brain here and ask a few questions... So, what it looks like is that this code will generate (if not already found) all of those locations/biomes in the file of choice upon initializing the plugin, but if the file exists will simply use what it is given. What happens if it finds incomplete data? Will it fill in the incomplete data, or will it simply use what it has and get grumpy when we ask for more? Also, in your example config file, were those color defaults selected by you, or did the code automatically generate an appropriate color for that biome? Finally, the big question: I need to grab the color information and plug that into the original code for the dust particle creator. Is the current format of the color data going to be compatible, or will I need to convert it into some other format? Here's a new sample of what I have at this time for using the color data to generate the dust plumes: [COLOR=#ff0000]void[/COLOR] [COLOR=#191970][B]DustParticles[/B][/COLOR] ( [COLOR=#ff0000][B]float[/B][/COLOR] speed, [COLOR=#004085][B]Vector3[/B][/COLOR] contactPoint, [COLOR=#004085]Collider[/COLOR] col ) { [COLOR=#0000ff][B]if[/B][/COLOR] (![I]dustEffects[/I]) [COLOR=#000080]return[/COLOR]; [COLOR=#0000ff][B]if[/B][/COLOR] (speed > [I]minScrapeSpeed[/I]) { [COLOR=#008000]// Set dust biome colour.[/COLOR] [COLOR=#0000ff][B]if[/B][/COLOR] (![COLOR=#191970][B]Equals[/B][/COLOR]([I]dustAnimator[/I], [B]null[/B])) { [COLOR=#004085][B]Color[/B][/COLOR] BiomeColor = [COLOR=#191970][B]GetBiomeColour[/B][/COLOR](col); [COLOR=#0000ff][B]if[/B][/COLOR] (![COLOR=#191970][B]Equals[/B][/COLOR](BiomeColor, [I]dustColor[/I])) { [COLOR=#004085][B]Color[/B][/COLOR] [] colors = [I]dustAnimator[/I].colorAnimation; colors[[COLOR=#00008b]0[/COLOR]] = BiomeColor; colors[[COLOR=#00008b]1[/COLOR]] = BiomeColor; colors[[COLOR=#00008b]2[/COLOR]] = BiomeColor; colors[[COLOR=#00008b]3[/COLOR]] = BiomeColor; colors[[COLOR=#00008b]4[/COLOR]] = BiomeColor; [I]dustAnimator[/I].colorAnimation = colors; [I]dustColor[/I] = BiomeColor; } } [COLOR=#0000ff][B]else[/B][/COLOR] [COLOR=#000080]return[/COLOR]; [I]dustFx[/I].transform.position = contactPoint; [I]dustFx[/I].particleEmitter.maxEnergy = speed / [I]maxDustEnergyDiv[/I]; [I]dustFx[/I].particleEmitter.maxEmission = [COLOR=#004085][B]Mathf[/B][/COLOR].[COLOR=#191970][B]Clamp[/B][/COLOR]((speed * [I]maxDustEmissionMult[/I]), [I]minDustEmission[/I], [I]maxDustEmission[/I]); [I]dustFx[/I].particleEmitter.[COLOR=#191970][B]Emit[/B][/COLOR](); } } [COLOR=#008000] // Color format: RGBA (0-1, decimal percentage)[/COLOR] [COLOR=#0000ff][B]public[/B][/COLOR] [COLOR=#004085][B]Color[/B][/COLOR] [I]genericDustColour[/I] = [COLOR=#008b8b][B]new[/B][/COLOR] [COLOR=#004085][B]Color[/B][/COLOR] ([COLOR=#00008b]0.75[/COLOR]f, [COLOR=#00008b]0.75[/COLOR]f, [COLOR=#00008b]0.75[/COLOR]f, [COLOR=#00008b]0.007[/COLOR]f); [COLOR=#008000]// Grey 210 210 210[/COLOR] [COLOR=#0000ff][B]public[/B][/COLOR] [COLOR=#004085][B]Color[/B][/COLOR] [I]dirtColour[/I] = [COLOR=#008b8b][B]new[/B][/COLOR] [COLOR=#004085][B]Color[/B][/COLOR] ([COLOR=#00008b]0.65[/COLOR]f, [COLOR=#00008b]0.48[/COLOR]f, [COLOR=#00008b]0.34[/COLOR]f, [COLOR=#00008b]0.0125[/COLOR]f); [COLOR=#008000]// Brown 165, 122, 88[/COLOR] [COLOR=#0000ff][B]public[/B][/COLOR] [COLOR=#004085][B]Color[/B][/COLOR] [I]lightDirtColour[/I] = [COLOR=#008b8b][B]new[/B][/COLOR] [COLOR=#004085][B]Color[/B][/COLOR] ([COLOR=#00008b]0.65[/COLOR]f, [COLOR=#00008b]0.52[/COLOR]f, [COLOR=#00008b]0.34[/COLOR]f, [COLOR=#00008b]0.0125[/COLOR]f); [COLOR=#008000]// Brown 165, 132, 88[/COLOR] [COLOR=#0000ff][B]public[/B][/COLOR] [COLOR=#004085][B]Color[/B][/COLOR] [I]sandColour[/I] = [COLOR=#008b8b][B]new[/B][/COLOR] [COLOR=#004085][B]Color[/B][/COLOR] ([COLOR=#00008b]0.80[/COLOR]f, [COLOR=#00008b]0.68[/COLOR]f, [COLOR=#00008b]0.47[/COLOR]f, [COLOR=#00008b]0.0125[/COLOR]f); [COLOR=#008000]// Light brown 203, 173, 119[/COLOR] [COLOR=#0000ff][B]public[/B][/COLOR] [COLOR=#004085][B]Color[/B][/COLOR] [I]snowColour[/I] = [COLOR=#008b8b][B]new[/B][/COLOR] [COLOR=#004085][B]Color[/B][/COLOR] ([COLOR=#00008b]0.90[/COLOR]f, [COLOR=#00008b]0.94[/COLOR]f, [COLOR=#00008b]1[/COLOR]f, [COLOR=#00008b]0.0125[/COLOR]f); [COLOR=#008000]// Blue-white 230, 250, 255[/COLOR] [COLOR=#0000ff][B]public[/B][/COLOR] [COLOR=#004085][B]Color[/B][/COLOR] [COLOR=#191970][B]GetBiomeColour[/B][/COLOR] ( [COLOR=#004085]Collider[/COLOR] c ) { [COLOR=#0000ff][B]switch[/B][/COLOR] ([COLOR=#004085]FlightGlobals[/COLOR].ActiveVessel.mainBody.name) { [COLOR=#0000ff][B]case[/B][/COLOR] [COLOR=#0000ff]"Kerbin"[/COLOR]: [COLOR=#0000ff][B]if[/B][/COLOR] ([COLOR=#191970][B]IsPQS[/B][/COLOR](c)) { [COLOR=#ff0000]string[/COLOR] biome = [COLOR=#191970][B]GetCurrentBiomeName[/B][/COLOR](); [COLOR=#0000ff][B]switch[/B][/COLOR] (biome) { [COLOR=#0000ff][B]case[/B][/COLOR] [COLOR=#0000ff]"Water"[/COLOR]: [COLOR=#008000]//Anything here would be the sea-bottom.[/COLOR] [COLOR=#000080]return[/COLOR] [I]lightDirtColour[/I]; [COLOR=#0000ff][B]case[/B][/COLOR] [COLOR=#0000ff]"Grasslands"[/COLOR]: [COLOR=#000080]return[/COLOR] [I]dirtColour[/I]; [COLOR=#0000ff][B]case[/B][/COLOR] [COLOR=#0000ff]"Highlands"[/COLOR]: [COLOR=#000080]return[/COLOR] [I]dirtColour[/I]; [COLOR=#0000ff][B]case[/B][/COLOR] [COLOR=#0000ff]"Shores"[/COLOR]: [COLOR=#000080]return[/COLOR] [I]lightDirtColour[/I]; [COLOR=#0000ff][B]case[/B][/COLOR] [COLOR=#0000ff]"Mountains"[/COLOR]: [COLOR=#000080]return[/COLOR] [I]dirtColour[/I]; [COLOR=#0000ff][B]case[/B][/COLOR] [COLOR=#0000ff]"Deserts"[/COLOR]: [COLOR=#000080]return[/COLOR] [I]sandColour[/I]; [COLOR=#0000ff][B]case[/B][/COLOR] [COLOR=#0000ff]"Badlands"[/COLOR]: [COLOR=#000080]return[/COLOR] [I]dirtColour[/I]; [COLOR=#0000ff][B]case[/B][/COLOR] [COLOR=#0000ff]"Tundra"[/COLOR]: [COLOR=#000080]return[/COLOR] [I]dirtColour[/I]; [COLOR=#0000ff][B]case[/B][/COLOR] [COLOR=#0000ff]"Ice Caps"[/COLOR]: [COLOR=#000080]return[/COLOR] [I]snowColour[/I]; [COLOR=#0000ff][B]default[/B][/COLOR]: [COLOR=#000080]return[/COLOR] [I]dirtColour[/I]; } } [COLOR=#000080]return[/COLOR] [I]genericDustColour[/I]; [COLOR=#0000ff][B]case[/B][/COLOR] [COLOR=#0000ff]"Duna"[/COLOR]: [COLOR=#000080]return[/COLOR] [I]sandColour[/I]; [COLOR=#0000ff][B]default[/B][/COLOR]: [COLOR=#000080]return[/COLOR] [I]genericDustColour[/I]; } } I assume that I could now likely get rid of the specifically handled body names and instead simply grab the vessel's current body/biome and query a method in the other file (I stuck all the other stuff in a file I uniquely, as if, named "Config.cs"... ingenious naming converntion I have there, aint it?) for the matching configuration. I also would need to make sure it's going to return to the default color for each body (which is going to probably just be a generic matching color to the body's apparent color from orbit) when no biome match can be found, in those rare cases where the body doesn't have them set up, or in the case of a mod-added celestial body. This is exciting... You have no idea how long I've been trying to figure out how this is done (at least three weeks between school, school, and more of... you guessed it... school). EDIT... whatever number we're on: Okay, so I tried to run it really fast to see what would happen and it wasn't a complete success. It seems that it can't even load these new classes right off the bat. Here's what it put in the log before KSP crashed: [ERR 13:08:17.263] AssemblyLoader: Exception loading 'DustFX': System.Reflection.ReflectionTypeLoadException: The classes in the module cannot be loaded. at (wrapper managed-to-native) System.Reflection.Assembly:GetTypes (bool) at System.Reflection.Assembly.GetTypes () [0x00000] in <filename unknown>:0 at AssemblyLoader.LoadAssemblies () [0x00000] in <filename unknown>:0 Additional information about this exception: System.TypeLoadException: Could not load type 'DustFX.Configs.BiomeDustColorInfo' from assembly 'DustFX, Version=1.0.5547.21743, Culture=neutral, PublicKeyToken=null'. System.TypeLoadException: Could not load type 'DustFX.Configs.DustColorDefinitions' from assembly 'DustFX, Version=1.0.5547.21743, Culture=neutral, PublicKeyToken=null'. System.TypeLoadException: Could not load type 'DustFX.Configs.DustColorFileWriter' from assembly 'DustFX, Version=1.0.5547.21743, Culture=neutral, PublicKeyToken=null'. System.TypeLoadException: Could not load type '<>c__DisplayClass8' from assembly 'DustFX, Version=1.0.5547.21743, Culture=neutral, PublicKeyToken=null'. System.TypeLoadException: Could not load type '<>c__DisplayClassa' from assembly 'DustFX, Version=1.0.5547.21743, Culture=neutral, PublicKeyToken=null'. I renamed that really long vague class/function/whatever-you-call-it to DustColorFileWriter for lack of anything better to call it. Anyway, to make sure it wasn't just a random KSP loader bug, I relaunched and, while successfully laoding up assets now, it still put the above bit into the log. So, I've got some issues in there somewhere.

no no no, by "bug" I meant, the perfectionism thing. Now I've got images of the original "bug" which brought about the term in relation to computers stuck in my head. I've gotta go see that exhibit next time they bring it up from storage.

Gotcha. I've got the same bug, I just lack the expertise to do it myself. Actually, what really has me messed up is that I can't write some code, make it output the result to the console and run it immediately like I would in the C# class, where we're only creating console applications. It would be really nice if there was some sort of development console we could run our code into and get some dummy results that would help make sense of it all. KSP takes over 10 minutes to launch even with a near-empty GameData folder, so that's not really very useful to me.

Sweet. My head is feeling better already. Now if I could just get the dancing midget to move on... you know how they tend to creep in and never go away... EDIT: One thing I noticed in your code is that SharpDevelop (the program I use to do this stuff) is flagging this: [COLOR=#008000][COLOR=#808080]///[/COLOR] [COLOR=#808080]<[B]summary[/B]>[/COLOR][/COLOR] [COLOR=#008000][COLOR=#808080]///[/COLOR] Gets the index of the material looked for[/COLOR] [COLOR=#008000][COLOR=#808080]///[/COLOR] [COLOR=#808080]<[B]/[/B][B]summary[/B]>[/COLOR][/COLOR] [COLOR=#008000][COLOR=#808080]///[/COLOR] [COLOR=#808080]<[B]param[/B] [B]name[/B][B]=[/B][COLOR=#c0c0c0][B]"name"[/B][/COLOR]>[/COLOR]Name of the material[COLOR=#808080]<[B]/[/B][B]param[/B]>[/COLOR][/COLOR] [COLOR=#0000ff][B]public[/B][/COLOR] [COLOR=#ff0000][B]int[/B][/COLOR] [COLOR=#191970][B]GetMaterialIndex[/B][/COLOR] ( [COLOR=#ff0000]string[/COLOR] name ) { [COLOR=#000080] return[/COLOR] [I]_materialNames[/I].[COLOR=#191970][B]IndexOf[/B][/COLOR](name); }...the item "name" in the "_materialNames.IndexOf()" is being flagged as "Cannot implicitly convert type 'string' to '?[]'" Other than that, this code is (as my C# professor Suzuki would say) "beautiful code." EDIT2: Odd, when I loaded up the complete RealChute source, the flag does not come up in that same spot. Oh well.

Nice, thanks. That gives me a bit more to work from. After I sleep off this headache, I'll dive into it again.

If you were to break down and start adding mod parts, lo-fi has some awesome suspensions in his wheels that would work rather well with that monstrosity.

I think, at this point, it is best to just call it a "hidden feature" and back away... far away from that issue. I can only imagine, with much horror, what problems would arise when dealing with spawning and attaching KF wheels and repulsors to crafts after the flight scene has been fully initialized.

First, a little background info: So, a while back a plugin was released by Pizzaoverhead (I sure hope I didn't butcher that) called CollisionFX. This plugin creates sparks and dust plumes to coincide with collisions between the active vessel and... well... everything else. There were some limitations, however. One of those was related to wheels. When rolling over anything not specifically classified as dirt, such as the false landscape that acts as the foundation of the KSC compound, the wheel would throw sparks and dust and lights and all sorts of crazy stuff as you rolled happily along. This was solved by disabling the effect for wheels. However, there was one part of those effects that were rather nice for the wheel: the dust. Over at the Kerbal Foundries development thread we discovered just how perfect the dust fit in with lo-fi's wheels and, more specifically, the tracks he developed. The sparks had to go, though. So, as a completely inexperienced programmer, I thought to myself "how hard could it be?" and dove right in to try and adapt the code to fit our needs. I had a number of issues while I worked on the original part module "CollisionFX" where i was attempting to separate the setup for the sparks from the dust. After a number of tries that ended up breaking the entire functionality of the plugin, I decided it was time to revert everything I had done and try to extract only the parts that I needed into a new class. This was a complete success and soon I was spawning dust in the wake of my rovers everywhere, complete with planetary and biome specific settings for dust color. Warping up about a month and now I have almost every setting that controls the dust strength, minimal and maximal particle counts, etc. running from fields which can be customized in the part module parameters. I've even broken free from the original DLL (just yesterday in fact) and have practically rewritten the entire thing in the process. Now I want to take it a step further: configuration files. The problems begin: This is where the headache begins. I know there are many plugins that I use in KSP that read/write to the scenarios in the persistence file, and countless others that read/write to their own configuration files. Almost all of these are sitting on my hard drive in full source, and I've been pouring over them to try and figure out how to adapt them to my needs. I want to load up the definitions for the planetary and biome specific dust colors from a config file so that these definitions can be expanded without having to recompile the entire thing. Right now they are all hard-coded and called up like this: [COLOR=#0000ff][B] public[/B][/COLOR] [COLOR=#ff0000]string[/COLOR] [COLOR=#191970][B]GetCurrentBiomeName[/B][/COLOR] () { [COLOR=#004085]CBAttributeMapSO[/COLOR] biomeMap = [COLOR=#004085]FlightGlobals[/COLOR].[I]currentMainBody[/I].[I]BiomeMap[/I]; [COLOR=#004085]CBAttributeMapSO[/COLOR].[COLOR=#004085]MapAttribute[/COLOR] mapAttribute = biomeMap.[COLOR=#191970][B]GetAtt[/B][/COLOR](vessel.[I]latitude[/I] * [COLOR=#004085][B]Mathf[/B][/COLOR].[I]Deg2Rad[/I], vessel.[I]longitude[/I] * [COLOR=#004085][B]Mathf[/B][/COLOR].[I]Deg2Rad[/I]); [COLOR=#000080]return[/COLOR] mapAttribute.[I]name[/I]; } [COLOR=#008000]// Color format: RGBA (0-1, decimal percentage)[/COLOR] [COLOR=#0000ff][B]public[/B][/COLOR] [COLOR=#004085][B]Color[/B][/COLOR] [I]genericDustColour[/I] = [COLOR=#008b8b][B]new[/B][/COLOR] [COLOR=#004085][B]Color[/B][/COLOR] ([COLOR=#00008b]0.75[/COLOR]f, [COLOR=#00008b]0.75[/COLOR]f, [COLOR=#00008b]0.75[/COLOR]f, [COLOR=#00008b]0.007[/COLOR]f); [COLOR=#008000]// Grey 210 210 210[/COLOR] [COLOR=#0000ff][B]public[/B][/COLOR] [COLOR=#004085][B]Color[/B][/COLOR] [I]dirtColour[/I] = [COLOR=#008b8b][B]new[/B][/COLOR] [COLOR=#004085][B]Color[/B][/COLOR] ([COLOR=#00008b]0.65[/COLOR]f, [COLOR=#00008b]0.48[/COLOR]f, [COLOR=#00008b]0.34[/COLOR]f, [COLOR=#00008b]0.0125[/COLOR]f); [COLOR=#008000]// Brown 165, 122, 88[/COLOR] [COLOR=#0000ff][B]public[/B][/COLOR] [COLOR=#004085][B]Color[/B][/COLOR] [I]lightDirtColour[/I] = [COLOR=#008b8b][B]new[/B][/COLOR] [COLOR=#004085][B]Color[/B][/COLOR] ([COLOR=#00008b]0.65[/COLOR]f, [COLOR=#00008b]0.52[/COLOR]f, [COLOR=#00008b]0.34[/COLOR]f, [COLOR=#00008b]0.0125[/COLOR]f); [COLOR=#008000]// Brown 165, 132, 88[/COLOR] [COLOR=#0000ff][B]public[/B][/COLOR] [COLOR=#004085][B]Color[/B][/COLOR] [I]sandColour[/I] = [COLOR=#008b8b][B]new[/B][/COLOR] [COLOR=#004085][B]Color[/B][/COLOR] ([COLOR=#00008b]0.80[/COLOR]f, [COLOR=#00008b]0.68[/COLOR]f, [COLOR=#00008b]0.47[/COLOR]f, [COLOR=#00008b]0.0125[/COLOR]f); [COLOR=#008000]// Light brown 203, 173, 119[/COLOR] [COLOR=#0000ff][B]public[/B][/COLOR] [COLOR=#004085][B]Color[/B][/COLOR] [I]snowColour[/I] = [COLOR=#008b8b][B]new[/B][/COLOR] [COLOR=#004085][B]Color[/B][/COLOR] ([COLOR=#00008b]0.90[/COLOR]f, [COLOR=#00008b]0.94[/COLOR]f, [COLOR=#00008b]1[/COLOR]f, [COLOR=#00008b]0.0125[/COLOR]f); [COLOR=#008000]// Blue-white 230, 250, 255[/COLOR] [COLOR=#0000ff][B]public[/B][/COLOR] [COLOR=#004085][B]Color[/B][/COLOR] [COLOR=#191970][B]GetBiomeColour[/B][/COLOR] ( [COLOR=#004085]Collider[/COLOR] c ) { [COLOR=#0000ff][B]switch[/B][/COLOR] ([COLOR=#004085]FlightGlobals[/COLOR].ActiveVessel.mainBody.name) { [COLOR=#0000ff][B]case[/B][/COLOR] [COLOR=#0000ff]"Kerbin"[/COLOR]: [COLOR=#0000ff][B]if[/B][/COLOR] ([COLOR=#191970][B]IsPQS[/B][/COLOR](c)) { [COLOR=#ff0000]string[/COLOR] biome = [COLOR=#191970][B]GetCurrentBiomeName[/B][/COLOR](); [COLOR=#0000ff][B]switch[/B][/COLOR] (biome) { [COLOR=#0000ff][B]case[/B][/COLOR] [COLOR=#0000ff]"Water"[/COLOR]: [COLOR=#008000]//Anything here would be the sea-bottom.[/COLOR] [COLOR=#000080]return[/COLOR] [I]lightDirtColour[/I]; [COLOR=#0000ff][B]case[/B][/COLOR] [COLOR=#0000ff]"Grasslands"[/COLOR]: [COLOR=#000080]return[/COLOR] [I]dirtColour[/I]; [COLOR=#0000ff][B]case[/B][/COLOR] [COLOR=#0000ff]"Highlands"[/COLOR]: [COLOR=#000080]return[/COLOR] [I]dirtColour[/I]; [COLOR=#0000ff][B]case[/B][/COLOR] [COLOR=#0000ff]"Shores"[/COLOR]: [COLOR=#000080]return[/COLOR] [I]lightDirtColour[/I]; [COLOR=#0000ff][B]case[/B][/COLOR] [COLOR=#0000ff]"Mountains"[/COLOR]: [COLOR=#000080]return[/COLOR] [I]dirtColour[/I]; [COLOR=#0000ff][B]case[/B][/COLOR] [COLOR=#0000ff]"Deserts"[/COLOR]: [COLOR=#000080]return[/COLOR] [I]sandColour[/I]; [COLOR=#0000ff][B]case[/B][/COLOR] [COLOR=#0000ff]"Badlands"[/COLOR]: [COLOR=#000080]return[/COLOR] [I]dirtColour[/I]; [COLOR=#0000ff][B]case[/B][/COLOR] [COLOR=#0000ff]"Tundra"[/COLOR]: [COLOR=#000080]return[/COLOR] [I]dirtColour[/I]; [COLOR=#0000ff][B]case[/B][/COLOR] [COLOR=#0000ff]"Ice Caps"[/COLOR]: [COLOR=#000080]return[/COLOR] [I]snowColour[/I]; [COLOR=#0000ff][B]default[/B][/COLOR]: [COLOR=#000080]return[/COLOR] [I]dirtColour[/I]; } } [COLOR=#000080]return[/COLOR] [I]genericDustColour[/I]; [COLOR=#0000ff][B]case[/B][/COLOR] [COLOR=#0000ff]"Duna"[/COLOR]: [COLOR=#000080]return[/COLOR] [I]sandColour[/I]; [COLOR=#0000ff][B]default[/B][/COLOR]: [COLOR=#000080]return[/COLOR] [I]genericDustColour[/I]; } }This is one area where the code is almost completely identical to what CollisionFX uses. At this time, to expand this further you'd have to edit that switch right there and add more cases. What I would like to do is instead make it load those definitions from a two-layered config node system such as, for example: BODY { name = Kerbin //Color format: (decimal) red, green, blue, alpha color = 0.75, 0.75, 0.75, 0.007 BIOME { name = Ice Caps color = 0.90, 0.94, 1, 0.0125 } BIOME { name = Highlands color = 0.65, 0.48, 0.34, 0.0125 } } BODY { name = Duna color = 0.80, 0.68, 0.47, 0.0125 }Now, I'm unsure why this is causing me such a headache, but every time I try to adapt some new way of coding the retrieval and use of settings from a file formatted in such a way I hit this brick wall in my ability to comprehend where and what needs to happen to make it all fit in the right place. I haven't even made it as far as actually telling the GetBiomeColour() method how to read the new data because I get this pain in the head every time I try to write the code that will import the configuration data. I don't really believe it's that complicated, but I can't seem to wrap my head around it. Sorta like statistics class... I had to drop that one this quarter due to just not being able to make sense of it. Obviously I don't lack examples of this being done, but what I do lack is a clear idea of what is happening and why it works in the code I am looking at. I have been taking a C# beginners class in college, preparing for a BA program in Application Development (it's a really vague description, and I'm not sure what it really means yet, but I'm having a blast getting ready for it.) and from what I've learned there, combined with my dabbling in these more advanced things that we do for KSP, I have a basic idea of what I'd like to have happen here. First, I would define the file that I'm loading from (path to locate it relative to the plugin, or absolute if I had to) and then I would define the node names I need to look for. I would then, much like I would do in a class example, create something along the lines of a two-dimensional array that would contain the body names in the first dimension, and the biome names in the second one. This is where the first painful spasm comes about as I think to myself "wait a sec, you dummy... the only planet that we have any clue about as far as biomes that correspond to landscape regions is Kerbin, so having biome info for other worlds is kinda stupid, aint it?" and I generally start to have a miniature stoke. Upon recovering from that, I continue. Okay, so maybe we leave Kerbin and it's biomes alone for now and concentrate on just expanding the planetary color definitions. So, I scrap the subnodes for "BIOME" in the proverbial trash bin and continue. we have now a pretty simple array that will contain the names of all the planets and a default setting for their dust colors. Another little painful twinge hits me as I say to myself "wait a second, my professor tells me that defining a new array without any clue how large it will be in the end is a recipe for disaster and that he will come back from the grave and haunt me if I do it... so that's not going to work very well" and another miniature stoke hits me. So, at this point I normally give up, scrap everything having to do with config nodes and go play a mindless zombie killing game. I'm really looking for some configuration-for-dummies style direction here. My brain can't take these miniature strokes forever, though they're beginning to feel a little bit like a sweet moment of release and I get a really weird craving for chocolate chip cookies... am I going totally nuts? Probably... I'll ask the dancing midget in the corner next time I get a chance.

I managed to get the DLL to recompile, though I had to disable one of the functions (the one that shades the parts blue when then can be painted/are current being painted) but otherwise it looks good. I'll give it a test run tomorrow if I get a chance. Either way, however, I won't be trying to take over or rewrite this thing. If it works, I'll post instructions on how I did it if anyone wants to reproduce it themselves. I'm not going to tackle licensing restrictions or anything like that.

It seems likely that the map view is simply an overlay given the fact that there's really no delay in the simulation between the map view and the flight scene. The navball, while tucked away usually, is still accessible through the map view which means you could probably control your ship entirely from the map if that made you happy. I have experienced a few things when switching between the map and the regular flight scene such as the camera zooming in really fast between views. This is usually not so noticeable, but when the system you're running on is having problems keeping up with the simulation, it can be detected. This leads me to believe that the sounds are not actually being muted while the map is up, but rather the camera is being set far away from the action, which causes the game to lower the intensity of the sounds based on your vicinity to them. As you've experienced, this is not always very accurate. I also have no proof that this is how they handle it. It's all just observation and logical thinking here. As for barking and tail-chasing... I won't say that this isn't a case of chasing your tail or barking up the wrong tree... all this means is that we're both barking up the wrong tree if indeed we are barking in a coherent fashion at all. A thought: I remember having a problem with sound in the map view when using the atmospheric sound enhancement mod (a very long time ago) in where all sounds would be severely muted when the map was up except for the odd occasional sonic boom sound that would pierce through the veil at full volume. I suspect it has to do with whether or not the plugin doing the call for the sound effect is checking against an available volume setting within the game, or whether or not the sound call is using a standard unity/KSP method or if they're defining a new system-based method for playing it. Stuff to chew on, I suppose.

alright then, accurate it is. That's some weird object naming going on there.

NOT entirely accurate. You can do it within certain limits. For instance, I have one of those all-in-one launch pads on the Mun and it works flawlessly. I haven't tried anything further out though.

Hey, lo-fi... this is from the latest release package on KerbalStuff, in the small track config: MODULE { name = KFWheel wheelName =[B] RoadWhee5[/B] colliderName = WC5 sustravName = Link5 steeringName = Link5 isIdler = false hasSteering = false rotationCorrection = 1.5 smoothSpeed = 40 wheelRotationX = 0 wheelRotationY = 0 wheelRotationZ = 1 susTravAxis = Y }Notice the bold item in the above code. Is this actually accurate, or am I detecting another typo here? Do we need to ban you from modding until you're completely sober or what?

Wow, a "ckicky draggy" typo... that's something I haven't experienced in so long... Anyway... you may be ignoring the dev repo for the time being, but I'm about a few days or so away from possibly (if I don't get bogged down with school work) doing an update to the TweakScale settings and stuff, so you may want to keep an eye out for my update next time you want to update the release. I'd say, worst-case scenario, I'll have something up in a week. Trying to take advantage of the new stuff that's been added to TweakScale to allow for more flexible scaling ranges.

I agree, those are beautiful tracks. - - - Updated - - - Now, just push your updates to the github already so those of us who don't update from the entire release package can get in on the fun... I mean, the last update to the dev repo is when I fixed your little typo in a module definition in a part config. That was ages ago.

thingies! Yes, that's the correct term for them. Along with "stuff" which means "any substance that has no actual meaning outside of a science journal" and "goo" which means "the substance you turn into when flung around at enough g-forces to turn your atoms into jelly."

So... what, is it using atmospheric engines for the early stages? It looks pretty sweet anyway.

Honestly, hard-coded hotkey toggles annoy me to no end. I was thinking something more like a per-part context menu option, which is also available in the FS wheel guide. I'll grant you that an overall toggle would be awesome. A toolbar button or something.