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