4x4cheesecake

@michal.don You did a great job on this challenge, thank you very much for all the time and effort you put into this. For me, this thread was always one of the most enjoyable places of the forum and I'm sure @sturmhauke will keep up the challenge in such an awesome way as you did Take care and fly safe

@r3_141592654 For OPM I would suggest SVE: or OPM_VO: both are not updated to 1.8x though so the best bet would be SVE but you will probably encounter some issus with scatterer as mentioned here.

add curly braces to the third line: @PART[InlineBallute*]:HAS[MODULE[TweakChute]]:FINAL { !MODULE[TweakChute] {} } that should fix your patch Dunno if this will allow you to deploy the ballutes earlier but that's at least the correct syntax to remove the tweakchute module

can be anywhere within your gamedata folder but yeah, paste it as a .cfg

You can add a module manager patch to your game to attach the required part module to all probe cores: @PART[*]:HAS[#CrewCapacity[0],@MODULE[ModuleCommand]]:FINAL { MODULE { name = BonVoyageModule showUpgradesInModuleInfo = false UPGRADES { UPGRADE { name__ = BonVoyageUpgrade_v2 techRequired__ = unmannedTech techLevel = 2 } UPGRADE { name__ = BonVoyageUpgrade_v3 techRequired__ = automation techLevel = 3 } } } } If you actually want it on manned command pods as well, just remove the "#CrewCapacity[0]" in the first line.

The mod throws an exception, every time I load a vessel in the editor which uses a different command pod then the previously loaded vessel or even when I exchange the pod in the editor. Doesn't seem to affect the functionality though, I want to report it anyway KSP 1.8.1 (tested on a fresh install with only MM and BetterCrewAssignment installed) Steps to replicate: 1) Place any command pod in the VAB 2) Delete the pod 3) Place any different command pod Thrown exception: [BetterCrewAssignment] (Exception) Mismatch at index 0: mk1-3pod versus mk1pod.v2: at BetterCrewAssignment.Crewable.List (ShipConstruct construct) [0x00147] in <fcaadc6adbe94684b181672bfcd58aa1>:0 at BetterCrewAssignment.CrewableList..ctor (ShipConstruct construct) [0x00006] in <fcaadc6adbe94684b181672bfcd58aa1>:0 at BetterCrewAssignment.AssignmentLogic.AssignKerbals (ShipConstruct construct) [0x00000] in <fcaadc6adbe94684b181672bfcd58aa1>:0 at BetterCrewAssignment.EditorBehaviour.OnShipModified (ShipConstruct construct) [0x00027] in <fcaadc6adbe94684b181672bfcd58aa1>:0 full log: https://www.dropbox.com/s/9ztlrx5h4nmseic/Player(BCA_exception).log?dl=0

There are quite a few benefits by shipping EVE without a default configuration though. It's easier to handle in the automatic install procedure of CKAN, other mod creators who want to utilize EVE don't have to take care of the default files, KSP doesn't have't have to load the default textures which are probably not even used anymore because you want to use a different mod for clouds, etc. , install instructions become more clear ("install this and this" instead of "install this and this but remove the default stuff) and there are probably a even more reasons.

I don't think you can do that but maybe you want to check out this mod: It's basically "for science" but it works with orbital science and there is no conflict at all

Uhm...did you install a config though? Which KSP version do you run? EVE and scatterer are not updated to 1.9.1 yet and both are having issues with the latest version of KSP. If you want to use both, you have to downgrade to a KSP version which is supported by both mods, for example 1.8.1. Btw a log file is always appreciated when you look for help, especially after encountering a mod issue. If you don't know where the log files are located, take a look at this thread:

There are two possibilities: 1) The mod contains a .dll file which holds some of the text which you want to translate (for example part mods with custom part modules or anything which adds an UI to the game): If the mod makes use of the localization feature in KSP (which is a requirement to make it easy to translate), it usually contains a folder called "localization" which holds all the localization config files. Well, sometimes it's just a plain config file within the mod folder, for example: "en-us.cfg", "es-es.cfg", etc. These config files look like this: Localization { en-us { #autoLOC_something = Some text to explain #autoLOC_something_else = Something else to explain } } This would be a localization file for english, as you can tell by the "en-us" in the third line. To translate everything to spanish, copy the whole file, change "en-us" to "es-es" and translate everything on the right side of the equal sign. Don't touch the "autoLOC" part or anything which has a "#" in front of it, this is important for the mod to grab the correct text whenever it is supposed to be displayed in game. If the mod doesn't use this system, there is no easy way to translate it and share the result. Also, ask the creator of the mod, if someone is already working on a translation and how you can share the result with him/her. 2) The mod contains just config files (for example tech tree mods, many contract packs, etc): Similar to the way above, you can translate these fairly easy if they already use the localization feature but if they don't, in this case you can implement it on your own Take a look at each and every config file of the mod and look for texts which will be displayed ingame, like part descriptions, titles, etc. Then, you can create a new localization file like the one above, introduce your own "#autoLOC_" tag (for example "#autoLOC_<modname>_1"), replace the text from the mod config with your new "#autLOC_" tag and write the tag together with the original text in the new translation file. For example, let's assume there is a mod called "Kerbal NoseCone" which changes the name and description of a part and comes with a module manager patch like this: @PART[noseCone] { @title = Improved Nosecone Deluxe @description = This is my awesome kerbalised Nosecone, it's GREEN!!! } Then you can change it to: @PART[noseCone] { @title = #autoLOC_KerbalNoseCone_1 @description = #autoLOC_KerbalNoseCone_2 } Add the original text in: Localization { en-us { #autoLOC_KerbalNoseCone_1 = Improved Nosecone Deluxe #autoLOC_KerbalNoseCone_2 = This is my awesome kerbalised Nosecone, it's GREEN!!! } } And your translation in: Localization { es-es { #autoLOC_KerbalNoseCone_1 = Nosecone Deluxe mejorado #autoLOC_KerbalNoseCone_2 = Esta es mi increíble Nosecone kerbalizada, ¡es VERDE! } } But again, make sure the mod creator is actually interested in this if you want to share the result and ask how you can share the results

Glad to hear I was able to help you Don't worry about the false report, the mods in this forum will easily figure out that it was a mistake

the solution is: KSP doesn't know anything about alt gr and just thinks, you have a second left control key

"alt" is not the same as "alt gr" And indeed, "alt gr" will actually throttle down your craft and the reason is quiet simple to find, if you try to bind the key ingame. When KSP ask you to press a key to bind and you press "alt gr", it will recognize it as "LeftControl". After a quick google search, I found this on stackoverflow: https://stackoverflow.com/questions/42863842/altgr-vs-leftctrl Most important part: So this seems to be a limitation of the .NET framework, which is used in Unity (the game engine KSP is build on) and therefore, I don't think there is anything you can do about it.

Welcome to the forum That's a weird issue, your game throws a "TimeZoneNotFoundException" which apparently prevent your game to load. You should check a few things: 1) Open the date/time settings of windows and check if a timezone is set for your pc. If not, set the correct timezone there and try to start the game again. 2) Check the windows registry: Open the windows search and type "regedit" to find and start the registry editor. Then navigate to "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation" and you should find various informations about the configured timezone: Write down the value of "TimeZoneKeyName", in my example it would be "W. Europe Standard Time", for you, I guess it should be "China Standard Time" Now, navigate to "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones" and check, if there is an entry with the same name you've noted before. If any of these entries in your registry is missing, then it is the cause of your issue and we have to figure, how we can fix it.

Nope, stock KSP allows to re-root "ghost" assemblies. @SteveD80 As far as I know, this is a known issue but easy to work around by enabling the stock re-root tool in the EEX settings, at least while re-rooting the non-attached assembly