ANAIS: Advanced NAvigation Innovative System

[Lemniscate Biscuit]

I'll try to see if I can make it happening to investigate. If you see it happen again can you please press F1 and post the errors here? Thanks!

Ok. i'll be sure.

 

[Ferrugem]

For me this error no longer happens, but I'm having problems now with More Parts

 

[Altaïr]

For me this error no longer happens, but I'm having problems now with More Parts

Ok, don't hesitate to tell me if it happens again. On my side I'm preparing a version that will catch errors and allow it to continue if a critical bug happens. It will also log errors in a specific file to ease the error reporting.

 

[Altaïr]

V1.3.1 is released!

With this version, the transfer calculation is optimized by making it not considering arrival dates leading to stupidly expensive transfers, which were difficult to calculate, and were not interesting anyway.

ANAIS has also been made more stable, it's now able to recover from errors, which will avoid interrupting the whole process for a single problem. To improve stability on the long term, this version now features...

Error reports

When an error occurs, ANAIS will now log the errors encountered in a dedicated Log file. You will find that file in the mod folder:

If you notice such file, please send it to me, and ideally tell me what you were doing at that moment to help me to investigate. This will greatly help me to chase those annoying bugs, that are sometimes very hard to recreate. Thanks in advance for your collaboration guys

Note: The config.txt file is the file that memorizes you panel settings, I don't need it. And don't worry if you accidentally delete it, the game will restore it automatically.

 

[Lemniscate Biscuit]

V1.3.1 is released!

With this version, the transfer calculation is optimized by making it not considering arrival dates leading to stupidly expensive transfers, which were difficult to calculate, and were not interesting anyway.

ANAIS has also been made more stable, it's now able to recover from errors, which will avoid interrupting the whole process for a single problem. To improve stability on the long term, this version now features...

Error reports

When an error occurs, ANAIS will now log the errors encountered in a dedicated Log file. You will find that file in the mod folder:
View attachment 110884
If you notice such file, please send it to me, and ideally tell me what you were doing at that moment to help me to investigate. This will greatly help me to chase those annoying bugs, that are sometimes very hard to recreate. Thanks in advance for your collaboration guys

Note: The config.txt file is the file that memorizes you panel settings, I don't need it. And don't worry if you accidentally delete it, the game will restore it automatically.

Alrighty!

 

[Ferrugem]

 

[Taw]

V1.3.1 is released!

With this version, the transfer calculation is optimized by making it not considering arrival dates leading to stupidly expensive transfers, which were difficult to calculate, and were not interesting anyway.

ANAIS has also been made more stable, it's now able to recover from errors, which will avoid interrupting the whole process for a single problem. To improve stability on the long term, this version now features...

Error reports

When an error occurs, ANAIS will now log the errors encountered in a dedicated Log file. You will find that file in the mod folder:
View attachment 110884
If you notice such file, please send it to me, and ideally tell me what you were doing at that moment to help me to investigate. This will greatly help me to chase those annoying bugs, that are sometimes very hard to recreate. Thanks in advance for your collaboration guys

Note: The config.txt file is the file that memorizes you panel settings, I don't need it. And don't worry if you accidentally delete it, the game will restore it automatically.

Update seemed to have made the mod usable now, logs below.

 

[Altaïr]

Update seemed to have made the mod usable now, logs below. View attachment 110901

Thanks, I'll have a look at that. I'll most likely need more informations, but in a sense I'm reassured, from what I see it's a bug that happens consistently. Random bugs are the worst to investigate.
However there's another exception you have before this, with the mod loader apparently. I'll ask the dev team about that, but just in case could you please check your file integrity? From Steam, right-click on Spaceflight Simulator, choose Properties. Then go into Installed Files and click "Verify integrity of game files".

 

[Altaïr]

Update seemed to have made the mod usable now, logs below. View attachment 110901

I asked the dev team, you apparently have the old mod loader installed. It must be removed to prevent issues, you can check the third question of this thread to know how to proceed ("I still don't have access to the official mod loader, how do I update the game?" and check under "if you played with Dani's mod loader").
Checking file integrity as explained in my previous post will allow to fix any mistake in case you mess up with your files, so no worries

 

[Taw]

I asked the dev team, you apparently have the old mod loader installed. It must be removed to prevent issues, you can check the third question of this thread to know how to proceed ("I still don't have access to the official mod loader, how do I update the game?" and check under "if you played with Dani's mod loader").
Checking file integrity as explained in my previous post will allow to fix any mistake in case you mess up with your files, so no worries

I don't have the modloader files as I have never installed an external one, I didn't even play the game before the official modloader was released. The top messages of the console was caused by an outdated mod apparently, I'm not a dev so I'm not sure what I should be worried about.

 

