Will Skyhook tech be available in KSP 2?

[sturmhauke]

I'm not convinced of the plausibility of the skyhook concept in the first place. The video kind of handwaves away the difficulty of intercepting the hook in atmosphere by saying it can be partially automated. Maybe so, but it's still a tiny, very fast target with a short window. And once the spacecraft is on the hook, it's going to be rotated around and be subjected to quickly changing forces. One thing you certainly don't want to do with a conventional spacecraft is make a rapid turn in the atmosphere - that's a quick way to turn it into confetti.

[Incarnation of Chaos]

2 hours ago, sturmhauke said:

I'm not convinced of the plausibility of the skyhook concept in the first place. The video kind of handwaves away the difficulty of intercepting the hook in atmosphere by saying it can be partially automated. Maybe so, but it's still a tiny, very fast target with a short window. And once the spacecraft is on the hook, it's going to be rotated around and be subjected to quickly changing forces. One thing you certainly don't want to do with a conventional spacecraft is make a rapid turn in the atmosphere - that's a quick way to turn it into confetti.

Also a hook has to grab something in the first place, so you end up with a situation where the intercepting ship has to be made of similar materials. Because otherwise the sheer force of making the connection would tear your ship in half.

 

[mcwaffles2003]

5 hours ago, sturmhauke said:

I'm not convinced of the plausibility of the skyhook concept in the first place. The video kind of handwaves away the difficulty of intercepting the hook in atmosphere by saying it can be partially automated. Maybe so, but it's still a tiny, very fast target with a short window. And once the spacecraft is on the hook, it's going to be rotated around and be subjected to quickly changing forces. One thing you certainly don't want to do with a conventional spacecraft is make a rapid turn in the atmosphere - that's a quick way to turn it into confetti.

Did you watch the vid? The hook wouldnt be in the thick part of the atmosphere

2 hours ago, Incarnation of Chaos said:

Also a hook has to grab something in the first place, so you end up with a situation where the intercepting ship has to be made of similar materials. Because otherwise the sheer force of making the connection would tear your ship in half.

Not necessarily, so long as both materials can withstand the sheer force themselves it'd be fine

[Incarnation of Chaos]

Just now, mcwaffles2003 said:

Did you watch the vid? The hook wouldnt be in the thick part of the atmosphere

Not necessarily, so long as both materials can withstand the sheer force themselves it'd be fine

And that's the issue.....you can't just make a craft out of aluminum or steel and put a carbon nanotube hoop on it to engage the hook. Since it would just be torn from the weaker materials around it.

[mcwaffles2003]

2 hours ago, Incarnation of Chaos said:

And that's the issue.....you can't just make a craft out of aluminum or steel and put a carbon nanotube hoop on it to engage the hook. Since it would just be torn from the weaker materials around it.

You say "and thats the issue" but disregard explaining the issue.... whats the weak link in this chain? Are you suggesting ships cant be built for the purpose of latching onto skyhooks? That steel/aluminum couldnt be manufactured to withhold the stresses? What stresses are you assuming the ship to be under? You have me at a loss...

[Gydra54]

I can't be the only one that's shuddering at the concept of latching onto a skyhook at interplanetary speeds... the window for hooking on and matching velocities would be absolutely abysmal, you'd have to perfectly line up and catch it in the span of what must be just a few seconds! No taking your time to cancel velocities and approach at really small speeds, if you're not careful, that thing is gonna drift away from you real quick. And if you don't catch it... off back into interplanetary space you go! Doesn't sound impossible, but certainly a very tense situation. I wish I could simulate this in KSP, sounds like a fun challenge.

Not a programmer, but I think this could be implemented, it seems like it would have to be a very "special case" thing though with a unique solution. Maybe some very smart modders will implement it somehow. I see some talk about it moving at very fast speeds and "skipping past ships", but it seems to me like the intended purpose is to only interact with it at low speeds (<100m/s). Unless I'm missing something, there's no need for super accurate collision simulations in this case, any more than any other ship. If you for some reason rendezvous at ridiculous speeds and it goes straight through, how is that any different from any other hyperspeed rendezvous with other craft? There's no material I can think of that could withstand the G-forces from latching on at the speeds at which this would be a problem anyway.

Basically, what I'm getting at, is that there's no need to simulate the entire skyhook at once at the same level of detail and at ridiculous accuracies. If you simplify it, the only real interaction seems to be with the "hook" itself, which you can treat as any other craft except with its own special case trajectory. There's also the cable, but you can make assumptions like assuming it will always be taut so that it's rigid. It doesn't seem that bad if you just simplify it to the things that acutally matter to player interaction. Just throwing out ideas, IDK, again I'm not a programmer, so maybe I'm just spouting nonsense.

[Meecrob]

8 hours ago, mcwaffles2003 said:

You say "and thats the issue" but disregard explaining the issue.... whats the weak link in this chain? Are you suggesting ships cant be built for the purpose of latching onto skyhooks? That steel/aluminum couldnt be manufactured to withhold the stresses? What stresses are you assuming the ship to be under? You have me at a loss...

You can make a rocket to be:

1) Strong enough to not be shredded by Skyhook

2) Light enough to actually overcome gravity on chemical engines to get to Skyhook

3) Cheap enough you would save money in normal operation vs. a conventional non-skyhook rocket design

Now pick only two.

 

[DStaal]

11 minutes ago, Meecrob said:

You can make a rocket to be:

1) Strong enough to not be shredded by Skyhook

2) Light enough to actually overcome gravity on chemical engines to get to Skyhook

3) Cheap enough you would save money in normal operation vs. a conventional non-skyhook rocket design

Now pick only two.

I think I'll hold off assuming costs/weights/strengths needed until I see an actual proposal for a specific design.  Lots of this depends on exactly how long the cable is, what orbit the hook is in, etc.

[Fierce Wolf]

It will have to be automatic, otherwise it's a docking at high relative speeds, which I have done before (and failed every single time).

[Snark]

19 hours ago, Bej Kerman said:

Would you like to go into the reasons anyways?

@Terwin covers some pretty good points already, a few posts above. 

Trying to put something like this into KSP would open many cans of very gnarly worms.

• Building is problematic. How do players build it?  To be useful it'll have to be extremely massive.  Ship it up in pieces?  How many pieces?  Seems like the number would be extremely large, and given that KSP is based on the idea of simple ships with a "tree" structure, trying to assemble the thing would be problematic.
• Spatially extended structures are problematic.  KSP treats ships as being small, specifically as being zero size.  This is a reasonable approximation when you're talking about things that are spacecraft-size rather than thousands of kilometeters long.  It allows KSP to use numerous simplifying assumptions that keeps the code and computations manageable.  For example, a craft is either in the atmosphere, or out of it-- there's no modeling of "the top part of the craft is in vacuum, the bottom's in atmosphere".  If it's in the atmosphere, the whole craft experiences pressure and airspeed uniformly, based on the values at a single point-- it's not as though "the bottom of the craft sees a different airspeed and pressure than the top of the craft".  Gravity is uniform for the whole craft-- the bottom of the craft doesn't experience stronger gravity because it's closer to the planet.  There's tons of stuff like that.  Something like a skyhook would blow all of those assumptions out of the water, simply by virtue of being large, regardless of how it's modeled.  Trying to solve all that will be ugly.
• Very large, floppy components are problematic.  KSP is based on ships with a reasonably small number of components, connected by reasonably stiff joints.  Giant structures like space tethers have some very complicated dynamics going on.  Either you'll have to model it as some sort of giant monolithic object that gets special treatment (in which case it's pretty disruptive to the normal flow of gameplay) or else as an assembly of many subcomponents (e.g. segments of cable), and simulating the dynamics of the whole thing would be nasty.
• Physics engine conniptions.  KSP only does active physics modeling of craft that are inside the "physics bubble", i.e. only the currently controlled ship and objects within a few kilometers of it.  Everything else is on rails.  It has to be that way because otherwise the game would bog down the CPU horribly, by forcing it to do huge numbers of calculations for huge numbers of objects, which would be a nasty O(N²) complexity problem.  Running things on rails outside a small bubble helps to limit that, and turn it into something close to an O(N) problem, which is much more computationally tractable.  However, having a giant thousands-of-kilometers-long structure would totally discombobulate such a system.  You'd have to vastly expand the physics bubble, slowing your CPU to a crawl, or else you'd have to come up with some sort of jury-rigged kludge special case solution to make it work, which would unavoidably have other side effects on gameplay.
• Playability issues.  Players have enough trouble trying to dock / connect things even when all the respective objects are in free-fall, moving at relative speeds of centimeters per second, and all the time in the world to adjust and maneuver.  To use a skyhook would require precision docking within a window of seconds to a thing that's accelerating continuously at multiple gees and (at the lower end of its arc) moving at high speeds through atmosphere.  There is no way in heck a player's going to be able to dock with that thing using "standard" KSP techniques; it will be impossibly difficult.  The only way to make it work would be either to put intrusive "here, let me fly your ship for you" autopilot into the game, or to (again) put in some sort of intrusive jury-rigged kludge mechanic that just automatically teleports you to "docked" when you get within a few kilometers of the endpoint, or something.  Yeah, you could try to spackle it over with a cutscene or the like, but it would be an interruption in gameplay, and wouldn't involve the player having to 1. design their craft skillfully, or 2. pilot it skillfully.  And if you're taking both the design and the piloting out of it, why even bother?  Might as well just give the player the ability to "launch to orbit" instead of "launch to pad" from the VAB.
• UI complexity.  However it's implemented, players are going to have to interact with the thing in a very different way than interacting with everything else in the game.  This means a whole new slew of UI affordances for dealing with all sorts of issues.  To take just one example among many, if a ship wants to rendezvous with one end of a skyhook, how do you track that in map view?  It's not in an orbit, it's continuously accelerating, which means you can't use the "closest approach to target" code that the rest of map view uses-- you'd have to have some sort of custom implementation with all the necessary UI widgets to deal with that.  Ditto all sorts of other stuff.  The devil's in the details.  Doesn't mean it couldn't be implemented, but it would be a great big chunk of work just for all that custom UI, quite aside from all the other coding to handle the physics and so forth.
• Micromanagement.  A real-life tether is going to have to either carry rocket fuel to regain momentum after it gives a ship a boost, or else it will fore the player to use it for down-bound traffic as well, and shift as much stuff down as up, in order to regain momentum.  So the player's going to have to manage the momentum of the thing, which feels like a tedious housekeeping chore.  It also means that when the player comes home, they can't just aerobrake as they do now (simple, quick, easy)-- no, they have to do another one of those rendezvous-with-the-end-of-the-tether things.  If the game doesn't want to turn all of that into a tedious bore, it would have to add yet more custom mechanics to try to automate it enough not to be a burden, so yet more hassle.

