Pehvbot

I've tried it with both and it seems to be fine. If there are problems I haven't found them yet.

This is just a guess, but I *think* you could extract the stock KerbalismConfig/System/ScienceRework directory and replace the /System/Science folder in the LRTR config. You just need to disable the Science node in the LRTR/config.cfg file. You will also need to dig through the /Support directory to find and science mods you are using. There's a non-zero chance you add in some glitches if you include mods that have both science parts and other types of parts. Use at your own risk!

Happy to include any techtree changes, especially currently unsupported mods. I haven't tried Procedural Wings yet but it's likely to have all the same UPGRADE issues and patches. I'm happy to add it to the list though.

1. I’m guessing the config file was overwritten because the new one added a new config element. I never thought about this problem. I’ll be sure to warn folks if I do that again. 2. The tech tree was lifted directly from RP-1 and is really designed for more parts than a stock game. In my ‘head canon’ I thought of the empty nodes as just necessary development that didn’t lead to manufactured parts. I’ll take a look at the mod to see if it just needs to understand the RP-1 tree. 3. That was lifted directly from RP-1 as well. I never use them so I never thought about it. It would be pretty easy to add a config setting to enable it. 4. It’s a LRTR issue. Because it uses the RP-1 science model it basically nukes all other science parts. The custom KerbalismConfig is only set to understand the LRTR experiments. It is possible to disable the science stuff in the config file but that then breaks the custom KerbalismConfig. I Can’t think of an elegant solution. Again thank you for the feedback. It helps quite a bit.

Thanks for the feedback! I don't really have much of a plan for adding support other than specific requests or finding a mod and going 'hey, this looks interesting...' Any/all feedback is welcome. In general adding a parts oriented mod goes something like this: Load it 'as is' and see if the parts are being properly rescaled (some parts just don't rescale, especially if they use custom mods internally) Do a sanity check on engines and tanks to make sure they are getting the correct volume and thrust adjustments Looping through these steps to get things 'right' Check tech tree positions. The RP-1 tech tree is completely custom, so normal tech tree positions don't work. I have a rough and ready script to put them somewhere in the RP-1 tree but it doesn't do a great job. I don't have much of a method to do this, it's mostly guess work and grouping 'like' things together. I have some php scripts to help but those are not good for public use. Exclude science only parts. The science stuff is also the custom RP-1 stuff and doesn't play well with normal parts. Fine tune engines a bit. In theory thrust should be 2.56 times the 'Kerbal' scale but in practice larger engines need more of a boost than that. The mod has a thrust adjuster (lrtr_thrustCurve) to do this. I've tried to avoid hand tuning each part so this number is normally done across all engines in that mod. LRTR definitely takes a 'good enough' approach (Less Real after all!). Look for weird bugs. Parts can use custom modules that can do strange things Look for UPGRADES that require specific tech (Again because of the RP-1 custom tech tree). I kind of slack on this one. Some mods like Bluedog have hundreds of parts and I'm kind of lazy. Add training times to Pods so the RP-1 training stuff works. Add in specific KerbalismConfig info. I normally don't play with any parts mods at all except ReStock/Plus so many of the 'supported' mods don't get completely tested. If you see problems please let me know. If there are unsupported mods you want to use, load them up and see what happens! I do have a short list of things I want to do, but no real timeline Run Restock/Plus without Making History installed. In theory it adds a version of the Making History parts. I think I have them correctly configured, but I'm not actually sure. Run the game with Breaking Ground ground features. The latest Kopernicus supports these now and the LRTR/config.cfg has a switch to enable them in RSS. I haven't tested them much. Play with Breaking Ground robotic parts and propellers. 1.10 fixes the rescale bug so use the LRTR/config.cfg to enable rescaling. Add some sort of science back into the manned Science Lab parts. My hope is to do this without adding any additional mods. If there are any mods you want included let me know.

I’m 99 % sure this is KerbalismConfig replacing the stock solar panels with its own mod. Take a look at KerbalismConfig/System/Misc.cfg. I don’t know what the fix is.