[Altaïr]

I don't have the modloader files as I have never installed an external one, I didn't even play the game before the official modloader was released. The top messages of the console was caused by an outdated mod apparently, I'm not a dev so I'm not sure what I should be worried about.

Oh, we could have misinterpreted the error message. It would be good to know what caused it though.

 

[Altaïr]

Update V1.3.2 is out!

I've finally managed to recreate and correct the bug reported by Taw. It was actually a bug caused by a numerical precision error in the closest approach calculation. It happened when you used the navigation from a rectilinear orbit (in other words, when you launch straight up). Mathematically, those trajectories are more tricky to deal with.

I reviewed the whole code and made it more robust to those trajectories, all my tests were satisfying, it should work nominally now.

Thanks Taw for reporting this bug and helping me to figure it out
However, even if the mod works, I would advise not to launch straight up for efficiency purposes. Especially in realistic!

 

[Ferrugem]

Update V1.3.2 is out!

I've finally managed to recreate and correct the bug reported by Taw. It was actually a bug caused by a numerical precision error in the closest approach calculation. It happened when you used the navigation from a rectilinear orbit (in other words, when you launch straight up). Mathematically, those trajectories are more tricky to deal with.

I reviewed the whole code and made it more robust to those trajectories, all my tests were satisfying, it should work nominally now.

Thanks Taw for reporting this bug and helping me to figure it out
However, even if the mod works, I would advise not to launch straight up for efficiency purposes. Especially in realistic!

thanks

 

[Taw]

Update V1.3.2 is out!

I've finally managed to recreate and correct the bug reported by Taw. It was actually a bug caused by a numerical precision error in the closest approach calculation. It happened when you used the navigation from a rectilinear orbit (in other words, when you launch straight up). Mathematically, those trajectories are more tricky to deal with.

I reviewed the whole code and made it more robust to those trajectories, all my tests were satisfying, it should work nominally now.

Thanks Taw for reporting this bug and helping me to figure it out
However, even if the mod works, I would advise not to launch straight up for efficiency purposes. Especially in realistic!

Thanks, Well, I do have to go straight up if I were to get into orbit, don't I?

 

[Noor Nehan]

Thanks, Well, I do have to go straight up if I were to get into orbit, don't I?

Ummh, No?

 

[Altaïr]

Thanks, Well, I do have to go straight up if I were to get into orbit, don't I?

Not too much!
This is how I reach orbit for example:

You see, I quickly angle my rocket to build my horizontal velocity, which will allow to enter orbit.
Then once I'm in orbit, I target the Moon to get an affordable transfer:


You see the difference with your transfer, where you burn straight up to the Moon?


That was my point, you should enter orbit first, then once you are in orbit, target the Moon, this will be much more efficient.

 

[Taw]

Not too much!
This is how I reach orbit for example:
View attachment 111074 View attachment 111075 View attachment 111076
You see, I quickly angle my rocket to build my horizontal velocity, which will allow to enter orbit.
Then once I'm in orbit, I target the Moon to get an affordable transfer:
View attachment 111073

You see the difference with your transfer, where you burn straight up to the Moon?
View attachment 111077

That was my point, you should enter orbit first, then once you are in orbit, target the Moon, this will be much more efficient.

Well I kinda meant rockets launch vertically, I just follow the recommended angle at the bottom of the screen.

 

[Noor Nehan]

Well I kinda meant rockets launch vertically, I just follow the recommended angle at the bottom of the screen.

Yes, you launch vertically but tilt at the recommendet angle at the bottom of the screen.

 

[Lemniscate Biscuit]

Can there be a mode that excludes all paths that intersect an atmosphere or the ground. Becuase ANAIS always says that the best trajectory is through the ground, and all the other paths that are actually usable are not that efficient. Is there a way around this (Just FYI this happens a lot during docking)?

 

[Altaïr]

Can there be a mode that excludes all paths that intersect an atmosphere or the ground. Becuase ANAIS always says that the best trajectory is through the ground, and all the other paths that are actually usable are not that efficient. Is there a way around this (Just FYI this happens a lot during docking)?

I concede that it's annoying, but unfortunately there's no easy workaround. What ANAIS does is that it searches the best transfer in a specific interval of dates ("the best" in the sense "the one that will cost the least ΔV"). Because there's no easy way to solve that problem, it's an iterative algorithm. The problem is that it's only after I calculated a transfer that I know the periapsis, and eventually if it is too low. Excluding those transfers would make the algorithm significantly more complex (and it is already very complex), and in the end it would give you a non-optimal transfer. It would be significantly more expensive than the transfer you currently get, and you would probably consider that it would be more interesting to wait for a better opportunity.