...And all of the above is what occurs to me just off the top of my head.  I'm quite sure that if one goes to actually design and implement such a feature for real, there would be scads more stuff like that, once one starts thinking it through to all the nitty-gritty nuts-and-bolts.  The devil is very much in the details for this sort of thing, and a feature such as you're asking for has many, many details.

It would be a great big honkin' ginormous feature to implement.

And that's without even considering whether there's any benefit to it, i.e. playability, what fraction of the player base would like it, etc.  I have my own concerns about this, which I could go into at length, but since it's just my opinion about what I like in a game (and my observation of what I think most players are into), I won't bore folks with it at length.  The executive summary is that just personally, I think this would be a really badly terrible idea for gameplay.  I think it would be intrusive and un-fun. I think it wouldn't add any new value to the fun of the game, while deflating much of the fun value of other aspects.  I think some of the benefits it does provide, such as they are, are likely to be somewhat redundant anyway, due to the presence of orbital colonies.  If it were present, I wouldn't use it, and its existence would bother me.  And my impression of the overall KSP player base would be that the vast majority of them wouldn't have a good use for it, either.  I just don't think this feature belongs in the game, period, even if one could wave a magic wand and get it for free.

But all of that, of course, is just my personal opinion.  If you like something different from me, great-- different people like different things.     However, regardless of how much a given player would or wouldn't like such a feature, the fact remains that it would be a hugely expensive and complicated feature to implement, and as such would suck development time away from other things.  Given how expensive it would be, and given its (I strongly suspect) limited appeal to the player base, I really can't see them implementing such a thing.  A feature that expensive would have to be justified by a huge benefit for the player base, and I'm just not seeing it.

 

[Meecrob]

Fair enough, I'm not claiming to be presenting a definitive analysis. @mcwaffles2003 said they could not see the weak link, so I was trying to illustrate reasons this design might not work.

Having said that, I feel pretty confident that whatever material they will use for skyhook will be expensive compared to steel/aluminum. In order to attach to this new material skyhook is made out of without RUD-ing, your rocket will have to either be made out of this new material (expense), or be significantly reinforced conventional materials (weight). Technically that is an assumption, yes, but it is based off of generally accepted principles in aerospace design.

Edited November 22, 2019 by Meecrob

[DStaal]

And I won't argue that there aren't significant engineering challenges - there definitely are, and they'll likely be some in material design.  I'm just saying let's not start claiming what the tradeoffs included in those challenges are until someone actually starts engineering one.   

[Terwin]

@Bej Kerman to expand on @Snark's post, would you pay for a DLC at least twice the size(and cost) of Breaking ground just for a sky-hook approximation?

Would enough players want sky-hooks enough to pay for that DLC to make it worth-while?

Personally, if I badly wanted a sky-hook approximation, I would just fly my vessel to a certain height, and then edit the orbit using the cheats menu.  Perhaps I would have a small satellite that I had to get within a certain range of while maintaining a certain altitude if I wanted more realism, but that is about as 'realistic' as it is feasible to be without breaking the game in many bad ways as mentioned previously.  (I suppose it might be even more realistic to just use the cheat menu to throw objects at your vessel until it undergoes a RUD, but I doubt that would be the sort of realistic you are after) 

 

[Incarnation of Chaos]

16 hours ago, mcwaffles2003 said:

You say "and thats the issue" but disregard explaining the issue.... whats the weak link in this chain? Are you suggesting ships cant be built for the purpose of latching onto skyhooks? That steel/aluminum couldnt be manufactured to withhold the stresses? What stresses are you assuming the ship to be under? You have me at a loss...

The entire point of a skyhook is to allow more conventional or general-purpose ships to have access to space at insanely low cost; having to build them out of exotic materials that can withstand the docking completely defeats this goal. At that point you might as well use expendable rockets.

 

