Variable sphere of influence

[lajoswinkler]

This occured to me a long time ago so I've decided to finally suggest it. I was looking at Ascension, the comet from Kragathea's Planet Factory, nowdays resurrected as Sentar Expansion. That body is on a highly eccentric orbit and always has the same SOI.

That does not happen in real life even if we ignore the n-body physics. SOI depends on the proximity to the orbiting body. If it's close to a massive one, its SOI will be smaller, and vice versa, considering its constant mass and volume. Because of this, you could be in a defined large orbit around a comet when it's far away from the Sun, but when it comes closer, you'd continue your way on an independent solar orbit. (In extreme cases, if the body approaches too close, it's not even holding its shape - it's smearing along its orbit, coming apart. It's the known Roche limit.)

 

I know n-body mechanism would be difficult to implement and cause a great deal of issues for all but very experienced players, but variable SOI shouldn't be a problem. Implemented into KSP, this would mean very large orbits around planetary bodies would be unstable and it would provide a new challenge.

I'd like to see this one day, especially if (hopefully) we get a comet in the Kerbol system.

[SpaceplaneAddict]

This would make Jool missions very.... interesting

[lajoswinkler]

Indeed it would. Bop and Pol. Satellites in very high orbits around them would experience detachments.

Laythe, Vall and Tylo have a circular orbit so their satellites wouldn't see any such things.

Moho has a pretty eccentric orbit so Kerbol could steal its high orbit satellites.

Edited February 27, 2016 by lajoswinkler

[SpaceplaneAddict]

And Dres and Eeloo would also have the same consequences

 

[lajoswinkler]

True, but a lot less pronounced because they're in the shallow parts of the Kerbol's gravity well.

[Hotaru]

In the stock system I think Gilly is where it'd be most noticeable. The upside is it'd be a lot less tricky to get an encounter if it was near apoapsis.

[SpaceplaneAddict]

2 hours ago, Hotaru said:

In the stock system I think Gilly is where it'd be most noticeable. The upside is it'd be a lot less tricky to get an encounter if it was near apoapsis.

And Gilly's SOI near Pe would shrink to the point of nothing.... probably.

[RocketPropelledGiraffe]

I am not sure for stock KSP. Gilly with its high eccentricity would certainly be affected the most - What SOI reduction would we be talking about?

The basic in-game consequence would be to simply make all orbits tighter so there will be no accidents during time warp. Most people (including me) propably don't enjoy continuously shepherding all their missions, they would just bring more delta v to avoid the effects. And if everyone would avoid the effect, then what's the point anyway?

Now for comets, that's a different story entirely. First of all, comets should totally be in stock. If they are implemented with their own SOI and gravity (and a Rosetta-Philae style mission would be soooo cool) the resulting problems have to be dealt with reasonably and as realistically as possible within the bounds of KSP's simplifications.
That not only includes the details for orbiting probes and possibly variable SOI  - although a stable orbit should always be possible to avoid the shepherding problem - but also interaction with other bodies. If a Gilly-sized comet flies very close to Bop there should be an effect. Dealing with all of this is devastating for the on-rails system, that's why we will propably never see it in stock and propably also why Squad chose to give the asteroids no gravity of their own. I am pretty sure that was the most sensible decision, even though it makes me a little sad everytime I encounter an asteroid...

 

Edit: Ok, I just put in the numbers really quick for Gilly. Assuming that instead a constant SOI size based on the semi-major axis the SOI is calculated dynamically using the actual distance between Eve and Gilly, the SOI at apoeve would be 195 km and 56 km at perieve. That's certainly a big difference, but there would still be no problems to maintain a stable orbit.

Edited February 27, 2016 by RocketPropelledGiraffe

[pandaman]

I quite like that idea. 

Definitely needs an on/off toggle in save difficulty settings though.  And suitable explanations. 

It seems to fit with how I see the 'stock' game developing, in terms of adding simple representations of real life spaceflight considerations in stock.  With more complex/realistic interpretations being provided by mods.

[lajoswinkler]

9 hours ago, Hotaru said:

In the stock system I think Gilly is where it'd be most noticeable. The upside is it'd be a lot less tricky to get an encounter if it was near apoapsis.