That's why honestly I consider it's not worth it: too much risk and complexity for a debatable benefit. When this happens, it's best to time-warp until you get a more interesting opportunity.

 

[Lemniscate Biscuit]

I concede that it's annoying, but unfortunately there's no easy workaround. What ANAIS does is that it searches the best transfer in a specific interval of dates ("the best" in the sense "the one that will cost the least ΔV"). Because there's no easy way to solve that problem, it's an iterative algorithm. The problem is that it's only after I calculated a transfer that I know the periapsis, and eventually if it is too low. Excluding those transfers would make the algorithm significantly more complex (and it is already very complex), and in the end it would give you a non-optimal transfer. It would be significantly more expensive than the transfer you currently get, and you would probably consider that it would be more interesting to wait for a better opportunity.

That's why honestly I consider it's not worth it: too much risk and complexity for a debatable benefit. When this happens, it's best to time-warp until you get a more interesting opportunity.

Understandable.

 

[Darthan]

As a possible work around would it be possible to colour the trajectory red if it intersects the planet or its atmosphere?

Some other suggestions after using it with low-acceleration spacecraft (e.g. ion drives):

Could a couple of parameters be added "Max Acceleration" and "Max Orbit Ratio"?

1) If the departure delta-V cannot be reached within "Max Orbit Ratio" * "the period of the current spacecraft orbit" time at "Max Acceleration", show the trajectory red.

2) For rendevous mode, if the arrival delta-V cannot be reached within 1.5 * "Max Orbit Ratio" * "the period of the current spacecraft orbit" time at "Max Acceleration", show the arrival delta-V values rather than alternative departure delta-V values. This would especially help with a rendevous to the Captured Asteroid, Phobos or Deimos at low accellerations.

3) For rendevous mode to a planet, could the target orbit be one that could be reached within "Max Orbit Ratio" * "the period of the target orbit" time at "Max Acceleration" (minimum the current target orbit, maximum half the distance to the sphere of influence boundary). If that is a bit too complex to calculate, a third parameter specifying the target orbit altitude could also work.

 

[Altaïr]

As a possible work around would it be possible to colour the trajectory red if it intersects the planet or its atmosphere?

That's easily doable yes, it's a good idea. I would probably do it only if the ship is in space though. Sometimes it's cool to be able to plan a rendez-vous while still being suborbital. I wouldn't like that transfer to be displayed in red for example:

Could a couple of parameters be added "Max Acceleration" and "Max Orbit Ratio"?

1) If the departure delta-V cannot be reached within "Max Orbit Ratio" * "the period of the current spacecraft orbit" time at "Max Acceleration", show the trajectory red.

2) For rendevous mode, if the arrival delta-V cannot be reached within 1.5 * "Max Orbit Ratio" * "the period of the current spacecraft orbit" time at "Max Acceleration", show the arrival delta-V values rather than alternative departure delta-V values. This would especially help with a rendevous to the Captured Asteroid, Phobos or Deimos at low accellerations.

3) For rendevous mode to a planet, could the target orbit be one that could be reached within "Max Orbit Ratio" * "the period of the target orbit" time at "Max Acceleration" (minimum the current target orbit, maximum half the distance to the sphere of influence boundary). If that is a bit too complex to calculate, a third parameter specifying the target orbit altitude could also work.

Honestly I'm not keen on such a change: the color of a transfer is originally meant to tell the player about the transfer efficiency, not if it's suitable for your ship's acceleration. This could lead to display a very efficient transfer in red, which would cause confusion.
There could be some unexpected side effects too. For example your second point, let's say I'm starting from LEO and I aim for Mars: as I start burning, my orbit gets more and more elliptic, so its period increases. If the transfer was first displayed in red, at some point it suddenly won't be red anymore, even if your arrival ΔV hasn't changed. And at some point I'll be on an ejection trajectory, so what do I use for my orbit's period now?

Overall I'm afraid it would be too confusing/too specific, I try to keep the mod simple.

In practice you can take your TWR and multiply it by g = 9.8 m/s² to get your acceleration. Then your ΔV divided by that value will give you your burn time. I agree that it's not as practical as a mod, but I think this is reasonably doable.

I thank you for the suggestion though

 

[Darthan]

Thank for your reply.

The red colour on transfer orbit (I think) is how the default navigator indicated an unsafe (planet impacting) trajectory, you could use some other indicator (not sure what, something in the text maybe)?.

The (insufficent accelleration) indicator changing while accellerating could actually be considered expected behavoir. For example, if you start from an orbit that is too low for your accelleration you always need to accellerate prograde to reach a higher orbit, not in the ANAIS indicated direction. Once the orbit is high enough you can use the indicated direction.

