4x4cheesecake

Yeah, time dilation is strong in 2019 Uhm... sure? I mean, I didn't add anything to the mod, just updated it for newer versions of KSP but I think its fine

Wow, its been a hot minute since we talked about this mod and I honestly thought you adopted it like 3 years ago already Anyway, glad to see you're still rocking here

@imcute Appreciate your effort but this thread is almost 4 years old, the issue got sorted out

@linuxgurugamer You might want to look at this anyway. Something fishy is going on there and I'll try to explain: First of all, there is a simple test you can do which is launching a vessel containing just a single command module and an experiment. You can run the experiment and then use "Collect all" just fine to store it in the command module (well, that shouldn't be possible though since "collect all" is not an option to choose from when you just right click the part itself, but I'll come back to this) Then, add a "Experiment Storage Unit" to the vessel, run an experiment and click "collect all" again. You will notice not just the orange warning but also, that the science data got duplicated: it's now stored in the command module as well as in the experiment storage unit and this duplication is the actual cause for the warning, since you cannot store the same experiment twice in the same container. So, my thoughts about that: I think this happens because the default ModuleScienceContainer comes with the "collect all" event but is slightly different configured for the command pods and dedicated experiment storage unit. By default, the ModuleScienceContainer has the attribute of "canBeTransferredToInVessel" set to "false" but its changed for the experiment storage unit to true: MODULE { name = ModuleScienceContainer reviewActionName = #autoLOC_502201 //#autoLOC_502201 = Review Stored Data storeActionName = #autoLOC_502202 //#autoLOC_502202 = Store Experiments evaOnlyStorage = True // i.e. can nearby regular vessels also do this, or EVA only storageRange = 1.3 canBeTransferredToInVessel = True canTransferInVessel = True showStatus = True } The command pods on the other hand, don't change this value and therefore using the default: MODULE { name = ModuleScienceContainer reviewActionName = #autoLOC_502201 //#autoLOC_502201 = Review Stored Data storeActionName = #autoLOC_502202 //#autoLOC_502202 = Store Experiments evaOnlyStorage = True storageRange = 1.3 } I think the science data gets duplicated because of this... I don't know how the "collect all" event works exactly but since it shouldn't be active for the command pod in the first place, I think KSP doesn't check properly for the "canBeTransferredToInVessel" attribute and adds the science data to the new container but then fails to remove it from the previous one because of this attribute. Though, the question is why the command pod actually is on the list of science containers, even though the mod actually checks for the "collect all" event being active on the part: https://github.com/linuxgurugamer/ScienceAlert/blob/5c9c88a3590f6bab886c6c455d5cfa589703be88/Source/ScienceAlert.Windows/DraggableExperimentList.cs#L92 I'm not sure if this is a mod issue or KSP issue but if (m != null && m.Events["CollectAllEvent"].guiActive) should be "false" for command pods but it's not, so every command pod is added to the list of "ModuleScienceContainer"... Maybe checking for "canBeTransferredToInVessel" would work better, though it comes with the drawback of being no longer able to use "collect all" in the early game until some kind of dedicated experiment storage unit is unlocked.

Why should it say "more"? The terminal velocity of your stage needs to be less than 12m/s or the stage will be destroyed all the time. If the message would just say "less than 12" I would agree, it should be "more than 12" and it would be a hint that your terminal velocity was above the required minimum of 12m/s. But since it says "less than 12 needed", the message tells you that everything above 12m/s is too fast for a successful stage recovery.

CKAN doesn't offer you this update because "B9 Part Switch" is not listed as compatible with 1.12 but it's a required dependency. I would assume that you can still install the update without any issues anyway, you just have to insists You can do that by two different ways: 1) Add 1.11 to your list of compatible KSP versions (in CKAN go to settings -> compatible game versions -> select 1.11) or 2) Select Stockalike Station Parts in CKAN, switch to the "Versions" tab on the right side, put a checkmark in front of the latest version and apply the changes as usual. CKAN will complain (before you install the mod and everytime you start the game through CKAN) but it will most likely still run fine. I personally prefer the second method since the first one affects all other mods as well and you might get an update or install a new mod which might be indeed incompatible with 1.12 but you won't get any notification from CKAN about it.

Yeah, I reported this "issue" to CKAN just to realize 5 min later that the mod is now actually maintained by the KSP-RO team I guess it will either get split and gets his own mod entry in CKAN or at least the metadata should be updated soon.

Please specify what you actually try to do and how. Do you try to update mods? Do you try to update the game? Since you're getting an error message, I assume you run some kind of software for whatever update you try to do, so is it CKAN? Steam? GoG? Standalone update from the KSP store?

@JEB'S DESTINY Your log shows quiet a few exceptions thrown by FAR. Not sure how this will prevent you from entering any buildings but a faulty mod can cause weird issues sometimes. I would suggest to remove FAR for testing purposes and see if it solves your issue. If it does, report it to the mod creator/maintainer Would be interesting to see if the other people with the same issue here also installed FAR but without a log, I'm not going to bother looking for similarities