Gilly's apoapsis is 48 825 km and its periapsis is 14 175 km. That would be an awesome challenge.

 

3 hours ago, RocketPropelledGiraffe said:

I am not sure for stock KSP. Gilly with its high eccentricity would certainly be affected the most - What SOI reduction would we be talking about?

The basic in-game consequence would be to simply make all orbits tighter so there will be no accidents during time warp. Most people (including me) propably don't enjoy continuously shepherding all their missions, they would just bring more delta v to avoid the effects. And if everyone would avoid the effect, then what's the point anyway?

Now for comets, that's a different story entirely. First of all, comets should totally be in stock. If they are implemented with their own SOI and gravity (and a Rosetta-Philae style mission would be soooo cool) the resulting problems have to be dealt with reasonably and as realistically as possible within the bounds of KSP's simplifications.
That not only includes the details for orbiting probes and possibly variable SOI  - although a stable orbit should always be possible to avoid the shepherding problem - but also interaction with other bodies. If a Gilly-sized comet flies very close to Bop there should be an effect. Dealing with all of this is devastating for the on-rails system, that's why we will propably never see it in stock and propably also why Squad chose to give the asteroids no gravity of their own. I am pretty sure that was the most sensible decision, even though it makes me a little sad everytime I encounter an asteroid...

 

Edit: Ok, I just put in the numbers really quick for Gilly. Assuming that instead a constant SOI size based on the semi-major axis the SOI is calculated dynamically using the actual distance between Eve and Gilly, the SOI at apoeve would be 195 km and 56 km at perieve. That's certainly a big difference, but there would still be no problems to maintain a stable orbit.

The point is to add a challenge to the game. It's not a difficult one. It's actually a minor one a great deal of players wouldn't even notice because people tend to park their vessels in tighter orbits. It would just cause vessels to slip from SOI if they're parked unusually high.

As you've calculated, one would need to keep anything below 56 km (an in-game dotted line marking the stable orbit). 56 km above Gilly is a lot.

 

If we're going to question the validity of such challenge, then why do we have electricity as a resource? Using the logic you mentioned, we could say there's no need for it because everyone will avoid loss of power by installing solar panels or an RTG unit.

I think this is a great compromise between what we have now and n-body system. Only certain bodies would be affected, no radical changes would occur and interesting missions could be created. If newbies would consider it to be too difficult, it could be switched off in the difficulty settings.

 

(I'd keep the on rails system and avoid small body interactions. As I've said, n-body system would be very difficult and it would cause mayhem and completely unreliable data and chaos. Kerbol system is too small and usage of high timewarp is too often for such thing to be implemented.)

[Whirligig Girl]

8 hours ago, SpaceplaneAddict said:

And Gilly's SOI near Pe would shrink to the point of nothing.... probably.

Actually the SOIs are computed from the point of the periapsis, not the semi-major-axis or Apoapsis. So Gilly's SOI would only get larger or stay the same as it is now, not smaller.

 

 

On the topic of variable SOIs, I'm not sure how feasible this is. The orbit system is meant to be deterministic (so you know where something will be at whatever time at all) so a variable SoI could screw things up. That said, it would be a cool feature if it could work without breaking the orbit system.

 

A compromise in the case of adding a comet would be to simply use the SOI size at the semi-major-axis distance instead of the periapsis distance, so you get an average of the possible ranges of SOIs. However, this is less realistic. Having a planet or moon have a smaller SOI most of the time is less physics breaking than having a planet or moon have a larger SOI for some of the time, because if an SOI is too big, you get weird screwy physics like subsatellite orbits that take longer than the satellite's orbital period.