Yeah, once you have 3 or more mods all with their own changes, things get a little crazy. Throw your own changes into the mix and you can get an almost random set of results. I feel like sometimes I install the exact same mods with the same versions in the same order, and get different results. For RealAntennas I think it's slightly easier to patch the existing PARTUPGRADE nodes directly since it means you don't need to re-insert the upgrades, but honestly it's nearly functionally identical. I'm testing something like this: @PARTUPGRADE[commsTL1] { @techRequired = lunarRangeComms %entryCost = 1 } And speaking of crazy, the 'fun' discovery was that RealAntennas also tries to patch the KerbalConstructionTime tech requirements for the Tracking Station, overwriting the LRTR settings. I think the only elegant solution is to have RealAntennas patch TrackingStation.cfg to add !LRTR to NEEDS. It already does this for RP-0. I'm testing a patch to reinsert the correct settings, but it ain't pretty.

The LRTRStock profile is actually cribbed from the RO Kerbalism profile by Standecco (although it uses an earlier out of date version). It's much closer to reality than the...er... less real LRTRSimple profile. It already uses real world processes to create the stock resources. For example, it uses the sabateir reaction (CO2+Water) to generate LiquidFuel. It would be easy to add in some cfgs to check if RealFuels is installed and to update the production of the LRTRStock profile to create the real fuels. Updating to the latest RO profile is on my list and should iron out some of the rough edges in the LRTRStock profile. In practical terms this means LRTRStock can't produce LiquidFuel/Methane on the Moon since there's no carbon/carbondioxide to speak of. You can of course make HydroLox from the water. This is one reason why Blue Origin (who favors the Moon) use a HydroLox landing engine and SpaceX (who favors Mars) use MethaLox landing engines. Good do know it's not hopelessly broken any more :-) There really wasn't any logic to the Fillet configs, or the shaped configs in general. I went with the stock settings and adjusted to the RP-1 tech tree just to have something that worked. Allowing any shape early makes sense. Adjusting the minimum size down also makes sense. I was planning to add procedural tanks to the start menu, but make them just cylinders with restricted size. The postWarMaterialsScience upgrade could then add all the shapes (no real reason not to, as you say) as well as unrestricted length. The next tier can be add unrestricted minimum size. I'll go ahead and roll it into the next update. It would be pretty easy to change the tech tree node name (i.e. name = ...) but keep the RP-1 display name to embed the stock tree into the new tech tree. It's just a matter of picking nodes that are 'close enough' and then updating references to the node name. It won't be a perfect match and mods should still be customized when possible, but that should fix this problem for any random mods used. I'll test it out and see. Again, thanks for the suggestions and bug tracking. I'll take a look at the procedural fairings and thrust plates.

Nope, it's kind of its own thing. It sits somewhere between stock and Simplex in terms of complexity. My goal was to make ISRU useful in a minimal LRTR install. It cuts down resources you can mine to Water and Ore. With these you can produce any of the consumables (Oxygen, Hydrogen, LiquidFuel, Oxidizer, Monopropellant, Fertilizer). The LRTRStock profile does basically same things, but just does them with more steps and mined resources. It would be trivially easy to mod it to produce HydroLox, MethaLox, or Hydrozine instead of LiquidFuel, Oxidizer, and Monopropellant and get something sort of close to real world results. There are three separate problems, all fixable. The first problem is that RealFuels removes the stock ProceduralParts fuel tank and inserts its own. This means none of the LRTR configuration files apply to them. The second problem is I made some changes to the configs without testing. I mean they were just super simple changes to some of the tags used for UPGRADES. How could I screw that up? Well, I screwed it up by not testing of course :-) Finally the RealFuels tank (first problem) wasn't properly excluded from rescaling. The model was being rescaled but the nodes weren't. All of them are fixed in the GitHub and will be included in the next update. [edit] Yep, your diagnosis was spot on. I broke the ProceduralParts upgrades in 1.3 which caused most of the weirdness. Thanks!

Version 1.3 is available. It's mostly small bug fixes. It also adds ISRU support. Version 0.7 of the KerbalismConfig is also out and has some major changes. It has two profiles, LRTRSimple (the default) and LRTRStock. LRTRSimple is a complete rebuild and may break existing games. The new profile simplifies resources a bit, adds ISRU support, and makes the Greenhouse useful again. The LRTRStock profile *should* fix Greenhouses but I haven't fully tested it yet.

