Alchemist

Members
  • Content Count

    1,733
  • Joined

  • Last visited

Community Reputation

1,078 Excellent

1 Follower

About Alchemist

  • Rank
    PowerTech Chief Engineer

Recent Profile Visitors

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

  1. 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)
  2. 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
  3. 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
  4. 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)
  5. 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.
  6. 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.
  7. 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.
  8. 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
  9. 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
  10. 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.
  11. 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
  12. 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!"
  13. And what if you lock steering to target:position? Does the effect still remain or is it specific to vector drawing over longer distances?
  14. I'm not 100% sure on technical details, but there were some moving parts in the nozzle to allow for a bit of thrust vectoring. Probably only a small authority, but you really don't need much for roll and yaw if you also have yaw deflection on SSMEs to compensate for any imbalance on that side
  15. The thing about roll authority on initial ascent is - Space Shuttle actually had some thrust vectoring on the boosters. It's easy to see that those are actually the best positioned to provide roll authority with only minimal perturbations on other axis (and if there still is some yaw effect - with proper flight guidance it can be automatically cancelled by balanced yaw response of all the engines). While it's clear that SSMEs with their large gimbal range were the main source of pitch control, you clearly can't expect engines this close together to handle both roll and yaw while they aren't on the thrust axis Also an advice from my experience: disable roll response on engines too close to CoM - those will likely produce more yaw than roll torque. Handling of my Energia replica greatly improved when I disabled roll on the 2 engines closest to Buran