Assuming this is actually an installation issue and not a compatibility issue, you can try my tutorial on mod installation: Though, if you are sure that everything is installed properly and the mods still don't work, we will need a log file to dig deeper into the issue. This thread explains where to find the log files and how to share them on the forum:

I see...well, I used a spreadsheet to calculate the SMA. If you want the orbit to be more precise, you can use 55495582.49 meters for the SMA, that's the actual value I've calculated which results in an orbital period of 12 days and 26 seconds according to the KER readout. I also installed SOC really quick (kronometer was already installed) which calculates a SMA of 55493693.3470702. Putting that value into the MM patch, the orbital period of the mun actually results in exactly 12 days (according to KER, it's 11d, 11h, 59m 60s ) Guess the missing kronometer mod threw off the calculations of SOC

First of all: Why do you delete the complete Body node just to change the SMA? Seems a bit overkill and you may or may not made a mistake by copying all theses lines, like missing a closing parenthesis. JNSQ has two different SMAs in the config, one is used if principia is present, the other for default KSP physics. Are you sure you edited the correct value depending which other mods you have installed? I did a quick test with this patch and it worked perfectly fine (using KSP physics, not principia): @Kopernicus:FOR[JNSQ] { @Body[Mun] { @Orbit { @semiMajorAxis = 55500000 } } } Though, I would suggest to use :AFTER instead of :FOR but it should work in both cases. Also, the SMA of 55500000 meters actually results in a 12 day orbital period, instead of 190 days when you use your 350000000 meters (it's not 100% exact but very close with ~12 days and 1 minute... did you use the correct gravitational parameter for JNSQ?)

Well, kinda... If you look into the api documentation for the "ModuleScienceConverter" and check out the "Public Attributes", you will find the default scienceMultiplier value but also it's type, which is an integer in this case. So when you try to use anything else than an integer, it will fall back to the default value.

It should actually still work the same way as before. I did a quick test and it still works for me using either of both methods I've suggested the last time (direct file editing or Module Manager patch). We might need some more insight here... First of all: do you try to edit the file directly or do you use a MM patch? If you try to use a MM patch, do you actually have MM installed? Which value do you try to set? And since you brought it up: You are really 100% sure edit the right file of the right game install?

Thanks for taking care if it, guys

Another thing about the prompt to read and agree to the community guidelines and terms: rule 2.2l and 5.1 contain a forum link which cannot be opened unless you agree to the rules so you basically agreeing to something you couldn't read before (as soon as you click the link you'll be just redirected to the community guidelines). You may want to consider to rework the guidelines there PS: yes, I know most people wont read them anyway but if this is the reason for the prompt in the first place: people could still claim not to know these specific parts of the rules.

OOHH, I misread that I thought you're suggesting to set the KSP directoy to read only so it's not possible to remove any files and once the game is installed, everything stays in place. Though, it would most likely prevent you from saving anything... Your thought process makes a bit more sense^^

Well, your version of PS was heavily outdated (mod version 2.5.3 for KSP 1.3.1) , I'm not surprised it caused issues. Try the latest version instead: https://github.com/prestja/ksp-planetshine/releases

Does this not prevent you from saving the game and ships? If not, it's a neat workaround

Since your flight log says "crashed into cube", I would be interested in your log file, to track down this mysterious cube. Please check out this post to learn about log files, where there are located and how to upload them

For questions to a specific mod, I would recommend to ask in the mod thread directly. The people around there know the mod and may came across the same issue already. Best I can offer are two MM patches you can try but no idea if the effect is exactly what you are looking for. Little disclaimer: I've never used RP-1 and I came to the following results by looking at the source code and MM-patches of the mod. @PART[*]:FINAL { @MODULE[ModuleAvionics] { %toggleable = true %disabledkW = 0.1 } } You can also try to remove the module at all but no idea if t hat will break anything: @PART[*]:HAS[@MODULE[ModuleAvionics]]:FINAL { !MODULE[ModuleAvionics] {} } (Your patches probably failed because you didn't specify what MM is supposed to do. If you want to edit a value or module, you should use an @ in front of it, otherwise MM will just add the module and/or value to the part config. You may want to take a look at the MM handbook if you want to create your own patches: https://github.com/sarbian/ModuleManager/wiki/Module-Manager-Handbook )

That's pretty normal, yes. The final step to load the main menu can take some time and it can be faster or slower depending on your system specs and the amount of mods you have installed. As long as you actually get to the main menu, it's fine Yes, you can delete the empty folders

Perfect I already spotted your mistake: You installed kopernicus and galaxies unbound in the wrong way. Looks like you just unzipped the mods directly into your game install and ended with this kind of file path: .../Kerbal Space Program/GameData/Galaxies_Unbound_A_Stellar_Odyssey-1.0.2-3/GU_A-Stellar-Odyssey/GameData/GU/... In 99% of the cases, every mod contains some kind of "GameData" folder which is supposed to help you to orientate. The "GameData" folder of the mod, is the exact same "GameData" folder of your KSP install. So to install a mod, you need to drop everything from the mods "GameData" folder, into the "GameData" folder of your game. To pick up the example from above, it should actually look like this: .../Kerbal Space Program/GameData/GU/... I actually wrote a tutorial on that topic with more detailed explanations and a lot of pictures: If you have any further questions, don't hesitate to ask

Would you mind to share your log file with us? Maybe we can find something you've missed Since you cannot attach files to a post directly, you need to upload it somewhere else, for example a cloud service like dropbox, one drive, google drive, etc... and share a download link with us. If it exists, you can also upload the kopernicus logs instead. Kopernicus creates a "ready to upload" .zip file wich contains pretty much everything you need t o diagnose kopernicus related issues. You can find this file (called "Logs-Kopernicus.zip" in "your_KSP_install_directory/Kerbal Space Program/Logs". Though, it's possible that kopernicus encountered an issue before it was able to create this log folder, in that case the regular ksp.log should be fine

Did you come across a specific issue you want to solve? That would allow us to explain the process using that issue as an example. Depending on the error type, you have to look up the game logs and/or logs created my other mods (MM, Kopernicus,...) and/or the MM config cache. Then you have to locate the error and try to figure out: 1. what exactly does the error tells you? (nullRef, NaN, Array out of bounds,...) 2. which mod throws the exception/error? (for example by looking at the stacktrace which usually contains some more or less obvious hints) 3. when does the mod throw the exception? (during startup, scene switch, in the editor, after clicking a specific button, ...) 4. try to replicate the issue in a fresh game install which has only that one particular mod (+dependencies) installed 5. locate the code which causes the error by looking at the stacktrace and the source code (usually found at github) 6. if you know how to code or you want to learn it, you can try to setup an development environment and try to find a solution for the issue which then can be put into a pullrequest for the mod creator to fix the bug. Btw.: It's really useful to enable "verbose logging" in the game settings and "Flush log immediately to disc" in the debug menu (alt+F12 or ctrl + alt + F12, works also during game launch) to get the most information out of the log. You may also want to display exceptions and warnings on screen while playing to get an better idea when exactly the error happens (the error pops-up in the upper right corner then). Little warning though: if you try to track down any little exception which doesn't completely break a mod, you'll loose any time to actually play the game ) Short example for Kaptains Log: The mod throws this exception: Exception handling event onGameStateCreated in class KaptainsLog:System.NullReferenceException: Object reference not set to an instance of an object at KaptainsLogNamespace.KaptainsLog.InitDisplayFields () [0x00025] in <a5378a797d1349b49b3b355ebb6a1d03>:0 at KaptainsLogNamespace.KaptainsLog.InitOnLoad () [0x0012c] in <a5378a797d1349b49b3b355ebb6a1d03>:0 at KaptainsLogNamespace.Utils.LoadLogs () [0x00062] in <a5378a797d1349b49b3b355ebb6a1d03>:0 at KaptainsLogNamespace.KaptainsLog.onGameStateCreated (Game g) [0x00000] in <a5378a797d1349b49b3b355ebb6a1d03>:0 at EventData`1[T].Fire (T data) [0x000b0] in <9d71e4043e394d78a6cf9193ad011698>:0 I hope I don't need to explain why this exception is definitely thrown by kaptains log and not any other mod So, to follow my own list: 1) it's a nullRef 2) Kaptains Log 3) The exception is in line 120054 of the log, line 120399 shows a scene switch from main menu to the spacecenter, so it's thrown in the main menu 4) I'm not going to bother with that for this example 5) The last method in the stacktrace says "KaptainsLogNamespace.KaptainsLog.InitDisplayFields ()", so I search for "InitDisplayFields" in the github repository of the mod and find this: https://github.com/linuxgurugamer/KaptainsLog/blob/9e878cc840a622eac87e36464f0a2e4456c72b40/KaptainsLog/KaptainsLog.cs#L346 6) I'm not going to load the whole thing into visual studio and try to find a solution but I can take a guess: We are looking for an object which is referenced in this code but potentially can be null. The list of "DisplayField" is initialized in line 325 and checked against null, so that's not the issue. Line 356 to the end of the method populates the list of displayFields, partially referencing "k14" from line 354: KL_12 kl4 = HighLogic.CurrentGame.Parameters.CustomParams<KL_12>(); (Thanks for the "meaningful" variable name, LGG ) So it's either "k14" which is null or any of the referenced properties. Fun fact: I wasn't able to replicate this issue in a reliable way, so this might be a race condition or it was just a fluke