Akira_R

It's at times like this (when I'm playing on my laptop not my super computer) that I miss the good old days with Active Texture Management, a (nearly) identical mod load out from pre 1.x would run ok on my laptop but will use up all of the available ram and crash out in 1.2

When you say the craft is corrupted what do you mean? Does the game freak out when you try to load it? If that is the case could you load up the game, go into VAB and try and load the craft, after game freaks out go ahead and Alt-F4 out of the game. Then upload your output log not your ksp log. if you follow the link I posted it will tell you where to find that log file.

@SlayerNebula Alt - F12 will show you the console, you might still have NRE spam if it's really laggy. Yeah one of the many reasons why I personally dislike CKAN and highly recommend that anyone interested in seriously modding KSP learn how to mod manually. It's actually very very very easy to figure out and will save you a world of headaches.

Kopernicus is spamming your log with NREs, so there is likely an issue with a planet pack or something, the only planet pack I see in your GameData folder is OPM, although there are a few folders there that I don't recognize. You can use more than one planet pack but as far as I know that requires a significant amount of end user tweaking. So if you do have other planet packs remove them first and then remove OPM. If after removing OPM your problem goes away I would recomend trying to reinstall Kopernicus and OPM manually. I personally greatly dislike CKAN, not to put down it's authors or anything, they have done some great work. I just see far to many issues pop up that could have been easily solved by a manual install. Unlike other games that I have modded (mostly Beth games) KSP is very intuitive and simple to mod manually. It is my recommendation that if you really want to run an extensive mod list like yours that you take the time to familiarize yourself with manual modding and how MM and KSPs cfg file system works, it may be intimidating at first but is actually really quite simple. You will be able to identify most problems pretty quickly on your own and generally be able to fix them as well, also eventually you will be able to use more mods and make them work better together by writing your own MM patch files.

It will be a lot easier to figure out what's happening here if you include your entire log file and a list of mods you are using.

Yeah NREs (Null Reference Exception) are generally bad news, especially if it is spamming the log, in which case it will massively slow down the game and eventually crash it. Given that the NRE is referencing Kopernicus the problem likely lies in a planet pack or something of that nature. What planet packs are you using? It is always helpful to post your mod list and an output log when seeking support. My current install has 100+ mods and sits around 20Gb RAM usage at the main menu (mod it tell it crashes baby, then buy more RAM and mod it some more!!) so I can assure you the game can handle it.

In the Sigma Dimension config there is a value you can tweak to help with this. The landscape parameter can be used to rescale the height of terrain features when rescaling a planet. You will have to mess around with it a bit but I was able to get my 3.2x rescale to look pretty good, obviously it's not super effective at 10x + but for 6.4x and under it is more than adequate.

If any one uses Station Science I made a patch adding some of it's functionality to a few of the SSTU parts. StationScience compatibility patch Current functionality: Research Lab added to BDB MOS-LS lab Research Lab added to SSTU-SC-COS-LAB parts Research Lab added to SSTU-SC-DOS-LAB SSTU-SC-DOS-FEM duplicated and made a new zoology bay I plan on including USI parts in this patch in the future. I have no current plans to add functionality to any other BDB lab parts (if there are any) as I do not use them (I play with a cut down BDB install, only use the Mercury and Gemini pods and accessories) RE balance: a small attempt at balance was made, mostly based off of research node placement (in CTT) and size of the part, the StationScience lab and zoology bay were disabled as well. If you wish to change the balance the .cfg is well commented and it should be fairly easy to see what I did and what to change. If anyone has any patches they would like to include in this please feel free to PM me.

Well i went ahead and started my own patch. StationScience compatibility patch Current functionality: Research Lab added to BDB MOS-LS lab Research Lab added to SSTU-SC-COS-LAB parts Research Lab added to SSTU-SC-DOS-LAB SSTU-SC-DOS-FEM duplicated and made a new zoology bay I plan on including USI parts in this patch in the future. I have no current plans to add functionality to any other BDB lab parts (if there are any) as I do not use them (I play with a cut down BDB install, only use the Mercury and Gemini pods and accessories) RE balance: a small attempt at balance was made, mostly based off of research node placement (in CTT) and size of the part, the StationScience lab and zoology bay were disabled as well. If you wish to change the balance the .cfg is well commented and it should be fairly easy to see what I did and what to change. If anyone has any patches they would like to include in this please feel free to PM me. @tomf you are welcome to link this in the OP or include it in the down load if you so desire.

