Altaïr
Space Stig, Master of gravity
Staff member
Head Moderator
Team Kolibri
Modder
TEAM HAWK
Atlas
Deja Vu
Under Pressure
Forum Legend
[BETA] ANAIS: Advanced NAvigation Innovative System
- Thread starter Altaïr
- Start date
Hello,
First of all, this mod is amazing. It’s really made interplanetary missions and docking easier, telling you the most efficient transfer and when to decelerate to dock with a craft. However, there’s one problem currently in the mod, which is the transfer window sometimes not showing until you escape a planet’s sphere of influence. I do use a planet pack on my main save but the same thing happened on a default world. Would be great if you could fix the issue if possible.
First of all, this mod is amazing. It’s really made interplanetary missions and docking easier, telling you the most efficient transfer and when to decelerate to dock with a craft. However, there’s one problem currently in the mod, which is the transfer window sometimes not showing until you escape a planet’s sphere of influence. I do use a planet pack on my main save but the same thing happened on a default world. Would be great if you could fix the issue if possible.
Altaïr
Space Stig, Master of gravity
Staff member
Head Moderator
Team Kolibri
Modder
TEAM HAWK
Atlas
Deja Vu
Under Pressure
Forum Legend
There is a problem with algorithm of Closest Approach Line mod. This problem was in Closest Approach Line right from the start and it persists up to now. And ANAIS has it too.
When our ship in focus has some not resonant orbit with some celestial body and intersects this body's orbit - we see two green lines with distances and number of laps in our orbit, after which these positions will be met.
Then if we burn our engine to change our orbit - we can see how green lines become longer or shorter with new distance numbers. That would be closest approach, which is calculated by the mod up to 12 laps ahead. There will be no closer points to targeted celestial body within 12 laps if we don't change our orbit.
For example, i see, that over 12 laps i will be 200 MM from target. Then i start burning engine in direction, which reduces this number. While i am burning i see how this number 200 MM becomes smaller, 198 MM, 170 MM, 153 MM, and so on. I want to reduce it "to zero", so i could meet with my target over 12 number of laps.
But while i am burning and looking at how this number decreases - this green line simply vanishes and is replaced by a new green line, which is MUCH longer, and shows for example, that meeting will be after 11 or 10 laps instead of 12, and it will happed 400MM away from intersection point. If i burn further - this 400 MM reduces again, to 350, then 300, then 270, but now it vanishes again - and i see a new line again, which is 400 MM or 500 MM and says for example 9 laps. While real CLOSEST line is actually still after 12 laps - it would be something like 20-30 MM away from intersection point. Next closest line will be over 11 or 10 laps and that is 270 MM away, but i don't see any of these two lines, so i can't make resonate orbit to meet there after 10, 11 or 12 laps - instead mod shows only a much longer green line for 9 laps choice and i have to burn again a lof of fuel to reduce 400MM+ for meating after 9 laps. And guess what happens next if i will do that new burning?
For now, i solve this problem in this way: i make burning blindly (after green line disappeared and replaced for a longer new one) to change my orbit enough to be where i need to be over 12 laps, then i timewarp and after many laps those more longer green lines vanish and replaced by original shortest close line, which was real closest. And then i can see how much did i missed. Then i load quicksave and burn more or less again blindly, not seen 12 laps green line and seen only 9 laps green line for 400MM+.
Thus after several trials and errors i finally meet some good approximation and after, for example, 5 or 8 laps from 12 i can see how green line to real closes approach returns and i can make further corrections already from that point in game.
This also happens if i do not burn at all.
For example i was lucky enough and closest green line was never vanished and replaces, and thus i established meeting point over 10 laps. Then i go timewarp and after 1 or 2 laps this green line (which is already small like a dot) vanishes and replaced for much longer green line for 3 or 7 laps for example, and only after many more laps new long green line will be discarded and original short (like a dot) will come back on the screen, so i could make 1 or several more laps and finally get en encounter.
Solution with quicksaves by trials and errors by going blindly is kind of not hard to implement and it consumes little time thanks to timewarps. But it is still very sad solution.
By all means, this is not a priority problem, it can be addressed after more important issues are solved and other work is finished.
I only think that this great mod would just look much better if such thing with disappearing closest lines would never happen.
When our ship in focus has some not resonant orbit with some celestial body and intersects this body's orbit - we see two green lines with distances and number of laps in our orbit, after which these positions will be met.
Then if we burn our engine to change our orbit - we can see how green lines become longer or shorter with new distance numbers. That would be closest approach, which is calculated by the mod up to 12 laps ahead. There will be no closer points to targeted celestial body within 12 laps if we don't change our orbit.
For example, i see, that over 12 laps i will be 200 MM from target. Then i start burning engine in direction, which reduces this number. While i am burning i see how this number 200 MM becomes smaller, 198 MM, 170 MM, 153 MM, and so on. I want to reduce it "to zero", so i could meet with my target over 12 number of laps.
But while i am burning and looking at how this number decreases - this green line simply vanishes and is replaced by a new green line, which is MUCH longer, and shows for example, that meeting will be after 11 or 10 laps instead of 12, and it will happed 400MM away from intersection point. If i burn further - this 400 MM reduces again, to 350, then 300, then 270, but now it vanishes again - and i see a new line again, which is 400 MM or 500 MM and says for example 9 laps. While real CLOSEST line is actually still after 12 laps - it would be something like 20-30 MM away from intersection point. Next closest line will be over 11 or 10 laps and that is 270 MM away, but i don't see any of these two lines, so i can't make resonate orbit to meet there after 10, 11 or 12 laps - instead mod shows only a much longer green line for 9 laps choice and i have to burn again a lof of fuel to reduce 400MM+ for meating after 9 laps. And guess what happens next if i will do that new burning?
For now, i solve this problem in this way: i make burning blindly (after green line disappeared and replaced for a longer new one) to change my orbit enough to be where i need to be over 12 laps, then i timewarp and after many laps those more longer green lines vanish and replaced by original shortest close line, which was real closest. And then i can see how much did i missed. Then i load quicksave and burn more or less again blindly, not seen 12 laps green line and seen only 9 laps green line for 400MM+.
Thus after several trials and errors i finally meet some good approximation and after, for example, 5 or 8 laps from 12 i can see how green line to real closes approach returns and i can make further corrections already from that point in game.
This also happens if i do not burn at all.
For example i was lucky enough and closest green line was never vanished and replaces, and thus i established meeting point over 10 laps. Then i go timewarp and after 1 or 2 laps this green line (which is already small like a dot) vanishes and replaced for much longer green line for 3 or 7 laps for example, and only after many more laps new long green line will be discarded and original short (like a dot) will come back on the screen, so i could make 1 or several more laps and finally get en encounter.
Solution with quicksaves by trials and errors by going blindly is kind of not hard to implement and it consumes little time thanks to timewarps. But it is still very sad solution.
By all means, this is not a priority problem, it can be addressed after more important issues are solved and other work is finished.
I only think that this great mod would just look much better if such thing with disappearing closest lines would never happen.
Altaïr
Space Stig, Master of gravity
Staff member
Head Moderator
Team Kolibri
Modder
TEAM HAWK
Atlas
Deja Vu
Under Pressure
Forum Legend
There is a problem with algorithm of Closest Approach Line mod. This problem was in Closest Approach Line right from the start and it persists up to now. And ANAIS has it too.
When our ship in focus has some not resonant orbit with some celestial body and intersects this body's orbit - we see two green lines with distances and number of laps in our orbit, after which these positions will be met.
Then if we burn our engine to change our orbit - we can see how green lines become longer or shorter with new distance numbers. That would be closest approach, which is calculated by the mod up to 12 laps ahead. There will be no closer points to targeted celestial body within 12 laps if we don't change our orbit.
For example, i see, that over 12 laps i will be 200 MM from target. Then i start burning engine in direction, which reduces this number. While i am burning i see how this number 200 MM becomes smaller, 198 MM, 170 MM, 153 MM, and so on. I want to reduce it "to zero", so i could meet with my target over 12 number of laps.
But while i am burning and looking at how this number decreases - this green line simply vanishes and is replaced by a new green line, which is MUCH longer, and shows for example, that meeting will be after 11 or 10 laps instead of 12, and it will happed 400MM away from intersection point. If i burn further - this 400 MM reduces again, to 350, then 300, then 270, but now it vanishes again - and i see a new line again, which is 400 MM or 500 MM and says for example 9 laps. While real CLOSEST line is actually still after 12 laps - it would be something like 20-30 MM away from intersection point. Next closest line will be over 11 or 10 laps and that is 270 MM away, but i don't see any of these two lines, so i can't make resonate orbit to meet there after 10, 11 or 12 laps - instead mod shows only a much longer green line for 9 laps choice and i have to burn again a lof of fuel to reduce 400MM+ for meating after 9 laps. And guess what happens next if i will do that new burning?
For now, i solve this problem in this way: i make burning blindly (after green line disappeared and replaced for a longer new one) to change my orbit enough to be where i need to be over 12 laps, then i timewarp and after many laps those more longer green lines vanish and replaced by original shortest close line, which was real closest. And then i can see how much did i missed. Then i load quicksave and burn more or less again blindly, not seen 12 laps green line and seen only 9 laps green line for 400MM+.
Thus after several trials and errors i finally meet some good approximation and after, for example, 5 or 8 laps from 12 i can see how green line to real closes approach returns and i can make further corrections already from that point in game.
This also happens if i do not burn at all.
For example i was lucky enough and closest green line was never vanished and replaces, and thus i established meeting point over 10 laps. Then i go timewarp and after 1 or 2 laps this green line (which is already small like a dot) vanishes and replaced for much longer green line for 3 or 7 laps for example, and only after many more laps new long green line will be discarded and original short (like a dot) will come back on the screen, so i could make 1 or several more laps and finally get en encounter.
Solution with quicksaves by trials and errors by going blindly is kind of not hard to implement and it consumes little time thanks to timewarps. But it is still very sad solution.
By all means, this is not a priority problem, it can be addressed after more important issues are solved and other work is finished.
I only think that this great mod would just look much better if such thing with disappearing closest lines would never happen.
When our ship in focus has some not resonant orbit with some celestial body and intersects this body's orbit - we see two green lines with distances and number of laps in our orbit, after which these positions will be met.
Then if we burn our engine to change our orbit - we can see how green lines become longer or shorter with new distance numbers. That would be closest approach, which is calculated by the mod up to 12 laps ahead. There will be no closer points to targeted celestial body within 12 laps if we don't change our orbit.
For example, i see, that over 12 laps i will be 200 MM from target. Then i start burning engine in direction, which reduces this number. While i am burning i see how this number 200 MM becomes smaller, 198 MM, 170 MM, 153 MM, and so on. I want to reduce it "to zero", so i could meet with my target over 12 number of laps.
But while i am burning and looking at how this number decreases - this green line simply vanishes and is replaced by a new green line, which is MUCH longer, and shows for example, that meeting will be after 11 or 10 laps instead of 12, and it will happed 400MM away from intersection point. If i burn further - this 400 MM reduces again, to 350, then 300, then 270, but now it vanishes again - and i see a new line again, which is 400 MM or 500 MM and says for example 9 laps. While real CLOSEST line is actually still after 12 laps - it would be something like 20-30 MM away from intersection point. Next closest line will be over 11 or 10 laps and that is 270 MM away, but i don't see any of these two lines, so i can't make resonate orbit to meet there after 10, 11 or 12 laps - instead mod shows only a much longer green line for 9 laps choice and i have to burn again a lof of fuel to reduce 400MM+ for meating after 9 laps. And guess what happens next if i will do that new burning?
For now, i solve this problem in this way: i make burning blindly (after green line disappeared and replaced for a longer new one) to change my orbit enough to be where i need to be over 12 laps, then i timewarp and after many laps those more longer green lines vanish and replaced by original shortest close line, which was real closest. And then i can see how much did i missed. Then i load quicksave and burn more or less again blindly, not seen 12 laps green line and seen only 9 laps green line for 400MM+.
Thus after several trials and errors i finally meet some good approximation and after, for example, 5 or 8 laps from 12 i can see how green line to real closes approach returns and i can make further corrections already from that point in game.
This also happens if i do not burn at all.
For example i was lucky enough and closest green line was never vanished and replaces, and thus i established meeting point over 10 laps. Then i go timewarp and after 1 or 2 laps this green line (which is already small like a dot) vanishes and replaced for much longer green line for 3 or 7 laps for example, and only after many more laps new long green line will be discarded and original short (like a dot) will come back on the screen, so i could make 1 or several more laps and finally get en encounter.
Solution with quicksaves by trials and errors by going blindly is kind of not hard to implement and it consumes little time thanks to timewarps. But it is still very sad solution.
By all means, this is not a priority problem, it can be addressed after more important issues are solved and other work is finished.
I only think that this great mod would just look much better if such thing with disappearing closest lines would never happen.
That's most likely an issue with the algorithm that chooses the best value on several turns.
What the algorithm does is that it calculates the approach at the node after 2 laps (the current lap is ignored since that case is covered by the blue line), then after 3 laps, and so on up to 12 laps. Now I have 11 approach values. But I don't choose necessarily the smallest one: a distance is easier to reduce if it's obtained after a high number of laps. So for example if I obtain a similar distance after 4 laps and after 8 laps, it will be cheaper to get the encounter after 8 laps. But it will be longer too. In practice, players may prefer to spend a little more ΔV to get a faster encounter.
That's why I have a strategy of selection that tries to find the best compromise: it penalizes encounters obtained after a high number of turns. It can still propose an encounter after 12 turns, but this is if the 12th one is significantly better than the others.
It can happen sometimes that as you burn, the algorithm suddenly finds a more interesting alternative in terms of number of laps, and it proposes it instead of the previous one. It can be a little more expensive, but I'm surprised that the distance shown increases by a great factor.
From my tests, the algorithm generally gives good results, but it's possible that it behaves strangely sometimes indeed.
I'll think about a variant of the algorithm, but I'd like to keep that ability to favor encounters that happen on a reasonable delay. Do you have an example of situation in which it happens?
Then it would be very nice solution to simply add mod's setting to main game menu, which changes settings as players prefer. Like there are settings for Vanilla mod in game menu.
For example ANAIS and Closest Approach Line can show settings like this:
- never suggest less fuel-efficient encounter;
- suggest less fuel efficient encounter if it reduces number of laps by more than X; (with pickable number)
- suggest less fuel efficient encounter if it can happen faster and the difference in ΔV to obtain it is less than: X; (a field to enter any value)
- use automatic algorithm of changing suggestions.
2nd and 3rd from those 4 about can be used both simultaneously and separately.
For example ANAIS and Closest Approach Line can show settings like this:
- never suggest less fuel-efficient encounter;
- suggest less fuel efficient encounter if it reduces number of laps by more than X; (with pickable number)
- suggest less fuel efficient encounter if it can happen faster and the difference in ΔV to obtain it is less than: X; (a field to enter any value)
- use automatic algorithm of changing suggestions.
2nd and 3rd from those 4 about can be used both simultaneously and separately.
Last edited:
Literally any interplanetary and any moving between any moons in Jovian system.
Requirements are - there are many laps to any closest encounter. The more laps - the more likely it will happen. It will change the line for a longer line either during burning, either during timewarp circling without burn.
Last time in Jovian system i just started with 12 laps and some pretty short green lines and as soon as i started to burn - lines disappeared and replaced with 11 turn lines, then 10 turns, then 9 turns, and so on, while i was still burning more and more fuel. Finally, i had to burn HUGE amount of fuel to finally get a green line, which did not disappear, it was something like 4 or 6 laps, i don't remember, i just wanted to see when will this stop. After that i just loaded quicksave before burn and after 2 blind guesses i guessed a good approximation for meeting after 12 laps, with almost zero fuel spent. And after some 5-6 laps this first shortest line returned and i made just a tiny correction to finalize it.
Requirements are - there are many laps to any closest encounter. The more laps - the more likely it will happen. It will change the line for a longer line either during burning, either during timewarp circling without burn.
Last time in Jovian system i just started with 12 laps and some pretty short green lines and as soon as i started to burn - lines disappeared and replaced with 11 turn lines, then 10 turns, then 9 turns, and so on, while i was still burning more and more fuel. Finally, i had to burn HUGE amount of fuel to finally get a green line, which did not disappear, it was something like 4 or 6 laps, i don't remember, i just wanted to see when will this stop. After that i just loaded quicksave before burn and after 2 blind guesses i guessed a good approximation for meeting after 12 laps, with almost zero fuel spent. And after some 5-6 laps this first shortest line returned and i made just a tiny correction to finalize it.
Altaïr
Space Stig, Master of gravity
Staff member
Head Moderator
Team Kolibri
Modder
TEAM HAWK
Atlas
Deja Vu
Under Pressure
Forum Legend
I could make a customizable algorithm indeed, though it would requires that I put my fingers into the UI settings. In short, it's not something that I could do quickly. Also, if I give access to some sort of settings, I'd prefer to keep things simple to understand. I'm not saying I'm discarding your proposal, but if I have to explain the algorithm before, very few people will use it in practice.
For example, I thought myself about a slider indicating on the left "I want to save fuel" and on the right "I want to save time". Each player would move the slider according to its priority and the algorithm could take it into account.
Also, I can't be too technical, for example I can't calculate the ΔV required to get an encounter in a given situation. ANAIS can do that but not the closest approach mod. Calculating the closest approach is a purely geometrical problem in which speeds are not involved. Actually I estimate that the ΔV required should be roughly inversely proportional to the distance from the node and to the number of remaining laps. This should not be too far off in practice, at least if the distance is small, but that's still not an accurate calculation.
There's another possibility however that would work well in practice: when the player selects a target, I calculate the best compromise as I did before, but then I lock that choice instead of reevaluating constantly. In your case, if the initial best approach is within 12 turns, it would keep being 12 turns as you reduce the distance. There's a similar mechanism in ANAIS: if your injection burn falls below 5 m/s, then it considers that you have chosen that route, so it will lock that choice. If you try, you'll notice that when you time-warp the arrival point remains fixed instead of drifting constantly.
I can do something similar for the closest approach. Either locking completely the choice, or making another proposal only if it's really better. That way the mod wouldn't constantly change your plans. Overall, it would still be possible to check for other opportunities by unselecting the target and selecting it again (to force the game to break the lock).
For example, I thought myself about a slider indicating on the left "I want to save fuel" and on the right "I want to save time". Each player would move the slider according to its priority and the algorithm could take it into account.
Also, I can't be too technical, for example I can't calculate the ΔV required to get an encounter in a given situation. ANAIS can do that but not the closest approach mod. Calculating the closest approach is a purely geometrical problem in which speeds are not involved. Actually I estimate that the ΔV required should be roughly inversely proportional to the distance from the node and to the number of remaining laps. This should not be too far off in practice, at least if the distance is small, but that's still not an accurate calculation.
There's another possibility however that would work well in practice: when the player selects a target, I calculate the best compromise as I did before, but then I lock that choice instead of reevaluating constantly. In your case, if the initial best approach is within 12 turns, it would keep being 12 turns as you reduce the distance. There's a similar mechanism in ANAIS: if your injection burn falls below 5 m/s, then it considers that you have chosen that route, so it will lock that choice. If you try, you'll notice that when you time-warp the arrival point remains fixed instead of drifting constantly.
I can do something similar for the closest approach. Either locking completely the choice, or making another proposal only if it's really better. That way the mod wouldn't constantly change your plans. Overall, it would still be possible to check for other opportunities by unselecting the target and selecting it again (to force the game to break the lock).
Any settings in any way you choose - that would be a very nice improvement to the mod!
It can be simply two tumblers in settings:
tumbler 1: i want to save fuel / i want to same time
tumbler 2: lock shortest approach line (on or off)
Where not locking simply uses your current algorithms as it is, but with two internal profiles instead of one:
- "save fuel profile" will use only very small difference to offer new encounter with fewer laps (and will keep offering new again and again, since player don't want it locked), when it will be for sure only tiny amount of extra fuel needed for this;
- "save time profile" will uses much bigger margin for new encounter suggestions, when it might eat a lot of fuel, but still there will be some reasonable limitation of margin.
For example you can increase margin from what is it now for time-saving profile and significantly decrease it for fuel saving profile. Thus if player can't get a lock of the first suggestion (that 12 laps away) and it was replaced to 11 or 10 - it would be for sure no more than very little difference in fuel consumption.
Or it can be like this, with only one setting available:
Scaler bar from 0% to 100% to pick (live sound volume)
Where scaler simply shows how big that margin for new green line would be. Scaler 0% will work like a lock, never show any new options, scaler 5% or 10% will be very fuel efficient, scaler closer to 100% will be very time efficient, but with huge extra burning.
Plus you can add 2 hotkeys in keyboard settings (like hotkeys for SAS mod), which can move scaler from keyboard between 0% and 100% (without any visalization on the screen). Then player can simply press hotkeys right when he is looking at map screen in game and in realtime he can see new green lines (and also bring back previous green lines!) and he can make his own choice in a very comfortable way. Plus he can alter his choice easily anytime later.
Very simple settings, consume very little screen space, and if anyone wants to know more details - he can read it here, you already made very nice and thorough explanation.
It can be simply two tumblers in settings:
tumbler 1: i want to save fuel / i want to same time
tumbler 2: lock shortest approach line (on or off)
Where not locking simply uses your current algorithms as it is, but with two internal profiles instead of one:
- "save fuel profile" will use only very small difference to offer new encounter with fewer laps (and will keep offering new again and again, since player don't want it locked), when it will be for sure only tiny amount of extra fuel needed for this;
- "save time profile" will uses much bigger margin for new encounter suggestions, when it might eat a lot of fuel, but still there will be some reasonable limitation of margin.
For example you can increase margin from what is it now for time-saving profile and significantly decrease it for fuel saving profile. Thus if player can't get a lock of the first suggestion (that 12 laps away) and it was replaced to 11 or 10 - it would be for sure no more than very little difference in fuel consumption.
Or it can be like this, with only one setting available:
Scaler bar from 0% to 100% to pick (live sound volume)
Where scaler simply shows how big that margin for new green line would be. Scaler 0% will work like a lock, never show any new options, scaler 5% or 10% will be very fuel efficient, scaler closer to 100% will be very time efficient, but with huge extra burning.
Plus you can add 2 hotkeys in keyboard settings (like hotkeys for SAS mod), which can move scaler from keyboard between 0% and 100% (without any visalization on the screen). Then player can simply press hotkeys right when he is looking at map screen in game and in realtime he can see new green lines (and also bring back previous green lines!) and he can make his own choice in a very comfortable way. Plus he can alter his choice easily anytime later.
Very simple settings, consume very little screen space, and if anyone wants to know more details - he can read it here, you already made very nice and thorough explanation.
Also you can add one more setting:
maximum number of laps to calculate: X
Somebody doesn't want 12, he wants only no more than 6 maybe. Or somebody else doesn't mind to use 20 or 30 and doesn't want to burn even a tiny bit, especially if each lap is only several hours of world time, or even less than 1 hour. Or if player found himself in situation, where he is extremely tight on fuel and doesn't mind circling for 50 game world years somewhere to meet with his target without any more burns after 20-30 circles.
maximum number of laps to calculate: X
Somebody doesn't want 12, he wants only no more than 6 maybe. Or somebody else doesn't mind to use 20 or 30 and doesn't want to burn even a tiny bit, especially if each lap is only several hours of world time, or even less than 1 hour. Or if player found himself in situation, where he is extremely tight on fuel and doesn't mind circling for 50 game world years somewhere to meet with his target without any more burns after 20-30 circles.
I have new idea. It would make the mod much better, especially if it can be made with little effort.
For now, Closest Approach Line shows green line suggestions only when we have no encounter ahead. If we have any encounter ahead - it shows nothing, it is like not working at all, until we actually reach that encounter, then mod starts to show suggestions again.
And that is very sad, since it requires to blindly guess our escape trajectory from somebody's SOI and only after we entered that SOI we can actually see green lines again and find out how good was our guess. It forces to make a lot of low-quality guesses, using quicksaves and repeating everything many times. Because before we entered SOI of this object - we see nothing at all in advance.
But the game actually shows our trajectory line furthermore after even 2 encounters and beyond, so we actually can see where we will intersect in the future with our future targets. That would be so, if we set orbits counter / conic section to highest value in game settings. And if that further line would have Closest Approach Line suggestions to selected future target (since our trajectory line intersects target's orbit line) - that would be totally new level of navigation!
That would allow to stage multiple gravity assists right away from scratch from any point in the game.
For example, we can still be one full orbit lap away from our encounter and already make Closest Approach Line corrections to our next target. And if encounter with next target will be less than 1 lap away after 1st target - we can already use Closest Approach Line to plan encounter with 3rd target in a row. That is new level of navigation. It would become even better, if the game would have settings to show encounters which are more than 1 lap away, but for now even with 1 lap encounters it would be already an awesome improvement.
And when this feature also will be enhanced by the ability to see suggestions from Closest Approach Line even for targets, which orbits our current path will not intersect at all (link) - that would allow making/staging even more flexible multiple gravity assists, even from much worse positions and situations in game, and using much less fuel too, since we don't need to waste fuel to get intersection in the first place.
For now, Closest Approach Line shows green line suggestions only when we have no encounter ahead. If we have any encounter ahead - it shows nothing, it is like not working at all, until we actually reach that encounter, then mod starts to show suggestions again.
And that is very sad, since it requires to blindly guess our escape trajectory from somebody's SOI and only after we entered that SOI we can actually see green lines again and find out how good was our guess. It forces to make a lot of low-quality guesses, using quicksaves and repeating everything many times. Because before we entered SOI of this object - we see nothing at all in advance.
But the game actually shows our trajectory line furthermore after even 2 encounters and beyond, so we actually can see where we will intersect in the future with our future targets. That would be so, if we set orbits counter / conic section to highest value in game settings. And if that further line would have Closest Approach Line suggestions to selected future target (since our trajectory line intersects target's orbit line) - that would be totally new level of navigation!
That would allow to stage multiple gravity assists right away from scratch from any point in the game.
For example, we can still be one full orbit lap away from our encounter and already make Closest Approach Line corrections to our next target. And if encounter with next target will be less than 1 lap away after 1st target - we can already use Closest Approach Line to plan encounter with 3rd target in a row. That is new level of navigation. It would become even better, if the game would have settings to show encounters which are more than 1 lap away, but for now even with 1 lap encounters it would be already an awesome improvement.
And when this feature also will be enhanced by the ability to see suggestions from Closest Approach Line even for targets, which orbits our current path will not intersect at all (link) - that would allow making/staging even more flexible multiple gravity assists, even from much worse positions and situations in game, and using much less fuel too, since we don't need to waste fuel to get intersection in the first place.
Altaïr
Space Stig, Master of gravity
Staff member
Head Moderator
Team Kolibri
Modder
TEAM HAWK
Atlas
Deja Vu
Under Pressure
Forum Legend
I see. This is an interesting idea, it should be relatively easy. Right now the algorithm only considers the first compatible trajectory it finds, but I can probably make it consider future trajectories if an encounter is planned.
I'm still busy with Anais (this takes time and I don't have that much...) but I'll try to do that, thanks for the suggestion.
I'm still busy with Anais (this takes time and I don't have that much...) but I'll try to do that, thanks for the suggestion.
Yes, that would be simple and probably the best - just to give green-line suggestions for future meetings with chosen target along entire known trajectory for current vessel, from current position and for as long (as far) as possible. So player could see green lines even before closest encounter (if player changed his mind and wants to meet with another target and chose another), then between several already lined up encounters (because the same reason), and then right after the last established escape point in several lined up encounters, even though player still didn't reach that point yet.
So if we already have 2 encounters ahead - we can already plan how to catch 3rd target with green line suggestions, if we could see them, even if we are 2 laps away before|from 2nd encounter.
And it also would be nice, if green lines will worked inside SOI of 2nd or 3rd target, or at least inside immediate closet encounter's SOI.
For example, if i am 1 lap away from encounter with Earth and encounter already is shown on the map, i can pick Moon as a target and mod shows blue line for the Moon. But green lines are not shown until i enter Earth's SOI - but then it will be too late to change course to catch up Moon. While when i am the whole one lap around the sun away from encounter with Earth's SOI - i could easily make corrections to catch up Moon as a target, if i could see green lines at this point (like i can see blue line).
And showing green lines for targets inside SOI of 2nd or 3rd encounter in the line would be even better, if possible. So, for example, we could already plan meeting with Jupiter's moon or Saturn's moon, when we are still one lap behind before meeting with Earth for last gravity assist. But since our trajectory line from exit point from Earth's SOI goes to direct encounter with Jupiter or Saturn - we already see second encounter and we could already target one of the moons inside Jupiter's|Saturn's SOIN and aim|navigate for that in advance, if we could saw green line suggestions for it at this point, while we are still one lap away before meeting Earth.
Also, if some moon or planet will accidentally gets in the way - scratching it's SOI with our ship will not hinder our efforts to navigate for our real target, which we can meet after this accidental encounter. While for now we simply lose green line as soon as accidental encounter came up and green lines come back only after accidental encounter was already made.
So if we already have 2 encounters ahead - we can already plan how to catch 3rd target with green line suggestions, if we could see them, even if we are 2 laps away before|from 2nd encounter.
And it also would be nice, if green lines will worked inside SOI of 2nd or 3rd target, or at least inside immediate closet encounter's SOI.
For example, if i am 1 lap away from encounter with Earth and encounter already is shown on the map, i can pick Moon as a target and mod shows blue line for the Moon. But green lines are not shown until i enter Earth's SOI - but then it will be too late to change course to catch up Moon. While when i am the whole one lap around the sun away from encounter with Earth's SOI - i could easily make corrections to catch up Moon as a target, if i could see green lines at this point (like i can see blue line).
And showing green lines for targets inside SOI of 2nd or 3rd encounter in the line would be even better, if possible. So, for example, we could already plan meeting with Jupiter's moon or Saturn's moon, when we are still one lap behind before meeting with Earth for last gravity assist. But since our trajectory line from exit point from Earth's SOI goes to direct encounter with Jupiter or Saturn - we already see second encounter and we could already target one of the moons inside Jupiter's|Saturn's SOIN and aim|navigate for that in advance, if we could saw green line suggestions for it at this point, while we are still one lap away before meeting Earth.
Also, if some moon or planet will accidentally gets in the way - scratching it's SOI with our ship will not hinder our efforts to navigate for our real target, which we can meet after this accidental encounter. While for now we simply lose green line as soon as accidental encounter came up and green lines come back only after accidental encounter was already made.
Altaïr
Space Stig, Master of gravity
Staff member
Head Moderator
Team Kolibri
Modder
TEAM HAWK
Atlas
Deja Vu
Under Pressure
Forum Legend
An interesting perspective for sure. Even if in my opinion it wouldn't be that helpful beyond the second encounters: the trajectories would become very unstable past the second encounter: a very small variation would result in a totally different trajectory on the long term, you would still have to make some mid-course corrections. But the idea is still nice of course.
That part however... I don't see how I could display a green line in this situation. The green line is to predict an encounter several turns ahead, but in the case of a fly-by trajectory there's only one pass. The green lines can only be calculated with a periodic trajectory. However if the predicted trajectory is elliptical then it should already work. Like if you're about to escape Earth and you target Venus for example, as your future trajectory is an ellipse around the Sun.
If you want to plan a direct encounter with the Moon in your case, it should be possible to tweak your trajectory (by combining prograde/retrograde/side burns) to reduce the closest approach (the blue line).
This part I agree.
That part however... I don't see how I could display a green line in this situation. The green line is to predict an encounter several turns ahead, but in the case of a fly-by trajectory there's only one pass. The green lines can only be calculated with a periodic trajectory. However if the predicted trajectory is elliptical then it should already work. Like if you're about to escape Earth and you target Venus for example, as your future trajectory is an ellipse around the Sun.
If you want to plan a direct encounter with the Moon in your case, it should be possible to tweak your trajectory (by combining prograde/retrograde/side burns) to reduce the closest approach (the blue line).
This part I agree.
This literally means this: for the tiniest amount of fuel we can change our trajectory so huge, that we can catch any body in entire solar system right away, without any future expensive fuel burns. And for this tiniest amount of fuel spent in advance we can even catch it with minimal laps to wait if our vector of approach would be satisfying enough in this case.
I meant, that when we enter to SOI with espace trajectory - we still have some apoapsis value, above this SOI's central body. That value is outside current SOI, but still can be used for periodic calculation.
For example, If this apoapsis is not too high, just a little outside of SOI, then only small burn will lower it back to current SOI and the orbit will indeed become periodic. But we have a nice pointer in advance - we can compare the amount of burn to distance, which green line shows, so we could guess some good approximation of the size of green line we need to keep in advance to negate it later with our future slowing down (to remain in this SOI instead of escaping).
In this case vector of approach will be awful, that is rarely worth it. Almost all the time it would be better to reduce speed inside soi to activate green line suggestion, but entering with much better vector in the first place. Unless we want only to drop a bomb with maximum fly-by speed and get away for good.
I meant, that when we enter to SOI with espace trajectory - we still have some apoapsis value, above this SOI's central body. That value is outside current SOI, but still can be used for periodic calculation.
For example, If this apoapsis is not too high, just a little outside of SOI, then only small burn will lower it back to current SOI and the orbit will indeed become periodic. But we have a nice pointer in advance - we can compare the amount of burn to distance, which green line shows, so we could guess some good approximation of the size of green line we need to keep in advance to negate it later with our future slowing down (to remain in this SOI instead of escaping).
In this case vector of approach will be awful, that is rarely worth it. Almost all the time it would be better to reduce speed inside soi to activate green line suggestion, but entering with much better vector in the first place. Unless we want only to drop a bomb with maximum fly-by speed and get away for good.
Altaïr
Space Stig, Master of gravity
Staff member
Head Moderator
Team Kolibri
Modder
TEAM HAWK
Atlas
Deja Vu
Under Pressure
Forum Legend
Oh, actually it's not that simple. Firstly, there's not necessarily an apoapsis for escape trajectories. It can be that the orbit is very elliptic and the apoapsis is beyond the SOI, but this case is rare in practice. As soon as the apoapsis goes beyond the SOI limit it really doesn't take long before the trajectory becomes hyperbolic. In this case the object definitely escapes and never comes back, like what we have in the Voyager quest challenge.
For example, for Earth, when you burn from LEO and once your apoapsis reaches the SOI, it only takes 4 m/s before you reach the escape velocity. You wouldn't go far with that.
Even if I showed those green lines for the small range of speeds concerned the result wouldn't be great, the orbital period varies greatly, even for small speed variations. Especially if multiplied by the number of laps. You would hardly get something predictible with that...
And to be honest it would feel weird to show an encounter in 3 turns (for example) if said encounter doesn't actually happen. I don't feel like it's a good idea honestly.
Aha, you're giving me mad ideas there
For example, for Earth, when you burn from LEO and once your apoapsis reaches the SOI, it only takes 4 m/s before you reach the escape velocity. You wouldn't go far with that.
Even if I showed those green lines for the small range of speeds concerned the result wouldn't be great, the orbital period varies greatly, even for small speed variations. Especially if multiplied by the number of laps. You would hardly get something predictible with that...
And to be honest it would feel weird to show an encounter in 3 turns (for example) if said encounter doesn't actually happen. I don't feel like it's a good idea honestly.
Unless we want only to drop a bomb with maximum fly-by speed and get away for good.
Altaïr
Space Stig, Master of gravity
Staff member
Head Moderator
Team Kolibri
Modder
TEAM HAWK
Atlas
Deja Vu
Under Pressure
Forum Legend
Some news about ANAIS!
I managed to make a first version that is able to calculate interplanetary transfers.
Here is an example with a transfer from Moon orbit towards an object in Earth orbit:
Yes the transfer targets another ship. Normally you would use that to target a planet, but if it works with a planet it works with a ship so why not?
There's also a very disturbing phenomenon that can be noticed: it's the fact that normally you would expect the velocity vector to be colinear with the Moon's trajectory when the ship exits the SOI, but it's not the case:
The explanation is simply that ANAIS anticipates the movement of the Moon during the transfer, so that the exit velocity will actually have the optimal direction at that moment:
Right now it's still buggy and it needs some polishing, but it's clearly a good start
Hopefully I'll have a working version soon!
I managed to make a first version that is able to calculate interplanetary transfers.
Here is an example with a transfer from Moon orbit towards an object in Earth orbit:
Yes the transfer targets another ship. Normally you would use that to target a planet, but if it works with a planet it works with a ship so why not?
There's also a very disturbing phenomenon that can be noticed: it's the fact that normally you would expect the velocity vector to be colinear with the Moon's trajectory when the ship exits the SOI, but it's not the case:
The explanation is simply that ANAIS anticipates the movement of the Moon during the transfer, so that the exit velocity will actually have the optimal direction at that moment:
Right now it's still buggy and it needs some polishing, but it's clearly a good start
Hopefully I'll have a working version soon!