Alshain

Well, If I had realized it was going to be that easy, I would have just waited on that earlier release. Bulb and ElectricLights are now versions 1.3.4 and 1.0.3 respectively to add localization support. (ATB doesn't have anything that needs localizing)

Done

When implementing IModuleInfo it is now required to also override a redundant method in PartModule. Some modules seem to use one while other modules use the other. Example: public string GetModuleTitle() { return "My Module"; } public override string GetModuleDisplayName() { return GetModuleTitle(); }

Ok, so finally after hours of searching it would appear that Squad added a redundant method in PartModule and some modules are using one and some modules are using the other. Why would you do this Squad? public string GetModuleTitle() { return "#autoLOC_6003003"; } public override string GetModuleDisplayName() { return GetModuleTitle(); } That was the solution.

Neither of those threads has anything to do with FAR. FAR does allow flaps to create additional lift if you use them properly.

Oh, I am so glad this is back!

Posts like that are viewed as a passive aggressive way of saying "is it ready yet". The rules say you can't ask for updates so instead people post complaints about people who might ask for updates (even though none have been made) as a way to call attention to the fact that there is a game update and they want the mod (or in this case list) updated. You may not be doing that, but people do.

I'm having a bit of difficulty here and I need some more eyes. My ElectricLights mod extends ModuleAnimateGeneric and ModuleColorChanger to consume electricity for the cockpits and command pods respectively. I have a set of code which I have been localizing using the stock dictionary. public override string GetInfo() { StringBuilder info = new StringBuilder(); info.AppendLine("<color=#FF8C00><b><<1>></b></color>").Replace("<<1>>", Localizer.GetStringByTag("#autoLOC_244332")); info.Append(Localizer.GetStringByTag("#autoLOC_244201")); info.Replace("<<1>>", Localizer.GetStringByTag("#autoLOC_501004")); info.Replace("<<2>>", (resourceRate * 60 * resourceAmount).ToString()); return info.ToString(); } public string GetModuleTitle() { return "#autoLOC_6003003"; } This code is exactly the same in both my extension modules. The module that inherits ModuleAnimateGeneric produces the following: So that is beautiful, it appears to be translating tags correctly and all is well. Then I look at the extension of ModuleColorChanger: Now, why does that say "Color Changer" instead of "Light"? I went back to my previous version DLL (with no localization, just static text) and it turns out it's broken there too. This was working in 1.2 with static text, but now in 1.3 it doesn't seem to want to return the title from my implementation regardless. Before you answer, no there is nothing to override in either module.

It seems to me, Squad could add a simple popup dialog when it detects a craft with non-existing parts to offer to A. Delete offending craft or B. Quit to Main Menu without saving the persistence file. That would solve this problem. They already are detecting the bad parts, they just need to react better. As far as going back to the old version when it detects bad parts, you can already do that in Steam. Properties -> Betas -> Opt in to previous version.

The first parts to support lights in that manner were the PorkJet Spaceplane+ parts. These parts have animations for the lights built into the model and thus they use a module called ModuleAnimateGeneric to switch them. Meanwhile ModuleLight (used by the placeable lights) does the same thing as ModuleAnimateGeneric but also adds the ability to consume a resource. The patch simply switches the Module over to ModuleLight, but as a side effect also adds color sliders in the editor that have no effect at all. Later, Squad added the capability to existing parts, but in order to avoid re-doing the models, they added a module that simply alters the visible color of an area. ModuleColorChanger does not support a resource consumption function that I have found nor does it have an analogue that does so. Therefore the patch in this thread does not work on the older command pods, only the cockpits. The ElectricLights mod explicitly adds resource consumption to both ModuleColorChanger and ModuleAnaimateGeneric, allowing command pods to consume electricity and removing those pointless color sliders from cockpits. Maybe I'm biased, but I recommend the mod.

I've update the thread to add all the recent submissions. @slubman I split one of your patches into two to allow users to choose what changes they want. It's best to keep them granular when possible. @Enceos' attachment node patch has been updated so make sure to get a new copy of that. All the structural scaling patches have been modified to add the proper bulkhead cross section (for filtering in the editor). So update those in your files as well. Since the thread is getting difficult to update, I have removed the obsolete patches and external patches sections. As much as I'd like to keep them, since we don't have proper BBCode support, this make it easier on me to update. I also removed the minimum version numbers because I was seeing cases where people believed they were the maximum versions (i.e. incompatible with the current version). As far as I know, all patches in the database are compatible with 1.3.0, if you find otherwise please let me know.

KSP 1.3.0 Status: AdvancedTweakablesButton: Requires No Update (except update Module Manager) ElectricLights: Requires No Update (except update Module Manager) Bulb: 1.3.3 Released (update required for 1.3.0) -Updated references for KSP 1.3.0 -Fixes an issue where existing lights would reset color when Bulb is first installed. -No localization at this time.

I'm aware of KOS but he said that he didn't want that in his original post.

The current release of Module Manager is not working and causing crashes. Any mod that uses it will not work either. We just have to wait for an update. Mods that don't use it should work provided they don't need updating.

Minecraft is an entirely other scenario which Mojang brought upon themselves. Their mod scene self-destructed because of Mojang's own stupidity. Trust me on this I was a big Minecraft modder. Once Mojang screwed everything up and Bukkit self destructed, a lot of us just gave up.

RemoteTech, but that replaces the whole communications system too. I'm not aware of a flight computer for stock.

Most of this can be improved with mods. Unfortunately Squad has shown absolutely zero interest in improving IVA. You are going to have to settle for RasterPropMonitor and NavUtilities to deal with 2 and 4. For 3, you have to use FAR. Squad already removed the bumpy runway, so 5 is done and 1 is not likely to change but you can double click the Window or if you have track IR, lean forward.

@cgwhite4 @Merkov The Steam version of the game can be reverted to 1.2.2 by going into the game's properties, clicking the Betas tab and selecting 1.2.2 from the list. No need to copy the game out of the install directory (unless you just want to) and no need to avoid playing KSP while you wait on Mods to update.

Yes. I recall many 'which mods should be stock' threads that went through the same issues. Many of which included discussions of RemoteTech, Kethane, Karbonite, and so forth that got pretty heated.

That wasn't a problem for ISRU, or ComNet. Why would it be a problem for Multiplayer.

ROFL, The mods already exist. Historical parts are already out there and you can play with them right now. The mission maker will only appeal to a small subsection of the games community, those that like completing challenges.

You disagree with what? I never said anything about the cheapest way.

You can move the parts with module manager. The new tabs will remain though.

No, it's designed to be used by those of us that hate the heat shield fairing. (i.e. the smart ones) If it blows up your vessel, it's a bug.

EDIT: sorry, I missed the 10m part. Nevermind. I don't know of any.