Jump to content

Alchemist

Members
  • Posts

    1,736
  • Joined

  • Last visited

Everything posted by Alchemist

  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!"
  16. And what if you lock steering to target:position? Does the effect still remain or is it specific to vector drawing over longer distances?
  17. 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
  18. 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
  19. 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
  20. 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.
  21. 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)
  22. Don't worry, once you set the ISRU for spice mining you'll be able to afford proper navigators ...oops, wrong Dune
  23. I suspect a suboptimal ejection angle (which is easy to mess up with too low TWR), probably coupled with attempt to get arrival earlier (which can increase capture cost quite a bit). Besides, aiming for low periapsis straight from interplanetary transfer and capturing at the said periapsis is always much cheaper (although, circularization into low orbit might be quite expensive, especially if you don't need to bring everything down there). Yeah, even if intending to put the main ship in high orbit I'd still aim for low pass, capture at Pe into elliptic orbit and then circularize at Ap.
  24. True, fusion reactor may require much less cooling than fission reactor of similar power output, because fusion reactor should be capable of harvesting energy from reacting plasma directly through electromagnetic fields. Still it doesn't take all the energy (so you at least have to deal with reacted plasma and there still is possibility to harvest more thermal energy from it), and you definitely still need to cool the coils and reaction chamber walls. You just don't go thermonuclear without having to deal with the thermal part of it. And I totally agree about combining nice design and some fancy extended functionality with the basic intended function - it always makes the mission more lively and individual. That's also why I don't really like minimalism challenges which encourage to strip everything but bare minimum of specified parts. I still prefer to add this (because why not? it's cool addition) and that (to make it a bit more plausible...) and then something more (it's just fancier this way) - and if it ends up several times bigger, then it's go big or go home. And you are just the master of making it both highly functional and very nicely designed. Keep up the good work, and we are faithfully awaiting every next chapter!
  25. Yeah, that might be a big problem with procedurally generated terrain. But in case of runway landings I found it quite safe to extend the range to couple kilometers Here is an example of almost simultaneous landing from opposite ends of KSC runway And while in the video the carrier touchdown ended up not that far from the already landed shuttle, during the development tests there were even moments when the carrier landed before the shuttle and without issues (apart from hitting the lights couple times while I was working on making that script handle sharper turns and shallower approaches better)
×
×
  • Create New...