Gaalidas

You can code plugins in python? Wow, shows how much I know about plugin making. I always assumed C# (or is it D-flat?) was the standard.

You're not? Well that's just great... and here I was thinking you were this superior being... Boy was I wrong.

-insert colorful expletives here- I was looking forward to 1.0, then you made me remember all the frenzy and headaches each update to KSP brings and now I'm dreading it. I sure hope you're proud of yourself. I'm going to have to go kill some more Kerbal interns again just to bring back that little bit of joy to my day.

So, it looks like the icons were being mipmapped and/or compressed when they shouldn't have been. LoadOnDemand wouldn't change how the icons are rendered, but the necessity of disabling the compression from other mods to make LOD run properly may have also cured your blurry button issue. I don't really know either way what the cause and/or fix was/is to that icon thing, but LOD wouldn't be doing anything to specifically fix that issue. It has to be a side effect of another mod you're running not doing what it was before LOD was installed. Normally other mods which compress or resize textures will have settings that remove icons from the process to reduce blurry icon syndrome. You may simply not have all the latest patches for the various mods installed for whatever texture compression mod you're using. The textures of the plane looking better is also likely an artifact of less texture compression being done in the background when LOD is installed due to the fact that less assets are actively taking up memory space. - - - Updated - - - That's a really hard question to answer. Reports have gone both ways depending on the system you're on, and the actual results vary as much as the variances of system setups everyone has. You'll have to give it a try yourself to know for sure. On my system, OGL didn't do squat for my memory compared to the standard DX9 mode. - - - Updated - - - One thing I'd question is whether or not LOD is actually handling the DDS textures or not. It may function well even with DDS being used in your game, but it would unlikely be handling the DDS files specifically. In my install, I even have a few mods that, after being updated several times, have a DDS for the diffuse texture, but a PNG for the normal map and/or emissive. The DDS is always loaded at maximum, but the emissive (if i load up that part with the emissive actively emitting) will take a moment to load up clearly, showing that LOD is only managing that part of the textures attached to that model. I'm unsure if there's an easy way to detect what LOD is actually doing in relation to the DDS textures right now though, and I have yet to install this into my game again. Oh, and I think my confusion about your buttons was because you called the bar on the top a "Module Manager" when ModuseManager is actually a mod for handling config patching. The area you're talking about I believe is called, in some form or another, an "Application Manager" or something along those lines.

y'know, I kid you not, it was just yesterday when I was looking around for a new project and thought to myself "the brakes! oh how that necessary clickage vexes me." Okay, so I'm not that eloquent with my words in my head, but it seemed to fit the mood right now. Anyway, I discarded the idea because I couldn't figure out how I would even begin doing that and tackled something else instead. Great that you've built this just in time to fill the gap.

I'm not sure I follow you there, but it is indeed good to have it back.

Alright, I can understand that perspective. Still, as an option, it might be nice to support a feature such as that for those of us who can handle it. I tried to do it myself, but apparently I couldn't locate the proper object names that the Firespitter texture-swapping modules required. It ended very badly.