[linuxgurugamer]

So here is a question.  The big issue of a skyhook is the need to have the vessel be able to withstand the stresses of connecting.

What if the skyhook went out far enough to be at the same height as an Kerbisynchronous orbit?  Then there would be no stresses on the ships caught and docked.

I see two problems with this:

First is that this would make it insanely long, 2683 km long.  The second is that it would be a major navigational hazard, blocking any real orbital activity close to the planet.  Space is big, but eventually the odds would come up with an impact, and then you have the problems of a 2683 tall structure falling to the surface.

[DStaal]

1 hour ago, linuxgurugamer said:

So here is a question.  The big issue of a skyhook is the need to have the vessel be able to withstand the stresses of connecting.

What if the skyhook went out far enough to be at the same height as an Kerbisynchronous orbit?  Then there would be no stresses on the ships caught and docked.

I see two problems with this:

First is that this would make it insanely long, 2683 km long.  The second is that it would be a major navigational hazard, blocking any real orbital activity close to the planet.  Space is big, but eventually the odds would come up with an impact, and then you have the problems of a 2683 tall structure falling to the surface.

I was reading through the Atomic Rockets page on Surface-to-Orbit to see how Skyhooks compare.  (It doesn't even make the page - it's in the 'infrastructure' section, as it's really best used in the interplanetary segments...) A better solution than this (if that's what you're going for) would be the 'Orbital Ring' - Build a complete ring in low orbit, magnetically couple it to tethers attached to the ground, climb the tethers like a space elevator.  It doesn't even have to be at the equator, if you do it right...  (No, you won't be at orbital velocity when you get off.)

But really, reading through that page there's a dozen or so cheaper and easier to build ways to get off the planet than the Skyhook.  I like the maglifter for the fact that it's all currently-in-use-at-scale tech, though it's really only a booster to ~300m/s.  (Still it saves an estimated 350 tones off the lift-off weight...)

It would still take a special-case code in the current KSP however, as the system would push the boundaries of the physics bubble.  So the question is: Which methods do the developers feel is worth writing special-case code for?

Of course we could just stick to Verne Guns, which I think people have already built in KSP...   

[Bej Kerman]

19 hours ago, Snark said:

@Terwin covers some pretty good points already, a few posts above. 

Trying to put something like this into KSP would open many cans of very gnarly worms.

• Building is problematic. How do players build it?  To be useful it'll have to be extremely massive.  Ship it up in pieces?  How many pieces?  Seems like the number would be extremely large, and given that KSP is based on the idea of simple ships with a "tree" structure, trying to assemble the thing would be problematic.
• Spatially extended structures are problematic.  KSP treats ships as being small, specifically as being zero size.  This is a reasonable approximation when you're talking about things that are spacecraft-size rather than thousands of kilometeters long.  It allows KSP to use numerous simplifying assumptions that keeps the code and computations manageable.  For example, a craft is either in the atmosphere, or out of it-- there's no modeling of "the top part of the craft is in vacuum, the bottom's in atmosphere".  If it's in the atmosphere, the whole craft experiences pressure and airspeed uniformly, based on the values at a single point-- it's not as though "the bottom of the craft sees a different airspeed and pressure than the top of the craft".  Gravity is uniform for the whole craft-- the bottom of the craft doesn't experience stronger gravity because it's closer to the planet.  There's tons of stuff like that.  Something like a skyhook would blow all of those assumptions out of the water, simply by virtue of being large, regardless of how it's modeled.  Trying to solve all that will be ugly.
• Very large, floppy components are problematic.  KSP is based on ships with a reasonably small number of components, connected by reasonably stiff joints.  Giant structures like space tethers have some very complicated dynamics going on.  Either you'll have to model it as some sort of giant monolithic object that gets special treatment (in which case it's pretty disruptive to the normal flow of gameplay) or else as an assembly of many subcomponents (e.g. segments of cable), and simulating the dynamics of the whole thing would be nasty.
• Physics engine conniptions.  KSP only does active physics modeling of craft that are inside the "physics bubble", i.e. only the currently controlled ship and objects within a few kilometers of it.  Everything else is on rails.  It has to be that way because otherwise the game would bog down the CPU horribly, by forcing it to do huge numbers of calculations for huge numbers of objects, which would be a nasty O(N²) complexity problem.  Running things on rails outside a small bubble helps to limit that, and turn it into something close to an O(N) problem, which is much more computationally tractable.  However, having a giant thousands-of-kilometers-long structure would totally discombobulate such a system.  You'd have to vastly expand the physics bubble, slowing your CPU to a crawl, or else you'd have to come up with some sort of jury-rigged kludge special case solution to make it work, which would unavoidably have other side effects on gameplay.
• Playability issues.  Players have enough trouble trying to dock / connect things even when all the respective objects are in free-fall, moving at relative speeds of centimeters per second, and all the time in the world to adjust and maneuver.  To use a skyhook would require precision docking within a window of seconds to a thing that's accelerating continuously at multiple gees and (at the lower end of its arc) moving at high speeds through atmosphere.  There is no way in heck a player's going to be able to dock with that thing using "standard" KSP techniques; it will be impossibly difficult.  The only way to make it work would be either to put intrusive "here, let me fly your ship for you" autopilot into the game, or to (again) put in some sort of intrusive jury-rigged kludge mechanic that just automatically teleports you to "docked" when you get within a few kilometers of the endpoint, or something.  Yeah, you could try to spackle it over with a cutscene or the like, but it would be an interruption in gameplay, and wouldn't involve the player having to 1. design their craft skillfully, or 2. pilot it skillfully.  And if you're taking both the design and the piloting out of it, why even bother?  Might as well just give the player the ability to "launch to orbit" instead of "launch to pad" from the VAB.
• UI complexity.  However it's implemented, players are going to have to interact with the thing in a very different way than interacting with everything else in the game.  This means a whole new slew of UI affordances for dealing with all sorts of issues.  To take just one example among many, if a ship wants to rendezvous with one end of a skyhook, how do you track that in map view?  It's not in an orbit, it's continuously accelerating, which means you can't use the "closest approach to target" code that the rest of map view uses-- you'd have to have some sort of custom implementation with all the necessary UI widgets to deal with that.  Ditto all sorts of other stuff.  The devil's in the details.  Doesn't mean it couldn't be implemented, but it would be a great big chunk of work just for all that custom UI, quite aside from all the other coding to handle the physics and so forth.
• Micromanagement.  A real-life tether is going to have to either carry rocket fuel to regain momentum after it gives a ship a boost, or else it will fore the player to use it for down-bound traffic as well, and shift as much stuff down as up, in order to regain momentum.  So the player's going to have to manage the momentum of the thing, which feels like a tedious housekeeping chore.  It also means that when the player comes home, they can't just aerobrake as they do now (simple, quick, easy)-- no, they have to do another one of those rendezvous-with-the-end-of-the-tether things.  If the game doesn't want to turn all of that into a tedious bore, it would have to add yet more custom mechanics to try to automate it enough not to be a burden, so yet more hassle.

...And all of the above is what occurs to me just off the top of my head.  I'm quite sure that if one goes to actually design and implement such a feature for real, there would be scads more stuff like that, once one starts thinking it through to all the nitty-gritty nuts-and-bolts.  The devil is very much in the details for this sort of thing, and a feature such as you're asking for has many, many details.

It would be a great big honkin' ginormous feature to implement.

And that's without even considering whether there's any benefit to it, i.e. playability, what fraction of the player base would like it, etc.  I have my own concerns about this, which I could go into at length, but since it's just my opinion about what I like in a game (and my observation of what I think most players are into), I won't bore folks with it at length.  The executive summary is that just personally, I think this would be a really badly terrible idea for gameplay.  I think it would be intrusive and un-fun. I think it wouldn't add any new value to the fun of the game, while deflating much of the fun value of other aspects.  I think some of the benefits it does provide, such as they are, are likely to be somewhat redundant anyway, due to the presence of orbital colonies.  If it were present, I wouldn't use it, and its existence would bother me.  And my impression of the overall KSP player base would be that the vast majority of them wouldn't have a good use for it, either.  I just don't think this feature belongs in the game, period, even if one could wave a magic wand and get it for free.

But all of that, of course, is just my personal opinion.  If you like something different from me, great-- different people like different things.     However, regardless of how much a given player would or wouldn't like such a feature, the fact remains that it would be a hugely expensive and complicated feature to implement, and as such would suck development time away from other things.  Given how expensive it would be, and given its (I strongly suspect) limited appeal to the player base, I really can't see them implementing such a thing.  A feature that expensive would have to be justified by a huge benefit for the player base, and I'm just not seeing it.

 

Simple - just don't handle ANYTHING like KSP did. KSP is garbage at handling literally anything that's not a plane or a rocket. KSP 2 is already getting interstellar travel, mega space stations kilometers across, a complete overhaul of timewarp, etc. I don't see why Star Theory should have the same physics of KSP 1, the same UI as KSP 1, have a physics bubble like KSP 1, etc. But then you have to look at everything that anyone wants in KSP 2 like it's going to have the same trash of a physics engine that Squad is happy with for some reason.

I mean, you say that the engine wouldn't be able to handle large structures, but we're getting massive space colonies that should run decently on most computers. You say that such large structures wouldn't be compatible with a physics bubble, but why would KSP 2 want to use a physics bubble system? You say that the UI complexity would be unbearable, but KSP 2 obviously isn't going to use the same UI as KSP 1.

For Kraken's sake, stop going on about these things like KSP 2 will use the same crappy alphabetti spaghetti code as KSP 1.

Edited November 23, 2019 by Bej Kerman

[DStaal]

2 hours ago, Bej Kerman said:

Simple - just don't handle ANYTHING like KSP did. KSP is garbage at handling literally anything that's not a plane or a rocket. KSP 2 is already getting interstellar travel, mega space stations kilometers across, a complete overhaul of timewarp, etc. I don't see why Star Theory should have the same physics of KSP 1, the same UI as KSP 1, have a physics bubble like KSP 1, etc. But then you have to look at everything that anyone wants in KSP 2 like it's going to have the same trash of a physics engine that Squad is happy with for some reason.

I mean, you say that the engine wouldn't be able to handle large structures, but we're getting massive space colonies that should run decently on most computers. You say that such large structures wouldn't be compatible with a physics bubble, but why would KSP 2 want to use a physics bubble system? You say that the UI complexity would be unbearable, but KSP 2 obviously isn't going to use the same UI as KSP 1.

For Kraken's sake, stop going on about these things like KSP 2 will use the same crappy alphabetti spaghetti code as KSP 1.

Let's address the physics bubble, as a good example.

Kerbin is 13,599,840,256,000 millimeters from Kerbol.  The largest value a 64-bit number can store is 18,446,744,073,709,551,616.  So far, so good.  We can in theory map every point on Kerbin to millimeter accuracy in a Kerbol-centric frame of reference, using three 64-bit numbers.

Wait a moment - it's probably best to be able to make Kerbol the center, so then we'll want to go negative as well.  So the largest value we can handle is now 9,223,372,036,854,775,807.  Still not a major issue, but...

Ok, let's step out.  Duna is 21,783,189,163,000 millimeters from Kerbol.  Basically the same order of magnitude.

Let's forget small steps - how about Eeloo?  113,549,713,200,000 millimeters max.  Still within the 64-bit signed int, though we're at least up another order of magnitude.  I could go on, but even Plock is only another 6 times further - not enough to make a difference yet.

(Note that *none* of these fit within a 32-bit signed int: 2,147,483,647.  So we're not going to be able to use the GPU for accelerating things here, most likely.  We're doing all calculations the long way in the CPU, not even doubling them up.)

Of course this is all within the Kerbin system - KSP2 is going to have multiple star systems.  For discussion purposes, let's declare Eeloo's AP as one 'solar system unit' - remembering Plock from Outer Planets Mod is still outside that, and still therefore reasonably close, we'd want to be at least 20 solar system units between stars.  As everything's centered on Kerbol, if the stars are equally spaced, and we have three in a row that's around 60 solar system units to the farthest star.  Still within our 64-bit signed int, but we're within a couple of orders of magnitude of the max...

Now, I haven't been talking about how the math actually works here.  Since all of this is in a universal coordinate system centered on Kerbol, any time you work out how something is moving you'll need to be computing it relative to Kerbol.  So, let's say you're driving to the monolith near the KSC.  The game needs to calculate, every frame, how far Kerbin has moved in its orbit, how much it's rotated around it's axis, how fast you're moving across the surface, how much gravity is affecting you, and move you that many millimeters in 3D space.

For every object in the universe.  Every frame.  And note that since we're stuck in 64-bit signed ints, we can't use any of the parallel processing tools that are designed around 32-bit ints.  That's going to be very slow.

Maybe there's an easier way?

A 32-bit *floating point* number can reach up to 3.4028235 × 10^38.  That's actually larger than our 64-bit *unsigned* int.  Now, the precision isn't as great - you aren't going to get millimeter precision all the way to the edge of that.  But if you use it to define a relative center from your universe center, you can then get the precision from *there.*

Let's see how that helps: From Kerbol, you can define Kerbin's center as your relative center.  Now our calculation for our rover only needs to know how far Kerbin has rotated around its axis, how fast you're moving across the surface, and gravity, and it only needs to do it for all objects working from Kerbin's center.  Oh, and since the numbers are all 32-bit, we can parallelize them through the CPU or GPU, if we're doing the same calculations on them.  If we center our relative center on the ship itself instead, we can also ignore (for the moment) Kerbin's rotation around its axis, leaving us with just the speed across the surface and gravity.

Of course, we've just created a 'bubble'.  Now, I'm working with millimeter-level precision.  For a lot of interactions, that's basically the minimum acceptable - we'd like better.  And the smaller the bubble the less *other* ships we need to calculate - ideally we'd only need to calculate the ship you're flying and the ship you're docking to.  The more we can push out of the bubble, the faster the game will respond as we can put everything else on 'rails' and just calculate where it is based on simple conic sections when we next need to look at it.

So the bubble is not a spaghetti hack - it's *good optimization.*  In fact, it's something KSP1 added in over time to address the original Kraken.  Contrary to stripping it out, from what we have seen KSP2 is doubling down on it - even your current ship/base will have some form of the bubble, where the parts of the ship you're looking at will be calculated to higher precision and the parts far away will be calculated at lower precision, in the name of performance.  Heck, every game in existence that has more than one level is doing something similar.

So you're decrying as crappy spaghetti code one of the basic things that make it possible for KSP to run at reasonable rates at all.

[sturmhauke]

I've seen the O(N²) thing mentioned a couple times now, so I thought I'd expand on that. It's called Big-O notation, and it's a way to talk about the complexity of a problem, and roughly the time it takes to solve. N is the number of elements in the problem space. O(N) would mean that the time to solve is proportional to the number of elements. O(N²) means that the time to solve is proportional to the square of the number of elements - in other words, doubling the elements quadruples the time to solve.

Physics is an O(N²) problem because everything interacts with everything else. The reason for the physics bubble is that for most things, gravity is negligible and the only really important problems are collisions and aero effects if applicable. Therefore you can keep the N low. But with a giant, hundreds-of-km-long skyhook, suddenly your bubble has to be bigger than that, or you have to code it differently.

[linuxgurugamer]

6 hours ago, Bej Kerman said:

Simple - just don't handle ANYTHING like KSP did. KSP is garbage at handling literally anything that's not a plane or a rocket.

Ok, you’ve made a very strong statement.  Please back it up with facts.

How about pointing to another game which solves the same problems that KSP does in a better way?

and, did you really need to quote the entire post?

[sturmhauke]

On 11/21/2019 at 8:25 PM, mcwaffles2003 said:

Did you watch the vid? The hook wouldnt be in the thick part of the atmosphere

The video posits that the hook would dip down to 80-150 km. Earth's Karman Line is defined at 100 km, and Kerbin's is at 70 km, which would put the hook at 56-105 km. 56 km is low enough to see aerodynamic heating at the speeds stuff would be travelling at, and 105 km is already out of the atmosphere and you might as well just carry a bit more dV to make orbit.

A space elevator is probably easier to do, even if you have to write special code for it. It doesn't move horizontally or rotate relative to the surface, which simplifies a lot of the problem.

[Gargamel]

8 hours ago, Bej Kerman said:

I mean, you say that the engine wouldn't be able to handle large structures, but we're getting massive space colonies that should run decently on most computers. You say that such large structures wouldn't be compatible with a physics bubble, but why would KSP 2 want to use a physics bubble system?

Most of us aren't wealthy enough to own a supercomputer good enough to model the entire universe, and still keep a playable frame rate.    

[Snark]

9 hours ago, Bej Kerman said:

I don't see why Star Theory should have the same physics of KSP 1, the same UI as KSP 1, have a physics bubble like KSP 1, etc.

I know, and I totally sympathize. I get that it's hard to understand this stuff, if you're not a programmer-- you'll recall that I pointed out that very concern at the start of all this. 

Executive summary is that "there are good reasons, and KSP 2 will have to solve many of the same problems that KSP 1 did, so it's not surprising that they'd have similar algorithms."  Folks in the few posts above have already provided a lot of good explanation of why a lot of these things are the case.  If you're having trouble following along, I'm sure folks would be happy to provide references for specific points that may be puzzling.

9 hours ago, Bej Kerman said:

I mean, you say that the engine wouldn't be able to handle large structures, but we're getting massive space colonies that should run decently on most computers.

Sure.  Because the space colonies will likely only be on the order of hundreds of meters in size, not hundreds of kilometers, meaning that they oughtn't need new algorithms to model them.

9 hours ago, Bej Kerman said:

You say that such large structures wouldn't be compatible with a physics bubble, but why would KSP 2 want to use a physics bubble system?

Because O(N²).  Because it's a good optimization and is necessary unless you want to force people to have a supercomputer to run the game.  Because it was a good idea when KSP 1 was written, and is still a good idea today.  Computers have gotten more powerful... but N is also getting bigger, and the fundamental issue with O(N²) remains.

Folks have already given a pretty good explanation of this in the posts above this one.  If you're still having trouble grasping the concept, here's a handy reference.

I recognize that that's a lot of technical detail to wade through, and I wouldn't blame you if you don't have the patience for it-- but if you'd prefer not to wade through it all, then about all you're left with is "people who have been doing this sort of a living for many years think it's a good idea", which I suspect would not be a very satisfying answer. 

9 hours ago, Bej Kerman said:

You say that the UI complexity would be unbearable, but KSP 2 obviously isn't going to use the same UI as KSP 1.

Sure.  And I didn't say that it would be "unbearable".  Simply that it would require a lot of specialized UI that would only be necessary for skyhooks, and which they wouldn't have to implement if skyhooks weren't in the game.

Implementing a complex feature is expensive.  It's just how software development works.  And resources are very finite, and there's never enough time to implement all the stuff one wants.  All I'm saying is that this would be an expensive feature that wouldn't provide benefits to other, non-skyhook stuff, so it would be a poor use of their resources to implement unless it were a really important feature with extremely high demand.  Which it doesn't appear to be.

Because of the finite resource in software development, it's always really important to try to get a whole lot of "bang for the buck".  And this feature would be a lot of bucks for not very much bang, that's all.

9 hours ago, Bej Kerman said:

For Kraken's sake, stop going on about these things like KSP 2 will use the same crappy alphabetti spaghetti code as KSP 1.

I expect that it'll do better at optimizing a lot of places where KSP 1 has rough edges-- for example, improving the physics engine to run more efficiently, so they can support higher part counts.

But the fundamental computational challenges remain the same, because 1. math, and 2. physics.  Math is math, and physics is physics, and these things don't change with new software versions.  That's why some of the basic simplifying assumptions-- such as patched conics for orbital mechanics, or the physics bubble-- will likely still be with us.

Unless you have some suggestions about how to turn craft physics into an O(N) problem? 

[nikokespprfan]

for the sake of argument, I want to challenge a few complaints about implementing it (EDIT: And then proceed to trow it all away again.)

1) Long vessels need extra code to account for gradient effects.

