Pehvbot

It looks like it's coming from the SSTU mod for the SC-ENG-SRB-A and SC-ENG-SRB-U parts. It's because the cfg file for these parts is slightly misconfigured (the upgrades don't define the maximum thrust for each upgrade). This is probably fine for stock installs but when you try to adjust the thrust for RSS, it fails. A quick and dirty fix is to exclude these parts from rescaling by adding this to a custom .cfg file (if you are not sure how to do this let me know). They won't be useable but it shouldn't affect anything else. @PART[SSTU-SC-ENG-SRB-A|SSTU-SC-ENG-SRB-U]:BEFORE[zLRTR] { MODULE { name = ModuleTagNotRescaled } } I'll add the proper fix for this in the next update.

I'm pretty sure you need the latest version (18.0) of RSS. There were changes to the textures in recent updates. https://github.com/KSP-RO/RealSolarSystem/releases/tag/v18.0

For whatever it's worth I ran into a solar panel issue with Kerbalism+Kopernicus. Kerbalism has it's own solar panel code. You need to add '%useKopernicusSolarPanels = false' to solar panels or they get completely fubar. The default config has this, but mine didn't. Solar panels would always be listed as 'retracted'. Even static panels were listed as retracted. I don't know if they are related problems.

Thanks for the feedback. I was just working on a preliminary version for 1.9.1 (although still 'officially' for 1.8.1) so I rolled in Modular Fuel Tanks and Procedural Fairings. Version 1.2 has been released. It's added support for a TantaresLV, Procedural Fairings, and Modular Fuel Tanks. https://github.com/pehvbot/LRTR/releases/tag/v1.2 It's also added preliminary (i.e. unsupported) updates for 1.9.1 so if you want to play with the latest dev builds of Kopernicus you should be able to run a 1.9.1 game in Real Solar System. I don't recommend this if you plan on continuing an existing save game though.

You can exclude parts from rescaling by creating a custom.cfg file (recommended to avoid over writing mod files if you update) and adding code such as: @PART[part_header_name*]:BEFORE[zLRTR]:NEEDS[LRTRRescale] { MODULE { name = ModuleTagNotRescaled } } The specific thing where it says 'part_header_name*' needs to be customized for each mod. Some mods use a common naming convention. Bluedog for example uses 'bluedog_' so it would read @PART[bluedog_*]:BEFORE... If there isn't a consistent naming convention there might be other ways to exclude the parts. If nothing else you can simply list their names with the OR operator '|' between them, i.e. @PART[part1|part2]:BEFORE... If you aren't sure how all this works, send me a link to the mod and I can whip something up. If it's a fairly common parts package I can make it 'official' and add it to the supported mods. The Terrier has a bug in its cfg file. It lists it's rescaleFactor twice which breaks rescaling. I've included a patch that fixes this so I wonder if the patch simply didn't get applied the first time. Also, thanks!

Yes, it's easy to separate the components. You can edit the config.cfg file to enable/disable the core features. The tech tree and science features should both work without modification, although the science part will break if you are using Kerbalism without LRTR's KerbalismConfig. The contracts will be a little more difficult. I'm not sure if a global search/replace will catch everything since it's all been 'hard coded' for RSS. If you keep the RP-1 crew training you may need to adjust the training time to match JNSQ time rather than RSS time. The game will break without Kerbal Construction Time and default KCT config is also set to RSS time so that would need to be adjusted as well. Overall I would say: -Tech Tree: easy -Science: easy -RP-1: moderate -Contracts: hard Let me know if you try all this and how it goes!

Easily? No. The mod has 6 more or less separate functions: Contracts, rescaler, science, tech tree, Custom Barn Kit (KSC buildings and features), and RP-1 features (astronaut training, ongoing costs, etc). They can all be enabled/disabled independently but most of them are hard coded for the RSS and would take some serious surgery to work elsewhere. Were there specific features you wanted to use?

I think it is because all parts must be 'Purchased' before they are active. If you right-click on the inactive part you should see a button in the lower left corner. You can turn this off when you start a new Career. If that is not the problem, let me know.

Version 1.1 has been released. This adds support for Procedural Parts as well as a bunch of bug fixes: NOTE: This version fixes the ridiculously low dry mass of the fuel tanks so they are at least plausible now. Existing craft will be noticeably less capable. https://github.com/pehvbot/LRTR/releases/tag/v1.1

Yeah, this falls under the 'Known Issues' category. The rescaler basically multiplies the size of all parts by 1.6. Normally this change gets propagated to the nodes as well so they get moved. Some parts need to move the nodes separately (i.e. fairing interstages, variants for thrust plates and structural tubes, etc). I'm guessing the nodes for the ProceduralPart are generated by the module itself so it's not easily patched . In this case the best option would be to not rescale the procedural parts at all and just use the in game procedural parts rescaling. Another problem is that the part upgrades are hard wired for the default tech tree. Because this mod uses a custom tech tree all these upgrades would need to be redone with patches Finally the default max sizes are based on Kerbin sizes not RSS sizes, so everything would be too small. This would need to be fixed with patches as well. Unfortunately it would require quite a bit of work to get it working properly. I *think* not rescaling the parts could work properly in sandbox, but it wouldn't really work for career mode because of the tech and size issues. Try this patch: @PART[*]:HAS[@MODULE[ProceduralPart]]:BEFORE[zLRTR] { MODULE { name = ModuleTagNotRescaled } } If you are not familiar with how ModuleManager patches work, let me know and I can walk you through how to add it. I've never used procedural parts so some of this is guesswork. I'll see how easy it is to get a working patch. I will probably be pretty bored soon, so I should have the time. If so I'll roll it into a new version and post info here.

Is it possible you are missing a dependency mod? If a DLL can't find another DLL it's expecting, it can throw an error like this.

Good to know! In the short term I'll update the description and add it as a dependency. I'd still like it to work without KCT just to give the mod more flexibility, but that's a problem for another day...

I'm guessing this is the same issue as below. It's crazy busy for me right now but I expect things to slow dramatically soon. Something's obviously wrong with the DLLs. I'll take a look at them but it may be a few days before you hear back from me. Unfortunately removing the DLLs cripples things since it relies on them to make all the various parts work together. This was only a diagnostic step. It looks like you don't have Kerbal Construction Time installed. I may have changed the DLLs at some point to require this mod and just never tested it again. Try replacing the plugins and installing KCT and see what happens. You can always disable the mod from the KSC ribbon menu.

I'm actually not sure. The mod itself is mostly a bunch of Module Manager patches which can't mess with game menus and the DLLs don't really dig too deep into the system. None of this *should* mess with the game like that. I suspect the warning is related to the menu problem but I'd need more info to be sure. I would start by deleting the LRTR folder and installing the latest version manually: https://github.com/pehvbot/LRTR/releases/tag/v1.01 If that doesn't help try deleting the 'LRTR/plugins' folder and see what happens, then send me the KSP.log file. Let me know if it fixes the menu glitch or not. The standard Custom Barn Kit is the right one.

I built an RSS mod called Less Real Than Real(ism), which is basically a simplified fork of RP-1 for stock and stock-alike parts.

Understood. I was mostly just curious to see what happens. And of course a big thanks to all the developers. Thanks! Thanks! I'll give it a shot when I get the chance.

So I decided to live life on the bleeding edge and compiled the latest GitHub release against 1.9 and loaded Real Solar System. And it worked. And looks great. I was surprised how well it went. Well, except all the biomes on all the bodies are upside down. I wasn't really expecting it to work but this was... not how I thought it would fail. Oh well, it was a fun experiment. Now back to 1.8.1!

Version 1.0 for Kerbal Space Program 1.8.1 has been uploaded. It's RSS/RP-1 for 1.8.1, but with training wheels!

CKAN will work on a Mac in console mode. You can run it from the Terminal. I installed it using something called Homebrew, which is a tool for installing Unix programs. You can find it here: https://brew.sh/ Basically you go there and copy/past the small ruby script on the screen into your Terminal window. Once you've installed the base software you can then install CKAN by typing 'brew install ckan' in the Terminal. After that's installed you just type 'ckan consoleui' to run it in console (text) mode. It's not quite as good but it will work.

How did it go?

You may want to wait even longer on this. I was wrong about it :-) You can adjust things by messing with the inclination settings, but you need to change basically all of the planets to make things work. My understanding is KSP1 doesn't support axial tilt, so to fake it RSS messes with the axial tilt inclination of every body in the system. You could just change the Moon's inclination to match the Earth, (i.e. to 23.44603795469773) and I *think* that would work, but that has other undesired affects. Really though, if you are trying to go to the Moon, it's better to understand how the launch windows work. It's a bit of a read but this has lots of cool info: https://history.nasa.gov/afj/launchwindow/lw1.html Basically you choose the right time and direction and launch straight into that orbit. So no inclination changes needed. The easiest way I know is to wait for a launch window that is 90deg (i.e. due east. I said west earlier but that's just because I'm a dyslexic idiot). To do this you target the Moon and wait for the target or anti-target marker in the nav ball to be right on top of the level maker. Just launch (...checks hands to make sure) right and you are good to go.