I'd sure think so. EDIT: So, I did a reinstall of this today, just to make sure I had the latest version installed and I'm running into a problem that's breaking the game's ability to even load past a the parts from this mod. I've removed the blank lines, but otehrwise the following output is straight from the output_log: PartLoader: Compiling Part 'Hangar/Parts/AsteroidHangars/MobileSmelter/MobileSmelter' (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) PartLoader: Compiling Part 'Hangar/Parts/AsteroidHangars/ResourceTanks/ResourceTank' (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KeyNotFoundException: The given key was not present in the dictionary. at System.Collections.Generic.SortedList`2[System.String,AtHangar.SwitchableTankType].get_Item (System.String key) [0x00000] in <filename unknown>:0 at AtHangar.SwitchableTankInfo.get_Type () [0x00000] in <filename unknown>:0 at AtHangar.SwitchableTankInfo.get_Cost () [0x00000] in <filename unknown>:0 at AtHangar.SwitchableTankInfo.Info (.ConfigNode n) [0x00000] in <filename unknown>:0 at AtHangar.HangarTankManager+<GetInfo>c__AnonStorey0.<>m__0 (.ConfigNode n) [0x00000] in <filename unknown>:0 at AtHangar.CollectionsExtensions.ForEach[ConfigNode] (.ConfigNode[] a, System.Action`1 action) [0x00000] in <filename unknown>:0 at AtHangar.HangarTankManager.GetInfo () [0x00000] in <filename unknown>:0 at PartLoader.ParsePart (.UrlConfig urlConfig, .ConfigNode node) [0x00000] in <filename unknown>:0 at PartLoader+.MoveNext () [0x00000] in <filename unknown>:0 (Filename: Line: -1) NullReferenceException: Object reference not set to an instance of an object at AtHangar.PartUpdaterBase.Init () [0x00000] in <filename unknown>:0 at AtHangar.HangarResizableBase.OnStart (StartState state) [0x00000] in <filename unknown>:0 at AtHangar.HangarPartResizer.OnStart (StartState state) [0x00000] in <filename unknown>:0 at Part.ModulesOnStart () [0x00000] in <filename unknown>:0 at Part+.MoveNext () [0x00000] in <filename unknown>:0 (Filename: Line: -1) So yeah... that happened.

Right now you're lucky this mod works at all. I don't believe there is any active development right now.

That's just vessel strength there. The Kerbal itself has been reported to be able to survive reentry no matter what angle it hit the atmosphere. That is, reports have found that the Kerbal can still respond in a small way even after high speed impact. No reports were filed to indicate how long they lived after the incident... but considering any "landing" which ends with a live Kerbal, no matter how long that life continues afterwards, is still a successful landing. All other data is unnecessary.

But now that you mention it, that name is a bit odd too... but I blame my sick brain on the people I'm hanging out with right now. It's not my fault, I swear.

Awesome. Nothing like those unexpected part failures when you pull a gentle turn that only peaks at a measly 32 gees. Kerbals don't turn to green goo until at least 60, right? We need to test this... gather the interns.

Oh, also... if you're using TextureReplacer, disable that mod's compression system. It'll mess up this mod in some ways that were never fully explained, but I assume are bad. Also, there will be some issues if you use TextureReplacer's GameData replacement method (placing textures in a copy directory structure beginning with "TextureReplacer\default\GameData\...") so you'll have to either replace those textures manually if desired, or give up that method of replacing part textures. As for DDS, there was some talk on the project page about adding some initial support for it, but I am unsure if this ever got completed to any compilable level. I never had issues with running this alongside DDS Loader, except that it wouldn't dynamically load/unload any of those textures.

hey, that's a good one. at least, undamaged until the user pulls 42 gees with it...

sweet. So, you should make that simple shape into a part. Using a KAS winch, that could be the omicron anchor. Or better yet, using BD armoury... the Omicron anti-gravity mine. Or maybe not...

When compiling, make sure you're compiling into the .net framework 3.5. If your IDE complains that it can't find it and will use that GAC to figure it out, that should be okay. On top of that, however, you gotta be running DirectX 9 mode (default for KSP) and having a good standing with a prominent deity of your choice (one who gives a bleep if you succeed in this stuff at all, that is) might help.

Now that's pretty. But, I gotta say, your name is really disturbing.

Awesome that someone got it to work. I tried many times with no success, but I wasn't as used to coding as I am now. I very much doubt our original author will be coming back to make anything official, so it's good that the license is as open as it is.

I gotta say, a part to use up electric charge... just for the sake of using up electric charge... well, it's actually sounding extremely "kerbal" to do that, but I really don't see much point otherwise.

It was definitely a great mod for making normally clashing parts look like they were made for each other.

It's not the title of the part that needs renaming, but the actual name at the top of the file. If you've done that already, then I probably just had a previous version in my install, which means you've got nothing to worry about.

