sevenperforce

Well, let's keep in mind, in the HP universe, someone had to write the recipe book. That someone was a wizard or witch who determined the correct amount of frog blood by a combination of theory and experiment. If a nuke hit Hogwarts and wiped out all their knowledge, wizards and witches could still rediscover the laws and rules governing magic. If the reader knew enough about the mechanisms by which magic operates, then yes, the reader could figure out the recipes in advance of the characters. Of course, Rowling didn't dial it down quite that precisely.

Yet even "doing it" is hard because there is nothing that can definitively be termed colonization. You can land a bunch of ships, and some of them can have kerbals inside, and that's a "colony" if you want it to be, but there's nothing qualitatively different between a one-way mission and colonization. You can recreate particular real-world plans, but that's about it.

You can do this.

Indeed. Sandbox play is huge in KSP but you end up with little reason to do anything once you arrive. And definitely no reason to colonize.

Nothing about the proposal changed; you're just understanding a little more about it. Coding timewarp interactions in multiplayer would be straightforward enough, but it would not be entirely simple. In order to implement a timewarp-handling system which does not cause paradoxes, you do have to do a bit of work. The multiplayer game would need a variable or two to define each craft's interactions with the multiplayer overlay. Probably InSOI and IsOrbitClosed. InSOI would have 17 possible values; IsOrbitClosed would be a boolean. Players would only see the orbits of craft controlled by other players if the InSOI variable of their craft matched the other craft, and they would only see the other craft as targetable if both their craft's IsOrbitClosed and the other craft's IsOrbitClosed were both true. IsOrbitClosed would be defined for each player with respect to their own universe. If your orbit crosses an SOI boundary within the next full orbit, IsOrbitClosed = false. If your craft will make one full orbit without crossing any SOI boundary, IsOrbitClosed = true. This is only defined with respect to your own universe. Does this make sense? Two vehicles controlled by different players would only able to interact when they are both inside the same SOI with closed orbits. Granted, this would preclude a very small subset of possible interactions (e.g., two players both burning from Kerbin to Duna simultaneously and then docking), but we have to accept that multiplayer is going to involve some tradeoffs. No paradoxes. Obviously, you're also going to have to figure out rules for collisions when two vehicles dock, but that's already going to have to be figured out for multiplayer anyway. To start with, Bill and Alice will not be able to dock in the first place if Bill's orbit crosses an SOI in the future, because Bill's IsOrbitClosed variable would be false. If Bill is on a Hohmann transfer from Eve to Jool, and Alice is in ordinary closed Kerbolcentric orbit, Alice will not see Bill's vehicle as targetable. She'll see the orbit, of course, but it will be greyed out and she'll see it ending at a random point in space. If both Bill and Alice are in ordinary closed Kerbolcentric orbits, then they can rendezvous and dock. Docking in multiplayer will have to have collision rules to start with, though, because you don't want two different people controlling the same vessel at the same time. Vessels probably need a tweakable that turns "open for docking" on or off, and you have a male-female interaction where one player has to actually initiate the docking and then assumes control of the target vessel, while the other player loses vessel control after docking. If Alice was the one to initiate the docking procedure, then she takes control of the combined vessel, and the part of the ship that formerly belonged to Bill is now part of Alice's universe. Bill can see it, of course, but Bill is not actively controlling it. If they swap positions, then the combined vessel switches over to Bill's universe. This might lead to some interesting gameplay, where Bill says "Hold on; I've got a transfer window in just a few weeks; let me take control and I'll get us there," or vice versa. But total dV is still conserved, so it doesn't break anything.