I've never tried this but if you dig into the /GameData/RealSolarSystem/RSSKopernicus/Earth/Earth.cfg file there's a line called 'inclination'. You could try setting it to 0. I have literally no idea if this will do what you want but hey, it's worth a shot. just change this: inclination = 23.44603795469773 to this: inclination = 0.0 //23.44603795469773 If you've never edited a cfg file there are some quick tutorials on line about modding KSP. Basically all you need is a text editor.

There's a bit to unpack here but I would start by saying: Learn to love the axial tilt! The real question is, what is the specific problem you are having? The Earth's axial tilt itself doesn't really affect things much. All Earth orbits are with respect to Earth itself so its tilt makes no difference at all. If you are going interplanetary, your orbit makes very, very little difference so again the tilt doesn't matter. I can only think of two problems and one of them not even related to axial tilt: The first is geostationary orbits. The default launch location is the real KSC in Florida at about 28deg north of the equator. Geostationary launches are more expensive since you need to adjust that 28 degrees. This just makes it a little more expensive in fuel. Just remember to adjust your normal/anti-normal as far from Earth as you can as this will make it cheaper. You can also use a mod to add more space centers and pick one closer to the equator. The second is lunar missions have a narrow launch window caused by both the axial tilt and launch location. There is an easy trick here though. Put your craft on the launch pad, target the Moon, and wait for the Target or Anti-Target markers to be on top of the position (level) marker. Once it's very close launch due west. This will put your craft on the same plane as the lunar orbit. From there you just pick the right time to burn prograde. You will get a launch window once every 2 weeks or so. There are other ways to get there, but this is the easiest.

Kerbalism should just pick up science experiments from their previous amount. It takes a few flights to get full science but that's definitely a feature not a bug. Make sure you have 3.2 since that has a much better science module. If it's not picking things up at the point you left off, there may be something wrong with the install or it might be an older KerbalismConfig folder. Are you using this one?: https://github.com/Standecco/ROKerbalism

It's a little self promotional but you could try this: It rescales stock parts to something like realistic size/mass/performance, supports a few popular stock part mods, and gives the full RP-1 experience with a lot less of the realism. If you don't want the contracts or tech tree, you can just extract the two config files from the root folder (lrtr-part-tweaks.cfg and lrtr-resize.cfg) and put them somewhere in your GameData folder.