We can all hope that will happen eventually. I fear that Squad may simply finish KSP as it is and start work on something new. I kinda hate the idea of a KSP 2 though, considering they could simply extend KSP instead of starting this whole development process all over again. If they want to bring in more income they could release a Unity 5 update as an addon/DLC or something. I don't know what would be a good option for them, but I'm unsure if they'll really update the version of Unity anytime soon.

That's an excellent question... and I don't know the answer. I'll do some digging around in the code... I know for certain that the tweakscale exponent settings don't take that into account at all, but we have a special variable that we set along with the scale which modifies a lot of other variables within the code, so it'll take some digging to figure out if the suspension is modified by it. However, absurdity with wheel numbers is a rather realistic situation with extremely heavy craft. Considering the vessels in KSP are likely a lot heavier than what we would build in the real world due to the fact that we would build parts that are made specifically for the purpose of that vessel rather than using rocket and space station parts to fill in the gaps... well, we'd likely be using an absurd number of wheels too. EDIT: So, I did some poking around and it turns out the "springRate" variable, also a config parameter, is indeed multiplied by the "tweakScaleCorrector" variable which is set to the equivalent of the current scale. "springRate" is a badly named variable for "Spring Strength" in the code. However, part mass (and other settings) is covered by a completely different exponent which is outside of this mod's specific settings, which means the strength may not be updating to compensate for any other changes such as the part's own mass. If the wheels are having to compensate too much for their own mass, then the vessel mass may not be taken into account correctly. I will aim to try and override that setting for the KF parts and see if that makes any difference. EDIT2: So, as a test, I'm adding a second modification on the springRate and damperRate in the tweak scale settings. If you haven't modified your local file, then you could try modifying your own local file and see if it makes any difference. In the code, those settings are already multiplied directly with the tweakScaleCorrector variable which is made to equal the scale level. However, if we also scale the base value that the scale corrector multiplies with then, in theory, we can increase the spring/damper to better match the new part scale without touching the original code. Granted, this is a work-around that we would want to update in the code itself later, but for now this is a good way to test the results. Since I don't have any really heavy rovers built at this time, it would be quicker if you were able to test the results. I'm going to try and explain what to edit now. So, in the file named "KF_Scaletype.cfg" you will be looking for this: TWEAKSCALEEXPONENTS { name = KFModuleWheel !tweakScaleCorrector = 0.8, 1.0, 1.2, 1.4, 1.6, 1.8 } Except there will be different values matching what scale levels that size-class can take. You'll want to make two copies of the line starting with "!tweakScaleCorrector" and place them under that line, then rename the two parameters to "!springRate" and "!damperRate" respectively. In the end, the sample from above should look similar to this: TWEAKSCALEEXPONENTS { name = KFModuleWheel !tweakScaleCorrector = 0.8, 1.0, 1.2, 1.4, 1.6, 1.8 !springRate = 0.8, 1.0, 1.2, 1.4, 1.6, 1.8 !damperRate = 0.8, 1.0, 1.2, 1.4, 1.6, 1.8 } This will have TweakScale make those two base variables match the scale level for that part, which will be further multiplied by the corrector in the code, thus increasing them even further that usual. This change could, however, have unusual results, so use caution during testing. I also don't know if it will affect already launched vessels or not. Usual backup procedures should be used in this case to avoid any permanent breakage. Let us know, if you decide to try this highly experimental change in your own game, what happens (if anything).

I have no words... except those... and the ones that followed them... and the others... and... I'm done now.

I have always suspected that the Kerbal is, in fact, a plant. We cannot assume that sentient life on other worlds would take the same form as our own. Research (aka. hypothesizing without any true evidence, and claiming to have said evidence anyway) into the possible reproduction process of a Kerbal has revealed that there is a high likelihood that pollen-based transfers of genetic material may be a key part of the process. The lack of physical differences between males and females of the species, if they do physically exist separately at all, is also a good sign that there is something else at work here.