Spoiler

We don't. Case in point: Gilly can not be de-orbited. It is a big, giant pebble, that is therefore put on rails like all other bodies in the solar system. And can you imagine what hellish nightmare not having Gilly on rails would be. Pfoo ; Its an SOI gone rogue. We'd need to think about at least 3-body physics, and we all know how bad and chaotic that becomes. Surely this must mean gilly cannot exist in game.

But no, instead gilly is on rails, it is a very simple thing described by unchanging conic sections, and we do not have that mess. This is feasible because gilly is big, heavy, and most importantly, protected by the devs refusing to play ball with anyone attempting to deorbit it.

IF a skyhook is properly built and positioned, it is a stupendously heavy rigidbody with cables thaughtly dangling in at most a thin part of the atmosphere. An object whose only experience of airdrag is slowing down their CoM speed and slowly de-orbiting (assuming any other effects to be negligable), and whose only further experience with momentum change is the ships it propells: m x v coming in, m x v going out. It will not experience weather (due to the distinct lack of weather in KSP), it will not experience tidal or tensile stresses (it is not long enough for that, and we don't really care about tides anyway), and it's counterweight center makes sure we can approximate it like we do a pendulum in our first physics class: a massless cord with a weight at one end.

As long as the thing is built well, in the way the video suggested, a substantial simplification will work relatively well, and few of us will complain about lacking accuracies we don't really care for....

2) We have trouble simulating the vessel at large distances because of physics bubbles.

