• Content count

  • Joined

  • Last visited

Community Reputation

128 Excellent

1 Follower

About PocketBrotector

  • Rank
    Colonist Wannabe
  1. Yes, if you just stack a bunch of LH2 tanks on top of a Nerv, you get a max dv of about 10.5km/s. However, if you just stack a bunch of LFO tanks on top of a Poodle, you get a max dv of about 7.3km/s. So even by the arbitrary zero-payload metric, there's some improvement over chemical engines. More to the point, you may have noticed that Kerbal Atomics adds a variety of new nuclear engines, most of which feature significantly higher Isp - sometimes dramatically so. In stock KSP, the Nerv is simply the only engine in its class, but with KA it's much more of a starter model. And yeah, less dense fuel means worse mass ratio for your tanks. I believe LH2 tanks do get a discount on mass compared to LFO tanks of the same volume, but it doesn't cancel the fact that the same volume of LH2 is much lighter.
  2. Just installed Snacks a short time ago and I've been enjoying the straightforwardness so far. Thanks for taking on the maintenance and improvement! As this appears dead simple to support in other mods, I've been writing patches to extend compatibility. I presume that the compatibility patch for a particular part pack should be distributed with the pack, rather than submitted for inclusion with Snacks itself? Wanted to make sure before I start making any pull requests. I've noticed some surprising behavior with the recyclers (that may or may not have been discussed above.) I was expecting the 40% efficiency rate to mean that Snack output would be reduced to 40% of Soil input, but it appears that both input and output are slashed to 40% of their cfg values. So when I launched a scientist in a hitchhiker and turned on the recycler, he was able to eat indefinitely as the recycler was still 100% efficient. I'm guessing this is not intended? If nothing else, it makes a lot of the estimates in the life support window inaccurate. Also, I think I noticed some notifications that kerbals were starting to go hungry while awaiting rescue. The changelog mentions that kerbals marked "unowned" are skipped over when Snacks checks for starvation, but in my experience KSP is not very consistent in how it marks contract-rescue kerbals - I took a look in the sfs and some are marked "crew" instead of "unowned". I can provide a copy of the save if it helps; perhaps it would be better to skip over kerbals in unowned vessels as well?
  3. Is there anywhere this is documented? The only place it's used in stock is in the ore tanks, which just jettison 100% of all resources. Would be handy to know how to use this feature for e.g. life support multi-resource containers, so that we could jettison some fraction of waste products without tossing all of the snacks out as well
  4. Just for clarification, are you saying that it's already possible to use MM to change the folder path that FE sees for a given part? (I'm not aware of such a feature but it's possible I've missed something in the MM documentation.) Or is it more that MM-created parts are insurmountably difficult to detect via existing FE folder checks? Thanks for everything related to FilterExtensions, by the way - this mod is pretty much essential for playing KSP with multiple part packs installed.
  5. I am wondering about an edge case I've encountered... ModuleManager allows us to create additional parts using the +PART syntax. For example, Extraplanetary Launchpads has the following: +PART[crewCabin]:AFTER[Launchpad] { @name = ExSurveyStation @title = EL Survey Station //adds EL functionality here } This is fine on its own. But in my experience, FilterExtensions will interpret this part to be in the Squad folder, not the ExtraplanetaryLaunchpads folder. So it will show up in the Squad category rather than the EL category. Is there a way to change this behavior? In my case, I'd like to duplicate/modify a few of the KIS containers to hold Snacks, but if I do that I'd want them to show up alongside the native Snacks containers rather than in the KIS category. Is this achievable using the +PART MM syntax in conjunction with FE folder checks? Or would I need to copy/modify the whole part cfg to the appropriate folder in GameData to get it to pass through the desired folder check?
  6. Do you have any release plans for the RTG replacement assets you showcased on Reddit?

    1. Beale


      Look to the skies, moon-brother.


      (Yes, you will see it released soon enough, but there's other work to be done in the meantime).

  7. Yes, thanks.
  8. I voted for the big (preferably 3.75m) thrust-optimized GCNR and the mini 0.625m engine, partly because they'd be differentiated on size from the current offerings. Also, the idea of a nuclear-driven launch vehicle is intriguing and to my knowledge has not been represented in KSP mods to date. I was unable to open the DC-X SSTO PDF, so I went with my gut instinct of "bigger must be better."
  9. Hey, thanks for this neat mod. Couple of comments/questions... Do the nodes on the fuel tank and heat shield seem oddly placed to anyone else? They work fine with each other, but if any other part is stacked with them, they will clip through or leave large gaps. I like look of the vernier engines - is there any chance of a five-way version that has the missing top-facing nozzle? I know it starts to get away from the inspiration material, but it would provide an aerodynamic-looking LFO-based RCS port suitable for both upper and lower stages - there aren't many mods that offer that combination of qualities in a part.
  10. Thanks all. Added license info to the readme and version info to the topic name. CKAN may come later; I haven't used it before so I'll have to read up on the metadata process. On balance... As I see it, the stock antenna progression is balanced by mass and bulk. More advanced antennas come later in the tech tree and are heavier, which makes them more significant as a payload; and they're bulkier, requiring wider rockets to launch. Taken together, the mass and bulk also means that relays are more likely to be used on appropriate craft (dedicated sats or a CSM) and less likely on unconventional relay craft (landers, rovers, planes, etc.) Each successive antenna is about double the mass of the previous, and one step up in diameter (.625, 1.25, 2.5m) which means they fit neatly into the truss system in fairings of larger launchers (1.25, 2.5, and 3.75m respectively.) This mod extends the progression as simply as possible, which is appropriate as the KSP mod ecosystem provides both the need (larger solar systems) and means (bigger launchers) to do so. So the antennas continue to double in size and grow steadily more powerful to reach more distant destinations, but they need bigger and bigger launchers/fairings to accommodate them (5m, 7.5m, and 10m are all more or less community standards). Big launchers probably aren't uncommon among the large-solar-system crowd, but I'm sure there are some who don't want to use them. And in any case, the progression to larger launchers probably isn't perfect; a 3.75m stack is already overpowered to get a trio of RA-100 satellites to orbit. So the compact antennas are offered as an alternative; they deploy to the same size but fit in a much smaller space for launch. (Communotron 88-88 is roughly 8 times wider when deployed than stowed, so e.g. a version that's only 1.25m wide stowed is easy to launch but expands to 10m deployed). They're the same mass, and when deployed they're even the same bulk, so they're balanced using the same progression as stock - they just don't require oversized launchers. This scheme has the advantage of leaving the stock antennas untouched, so that you don't have to mess with the balance or challenges associated with setting up a relay to e.g. Duna or Jool just because you install OPM, etc. @Snark summarized this pretty well over on the JX2 thread - offering bonus performance on existing alternatives tends to trivialize stock-scale relay networks without offering any more depth to make up for it. If the bonus performance is implemented as a PartUpgrade, stock balance is still tossed out - it just takes a bit longer to happen. Also, the stock tech tree only really has one node, Large Probes, available to extend the antenna progression, and CTT doesn't add any more nodes in that line either - so more powerful antennas ought to be differentiated by mass and bulk, as there's no room left in the tree to differentiate by technological advancement.
  11. It's the combined and updated version of everything I've provided to date (and looking back, I think I'm the only one who's been providing patches). So if you just have DIRECT itself and this, you'll have everything I have. If you want to use LH2, you'll want CryoEngines; and if you have CTT, you'll want the DIRECT_CTT patch I linked to above. EDIT: combined all support patches and moved them to here
  12. I have added some interstage nodes (with accompanying truss) to the DIRECT fairings, with the help of @IronCretin's fairing node calculator. The combined maintenance patches I've provided can be found here, with a Community Tech Tree support patch here. EDIT: Combined patches and moved to here
  13. New release on GitHub: Okay, but the entire stock system is only about 1AU in radius... I suppose estimating Kerbal interstellar distances are left as an exercise for the modder.
  14. *pushes up glasses* But clearly 60m would be size11... Size Diam Increase 00 0.3125 0 0.6250 0.3125 100% 0p5 0.9375 0.3125 50% 1 1.2500 0.3125 33% 1p5 1.8750 0.6250 50% 2 2.5000 0.6250 33% 3 3.7500 1.2500 50% 4 5.0000 1.2500 33% 5 7.5000 2.5000 50% 6 10.0000 2.5000 33% 7 15.0000 5.0000 50% 8 20.0000 5.0000 33% 9 30.0000 10.0000 50% 10 40.0000 10.0000 33% 11 60.0000 20.0000 50% On a more serious note, thanks for your bulkheadProfiling work. It's interesting to see how usage drops off in progressively larger sizes - 3.75m capsules aren't uncommon, which means there are some mods with 5m launchers, but not very many with 7.5m, and @NecroBones is the only person I know of who's working on 10m+ packs. As that's approximately the size of the largest rockets ever successfully flown in the real world, hopefully we won't need to bust out size9+ profiles anytime soon.
  15. Should be pretty easy with a 10m launcher, of course, but kind of annoying otherwise. At any rate, I suspect we're close to the point at which it doesn't make sense to keep scaling up stock dishes. If we extend the current progression another four steps, we'd have a 40m dish weighing 83 tons with a range exceeding 7.8 quadrillion meters... which is still shy of the interstellar relay from Kerbol StarSystems, apparently.