Pehvbot

Not comfortably, but I think it can work with a bare bones install. Youtuber Carnasa just posted a good guide for a basic install for the latest version here:

You can try Less Real Than Real(ism) It works with a wide range of mods but it's specifically intended to be as light weight as possible. It is definitely less real than Realism Overhaul but it does have realistic sized rockets and performance. Another option is SMURFF, which will improve performance for stock and stockalike parts so they work better in RSS without rescaling them to realistic size.

In theory it rescales everything, but sometimes mod packs use custom modules which cause problems. Near future works but I haven't checked Far Future yet. It's on my list and I hope to get to it sometime soon.

It's actually a bit tricky. It's pretty easy to change the rocket performance but that doesn't change the amount of fuel in a fuel tank. You would still need oversized tanks to have enough fuel to launch things. In theory you can hack the LRTR rescale code to do everything (increase thrust, add fuel, etc) except change the size but this creates all kinds of knock-on problems with other mods. This could never be an 'official' option. But if you are feeling adventurous you can try replacing the contents of the GameData/LRTR/rescale/rescale.cfg file with the following. This is entirely untested. I have no idea if it will work. You will need to remove SMURFF (be sure to remove the SMURFF folder from GameData). // //engines // //fix engine clusters, otherwise clustered engines get over boosted (see below) @PART[*]:HAS[#lrtr_engineCluster[*],!MODULE[ModuleTagNotRescaled]]:FOR[zLRTR]:NEEDS[LRTRRescale] { @MODULE,*:HAS[#name[ModuleEngines*]] { @maxThrust /= #$/lrtr_engineCluster$ @UPGRADES { @UPGRADE,* { @maxThrust /= #$/lrtr_enineCluster$ } } } @MODULE,*:HAS[#name[ModuleB9PartSwitch]] { @SUBTYPE,*:HAS[@MODULE] { @MODULE { @DATA:HAS[#maxThrust] { @maxThrust /= #$/lrtr_enineCluster$ } } } } @MODULE[ModuleEngineConfigs] { @CONFIG,* { @maxThrust /= #$/lrtr_engineCluster$ } } } // //rather than just boosting thrust linearly, this creates a curve to make powerful engines even more powerful //this helps create closer to real world values for stock engines //equation: (maxThrust / (maxThrust + X) + 1) * maxThrust * 2.56 //gives 1-2 multiplier as maxThrust increases with X determaining the steepness of curve //set in LRTR/rescale/engines.cfg // //parts without lrtr_thrustCurve don't get an extra boost to thrust @PART[*]:HAS[~lrtr_thrustCurve,!MODULE[ModuleTagNotRescaled]]:FOR[zLRTR]:NEEDS[LRTRRescale] { @MODULE,*:HAS[#name[ModuleEngines*]] { @maxThrust *= 2.56 @UPGRADES { @UPGRADE,* { @maxThrust *= 2.56 } } } @MODULE,*:HAS[#name[ModuleB9PartSwitch]] { @SUBTYPE,*:HAS[@MODULE] { @MODULE { @DATA:HAS[#maxThrust] { @maxThrust *= 2.56 } } } } @MODULE[ModuleEngineConfigs] { @CONFIG,*:HAS[#maxThrust] { @maxThrust *= 2.56 } } } //all other parts @PART[*]:HAS[#lrtr_thrustCurve[*],!MODULE[ModuleTagNotRescaled]]:FOR[zLRTR]:NEEDS[LRTRRescale] { @MODULE,*:HAS[#name[ModuleEngines*]] { %thrustN = #$maxThrust$ %thrustD = #$maxThrust$ @thrustD += #$/lrtr_thrustCurve$ @thrustN /= #$thrustD$ @thrustN += 1 @maxThrust *= #$thrustN$ @maxThrust *= 2.56 !thrustN = DEL !thrustD = DEL @UPGRADES { @UPGRADE,*:HAS[#maxThrust] { %thrustN = #$maxThrust$ %thrustD = #$maxThrust$ @thrustD += #$/lrtr_thrustCurve$ @thrustN /= #$thrustD$ @thrustN += 1 @maxThrust *= #$thrustN$ @maxThrust *= 2.56 !thrustN = DEL !thrustD = DEL } } } @MODULE,*:HAS[#name[ModuleB9PartSwitch]] { @SUBTYPE,*:HAS[@MODULE] { @MODULE { @DATA:HAS[#maxThrust] { %thrustN = #$maxThrust$ %thrustD = #$maxThrust$ @thrustD += #$/lrtr_thrustCurve$ @thrustN /= #$thrustD$ @thrustN += 1 @maxThrust *= #$thrustN$ @maxThrust *= 2.56 !thrustN = DEL !thrustD = DEL } } } } @MODULE[ModuleEngineConfigs] { @CONFIG,*:HAS[#maxThrust] { %thrustN = #$maxThrust$ %thrustD = #$maxThrust$ @thrustD += #$/lrtr_thrustCurve$ @thrustN /= #$thrustD$ @thrustN += 1 @maxThrust *= #$thrustN$ @maxThrust *= 2.56 !thrustN = DEL !thrustD = DEL } } } //solid //numbers chosen to get near real world values matching existing motors. No real math, just guesswork @PART[*]:HAS[@RESOURCE[SolidFuel],!MODULE[ModuleTagNotRescaled]]:FOR[zLRTR]:NEEDS[LRTRRescale] { @mass *= 4.08 @MODULE,*:HAS[#name[ModuleEngines*]] { @atmosphereCurve { @key,0 ^= :0 :: @key,0 *= 1.4 @key,0 ^= :^:0 : @key,1 ^= :1 :: @key,1 *= 1.4 @key,1 ^= :^:1 : } } } @PART[*]:HAS[!MODULE[ModuleTagNotRescaled]]:FOR[zLRTR]:NEEDS[LRTRRescale] { @MODULE,*:HAS[#EngineType[SolidBooster]] { @maxThrust *= 2 @UPGRADES { @UPGRADE,*:HAS[#maxThrust] { @maxThrust *= 2 } } } @MODULE[ModuleEngineConfigs]:HAS[#configuration[SolidFuel]] { @CONFIG,* { @maxThrust *= 2 } } } //jets @PART[*]:HAS[@MODULE[ModuleEngine*]:HAS[@PROPELLANT[IntakeAir]],!MODULE[ModuleTagNotRescaled]]:FOR[zLRTR]:NEEDS[LRTRRescale] { @MODULE[ModuleEngine*]:HAS[@PROPELLANT[IntakeAir]] { @maxThrust *= 0.5 @atmosphereCurve { @key ^= :^0 :: @key ^= : 0 0:: @key *= 0.75 @key ^= :^:0 : @key ^= :$: 0 0: } } } //cleanup @PART[*]:HAS[#lrtr_thrustCurve[*]]:AFTER[zLRTR] { !lrtr_thrustCurve = DEL } @PART[*]:HAS[#lrtr_engineCluster[*],!MODULE[ModuleTagNotRescaled]]:AFTER[zLRTR] { @MODULE,*:HAS[#name[ModuleEngines*]] { @maxThrust *= #$/lrtr_engineCluster$ @UPGRADES { @UPGRADE,* { @maxThrust *= #$/lrtr_enineCluster$ } } } @MODULE,*:HAS[#name[ModuleB9PartSwitch]] { @SUBTYPE,*:HAS[@MODULE] { @MODULE { @DATA:HAS[#maxThrust] { @maxThrust *= #$/lrtr_enineCluster$ } } } } @MODULE[ModuleEngineConfigs] { @CONFIG,* { @maxThrust *= #$/lrtr_engineCluster$ } } } @PART[*]:HAS[#lrtr_engineCluster[*]]:AFTER[zLRTR] { !lrtr_engineCluster = DEL } @PART[*]:HAS[@MODULE[ModuleRoboticServoRotor]]:NEEDS[LRTRRescale] { @MODULE[ModuleRoboticServoRotor] { @maxMotorOutput *= 4 } } //tanks and resources @PART[*]:FOR[zLRTR]:NEEDS[LRTRRescale] { @RESOURCE[Oxidizer] { @amount *= 3.6 @maxAmount *= 3.6 } @RESOURCE[LiquidFuel] { @amount *= 3.6 @maxAmount *= 3.6 } @RESOURCE[MonoPropellant] { @amount *= 1.25 // higher dry fraction // Note: this means that volume utilization will only be 1/3 that of a regular // LFO tank.... @maxAmount *= 1.25 } @RESOURCE[XenonGas] { @amount *= 4 @maxAmount *= 4 } @RESOURCE[Ore] { @amount *= 3.6 @maxAmount *= 3.6 // assume same density as LF/OX } @RESOURCE[IntakeAir] { @amount *= 4 @maxAmount *= 4 } @RESOURCE[ElectricCharge] { @amount *= 4 @maxAmount *= 4 } @RESOURCE[SolidFuel] //in line with real world fuel loads { @amount *= 5.78 @maxAmount *= 5.78 } @MODULE[ModuleFuelTanks]:HAS[#type[Solid]] { @volume *= 1.61 } @MODULE[ModuleB9PartSwitch]:HAS[#baseVolume] { @baseVolume *= 3.6 } @MODULE[ModuleFuelTanks]:HAS[#volume] { @volume *= 3.6 } @MODULE[Configure] { @SETUP,* { @RESOURCE,* { @amount *= 3.6 @maxAmount *= 3.6 } } } } // decrease resource costs @RESOURCE_DEFINITION[Oxidizer|LiquidFuel|SolidFuel|MonoPropellant|XenonGas]:FOR[zLRTR]:NEEDS[LRTRRescale] { @unitCost *= 0.1 } // Fuel tanks, lower dry mass but larger volume @PART[*]:HAS[@RESOURCE[LiquidFuel],!MODULE[ModuleCommand],!MODULE[ModuleEngines*],!MODULE[ModuleTagNotRescaled]]:FOR[zLRTR]:NEEDS[LRTRRescale] { @mass *= 2.4 } @PART[*]:HAS[@MODULE[ModuleB9PartSwitch]:HAS[#moduleID[fuelSwitch]],!MODULE[ModuleCommand],!MODULE[ModuleEngines*],!MODULE[ModuleTagNotRescaled]]:FOR[zLRTR]:NEEDS[LRTRRescale] { @mass *= 2.4 } // scale up intakes @PART[*]:HAS[@MODULE[ModuleResourceIntake],!MODULE[ModuleTagNotRescaled]]:FOR[zLRTR] { //@mass *= 2.56 @MODULE[ModuleResourceIntake] { @area *= 2.56 } } This will also be overwritten every time you update LRTR so keep a copy of it handy. Don't be surprised if mods like Procedural fuel tanks and RealFuels break. This patch definitely voids the LRTR warranty so good luck and let me know if you survive :-)

SMURFF does this. If you install SMURFF it will automatically disable the rescaler. I don't think it scales performance up quite as much, but it it shouldn't given the lower fuel mass needed. I've never tried playing a full game with SMURFF so I don't know how well it works with the other LRTR stuff (tech tree, contracts, etc). If you try this, let me know how it works. I'm always up for improving the mod and feedback helps.

Yeah, this is on me. As you guessed, it's looking for the wrong techtree node. LRTR uses the custom RP-1 tech tree which doesn't have the same node names. If you feel comfortable with adding a ModuleManager cfg you can create a new text file (call it mypatches.cfg or something similar) and save it to the GameData folder. Add the following: @PHYSICSGLOBALS { @autoStrutTechRequired = materialsScienceHuman } If you want it right away you can change materialsScienceHuman to start. I'll fix this in the next update. Not sure when this will happen though.

I don't know if anyone has mentioned this, but there may be a conflict between Kerbalism and non-deployable antennas. In my tests I'm not able to transmit science using 'fixed' antenna with both BARIS and Kerbalism installed. Deployable antenna see to work normally. I believe this is coming from the ModuleBreakableTransmitter module, or at least removing this module fixes the problem I was having.

For anyone who is interested: I've been playing with BARIS as the failure mod for LRTR and it seems to work well with some caveats: The monthly costs overlap with the built-in LRTR monthly costs and also are quite steep. You may want to disable them. I've removed some of the action cards that directly conflict with LRTR (specifically astronaut related ones). BARIS has a minor but annoying conflict with Kerbalism which disables science transmissions for non-deployable antennas. Unless/until this gets fixed I've disabled antenna failures when using Kerbalism Also Kerbalism failures overlap with BARIS you may want to disable or greatly reduce them, especially the engine failures. Launch cadences need to be much higher than stock games to account for failures. You may need to increase the BuildRate in Kerbal Construction Time. The easiest way is to directly edit default RP1 preset from the KCT settings: From the KSC right click on the KCT icon to open the settings Click the 'show/hide formulas' button to reveal the build formula Scroll down to 'Build Rate' and change the very beginning of the formula from (1+([L]... to (2+([L]... I'm still playing with this new build rate so feel free to adjust it as needed. The higher the number the faster the build rate.

v1.6.1 is a minor update with mod fixes for RealFuels, RestockPlus, and new stock parts. There is also an update for the companion LRTR KerbalismConfig improving support for 1.11 and improving some ISRU settings.

FYI, my Less Real Than Real(ism) mod does rescale both stock parts sizes and the RealFuels-Stock config to something like real world values. The down side is it's a sort of all-in-one mod with the RP-1 tech tree and contract system built in. You can also look at SMURFF which is designed to increase performance while keeping parts Kerbal sized. I can't confirm it's compatible with RealFuels, but it's worth looking at.

I'm able to run a reasonable RSS game in 1.11 on a 2015 Macbook Pro so your rig should be able to handle this just fine. I'm not an RSS or Kopernicus dev but my first step would be to start with a clean install and reinstall ModuleManager, Kopernicus, RealSolarSystem, and RSS-Config only. Make sure they are all in the root GameData folder. If this causes the same problem the next step would be to look through the KSP.log yourself to see if there's an obvious error message. After that try posting the KSP.log here.

That was sort of my thinking. My hope is that because a module is written in the cargo part cfg, it avoids that issue. On load the code would simply (ha!) insert any tagged modules of cargo parts into the containing part. The part in effect is the module, so it automatically gets added while in inventory. If you were able to at least insert part modules dynamically that's promising. I know basically nothing about C# or Unity so nearly all of my KSP coding has been at the 'banging on it with a rock until it stops moving' phase. I'm hoping to progress to at least the 'poking it with a sharp stick to get it to move in the direction I want' level. Knowing there's a stick is helpful.

Version 1.6 has been released. The release includes Misc bug fixes for 1.11 Fixes problem with the RP-1 command window in Sandbox and Science mode not displaying Adds a new command part (The Telemetry Launch Control Unit - TLC) an in-line part for early sounding rockets. Adds experimental support for Breaking Ground surface features which can be enabled in the config.cfg file. You can now play with Breaking Ground surface features scattered across the solar system. This is experimental and will likely be changed when there is official Real Solar System support. For now you can find all the various Breaking Ground surface features and includes the default contracts for them. Be a little careful, I haven't noticed a huge performance hit, but I tend to play a very light game, so your mileage may vary. If you do use it, let me know how it goes!

Thanks! Yes it's on CKAN, although 1.11 compatibility relies on a few mods that don't officially support it yet. I haven't noticed any serious problems except with Restock. Restock doesn't understand the revamped RCS blocks or HG-5 antenna yet. You will need to add some temporary patches to use them until it gets updated to 1.11 Create a Restock whitelist file (e.g. patches.restockwhitelist) somewhere in your GameData folder Squad/Parts/Utility/DirectAntennas/HGAntenna_v2 Squad/Parts/Utility/DirectAntennas/MiniAntenna Squad/Parts/Utility/rcsBlockRV-105_v2/ Create or add to a patching cfg file (e.g. patches.cfg) somewhere in your GameData folder. @PART[RCSBlock_v2]:BEFORE[000_ReStock] { RestockIgnore = True } Just so you know, I'm working on the next update which fixes a few problems with 1.11 as well as adds experimental support for Breaking Ground features (ROCs) in RealSolarSystem. It should be ready over the long weekend.

FYI, I've been able to replicate the problem (or at least *a* problem). I'm still looking at it but I think it's because the RP-1 menu is trying to load maintenance costs info but doesn't have any in sandbox mode. I didn't see it initially because I almost always load a career game and if you load a career game first THEN a sandbox game, it won't glitch. You can try this as a temporary workaround while I fix this.

Is 1.11.1 a pre-release? It is supposed to be working and does in my 1.11 test game. Any chance you can make the KSP.log file available?

I've been noodling around with an idea to use the new inventory system to add modules to parts by installing inventory items. It was inspired by the new evaExperiment, where an inventory item gatekeeps a module. 1.11 does this in a very simple way where having the item in inventory simply enables an existing experiment module. The full idea would basically be a way to create modular parts where a part isn't much more than an empty shell and the inventory items add the functionality you would want. A part would be created from the physical part (say an Octo probe shell) with a bunch of inventory slots and a volume limit. You would then use inventory items to add command, SAS, reaction wheel, comms, etc. This would allow you to add things like science experiments to probes or SAS to capsules (assuming you can stay within the volume limits!), enable upgrading existing parts, use the tech tree to shrink the volume for inventory items to cram more stuff in a part 'shell', etc. The only way this would work is rather than the current 'gatekeeper' method where the module is already on the part, you would need to be able to propagate a module 'upwards' from the inventory item to the host part. So before I dive in I thought I would ask has anyone tried to dynamically adding a module to a part or know if it's possible or not? If so is there some sample code for this? I would like to avoid spending time on either the impossible or on a known and solved problem. Also, maybe someone is already on this or it's just a stupid idea for reasons I haven't thought yet. I would want to hear about that as well. Thanks!

Try %TechRequired = stabilityRP0.

Now that Kopernicus more or less supports it I've been playing with adding Breaking Ground planetary features (ROCs) to RSS. I've simply remapped their locations and changed the descriptions to match their new homes. They seem to work well (except Earth/Kerbin features which don't show) but I'm wondering if anyone knows if the devs are working on or interested in official support for this.

It uses the standard RealSolarSystem scale which is 140km. It only rescales stock and stockalike parts so they are more more less real world size/mass/performance. It's basically just a way to play a lightweight version of RP-1.

Thanks for the help! It looks like these changes uncovered an existing bug in my techtree config that was ignored in older KSP versions. The lunarOrbiterCapsules RDNode had a broken 'Parent' node which caused all kinds of strange behavior, including with KerbalismConfig. The original RP-1 techtree is fine so I must have introduced it when I converted it to the LRTR mod. Again, thanks for looking at it.

The latest update v1.5.1 reverts the techTree config file back to one that works in 1.10 and lower. 1.11 is not supported yet. My apologies for my overly enthusiastic update

Thanks for the info! Frustratingly, I am getting wildly inconsistent results. I'm beginning to suspect a ModuleManager issue. In the previous version as well as the original RP-1 version worked fine in 1.10 or less. The code was very similar to your solution above but with !RDNode,* {} sitting inside the same patch that adds in the RP-1 tech tree instead of being its own patch. I changed it to -TechTree {} because I was getting very strange tech tree behavior in 1.11 and this *seemed* to fix it. In theory removing the TechTree node and adding it back in with a MM patch should work. And it does work sometimes. It looks like the ModuleManager.TechTree file sometimes gets written and sometimes it doesn't. With your patch I get even stranger behavior now. If I have kerbalism installed it seems to hangs when trying to add very normal parts throwing an error about RDNodes or it gives me a blank tech tree without kerbalism installed. NOTE: I'm running this in MacOS so it might be an OS specific issue. As of now I think LRTR is just not fit for 1.11. I'm going to see if I can create a bare minimum MM patch that duplicates the problem and make sure that v1.5 works with earlier KSP versions.

It's actually the opposite. The RP-1 tech tree is completely bespoke and gets disabled by having Community Tech Tree installed so folks who want to use a different tech tree can do that. However I just ran into the problem you described testing the v1.5 on a clean 1.11 install. It worked when I created the update and strangely it seems to have fixed itself after rebuilding the Module Manager cache. I'm not sure why it broke or why it is working now. I need to do some more digging on this. I'll respond as soon as I get a stable version.

Version 1.5 has been released. This version adds preliminary support for KSP 1.11. It also adds support for Procedural Wings and the Waterfall engine effects mod https://github.com/pehvbot/LRTR/releases/tag/v1.5 In addition it rebalances the 'Aeronautics' branch of the tech tree, making X-Planes more viable in early game. EDIT: I should add Waterfall requires the Restock config since all it does is properly scale the effects for rescaled parts.