Jump to content

Domfluff

Members
 View Profile  See their activity

  • Posts

    173

  • Joined

  • Last visited

 Content Type 

Everything posted by Domfluff

  1. Domfluff
    Going by Zubrin's paper, a fair percentage of the propellant is Uranium (more than 17 tons on his example Titan trip) - that's going to make refuelling this extremely expensive and awkward for ISRU, since that will need processing. The cooling requirements are going to be massive as well (I forget precisely how this is modelled in High Frontier - 5 therms of cooling? 1 therm was 120MW, but I can't remember whether HF models this linearly or on a log 2) Obviously the NSWR would fit in with a mod like DSEV. Obviously a Nertea-made advanced propulsion system pack would be unbelievable, but the chap has limited enough time as it is
  2. Domfluff
    I'm not sure it can be obsolete when there's nothing to replace it Balance is a slightly weird concept when it comes to a single player sandbox, but to fit it in the progression this has the same issues as things like Roverdude's Orion mod (although a NSWR is an order of magnitude more powerful). That feels pretty "balanced" to me, in that it appears fairly early in the CTT, but is really expensive and is awkward to refuel - the NSWR rocket won't appear as early, but both of the caveats can very reasonably apply to Zubrin's insanity above. "Zubrin's Insanity Above" would be a great name for any ship using it, of course. I can definitely understand why you would see this as apart from the other nuclear engines. This perhaps belongs more with the likes of a Fusion reactor (and your previous thoughts about why Fusion reactors/EM drives/whatever aren't in Near Future are entirely valid, I think). That said, currently I'm fairly happy with having Roverdude's Albecurrie drive as the top of the tech tree - everything up to that point is fairly plausible, but it feels okay from a game perspective to break things if you've gotten that far. Having a late game power system (or several, if the intention was to really dive into the whole "GW Thruster" thing) that make preceding ones irrelevant isn't necessarily the end of the world here, and could even feel like a justified reward.
  3. Domfluff
    TAC is older than USI Life support, and was definitely the best choice for a while. It's nice for Realism Overall saves, since the resources are real, meaning that it's easier to convert from genuine NASA numbers into a KSP game, and mods with realistic/detailed ISRU can do their things more directly. That said, the Hab/Home mechanics of USI add a huge amount to the game. Hauling enough supplies to Duna to survive until the next transfer window was difficult to begin with, now the actual living space of the base needs to be thought about and planned for. The softer default settings are also "stock-like" in design intent, since after the initial launch there is always a chance to rescue a mission failure - with the default settings you can always launch rescue missions or whatever if needed, and I think there's something to be said for that. You can clearly configure everything and turn it off, but USI Life Support is probably the closest to what Life Support would look like if it were part of the stock game.
  4. Domfluff
    On the Ike pod at least, burning RCS forwards (H) only activates thrusters on one side, resulting in spinning. Gilly and Minmus pods don't seem to have working RCS yet.
  5. Domfluff
    These look awesome. I'm currently using your older pods in my career, since it's nice to have "advanced" command pods on the tech tree, with integrated RCS and engines. The diameter is pretty awkward (and I'm not sure about the texturing on the adapters either) - it seems an odd choice when 3.75m would seem to work fine, and still fit the role as an advanced pod for mid/late game careers.
  6. Domfluff
    This is his work-in-progress album. It's really impressive, but I do wonder what the performance hit is going to be with the raycasting. The fundamentals sound pretty great to me (and should work well with his advanced propulsion, which is obviously the point).
  7. Domfluff
    Habitation is a massive part of USI:LS! In fact it's the factor which makes it different from TAC:LS, and really what pushes it over the edge. It's the one missing part that makes manned missions to Duna difficult in the mid game - otherwise it's fairly trivial to lock them in a one man can and send them wherever they need to go. I do think it should be enforced by default, mind you, and having some more habitation-centred parts (particularly inflatable modules) would make that difficulty curve a bit smoother. I'm curious as to whether you'll eventually implement radiation, and how that compares with Nertea's line-of-sight concept - his does sound like he's using USI:LS as inspiration (the intent is that they become tourists), and the need to have shadow shielding and the like is pretty exciting.
  8. Domfluff
    @PART[Malemute_ExpandingDockingPort]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true passableWhenSurfaceAttached = true } } @PART[Malemute_RoverCab]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[Malemute_RoverCrewCab]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[Malemute_RoverDockModule]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true surfaceAttachmentsPassable = true } } @PART[Malemute_RoverScienceLab]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[Malemute_RoverTail]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[Malemute_RoverTankLong]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[Malemute_RoverTankShort]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } Connected Living Space config. (Just saw there was already a Pull Request for this on Github, sorry. That one is a little more comprehensive. I just found myself needing one and threw it together).
  9. Domfluff
    Seems to work perfectly. Obviously you're running into the various stock problems with electric charge and high time warp - at the higher time warps it will show huge numbers, and at the highest level just the default value, but they're performing correctly (e.g., it may only show 1 day of electric charge on the life support panel and 0 EC on the resource panel at maximum warp, but that one day lasts until the reactor gives out, at which point they die as expected.) (Tested with stock solar panels, your reactors and the reactors from NFE)
  10. Domfluff
    Cheers, that's excellent.
  11. Domfluff
    Just trying to get something clear in my head with regard to recyclers (important when the radial one turns up). "If you have multiple Recyclers running, their effects are cumulative. The vessel-wide consumption reduction is capped by the most efficient recycler - so if your most efficient Recycler is a Science Lab, you can't reduce your Supplies consumption by more than 70%, no matter how many Recyclers are running. " Let's say you had a Science Lab (Capacity: 5 Kerbals, 70% recycler) and five radial recyclers (Capacity: 1 Kerbal, assuming a 25% recycler). Does "cumulative" in this sense mean that the total is a 70% recycler, with a ten Kerbal capacity? If not then how does this work in combination? (Incidentally, finally sat down last night and designed Duna Direct with regards to hab/home time. If we end up with inflatable modules then this will help a lot, but out and return hab times can be accommodated with a Hitchhiker pod + Cupola, and the surface stay with four of the inflatable surface hab modules).
  12. Domfluff
    Any time I've considered Orion within a Career save, it's always been the price tag that's made me balk at it - the commitment that's required to launch the thing means that the return on investment has to be significant, which means making a larger spacecraft (closed loop life support, many years of hab time), which makes it bigger and more expensive, etc. etc. I forget how expensive the last reference mission I strung together was, but it was at least 8 million funds. To me that suggests that it's about right - it's accessible technology, but the caveat is the will to do it, and the risk if anything goes wrong. Pranging it on the side of an asteroid does horrible things to your no-claims bonus. Clearly it's easy to grind funds in KSP if you really want to, but it does take effort and time to do so. Mining valuable resources is similar.
  13. Domfluff
    In terms of "where to go from here?", the obvious steps if at all possible would be to have controllable parachutes for gliding, and from there ultimately the Rogallo wing for capsules, which is something which still doesn't exist.
  14. Domfluff
    I'm not even sure where I'd request this (since I can't find a github repo for the Kontainers themselves), but it did occur to me idly that if the cargo Kontainers (the KIS ones) had a "hollow" option, with or without an animated door, they could be used to deliver cargo in a standardised manner - i.e., building the rover (or whatever), and docking it to the inside, landing it and driving it out. Obviously the functionality already exists in stock since the Cargo bay exists, but I could see the use of a standardised delivery system, with airbags/rockets/parachutes/whatever.
  15. Domfluff
    Awesome, and a form factor which will slot into space stations/launch stacks easier. Cheers!
  16. Domfluff
    Awesome. Any plans for the specs on that? How does it slot into the overall progression?
  17. Domfluff
    Oh, I've been doing that, and barely grazing the atmosphere. Even with a standard LKO recently, it immediately heats up to about 75 percent tolerance, and fluctuates between 50 and 75 percent, with the part far hotter than anything else on the craft (this is currently with stock aero). It's certainly usable as-is (with careful management it doesn't explode), but the result doesn't seem plausible, or at least intuitive. Fully prepared for this to be a problem with my expectations, mind you.
  18. Domfluff
    What did you change to fix it? The heat values can be altered in the part file, but I'm curious as to what is a sensible value (or even what the problem is), since the container does seem to be heating up far faster than it should. Was there a change to conduction in this version?
  19. Domfluff
    Speaking of the vision of the mod - I'm currently seriously digging into UKS/USI Life support since the addition of Hab/Home times, and finding it suitably difficult to plan a Duna mission without the advanced parts (Zubrin's "Battlestar Galactica"). On DasValdez's stream, you produced a KERB module, which was a 1.25m part that expanded to roughly the size of the Hitchhiker storage module (so, 2.5m). I'm going to assume that the game effect would be similar to that of a Hitchhiker module, in that it's one of the most efficient ways to add Hab time to the craft. Are there plans for integrating the KERB into USI:Life Support? Equally, a 1.25m-> 2.5m could be paired with 2.5m -> 3.75m and a 3.75m -> 5m part with correspondingly greater facility, so I'd guess that the intent would be for larger parts as well?
  20. Domfluff
    I meant that there are two methods of calculating transfer Windows in KAC, one seems to be fine (I've just launched three missions to Duna with it). There's a "model" option which seems to be okay, and a "formula" option which is badly off. It's possible I may just have been lucky.
  21. Domfluff
    The transfer windows "model"-mode is fine, it's just the calculations which are wrong. Obviously this won't help you if you are trying to use anything which changes the solar system. Otherwise, yes, Alarm Clock seems to be working fine.
  22. Domfluff
    The consequences of the hab and home times are configurable in the .cfg (same as the effects of being out of supplies). You can make it lethal, but (last time I checked) the default was for hab and home to have no effect. I usually set supplies to lethal and hab/home to "mutiny" (they're tourists, and they blow something up).
  23. Domfluff
    Awesome, thank you
  24. Domfluff
    You end up with the exact same results with Firespitter and IFS - the MM patch is loaded (you can see the texture configs in the VAB part menu), but no switching is possible. (Again, although there's a conflict, this is by no means a flaw or "bug" with Fuel Tanks Plus/Color Coded Canisters - these are working fine by themselves, it's just trying to run a combination of mods which is hurting it. Your CCC, FT+ and SpaceY mods, Roverdude's suite and Nertea's packs have been the core of my mod list forever, but that's not your problem by default.)
  25. Domfluff
    Mods used: https://github.com/blowfishpro/B9PartSwitch/releases (Current version of B9partswitch - replace the one bundled with Cryo Engines) https://github.com/ChrisAdderley/CryoEngines/releases/tag/v0.3.0 (Release of Cryoengines, with an earlier version of B9 part switch) https://github.com/sarbian/ModuleManager/releases/tag/v2.6.23 (Latest version of Mod Manager) The spacedock versions of Fuel Tanks Plus and Color Coded Canisters KSP 1.1(Win 64) Which leads to Z-fighting as expected (although B9 fuel switching is active): With either Firespitter or IFS installed (same behaviour with either or both): (e.g., http://mods.curse.com/ksp-mods/kerbal/237233-interstellar-fuel-switch) As I said above though, your mods are working fine in isolation, so this doesn't have to be "your problem". It's worth knowing that there's a conflict though. With the previous release, I was able to get around this by removing IFS and deleting the fuelswitch MM patches. This allowed for B9 to take over the fuel switching, and your mods would handle the texture changes.
×
×
  • Create New...