Jump to content

Leganeski

Members
  • Posts

    104
  • Joined

  • Last visited

Everything posted by Leganeski

  1. Keeping the RAPIERs attached decreases the range of the plane somewhat, but it allows you to make multiple trips without having to rebuild it each time. Once you set up some mining infrastructure, you could even take the same plane to Laythe!
  2. Definitely not during launch. NERVs are much less efficient than RAPIERs in air-breathing mode, so the purely air-breathing stage of the ascent should last as long as possible. I usually turn the NERVs on when the RAPIERs drop below about 4 m/s2 of thrust on their way to flaming out. The exact altitude depends on the ascent profile, but it's usually at about 22-26 km.
  3. Start with both, but turn off the RAPIERs as soon as the TWR you need to continue circularizing drops below what the NERVs provide. Optimally, it would be "run out of oxidizer" rather than "turn off the RAPIERs", but it takes quite a bit of testing to get that to happen at the right time.
  4. 4900 m/s is well within the range of survivability, but it needs to be just a crew capsule and a heat shield (and maybe some other small parts, such as a parachute or an experiment storage unit). Any large parts except for a heat shield will increase the ballistic coefficient significantly and usually end up hurting more than they help. If you need to recover two crew capsules, consider sending them down separately at different times, each with their own heat shield.
  5. Yes, this is critical for saving Δv because it lets you reduce the amount of oxidizer. Every kilogram of oxidizer (and oxidizer storage!) is wasted mass unless you absolutely need it to get into orbit. At 2.0 m/s2, a Mun landing is very difficult but not impossible. However, your TWR will increase by 25% or more from LKO to the final landing burn, and even at 2.5 m/s2, landing is much more manageable. It's still not easy to do with a plane, though, and a fifth NERV would make landing much easier at the cost of some Δv. Also, if you manage to reduce the amount of oxidizer storage by using NERVs for more of the ascent, that would improve TWR as well.
  6. I'm not sure how exactly FAR works, but this is probably because you're flying really fast through dense air. The dynamic pressure on your plane at the time of the screenshot is about 132 kPa (assuming you're at the equator just before noon, which is what it looks like to me based on Kerbol's reflection in the water). In comparison, a typical rocket launch in real life reaches a maximum dynamic pressure of about 30 kPa, and even that's enough to cause significant structural concerns. When you're flying against that much pressure, slight pitch adjustments will cause the wings to start producing a huge amount of lift, and in this case, it's more than they can handle. There's a reason why planes don't normally go supersonic until they're high up in the atmosphere.
  7. In case it's hard to tell from the picture, that spaceplane has five NERVs (with their shrouds still attached). To add to what @camacju and @Lt_Duckweed have already explained: from the picture, it looks like you're getting the 1500 m/s remaining Δv figure in low orbit from closed-cycle RAPIERs alone. If you managed to get the same payload fraction with a NERV vacuum stage instead, you would have over 4000 m/s from low orbit. Of course, the increased dry mass means that you wouldn't actually get as much payload fraction, but it would most likely still be a large increase in Δv. In terms of stability, replacing three RAPIERs with two NERVs won't really change much.
  8. Either. You're already using large wings, though, so more wings would be easier to practically accomplish. This is a tough one. Spaceplanes have an inherent tradeoff between Δv and flyability, although limiting the amount of oxidizer definitely helps. Stability issues are caused by improperly positioned centers of lift and drag relative to the center of mass. These centers are not visible in your picture, but make sure that your center of lift is just behind your center of mass, not only when the fuel tanks are full but also when you've used up some liquid fuel to power the jet engines. I've heard good things about TAC Fuel Balancer for that purpose, although I haven't tried it personally.
  9. Whoops, you're right. For some reason, I thought that you did some significant theoretical work on it, but I was probably just getting that confused with Eve Optimized Engines (which is also great, by the way).
  10. Welcome to the forums, @GradientOGames! From what I can tell in the picture, the plane needs a lot more wing area. When I built a Mk3 SSTO that was somewhat smaller than your plane, it had five pairs of Big-S Delta Wings, and even then, it could only barely take off from the runway or land on the polar ice caps.
  11. Are you sure that your pilot is in a command module (which provides control) and not a crew cabin? If the astronauts are in a crew cabin (or some other kind of habitation module), then there are no controls for them to operate. Also, the mission elapsed time is negative. I'm not sure if that's related to the problem, but it's probably not good.
  12. Personally, I felt like a stock system grand tour with no additional restrictions doesn't provide enough motivation for creative designs. Anyway, I just finished my grand tour of Galileo's Planet Pack, Grannus Expansion Pack, and JNSQ (rescaled to stock scale). I'm pretty sure I followed the intent of all the rules, but I would like to confirm these cases. Rule 1: the main parts mods were Near Future Launch Vehicles, ReStock+, Simple Fuel Switch, and Explodium Breathing Engines, all of which I believe to be balanced with stock parts. Rule 2: I did have to use the debug menu twice, once to circumvent the landing leg sinking bug and once to circumvent a bug where Lindor's entire SOI was heated to 7000 degrees, but neither of those times did it let me gain any advantage beyond what would have happened if the bug weren't there. Rule 3: I could not plant a flag on Tellumo because I landed in the middle of the ocean, but I did collect a surface sample there, which of course still required Valentina to touch the surface.
  13. Part 30: Everywhere and back again That was all the targets. Vall was the last one. Wait, really? Let's go check. (30.1) All the flags Yep, that's all of them. I guess it's time to go home. (30.2) Return to Kerbin Theoretical Δv: 1608 m/s Actual Δv: 1723 m/s (30.3) TGGT returns to Mun Theoretical Δv: 2556 m/s Actual Δv: 1900 m/s (Oberth assist at Kerbin) (30.4) Descent to the surface This concludes my grand tour of the JNSQ system, and completes all the goals of the mission. (I landed a kerbal on the surface of every solid body and returned home, without refueling on the same body twice.) When I started exploring GPP, I thought I could never go back to the stock system. But now I can! JNSQ fixes so many problems with the stock system, has much better terrain, and of course adds a bunch of even more interesting planets and moons. Thank you, @Galileo, @JadeOfMaar, and @OhioBob, for making yet another wonderful system! Craft files: Team Galileo Grand Tour mothership Oxygen plane Methane plane Eve plane Nara plane Tellumo plane Ion tug and Taranis lander (30.5) Epilogue The crew capsule and crewmembers are safely transported back to the KSC. While emptying one of the compartments in the capsule, Jebediah notices a flag at the back of the drawer. There's a label attached that reads "Tellumo". Thinking back to that part of the mission, he remembers Valentina carrying a flag back inside the crew capsule after she couldn't plant it in the water. Well, it's a flag, so it better get planted somewhere, right? It is only thanks to the efforts of countless people over a decade that KSP modding has reached its current state. However, there are a few people in particular without whose work this mission would not have been possible. Thanks to @linuxgurugamer for maintaining Better Time Warp. Thanks to @Gordon Fecyk for creating Explodium Breathing Engines. Thanks to @Snark for creating so many small mods that improve gameplay significantly, most notably Simple Fuel Switch. Thanks to @OhioBob for his dedication to maintaining the quality and consistency of all his mods. And last but certainly not least, thanks to @king of nowhere, whose OPM Kerbalism grand tour was what initially inspired me to do a grand tour mission.
  14. Part 29: Jool Jool, Vall (near top), and Laythe (above and behind Vall), from Tylo. Remaining in the Jool system is Tylo, which could be a bit of an issue because its atmosphere is relatively dense. However, the surface conditions there are not that different from Brovo, so TGGT should be able to land there. (29.1) Tam Theoretical Δv: 852 m/s Actual Δv: 1692 m/s (inefficient transfer) (29.2) Tylo Theoretical Δv: 2337 m/s Actual Δv: 882 m/s (aerobraking) (29.3) Vall Theoretical Δv: 2444 m/s Actual Δv: 3270 m/s (drag at Tylo) Total gravity assists: 39 Flags remaining: 0? (3 planted this chapter)
  15. Interesting! I was mainly referencing Lindor's description in the Tracking Station:
  16. Part 28: Lindor TGGT returns to the Lindor system but fails to find any traces of chocolate. (28.1) Nara Pol Theoretical Δv: 1492 m/s Actual Δv: 1426 m/s (gravity assists at Laythe, Laythe, and Tylo) (28.2) Prax Riga Theoretical Δv: 1649 m/s Actual Δv: 712 m/s (aerobraking) (28.3) Sun Talos Theoretical Δv: 1733 m/s Actual Δv: 2095 m/s (drag at Riga) Gravity assists so far: 39 (3 performed this chapter) Flags remaining: 3 (3 planted this chapter)
  17. Part 27: Moho I was worried that Moho would cause routing issues like Icarus did, but the adjacent bodies in the route are Minmus and Mun, which are perfectly positioned on the other side of an Eve gravity assist. (27.1) Laythe Lindor Minmus Theoretical Δv: 4332 m/s Actual Δv: 3412 m/s (Oberth assist at Kerbin) (27.2) Moho Theoretical Δv: 5445 m/s Actual Δv: 4361 m/s (Oberth assist at Kerbin, gravity assist at Eve) (27.3) Mun Theoretical Δv: 5503 m/s Actual Δv: 3248 m/s (gravity assists at Eve, Oberth assist at Kerbin) (27.4) Edna Theoretical Δv: 3138 m/s Actual Δv: 3504 m/s Gravity assists so far: 36 (3 performed this chapter) Flags remaining: 6 (4 planted this chapter)
  18. In general, it is possible to use multiple planet packs simultaneously: just install both of them. However, it is possible for two planet packs to have planets that occupy the same space, in which case those particular packs will not be compatible with each other. If you're using Kcalbeloh as a secondary system, it is quite far away, at a distance of 251 - 292 Tm away from the central star. No other planet pack that I know of occupies that range of distances, so anything should work fine with it. If you're using Kcalbeloh with the homeswitch, you can still add other planet packs as long as they don't also move the homeworld (i.e. GEP or OPM should work, but not Beyond Home). They will orbit Kerbol as usual. If you're using Kcalbeloh as a primary system, where Kcalbeloh takes the position of Kerbol, planet packs such as OPM that expect the stock system will not work. Other packs may work as long as all the systems they add stay far enough away from Kcalbeloh to avoid overlapping SOIs. Aralc's SOI extends to a maximum of 1.4879 Tm away from Kcalbeloh, so anything farther away than that should be compatible. For example, GPP Secondary (3.304 - 10.696 Tm) would work, while GEP (0.7 - 3.3 Tm) gets too close.
  19. This took me over a week to figure out because it doesn't seem to be stated explicitly anywhere, so I'll put it here: Module Manager does not support inline math operations. For example, if you wanted to calculate 71 * 58, the syntax product = 71 * 58 does not work. Instead, use the corresponding math assignment operator: product = 71 @product *= 58 Other supported operations include += (addition), -= (subtraction), /= (division), and != (exponentiation).
  20. If the bug only happens when you plan a maneuver node, you could enter orbit by burning retrograde at periapsis without a maneuver node and then continue as normal once you get a stable orbit. Even with a periapsis near Mandrake's orbit, this would cost at most an additional 300 m/s or so. (I've never experienced the crashing bug when my orbit is safely contained in the secondary star's SOI.)
  21. Interesting. I can never figure out what's going on with that bug; it doesn't appear most of the time and varies wildly in the amount of lag it causes before crashing. Perhaps someone on the Kopernicus team might know more.
  22. JNSQ increases the day length to 12 hours due to Kerbin's larger radius. However, given the context, I would guess that "10 hours" refers to 10/24 of each day.
  23. I've encountered similar issues with quite a few other planet mods when attempting to plot a trajectory into the SOI of a distant secondary star. I haven't able to figure out what the cause is, but I think it could be related to a planned trajectory that exits (in this case) Gememma, enters a really long orbit around Kaywell, and then encounters Gememma again at a time that's so far in the future that it causes floating-point errors. If so, that would explain why turning the conic patch limit down to 3 before plotting the maneuver seems to prevent crashes. Edit: As @Stamp20 points out, disabling "always show closest approach to target" also works, but it can be undesirable if you want to intercept a planet directly from the transfer.
  24. It appears so: Also, while the textures might not be finished yet, the entire system is very well done from a gameplay perspective. I would recommend checking it out!
  25. Great concept, creative craft design, and superb video editing! As someone currently hauling around a 355-ton mothership for my own grand tour, this mission is seriously impressive. I noticed (from the Distant Object Enhancement planet labels) that you had Quack Pack installed; are you planning to do a mission there in the future? How could anyone? It's so much more convenient than having to deorbit and then reorbit after dropping the lander.
×
×
  • Create New...