(Correct me if I'm wrong here)

Edited February 27, 2016 by GregroxMun

[nikokespprfan]

On 27-2-2016 at 2:32 PM, GregroxMun said:

On the topic of variable SOIs, I'm not sure how feasible this is. The orbit system is meant to be deterministic (so you know where something will be at whatever time at all) so a variable SoI could screw things up. That said, it would be a cool feature if it could work without breaking the orbit system.

Well, the game could know the upper and lower boundaries of each SOI and the time in between reaching lowest SOI and highest SOI. Maybe if the game knows the SOI border height as a periodic function of time, wherever the game asks for that border height, it will get a function instead of a constant value. The time is known by the computer, and thus the output should work as expected. But then again I have more knowledge of maths than of coding, so I might be wrong.

You could also have this only affect certain bodies, just like asteroids do not have gravity and planets are not movable.

Another simplification could be SOI seasons. Instead of having constantly changing SOI, you divide the orbit in different seasons, and during each season the SOI height is the same. This is just some brainstorming though.

Edited February 28, 2016 by nikokespprfan

[lajoswinkler]

It's a simple thing, any calculator could chug out the numbers on the go.

[Kerbart]

On 2/27/2016 at 8:37 PM, lajoswinkler said:

(...) Implemented into KSP, this would mean very large orbits around planetary bodies would be unstable and it would provide a new challenge. (...)

Challenges can be fun and when implemented in such a way that you would only encounter them in advanced stages (beginners who struggle to land on Minmus will not be engaged in intercepting comets or asteroids) it wouldn't affect playability that much.

The whole point of patched conics though is that it is deterministic and doesn't rely on iterative calculations. Wouldn't this interfere with that (the word “unstable” caught my attention)?

[lajoswinkler]

1 hour ago, Kerbart said:

Challenges can be fun and when implemented in such a way that you would only encounter them in advanced stages (beginners who struggle to land on Minmus will not be engaged in intercepting comets or asteroids) it wouldn't affect playability that much.

The whole point of patched conics though is that it is deterministic and doesn't rely on iterative calculations. Wouldn't this interfere with that (the word “unstable” caught my attention)?

As I've said, the unstable region would span in very high orbits where rarely anyone parks stuff. Those orbital heights usually pass unnoticed. Early in the gaming experience the players don't even encounter places with significant differences. Minmus is not one of those places.

 

I don't understand why is everyone so scared of "what will the newbies say". Same things happened with reentry heating. Years of "OMG, think of the n00bs!". Nowdays rarely anyone remembers it.

[Jim DiGriz]

This feature probably falls right out of Principia (along with many others):

 

 

[pandaman]

I think 'unstable' is possibly the wrong word as this can be interpreted to give a sense of randomness, though I struggle to find a better one.

I'm not sure how easy it could be for the game to calculate or predict the size of a SOI in advance, but when using a monouvre node to get an encounter then the game knows the positions of the bodies at the time of the encounter so, I guess, it should be able to calculate the SOI boundary position at that point.

Also the maximum 'safe' altitude and SOI size will not change, so can be added to the KSPedia database, any orbit in between those will be subject to disturbance at some point.  When entering orbit around a body you can see from the map view where it is in its orbit around its parent so you can make a rough judgement how long you have before you risk losing stable orbit and plan accordingly.

[lajoswinkler]

It's deterministic and predictable as anything in KSP. Bodies are still on rails, there is no n-body simulation. No randomness, simply one more thing to worry about if you're gonna park in wacky orbits.

[juanml82]

KSP is based on having stable orbits. No atmospheric drag, no n-body, no variable SOIs.

This could be changed, but it needs a station keeping GUI, to eliminate micromangment. Otherwise, you need to add dozens of KAC alarms (oops, not stock!) for every time a vessel's orbit has to be corrected.

So, instead, you'd need information about dV required to keep an specific orbit over an specific body through a specific timeframe in the VAB/SPH so the player can plan accordingly, and a station keeping system (with a toggle for those who like micromanagment) which makes periodic burns while the ship is out of focus to keep the orbit stable until the player chooses to let the orbit decay, or changes the vessel's orbit manually.

 

However, I this is the kind of overhaul better suited for a KSP 2 and I wonder if it has any meaningful effects, other than forcing players to add more fuel to their ships and giving realistic ion engines another use. Essentially, the game puts a system in place to realistically destabilize orbits but, if you want to avoid micromanagment, you also need another system to cancel it.

[Wjolcz]

Sounds like a good idea, as long as there were some warnings and time predictions about when a vessel will leave the SOI.

[lajoswinkler]

If you're gonna park in enormously high orbits where the variation applies and where seldom anyone ever parks anything, yes, an alarm would be a good thing. It could be used for spontaneous generation of missions.

This suggestion is not about creating nondeterministic systems. I repeat - stuff is on rails and the effect appears far away from bodies' surfaces. Present day SOI radiuses are calculated for their periapses, so SOIs would only oscillate between present value and some larger one. Not fluctuate, but oscillate. Predictable, periodic function.

[KSP Bro AE]

great idea

[Hydrazine_Soup]

I'd love to see this in the game

[Streetwind]

I'm not sure how viable this is - I have a hunch that it's largely a question about how vessels on rails are handled internally - but I like the idea in principle. I don't even think it requires a whole lot of extra explanation. It's just another quirk of physics that a player eventually discovers, and internalizes relatively quickly.

[Snark]

On 3/1/2016 at 10:01 AM, juanml82 said:

KSP is based on having stable orbits. No atmospheric drag, no n-body, no variable SOIs.

I wouldn't lump all those together.  Variable SOIs are in a very different category from atmospheric drag and n-body.  The former is a "don't" the latter two are "can't."

KSP really, really can't have orbits with atmospheric drag or n-body, because those require iterative modeling and either one would prevent ships from being able to run on rails.

However, variable SoI isn't like that.  You can run on rails just fine with a variable SoI, as long as it's deterministic.  So in principle I see no reason why KSP can't do this or why it should be particularly hard.

That said:  how hard it would actually be depends on how the internal code is written and how flexible it is.  To take an example:  Axial tilt.  There's no a priori reason why planets in KSP shouldn't be able to have any arbitrary axial tilt, but they're all zero.  Why?  Not for any fundamental mathematical or computational reason, but just because they took some shortcuts in coding in the early days of KSP, and now it's baked into the system everywhere and trying to rip that out and change it would be a massive, ugly coding task.

So for all I know, variable SoIs might be in that category, and be a non-starter just due to the way the code is set up.  But there's no reason in principle why it has to be hard.

On 3/1/2016 at 10:01 AM, juanml82 said:

This could be changed, but it needs a station keeping GUI, to eliminate micromangment. Otherwise, you need to add dozens of KAC alarms (oops, not stock!) for every time a vessel's orbit has to be corrected.

Why?  How is this any different from the game now, really?

Imagine than you're in orbit of, say, Duna.  There are "safe" orbits where you can park a satellite-- ones that are low enough or high enough that there's zero chance they will ever blunder within reach of Ike and have something unpleasant happen to them.  And then there's an enormous donut-shaped region around Duna-- Ike's domain-- where you try to orbit Duna at your peril.  You can put a ship in orbit there, but sooner or later it'll meet Ike and hilarity will ensue.

But that's okay because the player knows about it and knows where the boundaries are and therefore can plan around it.  I can orbit Duna just fine, without micromanagement, if I want to:  just put my ship in an orbit that I know is safe from Ike.

I see variable SoIs as the exact moral equivalent.  I know what the minimum and maximum SoI are for the planet I'm orbiting.  It would be displayed right there on the info panel in the map window.  So if I want a safe orbit that's guaranteed to be stable forever and I don't need to keep an eye on it, that's easy:  just park it where the Ap is below the minimum SoI.  And I know when and where the SoI will be big or little, so I can easily plan around that, too, just as I can plan around Ike's behavior.

Variable SoI would require neither more nor less micromanagement than orbiting a planet with a massive moon does.

On 3/2/2016 at 0:49 PM, lajoswinkler said:

This suggestion is not about creating nondeterministic systems. I repeat - stuff is on rails and the effect appears far away from bodies' surfaces. Present day SOI radiuses are calculated for their periapses, so SOIs would only oscillate between present value and some larger one. Not fluctuate, but oscillate. Predictable, periodic function.

^^ This.  This right here.  It wouldn't break anything, it would be (in principle, dunno about their actual code) straightforward to simulate, it would be entirely predictable, it wouldn't require the player to do anything they're not doing already anyway, and it would add a degree of flexibility to the game by making very eccentric elliptical planetary orbits more possible.

Edited March 4, 2016 by Snark