Jump to content

Xavven

Members
  • Posts

    1,114
  • Joined

  • Last visited

Reputation

989 Excellent

1 Follower

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I'm doing the opposite. There are a couple things I haven't done in KSP 1. I feel like once KSP 2 comes out, I'm not going to have the motivation to go back to KSP 1 and complete them. Now's the time to strike off the bucket list!
  2. Oh, I haven't made a SSTO since beta. What's fixed about it?
  3. Air intake "spamming" isn't cheesy. It's an appropriate and logical solution to flying at high altitude with low air pressure.
  4. Rather than a gentle gravity turn where you are thrusting prograde and using throttle to adjust trajectory, I prefer to have 1.8+ TWR and aerodynamic control surfaces to aggressively accelerate off the launchpad and fly with an angle of attack to aim for 45° and 1000+ m/s speed by 25,000 altitude. I want to get the heck out of the atmosphere so that when I drop my first stage, I'm at 40,000 m altitude and don't have to worry about the aerodynamic stability of the middle and upper stages.
  5. The opposite is usually true. When devs stop updating the base game, generally it's the start of the golden age of mods. It's easier to mod because you don't have to worry about the base code changing and breaking your mod. More time is spent adding features to the mod and less time is spent keeping it working with new base game versions.
  6. Just echoing this. One of the other games I play is Falcon BMS. It's based on a Microprose game from 1998. The code was released and a team of modders have been tweaking it ever since. Its most recent update was less than 1 month ago. It is vastly different from its original form. Regarding the main topic, I don't mind waiting until 2023 at all. I still have more things to do in KSP 1 and will be enjoying it more this year.
  7. Aaaahh, brilliant and simple! Thank you! Damn, why didn't I think of that? A total workaround to the original issue I had-- not being able to weld a fuel duct to different craft. Just make them 1 craft, temporarily. Thank you! Great! Just the kind of simple mod that removes the requirement to do a klaw workaround to get a hose connected, without adding other stuff I don't want to mod in. Thank you! To all: what a wonderful community. In less than a day I got multiple great solutions. I'm excited to get my surface base going now! Another big thank you to everyone.
  8. Ah, yes, good questions and I should have specified. I'm playing vanilla/no-mods and with the restricted fuel transfer rules on. Fuel cannot transfer through the klaw part with the restriction option enabled. Yeah, I had immediately thought of KAS for hoses, and in my unmodded game tried to get an engineer to weld an External Fuel Duct pipe between two crafts, and found out the base game doesn't let me do that.
  9. All my IRSU logistics designs to date have involved landing a whole refinery with drills, mining and refining on the surface, then returning everything to orbit and docking with the craft to be refueled. This works on low gravity bodies, and I like its simplicity of implementation. But on heavier bodies with higher dV requirements, hauling the drills and refinery to orbit and back (and empty ore tanks) eats into my total fuel yield. So I've been considering having a permanently grounded refinery and a separate fuel delivery lander, but my major logistical hurdle is the fuel transfer on the ground. Landing precisely on a docking port is quite tricky and maybe a fun challenge, but fuel-consuming, so I don't want to do that at all. It is within my abilities to land very close by (within crane range) and have a crane arm connect, but I'm concerned about dealing with uneven ground and therefore having to have a robotic arm or crane that articulates in 5 axes, potentially with a counterweight, and that can fold up nicely into a fairing. Doable, but I feel like it's maybe overly complex? I've thought of having a wheeled fuel-truck rover act as a middleman between the refinery and the lander, but that has downsides too, and the same issue of having to line up docking ports on the surface at predefined heights and angles. Maybe that approach is more complex, actually? So I'm looking for suggestions. How have you grappled with this problem?
  10. I agree with this, basically. I use all sorts of different engines on stages depending on need. However I will say that there are some engines that come into my builds quite often, and others that seldom fit my purposes. Spark, Terrier, Cheetah, and Poodle I use often on upper stages, landers and probes, or even sustainers. Ant, Spider, and Twitch I hardly ever find a use case for. Bobcat and Skipper see a lot of use as a light first stage, or a sustainer engines. But Skiff seems to occupy this strange niche case that hardly ever comes up, and the combined cost of the decoupler and the engine is usually as much or higher than simply using a Skipper with a larger fuel tank instead on a $ per DV basis. Skipper and Twin Boar are great first stages, with the latter being overkill for many of my builds but it's just too cost effective compared to the alternatives. And clustered Skippers make great first stage heavy lifters until bigger engines are unlocked in the tech tree. I hardly ever have a use for Thud. Huh, if I had to pick one, I'd pick Twin Boar. It just has SO much thrust and is so cheap that it had wide applications as a first stage for payloads big and small. I often find that I don't need something that powerful for my payload, for example it is giving me a TWR of 2.8, but when I price out a more tailored multi-stage lifter with engines that keep the TWR more in the 1.5 - 2.0 range, it ends up costing the same amount or more. Frankly I think the Twin Boar is just underpriced. But we don't need perfect game balance. Sometimes in real life you get a design that just dominates because it's effective, reliable, strong, and cheap. I like to think of the Twin Boar as that magic combo that some Kerbal rocket scientist devised.
  11. If it's an orbital fueling station then I put a boom on it that branches off to all three sizes so any ship I conceive of now and in the future can use it. Generally I use jr. on probes, standard on most manned ships, but occasionally I build big ships too with sr. I tried standardizing on jr. for all refueling, but quickly found out that even during refueling you want a solid, non-wobbly connection, so bigger ships need bigger ports.
  12. I agree. I'm sure it depends on personal build style, but I tend to put smaller landing struts on my creations, and in past versions I've had to manually set the struts to max strength and damping. In 1.12.2, maxing them turns them into rigid beams of diamond. They also seem to have less ground grip and my landers slide down even slight inclines much more easily.
  13. I was looking to say the same thing effectively. I'll add that I'd like us to have blurry/low-res textures for planets and moons in the home system for starters, to simulate the limitations of what you can see from ground-based telescopes with the Kerbal equivalent of circa 1960's Earth technology. Maybe slightly better textures if the player launches a space telescope to Kerbin orbit, but you don't get good textures until you send a probe into its SOI. For exoplanets, we should only have as much information as using the transit method ala the Keppler space telescope would give. Meaning, rough estimates of size and density, and only if they orbit their star in the viewing plane. No textures at all, and if they are small enough we shouldn't know they're there until a probe is in that star system.
  14. Nothing we say here is changing their minds, but to help you understand, software development is a business. They aren't going to make enough money bug fixing KSP 1 at this point. KSP 2 is very likely to be profitable, on the other hand.
×
×
  • Create New...