Here is the Kopernicus forum thread And GitHub https://github.com/Kopernicus/Kopernicus And Sigma Dimensions (the mod to apply the scaling change) forum thread And GitHub https://github.com/Kopernicus/Kopernicus

Some how Kopernicus is able to modify the in game clock to use a different day length (for instance 12 hours instead of the usual 6 hours), it also affects maneuver nodes and contracts, any chance we might see KAC able to reflect this type of change by pulling it directly from whatever Kopernicus is changing, or allow the user to manually set the day length some how in a cfg? Just FYI it looks like it is just the UI that is off, for instance an auto generated alarm for a maneuver node will go off at the correct time, it just counts down by 6 hour days on the UI. I haven't tried to manually set an alarm yet.

Derp i should have thought of that when I saw I didn't have a MagiCore folder. Deleted and it's working fine. However KCT is still counting down by 6 hour days, I tried both an existing save and a new game and in both cases KCT was still counting by 6 hour days, would you like logs and screens?

Any one have any MM configs that add station science functionality to station parts from other mods like USI, SSTU, BDB or anything else?

@magico13 tested latest build to check the new time/clock changes discussed in the release thread. However after install KCT seams to be misbehaving. KSP version: 1.2.2 (heavily modded) KCT version: 1.3.9.0 MagiCore version: 1.2.1.0 Old KCT folder deleted, no MagiCore folder was installed (IDK how KCT would have been working unless a way older build didn't need it, last time I updated was before you got the new build server) Installed from Build #23 Any save loaded whether it's an old one from before the update or a new one made after the update says that there is an error loading KCT data and that KCT is broken. Starting a new save the settings dialog seams to work fine, but selecting spend upgrades fails to open the upgrade window, instead you just get a small bar about the width of the upgrade window normally, same thing happens when clicking on the VAB button in the main UI, all the other buttons work as normal. Link to logs: https://www.dropbox.com/sh/1af69yylgxfkrhi/AAAAAEttukbQVzvSPGQvH6k7a?dl=0 Let me know if you need anything else or want me to try anything else, I'll try on a fresh install in a few hours.

It's been awhile since i messed with HR but there should be a launch_hotrockets.cfg file somewhere in the HR install, delete that and you should be good. And welcome to the forums! EDIT from @sebi.zzr

I don't really see a problem or potential error here, in fact this makes perfect sense, in the real world we would handle this by forgetting about those last couple minutes and adding an extra day every 23 years so as to keep the calendar in sync with the season. However in KSP this is not much of an issue, sure it may look funky with the year starting on say 2 but at least your day cycle still syncs up with the actual day/night cycle, which to me is the most important thing in this regard.

Cool, hopefully I get a chance to give it a try this weekend

@tater I have also found that 3x - 4x scale increases work fantastically with stock balanced parts, I am using 3.2x in my GPP install with essentially only SSTU parts for lifters and such, also no stock capsules, using a cut down BDB install for the Mercury and Gemini capsules. While I don't try and make any replicas I find that with stock balancing at these scales you get very realistic looking rockets. In fact the only reason I haven't gone up to a 6.4x or 10x rescale is the headache I would get trying to rebalance everything since I use a huge suite of mods lol.

Indeed that sounds like it should work, I would agree that the automagic method is much preferable I just assumed it would also be more difficult, i will definitely be up for testing, however I haven't updated my dev version of KCT for some time like probably since January, maybe even longer than that (not at home so can't check) will there be any save breaking issues? I know that at one point I had updated KCT and it borked up a save, which was luckily in the early stages of career, and I had to start over. EDIT: actually now that I think about it I didn't update KCT I added KSC-switcher to an already started save which borked up KCT involvement with KSC-switcher.