This occurs even for normal accellerations from LEO - in this case you usually need to start accellerating from behind Earth with respect to your target direction not in the ANAIS direction. Eventually your orbit will be large enough to be able to use the indicated direction. For very low accellerations the initial trajectory will actually be a spiral while accellerating continously (also the speed actually decreases while accellerating!)

On the rendevous side there is currently no indication of the direction and speed of the target until you are much too close to do anything about it at low accellerations (you also have to react quickly even at normal accellerations). If you could display the arrival delta-v when 'close enough' rather than alternate departure delta-v values that would help. Just need a suitiable way to determine 'close enough' . My idea was to use a max acceleration as a clue to this - again this could help a bit even for normal accellerations.

The way I've handled low accellerations at departure so far is to calculate a minimum altitude 'navigation orbit' for the accelleration and to not attempt to use ANAIS below that.

I don't have a good way to handle low accellerations at arrival though (asteriod or spacecraft rendevous) - only to attempt to guess how close you are relative to the target by guessing from how fast you appear to be closing from the map screen!

 

[Altaïr]

Sorry that I didn't take the time to answer before.

The red colour on transfer orbit (I think) is how the default navigator indicated an unsafe (planet impacting) trajectory, you could use some other indicator (not sure what, something in the text maybe)?.

The (insufficent accelleration) indicator changing while accellerating could actually be considered expected behavoir. For example, if you start from an orbit that is too low for your accelleration you always need to accellerate prograde to reach a higher orbit, not in the ANAIS indicated direction. Once the orbit is high enough you can use the indicated direction.

I understand your idea, but the way the mod works has to be kept simple so that most players can understand it. And by simple, I mean very simple. I made the choice myself to propose a control panel that gives the player some control over the algorithm, but those are high level parameters. I think the difference between "fly-by" mode and "rendez-vous" mode is easy to understand even without prior knowledge about the algorithm for example. And still, it's not always the case since many people don't understand what I mean by "ascending node" and "descending node" at first.
Another example is the transfer efficiency, as shown by the transfer color. The player is not required to understand how efficiency is calculated, as long as they know the color code they have all the needed information. The player has to be able to figure out what each parameter does without having to understand the algorithm previously. Otherwise 95% of players will just skip.

Side effects have to be avoided too. I'll give you an example of side effect associated to the transfer efficiency. You're in LEO (Low Earth Orbit), and you want a transfer to the Moon. ANAIS shows you a green transfer that goes slightly past the Moon. As per the color code, the transfer is good but not optimal, so you go for it. But as you're ending your insertion burn, the transfer gradually turns yellow. What's happening? Did your transfer suddenly become inefficient?!

Spoiler: The explanation

The explanation lies in how is calculated the transfer efficiency. ANAIS first calculates separately the departure burn efficiency, and the arrival burn efficiency. Then it calculates a weighted mean of both values. Each value is weighted by the ΔV associated to the burn. For information, the efficiency of a burn is basically evaluated as "how colinear is the transfer burn with respect to your velocity". Efficiency ranges from 0% to 100%.

In the case of a non-optimal Moon transfer, since the insertion burn is the most expensive, ANAIS naturally chooses to maximize the transfer efficiency of the most expensive burn and accepts to degrade the cheaper transfer as the best compromise. Overall, the whole transfer efficiency is rated "green".

Once you've made most of your insertion burn, from the point of view of the algorithm you've "consumed" the efficient part of the transfer, the part that remains (the arrival burn) is the inefficient one. As the transfer is constantly reevaluated it's now rated "yellow".
The transfer as a whole didn't become inefficient, it's just that you first made the efficient part of the transfer, and ANAIS ignores the part you've already made at that point.

Nice side effect right? And it's not even that complicated, once you understood the algorithm the explanation is logical when you think about it. But the problem is, how will the player react faced to this situation? Honestly I think I'm the only one that could figure this out (anyone don't hesitate to quote me on this if I'm wrong). See why I want to avoid side effects? Most players won't even try to understand how it works internally.

On the rendevous side there is currently no indication of the direction and speed of the target until you are much too close to do anything about it at low accellerations (you also have to react quickly even at normal accellerations). If you could display the arrival delta-v when 'close enough' rather than alternate departure delta-v values that would help. Just need a suitiable way to determine 'close enough' . My idea was to use a max acceleration as a clue to this - again this could help a bit even for normal accellerations.

The current way to determine "close enough" is when the anticipated encounter is expected in the next 60 seconds. Using a time parameter has the advantage of naturally scaling the distance at which it occurs with the approach speed. It's possible to make of those 60 seconds a parameter though. Overall I think it's more simple, so more understandable.