• Content Count

  • Joined

  • Last visited

Community Reputation

1,077 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. 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.
  2. 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.
  3. 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.
  4. 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? Yes, somebody replaced == with !=. Of course it misfires
  5. 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
  6. 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.
  7. 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
  8. 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!"
  9. And what if you lock steering to target:position? Does the effect still remain or is it specific to vector drawing over longer distances?
  10. 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
  11. 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
  12. You can take any size and mass. However, be aware that even class A won't fit in the mk3 payload bay, and with densities they have in stock (styrofoam???), carrying a small asteroid is more about drag than weight. Back when I was doing this mission there was a bug which made all the rocks spawn with 150t mass. Now that was a cool chance to drill it down to whatever mass you can carry while also picking something of a manageable size
  13. Weird, indeed. Last time I've tested it (when introducing the NAVMODE feature, because SASMODE is a bit useless without that) 1 frame delay seemed to be enough. Is it 2 now? maybe then using wait 0. wait 0. should do the trick.
  14. Yeah, there is the issue with SAS resetting its mode when you switch it on. (stock behavior) wait 0. (same behavior with any number that happens to be less than a physics tick, like wait 0.001.) is sufficient to make the script skip exactly 1 update tick (wait command always skips at least 1 update, even if the condition is already met before that)
  15. Don't worry, once you set the ISRU for spice mining you'll be able to afford proper navigators ...oops, wrong Dune