Yep, you just need to make sure it patches after the tech tree changes and doesn't include the external seat. LRTR also has the RP-1 training times. The earliest one it uses is the X-1. If you look under LRTR/support you can see how I've done it for each parts mod. I don't know of any best practices guidelines. I know from personal experience I would go through a lifecycle that started organized, got less and less organized as I added things until it became unmanageable, then I would go through and redo everything. By then I started to have a better idea of what I wanted to do. I just keep repeating this. In your case since you are trying to tie mods together I would create working subfolders for each mod (i.e. tmp_lrtr, tmp_rss, etc), throw the changes into those folders somewhere, and once you are happy with the results see how they can be either be integrated back into the original mod or simply cleaned up and added to a more permanent file/folder structure. My own goal for LRTR was to make it as light weight as I could with as few hard dependencies as I could get away with. I'm definitely open to any changes or support files that support, but not require, other mods or modes of play. Also any tech tree or contract suggestions. The way the mod is configured you can even have alternate features (such as two different tech trees) selected by the LRTR/config.cfg file either internally to LRTR or by adding another mod.

Looks good so far. In general you can just push most airplane stuff to the 'supersonic' branch of the tech tree somewhere. I've basically ignored aircraft and I'm pretty sure the breaking ground parts need to be better arranged as well. If you see things that look out of place feel free to bring it up. One RP-1 specific issue is that the earliest cockpits should not be able to go above about 10,000m for very long (no pressure suits, pressurization). They should have @MODULE[ModuleUnpressurizedCockpit] added to them. Right now it's being done in the LRTR/parts/capsules.cfg but really it should be in the specific LRTR/support/ files. I'll probably fix for the next release.

Yep, definitely still rough around the edges :-). I'll add the fix to the next update. Thanks!

Yeah, it looks like it removes the stock part and reinserts a procedural fairing using the same name. It's just a guess, but it might be an ordering problem. If LRTR ran after PFFE it would likely place it correctly. If that's the problem the fix is theoretically simple, just add another 'z' at the beginning of LRTR (i.e. FOR[zzLRTR]). The problem of course is if some other mod relies on the current ordering of LRTR, then it breaks that mod. It's also a giant pain to change because it's used across the entire mod and even in the KerbalismConfig. A local fix for you would be to simply re-insert the parts using a custom script. @PART[fairingSize1]:AFTER[zPFFE]:NEEDS[LRTRTechTree] { %TechRequired = earlyMaterialsScience } @PART[fairingSize2]:AFTER[zPFFE]:NEEDS[LRTRTechTree] { %TechRequired = materialsScienceAdvCapsules } @PART[fairingSize3]:AFTER[zPFFE]:NEEDS[LRTRTechTree] { %TechRequired = materialsScienceLunar }

Yeah, the 'After' numbers should have been the numbers all along. I'm guessing something was busted in the RealFuels-Stock patches. I never did proper testing. At any given era you should be able to build a reasonable facsimile of a real rocket from that time frame. If you can't it means my code is broken somewhere, typically from an untested (or poorly tested in this case) mod. I never really talked about what the mod does when rescaling so this is as good an opportunity as any. At it's core it's pretty simple. Kerbal scale parts are 5/8 the size of 'real' parts so the mod just increase the size to 1 by using 8/5 (i.e. 1.6) All the 'magic' of the mod happens in the rescale.cfg file. It's fairly complicated but it really only does four things: 1) It rescales parts in all three dimensions (i.e. length/width/height) by 1.6. This doesn't change the mass or the volume, that would need to be done later. 2) It rescales thrust of engines by 2.56 (i.e. 1.6^2). This is because thrust can be abstractly thought of as coming from the area of the bottom of the engine bell. If you increase both the width and length of the bell by 1.6, that's 1.6*1.6, so the area is 2.56, and thus the thrust is increased by 2.56. This mostly works but stock engines are a bit nerfed for game balance as they get bigger so I added in some code to make larger engines get a bigger than 2.56 increase. Solids are even more nerfed so I double the thrust again. 3) It rescales the volume of fuel parts to 3.6. In theory it should be a bit more than 4 (1.6^3 height*width*length) but 3.6 gives a more real world results. Technically I don't do anything with volume for the stock game, I just increase the amount of fuel/oxy by 3.6. It adds even more solid fuel, again to de-nerf them and bring them into line with real motors. 4) It rescales the drag cube (aerodynamic surfaces) for the increases size. This part is black magic for me, so I don't actually know what it's doing other than 'it seems to work'. Everything else is just cleaning stuff up, making attachment points work correctly etc. In theory I should be adjusting the mass as well but it turns out KSP parts are pretty close to real world mass already so I don't do this for very many parts. My goal was to avoid tweaking individual parts, since... well who has time for that. Doing the above four things gives 'good enough' results. There are a bunch of support files but they do very little fine tuning, it's mostly fixing glitches and making sure they work with some of the RP-1 features (contracts, science, crew training). I'm guessing RealFuels still has some rough edges so keep the comments coming.