@magico13 regarding the "issue' that really isn't an issue that @New Horizons posted about. Recently there have been some improvements in Kopernicus and Sigma Dimensions that allow the game to display game time relative to the rotational period of Kerbin (or simply the home body if it is replaced). essentially there is a day length multiplier built into Sigma Dimensions that allows you to slow down (or speed up) the rotation of Kerbin when rescaling it, Kopernicus then takes this and works some magic with the in game clock so that it and all maneuvers and contracts will display using this new value for the length of a day. For instance in my 3.2x game I am using a day length multiplier that gives me 11 hour days, this keeps the rotational speed of the planet close to what it is in stock. Now this has absolutely no affect on KCT, builds still take the same number of Kerbal - hours and the UI just displays the number of days assuming 6 hour days. I assume you keep track of the builds via number of seconds, just like pretty much any other mod out there that deals with time, and then you have some division factor that is used to display the number of days/hours/minutes the build will take. How difficult would it be to expose this factor in a cfg file or make it editable in some way in the in game menu? I believe this would really be the only change necessary, as the builds would still take the same number of Kerbal - hours, there is simply more hours in a day now. EDIT: I just saw that you are already talking about addressing this above, thank you magico!!

I posted a request on the USI-LS forum but I doubt that Rover Dude really paid much attention to it, if i knew the first thing about C# I would definitely make a pull request, however I only know a little bit of C, and that was taught to me over 10 years ago now sooooo......

You can change the rate at which USI-LS uses resources (which I have done in my game) however the UI will still display the time in 6 hour days, so if I have changed it so that the supplies in a pod will last for 5 of my 11 hour days, the UI shows it has 9 days 1 hour of LS

@Poodmund @New Horizons @Galileo Regarding using Kopernicus time with rescales. I have been using a 3.2x game modified to an 11 hour day for a while now, using this the in game clock ticks by with 11 hour days and contracts and maneuvers all use the same 11 hour day, I have not had an issue with KAC's auto generated alarms, they always go off at the right time and I haven't really looked to see if they are counting down by 6 hour days or the new 11 hour days, and I haven't had to input a manual alarm in quite some time sooooo there is that. However any mod that keeps track of time will stay in the 6 hour day format, this includes KCT, USI-LS, and TAC-LS (I think), and probably things like EPL, NFT, KSPI-E. This is because the game itself and all mods (that I am aware of) keeps track of everything in seconds and for UI purposes simply does some division to display things in the year/month/day/hour/minute format we see. In all the mods that I have come across that handle time this division factor is hard coded and not changeable, I have made some requests to mod authors to allow us the ability to specify a day length in some way in a cfg but have not had any luck so far. This in no way makes them inaccurate though, the times themselves haven't changed, they are still showing the correct number of seconds until that particular event, you just have to remember that if USI-LS says you have 5 days of life support left it's really saying you have 5 days * 6 hours = 30 hours of life support left. This isn't game breaking in any way, it's simply annoying. Until more mod authors get on board with either getting their day length factors from Kopernicus directly, or at least have an option in a cfg to make adjustments to it, I would recommend not having any day length changing behavior be the default behavior in GPP rescales because of this potential confusion, I would probably leave them as an additional optional feature along with the rescales with all the appropriate warnings about their use.

Well in the OP there are actually only two:

@Gameslinx the planet pack is looking good! However my pedantism is getting the best of me and I have to point out that in the OP you make several references to SSTOs when I think you meant space-planes, as SSTO simply means single stage to orbit and does not in any way imply a space-plane type design. For instance the Lunar Ascent Module used in the Apollo program was a Lunar SSTO, and any probe/vehicle that you have designed that is capable of reaching orbit around a body without dropping any bits off of it is by definition an SSTO. A space-plane also doesn't need to be an SSTO either, for instance many of my space-plane designs have leveraged the use of under wing drop-tanks to help get to orbit, which makes them by definition not SSTOs. Anyways sorry for the little pedantic lecture there, carry on good sir.