Jump to content

JebIsDeadBaby

Members
  • Posts

    163
  • Joined

  • Last visited

Posts posted by JebIsDeadBaby

  1. One more thing I've just found out - if you change EC utilization, you need to change EC unit mass in all tank definitions that can hold it. Otherwise EC starts adding TONS to the total weight of a tank. If you want to stay in line with battery power/weight ratio of 100EC/5kg, unit mass of EC should be utilization/20/1000, so in case of utilization of 7 it should be 0.00035.

    @TANK[ElectricCharge]
    {
    	@utilization = 7
    	@mass = 0.00035
    }

     

  2. On 8/17/2020 at 4:09 PM, king of nowhere said:

    i had enough deltaV on my ship to get to mun normally, and i burned it all without ever getting close.

    This may be heavily dependent on TWR of your rocket. Imagine, you have a 100 kg rocket capable of 1200 N of thrust. From the Newton's 2nd law of motion we know it will be capable of initial acceleration of 12 m/s^2. BUT... when your rocket goes straight up, there is gravity which accelerates it in the opposite direction at ~10 m/s^2 (on Earth). This means your rocket accelerates at 2 m/s^2, 6 times slower than expected, while still burning fuel at full rate. A 1000 N engine (which gives TWR of 1.0) not only wouldn't be able to reach the Mun or even 80 km, it wouldn't go anywhere at all. 

    So I think a rocket powerful enough to reach the required speed fast enough could in theory be more efficient. 

  3. 14 hours ago, Bellabong said:

    should one really have the ability to put a 1.7 ton capsule into a full orbit at T0 with a T1 launchpad? The BDB Mercury for example comes to around 1.2 and needs a T1 Atlas for orbit at stockalike scale and that is nowhere near the T1 launchpad limit. 

    I'm not sure what case you're arguing here. IMO it should be possible within 18t limit with Tier II (General Rocketry) parts tops. I must admit I haven't played stock in ages and I'm out of touch with stock difficulty level but IIRC it was possible in stock (Mk1 to orbit is rather basic achievement after all). Regardless of how modded is your game, you'll be stuck with T1 VAB and T1 launchpad for a while and your ability to milk science and funds with basic parts may be limited.   

  4. Huh, I started to wonder where the original value of basemass = volume * 0.000016 actually comes from. I guess the original creators did their research but I thought I'll check the numbers. It's surprisingly hard however to find fuel tank volumes for common boosters. Finally I've found this paper titled Analysis of Propellant Tank Masses, which is exactly what I was looking for. It deals with LOX/LH tanks. Long history short, it shows that tank mass to propellant mass ratio is usually about 1/10, with 1/20 being the best one could aim for in their design. Now, LH tanks tend to be huge and thus, I assume, their tank to propellant mass ratio is a bit worse, so let's stick to 1/20 ratio for a bit. From www.braeunig.us we find that  common LOX based propellants density comes in range of about 0,8-1,5 kg/l. Let's assume for the sake of simplicity that the average density of our mixture is 1,2. This gives propellant mass in a 500 l tank of 600 kg. Applying our ratio to it we get 30 kg of 500 l tank dry mass. 

    500 l default tank filled with A50/NTO in RF has dry mass of 17,3 kg and wet mass of 604,3 kg, which gives even better ratio of 1/33. And only when looking into RF tank configs I realized how elegantly it is made. If I get it right basemass constitutes for only about 50% of the dry mass - it's like a mass of a bare frame, without any actual tanks inside. Only after you choose fuel type, a weighted average (I guess) of mass parameters defined for every fuel tank type is added to the basemass, which finally gives the final dry mass of the whole assembly. Beautiful.

    Anyway, from the original thread I gather that they based their values on Titian tanks. I dunno, maybe they indeed were that lightweight. It seems however that you could double tank dry masses and still call it realistic. You would have to double not only basemass parameters but also mass parameters for every tank defined within TANK_DEFINITION node. 

  5. As I said - barely possible with a simplest rocket. This Real Fuels example of yours: the rocket has only 400 m/s excess of Delta-V (I assume JSNQ of course) and just 1.12 TWR on launch. I'm willing to bet it will burn these extra 400 m/s just trying to get off the ground. Even if it gets to the orbit it probably won't be able to return. Add Kerbalism and Deadly Reentry to the mix and you're stuck. I don't want to argue about exact values, just want to point out that in a career mode with some realism mods, this can lead to being unable to progress in the early game. Although I understand you can't cater to all possible mod combinations. 

    Still, service and fuselage tanks should be adjusted as well. Right now there is no point in using default tanks.

  6. 7 hours ago, ValiZockt said:

    Seaching the changes you did below, how does it play with it? 

    For Mk1 50 l makes sense visually (could be even lower, like 30 l) and in the early game works perfectly in terms of difficulty. I play with Kerbalism however, so I get lower EC consumption by antennas, I use EC utilization of 4 though, so I can fit less EC to begin with. This way I get a pod capable of a few orbits. Once you upgrade VAB and get service tanks, pod tanks are not a concern anymore. 

    Pod patches need to be revised anyway as now they look for pods with either monopropellant or LF. New KV pods that were just added with Restock+ have only EC, so they don't get patched at all. 

    7 hours ago, ValiZockt said:

    Yes, that was intentional, before that you could easily get 2-3x times the Delta-V (m/s) out of tanks/rocket as you would normally. (Which made sense before as RF-Stock was more thought for 6.4x, which is a bit deprecated by now, as the new 2.7x is taking over). Service & Fuselage Tanks aren't effected as their to small to really get a big effect out of it.

    Well, heavier tanks are brutal. Mk1 into orbit within 18 t limit is barely possible, and Stayputnik to the SOI edge is straight out impossible. As for service and fuselage tanks I don't get it. They come in similar sizes as default ones. IIRC a 500 l default tank now has a drymass of ~85 kg, while 500 l service tank of ~18 kg. Doesn't make sense as service and fuselage tanks are supposed to be around 3 times heavier. Now they allow to cheat your way out of heavy default tanks. 

  7. Another question: in Fuel_Conversions.cfg since 5.0.0 there is a new basemass definition for Default and Cryogenic tanks

    // set drymass of all RealFuels configured tanks dependent on max volume
    @PART[*]:HAS[@MODULE[ModuleFuelTanks]:HAS[#type[Default]]]:AFTER[RealFuels]
    {
      @MODULE[ModuleFuelTanks]
      {
        %basemass = volume * 0.00015 
      }
    }
    
    @PART[*]:HAS[@MODULE[ModuleFuelTanks]:HAS[#type[Cryogenic]]]:AFTER[RealFuels]
    {
      @MODULE[ModuleFuelTanks]
      {
        %basemass = volume * 0.00015 
      }
    }

    The problem I have with this is that it's 10x higher that original RF setting (which was 0.000016 - one zero more). Is this intentional? If yes, why service tanks and fuselages are not corrected? 

  8. Was looking through KSP.log again and found this:

    [ERR 16:37:17.401] Exception handling event onNewGameLevelLoadRequestWasSanctionedAndActioned in class CustomBarnKit:System.ArgumentException: The Object you want to instantiate is null.
      at UnityEngine.Object.Instantiate[T] (T original) [0x0003d] in <5aeafee3fea24f37abd1315553f2cfa6>:0 
      at CustomBarnKit.CustomBarnKit.LoadUpgradesPrices () [0x0015e] in <d1abfd90e526443c9289aaa81ce9b36e>:0 
      at CustomBarnKit.CustomBarnKit.LoadUpgradesPricesSceneChange (GameScenes data) [0x0000d] in <d1abfd90e526443c9289aaa81ce9b36e>:0 
      at EventData`1[T].Fire (T data) [0x000b0] in <c1858a3f77504bd1aaa946fdccf84670>:0 
    
    [EXC 16:37:17.402] ArgumentException: The Object you want to instantiate is null.
    	UnityEngine.Object.Instantiate[T] (T original) (at <5aeafee3fea24f37abd1315553f2cfa6>:0)
    	CustomBarnKit.CustomBarnKit.LoadUpgradesPrices () (at <d1abfd90e526443c9289aaa81ce9b36e>:0)
    	CustomBarnKit.CustomBarnKit.LoadUpgradesPricesSceneChange (GameScenes data) (at <d1abfd90e526443c9289aaa81ce9b36e>:0)
    	EventData`1[T].Fire (T data) (at <c1858a3f77504bd1aaa946fdccf84670>:0)
    	UnityEngine.DebugLogHandler:LogException(Exception, Object)
    	ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object)
    	UnityEngine.Debug:LogException(Exception)
    	EventData`1:Fire(GameScenes)
    	<FireLoadedEvent>d__44:MoveNext()
    	UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr)

    These prices from my examples didn't come from any of the configs and this error message says something about setting prices. Maybe it's important. 

  9. Does CBK work with 1.10? I use it with Bureaucracy but in-game values for upgraded buildings are a weird mix of both. VAB for example:

    CBK - VAB
    	{
    		levels = 3
    		upgradesVisual = 1, 2, 3
    		upgrades = 56000, 225000, 845000
    		partCountLimit = 30, 255, -1
    	}
    
    BUREAUCRACY - @VAB
        {
            @levels = 5
            @upgradesVisual = 1, 1, 2, 2, 3
            @upgrades = 56000, 112000, 224000, 448000, 896000
            @partCountLimit = 30, 60, 120, 240, -1
        }   

    What I get in-game for the first upgrade: cost 450000, parts 120. 

    Or Mission Control

    CBK -	MISSION
    	{
    		levels = 3
    		upgradesVisual = 1, 2, 3
    		upgrades = 19000, 75000, 282000
    		activeContractsLimit = 2, 7, -1
    	}
    
    BUREAUCRACY -    @MISSION
        {
            @levels = 4
            @upgradesVisual = 1, 2, 2, 3
            @upgrades = 19000, 38000, 76000, 152000
            @activeContractsLimit = 2, 4, 8, -1
        }

    In game first upgrade - cost 150000, active contracts - 8

    In my KSP log I see that Bureaucracy values are applied correctly, so it seems that the game or CBK do not interpret them correctly. 

     

  10. Hi, 

    can you explain reasoning behind volume multipliers for tanks integrated into pods? Here's the code:

        name = ModuleFuelTanks
        volume = 0                                      // creates a blank volume for utilization
        @volume += #$/RESOURCE[ElectricCharge]/maxAmount$  // searches for electric charge
        @volume *= 1.7                           // RF has charge at 1000 units per liter (gets multiplied later)
        @volume += #$/RESOURCE[MonoPropellant]/maxAmount$  // searches for previous amount of MonoPropellant to use as volume
        @volume *= 5                                    // multiplies by 5
        type = ServiceModule                            // this is best type to use for RCS tanks, also can hold LS resources
        basemass = -1

    Now, this code puts a 135 l service tank into a tiny Mk1 pod (which originally has 50 EC and 10 Monoprop). Ain't it a bit too much? The old value was 50 l, since the old multiplier for EC was 0.0002, which didn't make much sense neither but virtually nullified EC. 

    Imagine you have a pod with only 50 EC in stock. What you want to do is to have the same amount of EC available after adding a service tank to hold it with Real Fuels, right? So volume multiplier should be an inverse of utilization. You use 7 for EC, so it should be 1/7 ~= 0.143. 

    Anyway, for some crazy reason with the latest RF I get not 135 l but 475 l tank inside Mk1 pod. If you have any idea where these extra 340 l may come from, I'd grateful for suggestions. I'm pretty sure it's not from your configs but I've already checked all the other suspects and found nothing that would tweak resources or volumes before RF.  

    EDIT: NVM the last part. I think I'll change that part entirely to 

        name = ModuleFuelTanks
        volume = #$/CrewCapacity$
        @volume *= 50
        type = ServiceModule                            // this is best type to use for RCS tanks, also can hold LS resources
        basemass = -1

    so per every crew member in a command module there will be a personal 50 l tank for essentials and that's it. I'll see how that will work for me. 

  11. On 6/27/2020 at 12:13 PM, severedsolo said:
    • Kerbals can now retire and will be assigned a random retirement date on first load. They can delay their retirement date by running missions (Credit for the idea to the RP-1 team, code is my own)

    Huh, I was literally about to propose this, since I liked this feature in BARIS (-nauts that don't fly get frustrated and leave the program eventually). Maybe you could add to this random events like "Jeb Kerman is tired of idleness and expects to get an orbital flight within next 120 days or will get -20% Morale drop". You could actually replace retirement date with Morale system, since it's already here and serves more or less the same purpose. Say each Kerbal looses 0,5±0,4% of Morale per day when on Kerbin and gains 5±4% per each day in space. 

  12. Hey, 

    I thought I'll share my take on Restock Plus' Pug with you, maybe you'll like it. Here is a config I use:

    @PART[restock-engine-125-pug]:FOR[RealFuels_StockEngines] //Pug
    {
    
      @mass = 0.12
      @cost = 118
      %entryCost = 590
      @maxTemp = 1450
      
      
      @MODULE[ModuleEngine*]
      {
        @name = ModuleEnginesRF
        @maxThrust = 30
        @heatProduction = 88
        @atmosphereCurve
        {
          @key,0 = 0 298
          @key,1 = 1 106
        }
        !PROPELLANT[LiquidFuel] {}
        !PROPELLANT[Oxidizer] {}
        !PROPELLANT[MonoPropellant] {}
        PROPELLANT
        {
          name = MMH
          ratio = 48.782129
          DrawGauge = True
          %resourceFlowMode = NO_FLOW
    	  %resourceTransferMode = NONE
        }
        PROPELLANT
        {
          name = NTO
          ratio = 51.217871
          %resourceFlowMode = NO_FLOW
    	  %resourceTransferMode = NONE
        }
      }
      
      MODULE
      {
        name = ModuleEngineConfigs
        type = ModuleEnginesRF
        techLevel = 1
        origTechLevel = 1
        engineType = O
        origMass = 0.12
        configuration = MMH+NTO
        modded = false
    
        CONFIG
        {
          name = MMH+NTO
          maxThrust = 30
          heatProduction = 88
          PROPELLANT
          {
            name = MMH
            ratio = 48.782128919391745
            DrawGauge = True
            %resourceFlowMode = NO_FLOW
    		%resourceTransferMode = NONE
          }
          PROPELLANT
          {
            name = NTO
            ratio = 51.217871080608255
            %resourceFlowMode = NO_FLOW
    		%resourceTransferMode = NONE
          }
          IspSL = 0.9600
          IspV = 0.9500
          throttle = 0
          ignitions = 0
          ullage = false
          pressureFed = true
          IGNITOR_RESOURCE
          {
            name = ElectricCharge
            amount = 0.3
          }
          
          
        }
        CONFIG
        {
          name = Aerozine50+NTO
          maxThrust = 30
          heatProduction = 88
          PROPELLANT
          {
            name = Aerozine50
            ratio = 50.32974661575842
            DrawGauge = True
            %resourceFlowMode = NO_FLOW
    		%resourceTransferMode = NONE
          }
          PROPELLANT
          {
            name = NTO
            ratio = 49.67025338424158
            %resourceFlowMode = NO_FLOW
    		%resourceTransferMode = NONE
          }
          IspSL = 0.9600
          IspV = 0.9500
          throttle = 0
          ignitions = 0
          ullage = false
          pressureFed = true
          IGNITOR_RESOURCE
          {
            name = ElectricCharge
            amount = 0.3
          }
          
          
        }
      }
      ignitions = -1
      ullage = false
      pressureFed = true
      IGNITOR_RESOURCE
      {
        name = ElectricCharge
        amount = 0.3
      }
    
      !RESOURCE[LiquidFuel] {}
      !RESOURCE[Oxidizer] {}
      !RESOURCE[MonoPropellant] {}
      !RESOURCE[SolidFuel] {}
      !RESOURCE[XenonGas] {}
      MODULE
      {
        name = ModuleFuelTanks
        basemass = -1
        volume = 200
        type = ServiceModule
        dedicated = true 
        TANK
        {
         name = MMH
         amount = full
         maxAmount = 48.782129%
        }
        TANK
        {
         name = NTO
         amount = full
         maxAmount = 51.217871%
        }
      }
      
      
    }

    What are the big differences:

    1. it's a pressure fed engine with unlimited ignitions and no ullage.

    2. it has it's own 200 l fuel tank (these 6 spheres - I imagined them to be helium pressurized bladder tanks).

    3. it won't draw fuel from other tanks. 

    Pros: in early game ullage can be a huge problem as RCS comes much later. Such engine works perfectly as Mk1 pod retro pack and later as descent engine for light lunar landers in both stock and JNSQ. Unlimited ignitions and no ullage make it a very versatile and interesting option and not just a crappier Terrier. Limited fuel capacity prevents cheating. Or does it....

    Cons: while it won't draw any fuel from other tanks it's still possible to transfer resources once the 200 l tank gets empty.  Neither %resourceTransferMode = NONE nor %transfer = NONE work for me (I guess they are not part of PROPELLANT node). With just 30 kN of thrust it won't really work well with heavy vessels but still...

    If you know a way to block fuel transfer, I'd love to know it. My Pug would be complete then. I also noticed that it still says Draws evenly... in the description. I guess it gets the flow mode from the RESOURCE definition, but it respects NO_FLOW setting anyways. 

  13. 4 hours ago, ValiZockt said:

    It makes it so much more challenging and fun.

    Huh, it makes it literally unplayable for me. Maybe realistic masses spoiled me but with Tier 2 parts I simply cannot build an orbit capable rocket within 18 t limit. The best I was able to do was about 3000 m/s ΔV (vacuum), which is about 400 m/s ΔV short of what is needed just to get to the orbit. And I need to return too. I don't remember stock KSP being so hard...

  14. Quote

     If you play with Stock Scale, go to Kerbal Space Program/GameData/RealFuels/RealSettings.cfg and set useRealisticMass to false, if you play with JNSQ (or everything bigger than 2.5x the size of Kerbin) leave the setting as it is.

    And what's the difference between these two? I've just realized I played stock scale with realistic mass enabled all this time.

    BTW, one thing you could update is Electric Charge utilization (this needs to be addressed in Reafl Fules too). 1000 is waaaay to much. Mk1 pod gets 50 l internal service tank - you can put 50.000 EC in there!! This makes batteries, fuel cells and even solar panels obsolete from get go. I personally use 4. This allows for an equivalent of two Z-100 batteries in the pod. 

  15. 11 hours ago, GJNelson said:

     

    Actually, I like it in the "Start" tech node. I use it as the control core for my early unmanned launches at the start in career mode. If you could leave a copy in the "Start" tech node, perhaps with limited capabilities that can be expanded on through development and research, I would love it. Having an unmanned control core at the start makes the early historic unmanned launch vehicles possible in game without any other mod needed.

    The Science Container / Experiment Return Unit, is what I'm talking about. It's a part covered by Restock +. It is currently included in the "Start" tech node. It makes a great unmanned probe core for starting in career mode.

    I second that. 

    Ideally I'd see in it's place some very basic conical 0.625 part (say just 3 EC and internal antenna), so one could complete some early missions with sounding rockets made of those sweet 0.625 SRBs. 

     

  16. @severedsolo - a little update as this may be a Contract Configurator bug after all. Today I decided I'll play with CC and Exploration Plus. When configuring the game I thought that even though I've installed Exploration Plus, why not disable it and enable stock exploration contracts and give it a try. And lo and behold, stock contract worked!. So i thought that maybe by doing this I unlocked something locked by CC earlier (even though it should be near impossible taking into account that I made a clean install of KSP and all of the mods since then). So I uninstalled both CC and E+ but the bug reappeared. Then I installed CC again and thought that maybe it will fix the bug even if I won't use it to enable any additional contract packs. But it didn't. With or without E+ I still have the bug and am unable to recreate this situation when it was gone for this one time. 

    But this makes me think that it indeed is caused by CC, although I dunno how this could be possible, unless CC files or files modified by CC are kept somewhere outside the KSP folder. 

    EDIT: I was kinda surprised that right after installing CC and E+, E+ was enabled in CC settings menu and stock exploration contract was disabled. I'm pretty sure that when I installed both of them for the first time a few weeks ago, I had to enable E+ manually. Do you know if CC should enable E+ and disable stock by default? 

  17. 6 hours ago, severedsolo said:

    I've heard this before on the Kerbalism discord

    If yesterday - it was me. 

     

    6 hours ago, severedsolo said:

    stock contracts or Exploration Plus?

    Stock. BUT... When I installed Bureaucracy a few weeks ago (amazing mod BTW, thank you very much for it. Are you an old Buzz Aldrin's Race Into Space player by any chance?) I did install Contract Configurator and Exploration Plus, as suggested. I switched off stock storyline contracts but this Gather Science from Kerbin kept appearing anyway. I was a little surprised but considered it a bug and just ignored it. I noticed the problem I have now after uninstalling both Contract Configurator and Exploration Plus. Yesterday I did a new clean install of KSP and new clean install of all mods - and the problem is still there. 

    The only strange thing with this clean install of KSP was that it installed with my saved games (and I deleted KSP folder before installing). So maybe it wasn't that clean after all and Steam used some files backed up in the cloud and they cause the problem. This would mean however that Contract Configurator messed something up pretty badly, which I doubt is possible. 

    6 hours ago, severedsolo said:

    2) Log please

    In a few hours.

     

    6 hours ago, severedsolo said:

    3) Is it reproducible every time?

    Yes. 

    6 hours ago, severedsolo said:

    4) Have you eliminated other mods? Ie tested with just Bureaucracy, Flight Tracker and Kerbalism (and dependencies obviously).

    Mostly. I think I finished yesterday with Kerbal Construction Time and Scrap Yard also installed. I'll let you know in a few hours. 

     

    EDIT:

    @severedsolo

    logs here. I can confirm that Bureaucracy, Flight Tracker and Kerbalism + dependencies ONLY (and Breaking Ground) result in a bug. If I remove Flight Tracker from this combo the bug is gone. Logs come from a buggy session with Flight Tracker. I just picked the contract, built Mk1 pod, recovered Crew Report and got back to KSC. Then quit the game. 

  18. Hi, 

    I think a bug appears when Bureaucracy, Flight Tracker and Kerbalism are installed together. When they meet, the very first contract, Gather Science from Kerbin, does not register recovered or transmitted science. It can't be completed by cheats - it immediately reappears. And without it completed it seems no story line contracts beyond Orbit Kerbin get generated.  Bureaucracy & Flight Tracker without Kerbalism don't cause trouble, Kerbalism without Bureaucracy & Flight Tracker does not cause trouble AND... Kerbalism & Bureaucracy without Flight Tracker also work fine. 

    I noticed that Bureaucracy seems to work without Flight Tracker. What does it need Flight Tracker for? Because adding Flight Tracker to these two causes this one tiny but very, very annoying problem. 

×
×
  • Create New...