1) I'll put the KerbalismConfig CKAN entry on the list but I'm not sure how long this will take. 2) The issues was between RealFuels-Stock and the rescaler code. LRTR applies a thrust increase for solids on top of the 'normal' increase. RealFuels handles thrust in a custom module which was being increased normally for all engines but it wasn't getting the additional increase for being a solid as well. It also wasn't adding enough fuel, so it was both under powered and under fueled. The latest rescaler.cfg file on the github fixes this. The results don't quite match RO, but they are much saner. And thanks for the feedback! I wouldn't have even looked at this problem.

I should have suggested using :AFTER[zLRTR] instead of :BEFORE[zLRTR] to remove all the UPGRADE info. That way you don't need to worry about what LRTR is doing, it will just get overwritten so you don't need to remove the proceduralparts.cfg file. My guess is the tank inconsistency is coming from RealFuels. The Oscar B has its own issues in stock, since it carries about twice as much fuel as it should based on volume, but I think RealFuels ignores the default numbers and inserts a 'volume' they assigned. LRTR just increases the volume RealFuels adds by assuming it's a cylinder with both length and diameter increased by 1.6x. In theory that makes it almost exactly 4x increase in volume but I use 3.4 instead to get a more real world mass fraction.

I *think* part of the problem is the Procedural Parts changed how they upgrade sizes. It now uses the built in UPGRADES feature instead of TECHLIMIT. As far as I can tell TECHLIMIT no longer does anything. It's still rough around the edges but I've updated the proceduralparts.cfg file to use UPGRADES instead. If you want that true bleeding edge experience you can download it and give it a shot. Note: You need to go into the R&D facility and 'buy' each upgrade. Currently the costs are crazy high for some upgrades. https://github.com/pehvbot/LRTR/blob/master/GameData/LRTR/support/proceduralparts.cfg EDIT: With a little more digging, it looks like RealismOverhaul uses this file to remove upgrades and free up the size limits: https://github.com/KSP-RO/ProceduralParts/blob/master/GameData/ProceduralParts/Parts/ZOtherMods/RealismOverhaul.cfg You can use this to avoid having to deal with upgrades. Just change BEFORE[RealismOverhaul] to BEFORE[zLRTR] and remove LRTR/support/proceduralparts.cfg

Good info. The tank type and procedural part fixes should be pretty easy to roll back into the mod.

I did a quick test and Real Fuels did work for me, so I'm not sure what is going wrong. Make sure you install the RealFuels-Stock mod, that's where all the magic happens. Having said that, I did no real testing other than launching a few rocket designs as a 'sanity check'. If you have both RO installed, my guess is it's an issue between RO and RealFuels-Stock. LRTR by itself doesn't change tank types. I don't think RO and LRTR will work together in any case, they will wind up stepping on each other's toes way too much. LRTR has a specific 'sounding payload' part in the science section (really just a shrunk and repurposed Science Jr.). I don't know if Real Fuels will add sounding payload to regular tanks but the idea is you get through sounding rockets as soon as possible. Sounding payload is nearly obsolete by the time you have liquid fuel tanks and engines. Yeah, fairings are a step above tanks on purpose. The idea is that fairings are harder than tanks to create, so they require a bit more engineering. If you look at the history of fairings, the fairing size always appeared somewhat after the tank size. It's also for a bit of play balance. In my play throughs the timing seems to work about right in terms of historic milestones. You can definitely adjust this if you like though. For example, adding a .cfg file with this will moved the 1.25 fairing 'down' one tech level. @PART[fairingSize1]:AFTER[zLRTR]:NEEDS[LRTRTechTree] { %TechRequired = postWarMaterialsScience } The materials science branch of the tech tree is: postWarMaterialsScience earlyMaterialsScience materialsScienceSatellite materialsScienceHuman materialsScienceAdvCapsules materialsScienceLunar materialsScienceSpaceStation ...

