4x4cheesecake

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

Oh, weird....I was sure it's going to be BetterTimeWarp. Well, in this case, I have no clue what causes this issue, sry

So did you figure it out? Black Sky is usually related to scatterer and a wrong config. Did you install RSSVE or RSSVE-Lite? The latter one doesn't contain a config for scatterer, just the configs and textures for EVE, so scatterer probably loads the default config which doesn't work in RSS. I would suggest to try RSSVE then, for your convenience, I've uploaded it to my dropbox, which provides an easier and faster download then archive.org https://www.dropbox.com/s/2wacz6aoc663azm/RSSVE-1.2.2-RC3.zip?dl=0 (RSSVE was released with a CC BY-NC 4.0 License, this is just a reupload. All credits goes to Phineas-Freak)

I would suspect "BetterTimeWarp" to be responsible for that since it will directly affect the timewarp behaviour. Should be easy to test by uninstalling it and go for a test flight. If it turns out to be this mod, I don't know if there is an actual fix for this issue except for uninstalling it, but you may want to report it in the mod release thread.

@Outsoldier Well, you run a RSS install and SVE will only apply effects to Kerbin, Eve, Duna, Laythe, and Jool... since these planets are usually not present in a RSS install, you see no difference. Try RSSVE or RSSVE Lite instead. RSSVE (seem to have no offical download link anymore but it's available on archive.org): https://archive.org/details/RSSVE-1.2.2-RC3 RSVE-Lite: https://spacedock.info/mod/1136/RSSVE-Lite On a sidenote: your GameData directory contains an additional GameData folder, which usually indicates a wrong installed mod you may want to take a look at that as well

It does, it will affect the reaction wheels in your craft and SAS, especially when you set it to a specific direction, will "override" the trim. But if you turn SAS off, the trim will turn the ship around without any inputs so pretty much the problem described in OP.

Check your KER settings (enter the VAB or SPH, place at least a command pod to get the KER Dv window and open the settings there). Quote from KER OP: Since your KER toolbar icon is greyed out, I assume your vessel/tracking station doesn't fulfil the requirements, defined in your settings.

Did you set the trim control by accident in one direction? "Alt + X" should reset the trim settings

Try pressing "F4"

Black sky and no water usually indicates a wrong config for scatterer. The latest version of SVE uses an updated config to match the new syntax of scatterer 0.5xxx versions (the .version file claims to be compatible with KSP 1.3.0 and above anyway but I wouldn't trust it in this case). Have you tried an older version of SVE already, like v. 1.3.0.4?

Are you sure? "Before ReAlerted" was maintained up to KSP 1.3.1 and I would expect the mod to break in any KSP version above 1.4. Anyway, the part of the code which is used to deploy the experiments relies on the stock "ModuleScienceExperiment" but DMagic OrbitalScience uses a modified (derived) "DMModuleScienceAnimate" to handle the experiments. Well, ScienceAlert could invoke the "DeployExperiment" event instead of the method and it should work with both, stock experiments and at least OrbitalScience but it's up to LGG to decide if he actually want to support other mods which may or may not increases the maintenance work.

@fragtzack have you tried to use the "edit" button next to the "HUD2" button to move the window? These HUD elements don't have a fixed position, you can place them everywhere you want. PS: 2560x1440 is the "2k" resolution (WQHD), 4k would be 3840 x 2160

I didn't^^ In the end, I was used to go through the logs just by using the search function of notepad++, I usually found the part of the log I'm interested in much fast, then by starting an additional plugin. If you want to try it anyway: it's a fairly simple xml file which includes the search terms but since the output_log doesn't contain prefixes for errors, warnings, etc, you have to edit them and maybe even add a few more. Can't remember if the terms are case sensitive but that should be easy to find out

Yes for SVE, no for SVT. Short answer: SVE + EVE takes care of the sky and SVT + kopernicus of the ground Slightly more detailed answer: EVE is indeed "just" the tool which allows to add clouds (and city lights) to the game but without any configs and textures, nothing will change by just installing EVE. SVE Provides these textures and configs, so it depends on EVE. SVT on the other hand, uses kopernicus to change ground textures (and adds additional ground scatter). Same principle but based on kopernicus: Kopernicus is "just" the tool which allows to modify celestial bodies but without a config, nothing will change (at least on the surface, some stuff may happen internally but these are unnecessary details now). SVT provides configs and textures to modify the appearance of the surface of celestial bodies and depends on kopernicus (but not on EVE).

The option is not in the game, but in steam. I've recently described the procedure to someone else, who wanted to use the german translation. Just follow the same steps but set it to french