Jump to content


  • Posts

  • Joined

  • Last visited


1,098 Excellent

Profile Information

  • About me
    PowerTech Chief Engineer

Recent Profile Visitors

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

  1. Well, I recently found myself messing with my good old crew shuttle Hydrargyrum. Originally, it turned out capable of getting to Mun orbit and back to Kerbin. Or with an orbital refueling at either moon go full Kerbin - Mun orbit - Minmus (well, nearly anything can land there) - Sun orbit - Kerbin route. And with over 90% refund due to full reusability. Even made a cargo version for running recovery contracts. Here are both shuttles and their launcher: But running tourist contracts around Kerbin gets a bit boring, especially after you unlock everything (and unfortunately it requires almost entire tech tree and couple millions for part unlocks and building the shuttle - even if 49% of launch cost is refunded in less than 10 minutes!) So I tried refueling it at the Mun orbit and... getting it down there. Even if it never got any special implements for landing anywhere except Kerbin. OMS engine was sufficient...https://imgur.com/ElmVsxMhttps://imgur.com/ElmVsxM But today I went a bit overboard. It was meant as crew training and tourist flight using previous expedition's landers, but a certain lander would require a bit too many trips there and back, so after refueling at Ike... are we sure this is how you fly a shuttle? And... Honestly, I didn't really expect this to work.
  2. The way kOS handles it, vessel:position returns the center of mass. And the coordinate system is ship-centered, so for current vessel ship:position=v(0,0,0) Not the most obvious thing, but that's how it works
  3. 1. Assembly: The way you assemble the ship is not prescribed. If you bring fuel from Minmus using pre-existing infrastructure (or even incorporate an old lander you've had around), that can be considered just as part of orbital assembly. However, the final vessel must depart as a single ship from LKO 2. Departure: You are not supposed to interact with anything not included in your ship after leaving LKO - so preexisting fuel infrastructure is out of question after this point. However, if you transfer to Minmus and use ISRU-equpped lander to refuel from it before flying to Jool, it is acceptable. 3. Jool: You are not supposed to use preexisting infrastructure or anything other than what arrived there as part of your mothership (relay satellites and scouting are OK, but definitely no docking with other vessels for boosting or refueling). But you can use ISRU you bring with you for refueling at the moons.
  4. It definitely shouldn't (and pretty much can't) be done by simulating the entire thing, let alone custom-built from small parts. But if when you approach the end the things actually simulated are the few parts on the end and then there is just the structure going into the distance simulating the rest of the thing with all the inertia (yes, completely custom code for a specific part) - that's something plausible. Anyway, docking to the hook would be a very Kerbal piloting experience. Because, even if the horizontal speed is matched, you are still on suborbital trajectory and gravity pulls you down, while the thing you are trying to dock with has upwards acceleration (due to its rotation). Which would probably be even more complicated than precision landing with VTOL. (Of course, tethered drone option does allow to get a few moments of 0g maneuvering, but quite a narrow window at that)
  5. Sounds rather fun, but I'm not sure I see that much advantage compared to a space elevator. Just shorter string won't be that advantageous, if you end with much higher load on it due to swinging and higher propellant expenses for keeping the counterweight in orbit. Anyway, it would be quite interesting to have support for such superstructures. And it probably should be quite doable with some smart design to avoid full simulation of both ends
  6. True. Of course, Mun's gravity and low altitude also means that it doesn't take much propulsion for emergency landing either, to the point a good RCS system could be enough (and also work as backup in case of attitude control issues). I agree, backup thrusters wouldn't help with that (although, crewed test of something you are pretty much checking if it blows up again or not is quite the Kerbal practice. But pretty much everybody playing KSP sometimes does that - having the revert button causes some specific habits) That pretty much was my point - what if it manages to lift off and not blow up, but the controllability goes haywire (because if you don't fully understand how it works, chances are it would do something unpredicted)? Yeah, there clearly is a bit of Kerbal logic involved: 1) crashing into ground is already a progress compared to blowing up mid-air (where? On Mun??) mid-flight, we'll think about it when we get there. 2) why to bother with ensuring softer landing if most equipment is lithobrake-certified for such impact speeds? (which also has the implication of structural elements already having a few tons of extra weight spent on this sort of rigidity...) On another topic: the explanation about pouring electricity into graviolium to produce gravity waves and static discharges forming as a side effect - is this a Mass Effect reference? There was pretty much the same explanation for how all such tech works
  7. An entire base disappearing only to quietly reappear at another location - now that's the real Mun conspiracy. Fortunately for them, telescopes on the surface just don't have the kind of resolution due to atmosphere to see such things going on on the Mun (so unless somebody would use a high-aperture orbital telescope knowing where and when exactly to look - chances of somebody spotting it in action would be pretty much zero). One thing about the saucer prototype I'm a bit concerned of - shouldn't there be some kind of backup propulsion system in case the prototype antigravity drive fails? Of course, one may argue that it's not very safe to carry chemical fuel on something spewing electric discharges in all 6 directions either, however a small fuel leak would be much less of an issue without atmosphere, but to worry about possibility of the fuel exploding on very hard landing - if you already have a nuclear reactor running, some propellant won't add to much mess to the worst-case scenario (as opposed to the possibility of preventing the crash)
  8. I guess the main problem with several players managing their own sets of ships in the single universe would be the fact that timewarp is one of the core mechanics for anything beyond just going to LKO. You can't just force multiple players into the same timeframe. Meaning, you'd need some way to record actions of a vessel to then be able to replay those as another vessel is flown later by real time but around the same in-game time. BTW, this feature to rewind some in-game time and take control of another vessel has applications even for single-player game - from managing a fleet of interplanetary ships sent to their destination all at once, to landing detached stages as main craft achieves orbit. And, depending on how much is recorded, this technology can even create replays - to rewatch the vessel performing all the maneuvers (which can also be extremely useful for sharing stories, be it good screenshots or cinematics). Downsides of this are the amount of data to be stored and the logistics of possible interactions between vessels played at different moments. And these issues will probably grow to unmanageable levels very quickly if you allow unlimited timewarping forward and back. What I'm thinking about is some sort of time window mechanic to limit in-game time difference between things getting done in the same real time. Basically, you have a time window, within which you can warp forward on one mission, then go back in time and pick another vessel to fly (or have another player fly another vessel at different in-game time pint within the same window). But you can't warp beyond the end point (for a longer mission that means you'll have to leave it where it is and come later) and you can't go back in time to a point before the start point of the window (so if you missed a maneuver that badly, you'll have to deal with it). And probably new flights should be started around the middle of the window. It can be turn-based (window just shift from one position to the next with minimum overlap), but I'm more inclined to real-time progression, when the window gradually moves along in-game timeline, probably at several times the real-time (exact rate can be negotiated and renegotiaded between players depending on the actual pacing of the game - which would warrant faster time progression for long-range spaceflights). As for the width of the window, it should avoid being too strict, so for always-online server I'd recommend having a point of in-game timeline being available for something like 25-40 hours IRL (for shorter game sessions between which the server is paused, it can be more narrow window and with faster moving rate). Additionally, there should be some option that allows the players to skip some time altogether, if they agree to do so. Of course, this still leaves the question of synchronizing interaction, but even just forcing to timewarp to the last point the other vessel was interacted with, before allowing to approach it is much less of a problem, if the time difference ends up being hours not weeks. Anyway, for spaceflights it's only realistic that docking to or taking control of each other's vessels should be agreed between players before it happens, so some permissions mechanics are a good idea. Additionally, there totally should be a option for multiple players to get full coop multiplayer (fully synchronizing in-game time) to fly multiple vessels in close proximity (or maybe even assume several roles within a single vessel). And no, it's not opposed to the asynchronous space program managing discussed here, quite the opposite - the asynchronous mode allows all players to make whatever preparations needed on their own and then conveniently come together at the same time (both in-game and IRL) for the joint flying part.
  9. To be fair, you can manage SpaceX style boost back if you have good enough TWR with just kOS. The general idea is steeper initial ascent than for typical rockets. which leaves you with higher vertical and lower horizontal speed at stage separation - which is also what makes the boost back maneuver cheaper with first stage turning back straight after separation you can even manage to complete the boost back before leaving physics range for atmospheric flight (I would still recommend to increase the packing/unloading range for the stage to something like 35-40 km for both atmospheric and space flight) now here is a notable TWR limitation for the upper stage - you have limited time until the first stage passes its apoapsis and then falls back into the denser layers of the atmosphere (that's why vertical speed on stage separation is so important; you might want to perform the boost back angled slightly upward if you have problems with first stage falling back way too soon). In this time the second stage has to leave the atmosphere and either complete orbital insertion or (for higher target orbits) get trajectory with enough time to apoapsis to land the first stage in the meantime and then switch back for circularization. and then you switch to the first stage (which should be reentering by then) and perform the landing And that's what my fully reusable 2-stage shuttle does. The orbiter completes orbital insertion (yes, it involves a bit of pointing downwards for circularization) before the launcher reenters. However, having wings and jets, the first stage aims for 40 km undershoot, falls almost vertically, pulls 9g turn and then glides back to runway. Of course, with a rocket you would aim for some overshoot taking into account the drag and then perform some braking corrections as you approach the landing site. I once did a bit of experimenting with that, but never actually completed what is required for precision landing in atmosphere.
  10. That line is a rather obvious error, however the file might need a bit more investigation. For example, I have some suspicions about what happens if the engine modules are declared in opposite order than they are listed in multimode engine module (namely, secondary engine declared in the part file before primary) - kOS interpretation may give opposite results than actual stock behavior resulting in quite a mess.
  11. Let me see... Nothing too special about the part config in question... what about RAPIER? Yup, broken, too. Let's see the source... great, it has been refactored several times over. Oh wait, where did that come from? https://github.com/KSP-KOS/KOS/commit/567820cbbaebb71092bcd4eb4c0ba6a34f176776#diff-8f94cb2f0d2ce25080591180a75f3360R38 Yes, somebody replaced == with !=. Of course it misfires
  12. Oops... so much for "we bring them home". Sleeping over risky mission parts is not too healthy Kerbin Galactic really seems to share quite a bit of the tendencies to overstretch hardware capacity with where those part designs came from. Which sometimes tends to backfire, unfortunately, especially when the crew is in no position to intervene
  13. Yeah, the surest way to get out of trouble with aerobrake gone too deep... is to have delta v and TWR at which you wouldn't exactly need to aerobrake. On the other hand, participation in the Shuttle Challenge has taught me to appreciate aerodynamic control capabilities on aerobraking (plus, spaceplane configuration makes sure you have proper attitude for emergency boost in case you still need it). Well, at least they had the lander in tow, hopefully there was enough space for the crew and enough time to get in there. But in order for everybody to get back, the two space agencies will have to cooperate for once.
  14. The question of lift was about why it doesn't stay upside down, but rolls the other way around soon after SRB separation. By the way, this maneuver is not a thing for Buran - it stays belly-up. Which clearly means the reasoning involves something about the configuration after booster separation - and here Shuttle and Energia-Buran have high thrust deflection in opposite directions
  15. To be fair, with most of the thrust being SRBs and most of the weight being ET+SRBs, the resulting thrust vector should still be quite close to being along the ship. But all of this also means the SRBs have to do most of the work on yaw and roll control And to think of it, with such thrust vector, starting pitch program early on (pretty mush as soon as roll to the proper azimuth is complete) and with noticeable deflection from vertical gives a good option to actually pass maxQ with the Shuttle perfectly aligned with airspeed, while the offset thrust compensates for perpendicular to velocity gravity component. Well, after booster separation SSMEs have to align their pitch axis deflection with CoM, at which point they have perfect control over all 3 axis of rotation. And while air may be too thin for control surfaces, isn't the point of the belly-down roll to have the lift turned up? Given the offset between thrust vector and the longitudinal axis at this point, lift should be a concern. Of course, with the tools we are offered in stock KSP all of this typically boils down to "forget the efficiency optimization, just choose something SAS can handle without wobbling the shuttle apart steering with this gimbal range!"
  • Create New...