Sure it does. If a control surface is folded flush to the side of the rocket and control authority is set to off, it will have negligible effects on your center of pressure (unless you're doing some really wild gravity turn). An action group can unfold the grid fins, causing them to redock to the vehicle and enable control authority, and you'll have your control surfaces operational.

It's not entirely impossible to build folding fins that deploy permanently on a stock hinge. They can then be keyed to control pitch and yaw, though not necessarily roll.

There's a near-future solution that might actually be workable. I guess you'd call it a FlexLock. Imagine a standard egress hatch, like the one on Dragon 2. Inside the vehicle, place a human-sized doorway as flush as possible against the hatch opening, closed around the perimeter. In normal use, the doorway does not impede or obstruct the hatch, since the doorway only protrudes a few inches from the side of the vehicle (or perhaps slightly more, depending on the interior mold lines). For use as an airlock, a flexible material (likely a blend of an airtight silicone and something with very high tensile yield strength, like kevlar) is attached to the base of the doorway. For an EVA, the astronaut steps into the doorway, and the material is rolled/zipped up around the perimeter of the doorway. It is stretchy enough that the astronaut's body is still protruding into the cabin area, but the material has sealed him off from the inside. Then the hatch is opened, and he climbs out. The hatch may then be closed. When astronauts need to return, they open the hatch, climb in, using their bulk to push the material back inside the cabin, and seal the hatch. So it's like a standard airlock, for the most part, but much smaller because the interior hatch is flexible.

Doesn't matter. As I've explained, the positions of other SOIs are not shared. The only things shared within SOIs is the rotation of the object and the positions of manmade vehicles within that SOI. Bill and Alice both exit their respective SOIs at the same time, gamer time, and appear in Kerbol's SOI. Chances are, they will have each already burned for a rendezvous with their destinations, and so their orbits will be greyed-out with respect to each other. Bill will see Alice's orbit disappearing at a random point in space, probably nowhere near Kerbin, but that doesn't matter to him; Alice will see Bill's orbit disappearing at a random point in space, probably nowhere near Duna. Again, doesn't matter. If Bill and Alice end up in Kerbolcentric orbit, then they will both see each other's orbits as closed. They will see the various planets at different places, but that doesn't matter. They can rendezvous to each other, if they like. If they then decide to head to the same destination, they will each have to warp to a good transfer window individually, which will probably take them way out of sync with each other, but they'll arrive at the same time so it's not an issue. Nothing Charlie does can affect Bill or Alice.

Slight diversion, but are there any thoughts about suitport and airlock alternatives? It's something that's also viable for nearer-term stuff, like a return to the moon, for example. Suitports are a nice solution, but they are ungainly, they have poor CoM, and they do not permit transfer of any objects from outside to inside. Full-vehicle depressurization, as used in the first spacewalks and in the Apollo missions, requires all vehicle occupants to go on EVA together, exposes the interior of the vehicle to hard vacuum, has no protection against dust entry, and uses a lot of consumable resources. Airlocks, as used on the ISS and proposed for the Altair lunar lander, solve several problems but are heavy, bulky, and require long cycles. What solutions are available for making EVA a little more...manageable?

More on this.... A reusable lunar lander sounds very good, but without lunar surface assets, it's not necessarily better than an expendable version, in terms of launch costs. There are two ways of going about it. The first is to make the "moon taxi" 100% reusable. This results in two requirements: first, it needs to be an SSTO, which means it needs to carry almost 4 km/s of dV. That's a lot, especially if you're using hypergolics; you'd need more than 70% of your lander to be propellant. This means pump-fed engines and autogenously pressurized hypergolic tanks, and you need 100% of the propellant to be transferred from Earth, each time. You need to have a way to mate and transfer propellant. The other way is to use either drop tanks or drop stages. Instead of bringing propellant from Earth, you're bringing either tanks or whole stages, which attach to the lander and are discarded. This no longer requires quite as high a mass ratio, and you may be able to get away with cryogens, but now you have to deal with the problem of orbital assembly, which is different from the problem of orbital propellant transfer. You're also bringing along a specialized set of equipment each time, rather than (perhaps) just a tanker. And that fuel needs to be plumbed to the RCS system as well. When it all comes down to it, you can probably get a whole new lander into lunar orbit with a lower mass-in-LEO expenditure than doing full reuse.

The N1's Blok D kerolox upper stage was designed for multiple restarts in cislunar space, back in 1969, so I can't imagine the changes would be TOO extreme. A penguin tumble keeps the propellant together, rather than up against the edge of the stage, for this purpose. Also gives the astronauts a very low simulated gravity to help keep them oriented. Might need to paint the kerosene tank black to provide solar heating. Yes, you discard some upper stages and some propulsion assist pallets. You also discard your lander. The mission can be flown with a reusable Falcon Heavy if you use a second reusable Falcon Heavy for the TLI and LOI burns, as with Dragon 2. The above plan does not require Falcon Heavy be man-rated. Extending the Falcon upper stage only very marginally increases mass to orbit. In fact, for a fully-expendable Falcon Heavy, you can actually get as much or more payload to orbit by simply going without an upper stage at all. Kerolox doesn't have high enough isp for upper-stage stretches to be rewarding; all the performance of kerolox comes from the early stages. Unless an upper stage is actually recoverable, then there's no reason to do orbital refueling. Falcon upper stages are expendable. Sending an upper stage back to LEO for reuse doesn't make sense if the only way to refuel it is to send up another expendable stage; just send up the expendable stage in the first place. A reusable lander in lunar orbit is dead mass useless unless it can be refueled. Refueling pressure-fed hypergolic tanks on orbit is more or less impossible. So that's the problem there. A reusable lander would need to have all of its consumables manually replenishable in cislunar space. It would also need to have its entire propulsion system, including RCS, be refuelable. Dragon 2 is not a good candidate for in-space reuse. Since the hypergolic tanks cannot be refilled in space, the only thing available for reuse is the pressure vessel and ECLSS.

It's a yaw motion, which shouldn't be too high on the gees. The higher-gee maneuver will be the stall swoop at the end. Right, that's what I meant too. Split body flaps can only do you so far; at some point you need to have an entry profile which utilizes your a single fixed lifting surface. A nose-up entry would cause a "skip" and fail to complete entry at all; you'd lose speed while gaining altitude, both of which decrease available lift, and you'd eventually stall out at the edge of the atmosphere and fall into a tumble. This was the reason the Shuttle needed a very complex entry profile with big S-curves. Coming in nose-down directs that same lift vector roughly down and opposite your direction of flight, so you are pushed deeper into the atmosphere and lift remains constant. The one thing I'm worried about here is the drag effects on those winglets. During the initial nose-down entry, those winglets are going to get a TON of drag, and it is REALLY going to want to go shuttlecock and roll 180 degrees. I don't know how they will prevent that. Once you're through that portion, it gets much easier. The heavy nose and heavy engine cluster put the CoM very close to the physical center of the vehicle, allowing that scary-looking yaw flip on RCS. After you're through the majority of the heating, you can yaw around to nose-up, then pitch down and use body flaps to further adjust pitch to control your trajectory. Can't do that sooner, or you'd burn your nose off. At this point, you're still coming in toward your landing site at hypersonic speeds. Retropropulsive braking would take way too much propellant at this point, so you use control surfaces to pitch up and climb, trading velocity for altitude slowly until you stall just above your landing site. RCS is used to prevent uncontrollable tumble, and the engines are lit for the landing burn. I'm worried about post-stall stability, though.

How about Ike? And my bud's craft at same orbital heigh around duna? Will the accelerated ike smash my bud's craft or will my craft miss the planned encounter with Ike upon arrival? In the specific instance you cite, you would see an overlap between Ike's position and your friend's DSO craft. Might be slightly jarring, I admit, but if you're headed to a rendezvous with Ike, then your trajectory will drop out of phase with the shared Duna SOI the moment it intersects Ike's SOI, so it won't matter. If you're planning a rendezvous with your friend's DSO craft, then you'd position-warp around to a good ejection point rather than timewarping, so Ike wouldn't move in the first place. "Good" is relative. It's not simple and straightforward, no. But that doesn't make it "not good". The goal is to preserve standard gameplay, including mechanics like timewarp, while allowing multiple players to interact with each other, without producing paradoxes. So, yes, simultaneity between craft locations and celestial bodies will be broken. But that's not "not good"; it just needs a handling rule. Insulating individual SOIs and spacecraft from timewarp, while allowing position warp for individual spacecraft, is a universal handling rule which solves that problem. In that case, seems you forgot to present the general rule. Allow me to refer you back to my very first post: True warp and dynamics warp are the problem. If you're warping toward a specific destination, moving your vehicle faster along your orbit (as with position warp) doesn't help, because then you'll miss your destination when it arrives. So the solution here is a little more complex. In order to deal with true warp and dynamics warp, each player's warp experience has to be segregated. What is shared across multiplayer is not the entire solar system, but each individual SOI. Suppose Bill wants to go to Duna, but Alice is already on Duna. No problem; Bill does the usual ascent, warp-to-window, trans-Dunian injection, and warp to SOI entry, with all the planet and moon positions stored locally. Once Bill enters Duna's SOI, he suddenly "pops up" on Alice's map view. They share only the SOI, not the whole solar system.

Propellant transfer on the Falcon upper stage is not really feasible, since the tanks use helium for ullage pressure. I mean, automated high-pressure helium transfer could be done, but it would be an immense, immense redesign. Orbital docking and upper-stage extended restarts, on the other hand, are definitely feasible. A Draco-based propulsion assist pallet, mated to the payload adapter inside the D2 trunk, could provide enough dV for the burn out of Lunar orbit and onto an Earth entry trajectory. The same propulsion pallet on a stripped-down D2 could provide enough dV for single-stage ascent off of the moon, though TWR would be insufficient. You'd want to use Joint Lunar Orbit Rendezvous rather than Earth Orbit Rendezvous, though. I have started crunching the numbers on this, and so the profiles may need to be adjusted slightly depending on dV, but the overall plan is solid. Launch crew on a standard Dragon 2 with a propulsion assist pallet in the trunk, using an ASDS-recovered Falcon 9, into LEO. Launch an ASDS-recovery Falcon 9 carrying only an international docking adapter, with a slightly-modified upper stage to allow for boiloff protection and extended restarts, into LEO. Use Dragon 2's OMS to rendezvous and dock, nose-to-nose, with the IDA on the business end of the Falcon 9 upper stage. Use the Falcon 9 upper stage to perform the TLI burn, then use Dragon 2's thrusters to place the vehicle into a slow penguin tumble, with the docking still secure. Use an expendable Falcon Heavy to launch a stripped-down Dragon 2 directly into TLI. The stripped-down Dragon 2 has no aeroshell, no heat shield, no parachutes, no ballast sled, and only one SuperDraco in each engine pod. It also has fixed landing legs on the trunk, a propulsion pallet mated to the trunk payload adapter, and either suitports or an expandable airlock in place of its egress hatch. Keep the Falcon upper stage mated to the trunk. Once the crewed Dragon 2 arrives at the moon, the Falcon 9 upper stage mated to its nose performs one additional burn for direct LLO insertion, then it is discarded. Once the second stack arrives at the moon, its Falcon 9 upper stage is also used for the same lunar orbit insertion burn, but it remains mated to the trunk of the modified Dragon 2. The crewed Dragon 2 executes a rendezvous with the second stack, docks nose-to-nose, and executes crew transfer. The first Dragon 2 then performs a deorbit burn with its propulsion assist pallet, undocks, and then reverses and brings its orbit back up. The lander, with Falcon 9 upper stage still attached, descends toward the landing point. Shortly before periapse, the Falcon 9 upper stage fires to kill horizontal velocity, then is jettisoned. The lander descends on SuperDracos and lands. Following the lunar surface mission, the SuperDracos fire again to lift off and raise apoapse, after which the propulsion assist pallet in the trunk is fired to burn into orbit. Once orbit is reached, the propulsion assist pallet is discarded, and the two Dragons rendezvous. Crew transfers back, and the first spacecraft burns for home.

Gravity drag on Mars is cheap. Delta-V is not.

No, they are saying that heat shields and parachutes alone are not sufficient to land payloads above 5 tonnes.

Depends on what type of exchange you're dealing with. Server pings would be 15 ms, but streaming lag direct from the server to you is just 7.5 ms.

And, for anyone wondering, the round-trip speed-of-light lag at 1125 km is 7.5 milliseconds.

From the FCC license: the two satellites will be inserted at 514 km but will move to a circular 1125-km orbit under their own propulsion. Inclination is 97.4 degrees.

Supersonic retropropulsion is one of the technologies which SpaceX specifically wanted to test using Falcon 9 for Mars landing applications. If I recall correctly, they even partnered with NASA for some of the research on that.... https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20170008725.pdf There we go. SpaceX gave NASA their data on supersonic retropropulsion so they could produce papers like these. If I were you, I'd cite the hell out of that paper if your proposal involves supersonic retropropulsion in any sense.

The solution is simple. The Starlink satellites should just turn their lights off whenever anyone is looking at them.

Oh yes...is preserved...I just need to log back in a few mouths to do it. Ok, that is My plan. I have my ship in LKO ready to depart to Duna, my issue is that The transfer window is three months away( notice that is a timing problem). What I need to do? As you say, teleport don't help me at all. Again, you've got it upside-down. Please take a second to actually understand the proposal. Your ship is in LKO, ready to depart to Duna, but the transfer window is three months away. In singleplayer, what do you do? You warp for three months, your ship completes half a zillion turns around Kerbin, the Mun and Minmus whip around Kerbin a corresponding number of times, the windows line up, and finally you reach your desired transfer window. You do your TDI burn, and then what happens? You warp ahead, as you leave Kerbin's SOI, enter Kerbolcentric orbit, and finally collide with Duna's SOI. What's the difference in multiplayer? In my proposal, you do the exact same thing, except that time does not accelerate within individual SOIs. When you timewarp in multiplayer, bodies on rails (the Mun, Minmus, Duna, and so forth) all accelerate their positions, but manmade objects inside those SOIs do not accelerate. Your timeline is now different from everyone else's, and you see objects on rails in a different place than other players see them, but the timeline within each individual SOI is preserved. That's how the paradox is avoided. Each player is still playing, in essence, a single-player game. However, individual SOIs are shared. As long as your craft's trajectory does not cross SOIs, it can be interacted with normally. As soon as you're on an escape trajectory (or intercept trajectory), it is no longer available for targeting or docking or other interaction. In the above example, another player wouldn't see anything special happening while you were warping to the transfer window. Of course, YOU see the positions of the moons and planets changing, in your own game, but they do not. They see your craft continuing along its usual trajectory normally. But then, once you start your TDI burn, they see your apoapse growing and growing (though, from their perspective, it may not actually appear to be heading in the correct direction), until suddenly you reach escape trajectory and your craft's trajectory suddenly goes grey. When you warp out of Kerbin's SOI, that trajectory disappears altogether. If that other player happens to have a base on Duna, and they happen to pop over to Duna, what will they see? Nothing, at first. And then, as you warp forward, they suddenly see a grey trajectory pop up in their Duna map view. A few moments later, you start your injection burn, and suddenly your craft appears. Which is exactly what needs to be solved. You think that, because you missed the fact that "position warp" is the exception.

Just as a simple proof of concept, I constructed a pulse explosive engine using a cluster of Mainsails and a small fuel tank as the "explosive" and a long stack of tweakscaled structural fuselages as a nozzle. Ends up with a specific impulse of about 14 seconds and an effective TWR of about 190:1, assuming one pulse per second.

So it need to be addressed. Even if just to conclude it's not a problem. (Personally, I think it is something the devs should be concerned. But that is besides the point) There's a big and evident difference. In the single-player game when I warp time pass. For everything, including my craft, position will be a continuous function of time. Your idea breaks that continuity. The passing of time is of no consequence in singleplayer warp, because if you miss a transfer, you can literally just warp longer until it comes around again. In singleplayer, if you want to warp to when the KSC will be exactly opposite your deorbit burn, you select a point that trails KSC by about 0.8pi radians. In the "position warp" for multiplayer, you select a point that trails KSC by 1.0pi radians. What's the difference? "Well, in singleplayer I would have caught up with my deorbit point 0.2pi radians later!" It makes literally no difference in gameplay. Same with a rendezvous to another ship. In singleplayer, if you are in roughly the same orbit as your target, you can jump over to the tracking center and warp for a day or a week or a year until your phases cancel and you're close together. "Position warp" makes this slightly easier, but there's no meaningful difference in gameplay. "Just a fortuitous consequence"? I don't know about you, but every single time I've done an interplanetary mission, I've based it on what will have the lowest dV, within a certain range. Choosing a specific time to deorbit does not change the dV required for the maneuver. Choosing a transfer burn time does. Position warping within a single SOI has little effect on gameplay and can be handled "simply", but position warping across SOIs involves multibody dynamics and cannot be handled by simply teleporting to a different point in the orbit. You've got it upside-down. It's not about trying to force certain dV requirements. Nothing remotely like that. It's about preserving the ability to perform transfers, period. "Position warp" can let you do things within a single SOI in a very simple and straightforward way, but if your plan is to leave your SOI, "position warp" does you no good whatsoever. I can "position warp" around Kerbin 10,000 times, but it won't get me any closer to my Duna transfer window. Once I've done my burn to Duna, I could "position warp" forward along that Hohmann, but then I would beat Duna to the rendezvous, which wrecks my transfer completely. For warp in multiplayer to work, you need to still be able to plan a transfer, execute the transfer, and complete the transfer as in singleplayer, without the transfer taking six months of play time. This has nothing to do with some artificial enforcement of dV requirements. It's about replicating the singleplayer experience, as far as is possible, in a multiplayer setting. "Position warp" can be used to replicate the warping within SOIs, but you need a different solution when you are transferring between SOIs. The different solution is that timewarp undertaken by a singleplayer warps objects that are on rails, for them only, without changing anything within the SOIs. Each SOI becomes, in essence, a warp-protected bubble. That makes no sense. You can't claim to ignore the other objects (e.g. KSC ) position when your objective is to interact (e.g. land at) with such objects. Ignoring the other objects woul be doing the deorbit burn regardless of the position of KSC instead of when KSC is exactly on your path. If you are trying to warp only within an SOI, you can do so without worry about the relative positions of other SOIs. Warping to apoapse on ascent or warping to a rendezvous or warping to a deorbit point can be done instantly, without needing to keep track of the positions of the Mun or Minmus or Duna or Eeloo. But if you are warping across SOIs, you need a different solution. You seem hung up on the idea that there's some inherent problem with treating different warp situations differently. There isn't, but let's set that aside for the time being. What, exactly, is the problem with the timewarp solution of having each player's solar system progress on its own timeline and merely insulating each on-rails SOI from that timewarp?