Spoiler

Since we are already putting the tether on simplified physics, we might as well do so for the position of the tip. The position of the tip is given by cycloid curves, which can be calculated exactly (from a mathematical point of view) because we approximated the distortions away in point 1. The only thing is momentum change through docking, which means updating the "orbit" whenever something docks, maybe with a constant drag of pretended atmosphere on top,... nothing crazy. That we can calculate this exactly immediately pre-empts every physics bubble issue. We know where it will be, there is no physics required, you don't need to simulate the teather tip as actually being connected to the counterwheigt in the same way we imagine for ships. It can just be a "ship" moving under unnatural but known forces, fake thether stretching up to an invisible, unloade counterweight, simulating only that docking robot at the end.

Again, as long as the thing is built well, few of us will complain about lacking accuracies we don't really care for....

But this is KSP we are talking about.

Spoiler

The thing will not be constructed properly. Who do you think we are, people who only do what the code expects us to? Nonononono. We are not sensible enough to give it a wheighty counterwheight CoM, or to put that CoM neatly outside the atmosphere. Don't expect us to make the thether short enough to be realistic strengthwise. Also don't expect us to use it properly. Danny will definately try to break the tip by crashing into the cable at rediculous speeds. How catastrophically does it break when I let it spin sideways, or at an angle, or when i crash it into the atmosphere. What if I let it's center of mass move along weird orbits or beween SOI's. *miniacly wringing hands under a proper evil laugh* *calms down to a relaxed tone*

We can and will bring the code to its knees, and when we do, that is when we need to resort to actually simulate the darn thing in minute detail.

... unless....

Unless building a skyhook is like building a colony. Once you have completed it, all the complex dynamics keeping the system operational will be neglected because you have succeded in your goal. From now on, it just works. It is, after all, a megastructure. The question is, will we be satisfied by that?

3) The tip is satationary at the ground.

Spoiler

I was going to bring this up. The original plan is to do it in such a way that the tip is stationary when you want to dock, like the contact point of a wheel is stationary on the ground. However there is orbital velocity to account for, and that is if the player sets it up correctly.

If the tip was stationary however, that reduces the complications of it tremendously, from everything from docking to what parts/materials do i build my ships out of.

I was going to bring this up, but it's false upon closer inspection and so my point is moot

Edited November 23, 2019 by nikokespprfan

[Motokid600]

Ill never understand the obsession with these overly intricate alternative methods of getting to orbit. What's wrong with basic reusable rockets?