1) Glad it worked! I'll fix it for the next version. 2) Yes, in stock, the stayputnik is the only option. Really, the only starting option in stock is a stayputnik with a small SRB and some fins. I call it my 'bottle rocket' era :-) I never tested it with FAR and it's not clear to me how rescaled aerodynamic parts will work. I'll add it to my 'things to test' pile. You could play with the number/placement of fins and adjust the thrust of the SRB motor so see if you can get a viable rocket. If you want some more flexibility you can add Completely Non-Aggressive Rocketry. It gives you a V-2 like rocket from the start and works well with the mod. 3) KCT configs are a bit black magic to me. I took this directly from the RP-1 folks and I modded it a bit for LRTR. You will likely need to ask the folks over there or KCT for guidance. Oh, and thanks for the feedback! I took a look at the mods you added from the discussion thread and will add them to the supported list when I can.

1) I never tested this on a Linux box. If I had to guess I would say it's a case-sensitivity error. If the Linux version is case sensitive, it's looking for pluginData rather than the existing PluginData. Try changing the name of the file '/home/boris/Games/KSP/KSP_linux/GameData/LRTR/PluginData' to (lower case p) pluginData. If that works please let me know and I'll fix it in the next version. 2) This is from me. It comes from the LRTR/support/mechjeb.cfg file and follows the 'avionics' branch of the tech tree. If you use a different tech tree it disables these. Did you want an 'always complete' mechjeb? I never use it so I just added barebones support. It should be pretty easy to change the cfg to make fully active a config option. 3) Yep, that's the way it was set up. It uses a slightly modified version of the RP-1 config. Although it's hard coded to load this by default, you can definitely change it back to the KCT stock, or any other version by right clicking on the KCT ribbon icon and opening up the settings. One thing to note though, the stock config is is set up for Kerbin timescales rather than Earth timescales.

As author of LRTR there are a couple of things to note: It has preliminary support for the RealFuels-Stock which seems to work, although I never did a full review. It DOES NOT have ISRU support (yet). I don't think it would be super hard to implement, but because the mod is stolen from based on RP-1, which removes it, it doesn't have it. It has a KerbalismConfig for it. It also supports Snacks! It doesn't support any other life support mods (yet). It uses the RP-1 tech tree. This does a good job of following historic progression but is completely different from the stock tree. This of course causes problems for any mod expecting the stock tech nodes to exist. The mod patches unsupported parts to put them somewhere sensible in the RP-1 tree but this doesn't always do a great job. Most stockalike parts work fine and many are 'officially' supported. However some parts use custom DLLs which don't always play well with rescaling, and as noted placement in the tech tree can be a little suboptimal for unsupported parts. It's 1.10 'ready' meaning if you dare, you can use the bleeding edge Kopernicus build and it should work. Some of the pre-req mods are out of band, but it worked reasonably well in tests. Nearly all of the components (Tech Tree, Contracts, Science Parts, etc) can be enabled or disabled so it's pretty easy to use a different mod for these things. Overall it was intended as a light weight alternative to RealismOverhaul and RP-1. My goal was to support as many KSP mods as it can but avoid 'bespoke' hard-coded solutions as much as possible. Support patches are normally pretty simple and usually designed to make the mod work with as little change as possible. I'm still working on it and am happy to add support for mods if folks are interested. And of course if you wanted to take a crack at adding ISRU support (or anything else you wanted to add), that would be fantastic.

Another option is Less Real Than Real(ism). It is basically the Real Progression (RP-1) career mod without Realism Overhaul. It rescales stock and stockalike parts to real scale and something close to real world performance.

So I've been digging into the SSTU mod a bit. It uses a bunch of custom modules internally. In particular it uses a module that 'builds' some parts out of several models, so you can change the look or features of a part in the VAB. The rescaler can't adjust the size of these internal models which means these parts won't rescale properly. The parts will look like they have gaps in them and won't be the right size. There may be other issues with this mod as well. Unfortunately this means either not using the mod or using SMURFF. If you install SMURFF, it will disable the rescaler and (hopefully) adjust all the installed mods to work at Kerbal size at RSS scale.