• Content Count

  • Joined

  • Last visited

Everything posted by Pehvbot

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. I'm pretty sure you need the latest version (18.0) of RSS. There were changes to the textures in recent updates.
  8. 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.
  9. 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. 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.
  10. 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!
  11. 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!
  12. 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?
  13. 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.
  14. 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.
  15. 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.
  16. 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.
  17. 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...
  18. 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.
  19. 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: 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.
  20. 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.
  21. 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.
  22. 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!
  23. 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!
  24. 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: 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.