Pehvbot

Members
  • Content Count

    44
  • Joined

  • Last visited

Posts posted by Pehvbot


  1. 7 minutes ago, boribori said:
    1. Yes, that was it! And some of those screen texts were actually quite helpful :) Thanks!
    2. I found the tree config and now I know what to research first. I initially thought I couldn't get any rockets in the air just because I hadn't played early career in ages and wasn't used to launching without ascension guidance. Now however I fear it is because of FAR. When you start there seems no possibility to build an aerodynamic rocket. The only option seems to be the Stayputnik. Is that correct?
    3. I first want to play LRTR as it was intended before I start changing too much, but eventually I will probably want to write my own KCT formulas. Do you have a document somewhere that explains what your formulas do? I find this document https://github.com/magico13/KCT/wiki/Preset-Formulas-and-Math-Parser-Documentation very difficult to read.

    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. 23 hours ago, boribori said:

    I just started playing LRTR (with Kopernicus Bleeding Edge on 1.10.1) and so far I love it, but I have a few questions/issues:

    1. I see this in my log:
      
      [LRTR]: Patching failed: with error , exception System.IO.DirectoryNotFoundException: Could not find a part of the path '/home/boris/Games/KSP/KSP_linux/GameData/LRTR/pluginData/Screens'.
        at System.IO.__Error.WinIOError (System.Int32 errorCode, System.String maybeFullPath) [0x000f7] in <ad04dee02e7e4a85a1299c7ee81c79f6>:0 
        at System.IO.FileSystemEnumerableIterator`1[TSource].HandleError (System.Int32 hr, System.String path) [0x00006] in <ad04dee02e7e4a85a1299c7ee81c79f6>:0 
        at System.IO.FileSystemEnumerableIterator`1[TSource].CommonInit () [0x00054] in <ad04dee02e7e4a85a1299c7ee81c79f6>:0 
        at System.IO.FileSystemEnumerableIterator`1[TSource]..ctor (System.String path, System.String originalUserPath, System.String searchPattern, System.IO.SearchOption searchOption, System.IO.SearchResultHandler`1[TSource] resultHandler, System.Boolean checkHost) [0x000d6] in <ad04dee02e7e4a85a1299c7ee81c79f6>:0 
        at System.IO.FileSystemEnumerableFactory.CreateFileNameIterator (System.String path, System.String originalUserPath, System.String searchPattern, System.Boolean includeFiles, System.Boolean includeDirs, System.IO.SearchOption searchOption, System.Boolean checkHost) [0x00009] in <ad04dee02e7e4a85a1299c7ee81c79f6>:0 
        at System.IO.Directory.InternalGetFileDirectoryNames (System.String path, System.String userPathOriginal, System.String searchPattern, System.Boolean includeFiles, System.Boolean includeDirs, System.IO.SearchOption searchOption, System.Boolean checkHost) [0x00000] in <ad04dee02e7e4a85a1299c7ee81c79f6>:0 
        at System.IO.Directory.InternalGetFiles (System.String path, System.String searchPattern, System.IO.SearchOption searchOption) [0x00000] in <ad04dee02e7e4a85a1299c7ee81c79f6>:0 
        at System.IO.Directory.GetFiles (System.String path, System.String searchPattern) [0x0001c] in <ad04dee02e7e4a85a1299c7ee81c79f6>:0 
        at System.IO.DirectoryInfo.GetFiles (System.String searchPattern) [0x0000e] in <ad04dee02e7e4a85a1299c7ee81c79f6>:0 
        at System.IO.DirectoryInfo.GetFiles () [0x00000] in <ad04dee02e7e4a85a1299c7ee81c79f6>:0 
        at (wrapper remoting-invoke-with-check) System.IO.DirectoryInfo.GetFiles()
        at LRTR.LoadingScreenChanger.Update () [0x00084] in <7e7701d9b5df4cf584cc5ed415df92ff>:0 

      Is that a problem? (I do get some crashes, but I don't think it's related to this. Full Player.log just in case.)

    2. How is Mechjeb tied into the tech tree and facility upgrades? Is that a question for LRTR or for RO/RP-1?

    3. KCT is not working as I am used to, no faster building with recovered parts, etc. Is that expected behaviour? Does it have something to do with the LRTR config for KCT, did this originate in RO/RP-1? (I read the KCT guide but I cannot figure out what the LRTR formulas do.)

    Thanks!

    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. On 7/29/2020 at 2:34 AM, FabioofSpace said:

    So, I got 12 errors all originating from the rescale.cfg. Here are the logs and mod list in a file
    https://drive.google.com/file/d/1kCnLgO3mv4Lx7lRr1MJtmh0b1o7ARZpd/view?usp=sharing

    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.


  5. 18 hours ago, FabioofSpace said:

    So, I got 12 errors all originating from the rescale.cfg. Here are the logs and mod list in a file
    https://drive.google.com/file/d/1kCnLgO3mv4Lx7lRr1MJtmh0b1o7ARZpd/view?usp=sharing

    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.


  6. 2 hours ago, Entropian said:

    Hi,

    I'm trying to run RSS version 16.4 with Kopernicus version 1.9.1-5 on KSP 1.9.1.  When the main loading is complete, the "secondary" loading (after the main screen changes) seems to go on indefinitely.  I don't know if this is an RSS issue or a Kopernicus issue though.  I know that RSS is supposed to run on 1.8.1, but I wanted to check if it would run on 1.9.1 and see what issues would come up.

    Log: https://www.dropbox.com/s/s4xtehzmbzldrjb/Player.log?dl=0

    I've installed all the dependencies as well.

    Thanks.

    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


  7. 26 minutes ago, R-T-B said:

    Yep, that was the conclusion I came too today as well.  Not our fault, maybe not their fault, probably squad's fault... lol.

    At first I was eager to blame myself because Kopernicus actually does mess with the solar panels (for super cool multistar tracking!) but that went nowhere, it's all good behaving code.  Looks like Squad's got work to do.

    Anyhow, new release for 1.10 that fixes the crash-on-load with certain packs that have particles, like GPP.  Now you can have your pretty particles and load it without edits and shenanigans!

    I hope I don't regret these words, but it's actually been pretty good to me, stability wise.  Try and break it for me...  and maybe we're at the point where we can have some fun, too. :)

    https://github.com/R-T-B/Kopernicus/releases

    Click "assets" to grab a prerelease.  You probably want version 2 right now.

     

    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.


  8. 21 hours ago, Karin said:

    Thanks for the code, I'm new to modding (I play with mods for a long time but I started to understand more deeply how they work recently) but I know how to work with this.

    I found these issues while I played with your mod
     

    • Modular Fuel Tanks and the fuel switch in Firespitter messes up the volume in the tanks, their volumes either overwrite the rescale or don't get it applied at all, all I know is most of my tanks had stock volumes with them installed (which is sad because one of my mods (Cormorant Aeronology) has firespitter as a dependency)
    • the fairing side parts in Procedural Fairings mod don't fits correctly in the base. excluding them from rescaling might fix, I didn't tried that yet

     

    Overall everything looks good

    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.

     


  9. 8 hours ago, Karin said:

    This is exactly what I've been looking for since I tried playing RSS. RO was always too much for both me and my pc.

    I've decided to install this with some parts mods that I use on my stock save and see if anything feels under/overpowered, but since it's a pure rescale I guess it will only reflect how the part originally feel.

     

    Some questions:

    There are some mods that are built balanced for a 2.5x system and rescaling them like the stock parts would made them too powerful, right? If so, how can we balance it?

    I noticed the Terrier size didn't match the 1.25m tanks after rescaling (even in a clean install). It's intended?

    edit: don't know what was causing it but now it's correct

     

    Nice work and thanks

    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!


  10. 13 hours ago, Redleg1 said:

    @Pehvbot Thanks for the reply.  Yes I am mostly interested in being able to use the contracts and maybe even the tech tree with JNSQ which is a 2.7x scale system.  For the contracts I think it would be a matter of changing the names of the bodies to reflect the JNSQ system which would not be difficult. But what I am not sure is whether the Contracts or the Tech tree can work without the rest of the parts of the mod.

     

    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!

     


  11. 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? 


  12. 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.


  13. 42 minutes ago, Fulgora said:

    Hey zer0Kerbal,

    thanks for providing this mod! I have used DangIt in the past and am now considering to switch to this one.

     

    I have noticed that OhScrap has some issues with ModuleManager 4.1.3 (did not test other MM versions):

    https://forum.kerbalspaceprogram.com/index.php?/topic/50533-18x-19x-module-manager-413-november-30th-2019-right-to-ludicrous-speed/

     

    I have:
    KSP 1.9.1

    ModuleManager 4.1.3

    OhScrap 2.1.1.0 (also tested 2.1.0.0)

    Windows 8.1

     

    Problem:

    The game does not finish loading. Depending on whether Squad DLC are installed it stops at "Verifying <expansion>" or "Loading expansions..."

    It also says in the loading screen:

    
    Mod(s) DLL that are not compatible with this version of KSP
    OhScrap 2.1.1.0 path/to/OhScrap.dll

     

    If you cannot reproduce the issue I can also test it on Linux.

    If you need any help in debugging / testing feel free to hit me up!

     

     

    Many thanks and best regards

    Fulgo

    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.


  14. 3 hours ago, gooseapple5 said:

    I lied, after restarting it again it seems to have worked this time.

    I'm guessing this is the same issue as below.

    3 hours ago, Lenniepen said:

    Thanks for your answer!

    - Manually installing didn't solve the problem

    - Deleting the \LRTR\plugins folder did solve the problem!

    This is the log file from the attempt with manual install and without deleting the plugins folder: https://www.dropbox.com/s/8xdvzc9zj1hvm2y/KSP.log?dl=0

    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.


  15. 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.

     

    9 hours ago, Lenniepen said:

    Hi, I haven't played KSP seriously in about 2 years, and am trying to pick it up again. I'm really glad I've found this mod, because ROmini is what I've used a few years back, and am still looking for combining Real Solar System with stock difficulty (so without Realism Overhaul).

    However, I can't seem to get this working in KSP 1.8.1 (with both DLC's). When I've only installed LRTR (using CKAN), including all dependencies, I have this weird problem that I can't click on any buttons in the main menu. They change color when I hover my mouse over them en click them, but nothing happens.

    I've tried the following:

    - Vanilla combined with RSS (and dependencies): menu buttons work fine

    - Vanilla combines with RSS and LRTR (and dependencies): menu buttons don't work

    - Vanilla combines with RSS and LRTR (and dependencies), but manually deleting Kopernicus Planetery Modifier: menu buttons work fine!

     

    Also:

    - I get the warning from Module Manager that LRTR\plugins\LRTRKCTBinder.dll is not supported in this KSP version (1.8.1).

    - Which Custom Barn Kit-config do I need to pick? I've picked Stock, instead of RO, is that ok?

     

    Any ideas?

    Thanks in advance

     


  16. On 2/10/2020 at 9:59 PM, Atlas Gaming said:

    I'm looking for a suggestion for any mods OTHER than Realism Overhaul which change the stock engines to real world specs compatible with Real Solar System but without all the other stuff that RO does... Plus right now RO does not work with 8.1 and all the rest of my mods are standardized on 8.1.

     

    Worst case I guess I can write scripts manually to update each engine, but I'm hoping someone has already done something like this.

    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.

     

     


  17. 1 hour ago, Galileo said:

    Keep in mind, the required updates for he new atlas shader has not been implemented, so things will still be very broken at the moment if you attempt to use the ultra shader stuff.

    Understood.  I was mostly just curious to see what happens.  And of course a big thanks to all the developers.  Thanks!

    3 hours ago, Dragon01 said:

    Actually, this may a problem with RSS, not a bug in Kopernicus itself. The biome maps were broken in 1.8.1, and something might have gone wrong during texture conversion. Vertically flipped textures are a common sight of someone forgetting to flip a non-DDS one.

    If you feel like doing some more testing, try loading JNSQ. It seems to use the most Kopernicus features, and it's up to date for 1.8.1.

    Thanks!  I'll give it a shot when I get the chance.


  18. 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!  

    IcSUpZU.png


  19. 52 minutes ago, KnedlikMCPE said:

    It is 32bit which is unsupported, so is there a tutorial how to install it manually?

    Edit: Solved it! Just somehow accidentally deleted KCT from GameData. Also, is there a tutorial how to hell rendezvous and dock in RSS?

    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.