When a route point is added, it does not add but is replaced by a point named ’ATIS' (it may not be the point originally selected on the map). The route is therefore not traced according to the user’s wishes.
I don't understand this issue. Would you mind providing more details here (e.g. a specific example, possibly with screenshots)? The "ATIS" reference in particular is confusing.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It can be very tricky to input a point the way the route manager expects you to do. I had a lot of issues myself.
Just to be sure, can you please try to add a simple point like just KSFO there and see if that works?
If it does, then that might indicate a posible syntaxe mistake in your input.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The fact that it shows "ATIS" makes me think this user's nav cache is somehow badly corrupted. What made me think this was seeing "AWOS" on the launcher screen after a reload of the nav cache. Perhaps somehow a corrupted cache could cause this problem where the point they enter becomes "ATIS".
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That sounds more like memory corruption (PUI showing the wrong string). Do we have fixes in the DB with 'ATIS' or 'AWOS' in the name? Otherwise they could only come from the radio / atc frequency dialog, which seems very weird.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The freqeuncies are in the DB, but the names aren't; we use integer codes to know if it's TWR, GND, ATIS etc. It doesn't 100% rule out the nav-cache, but it makes it seem fairly unlikely to me. Of course best thing would be if we had a test case we could reproduce (same for the AWOS thing you saw), but without that, it's a bit tricky to know what to suggest.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For my case what I was doing was making some change that triggers a cache rebuild and reloading the launcher. Afterwards, the selected airport that is shown becomes something entirely random. It's usually another airport but in this case was "AWOS"!
i.e. it's unreproducable :(
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hmm, we could still dig there a bit: if you do say 10 cache rebuilds, what do you see? I ask becuase you shouldn't see a rnadom selected airport as a result; that is emphatically not how that information is saved. We save locations as 'lat+lon+type+frequency', so that if the DB changes, we can find the location again. So I don't know why you are seeing a random location, it's a bit weird.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Another interesting symptom - I re-added the jersey custom scenery and closed flightgear with "active runway" BIKF selected. After reloading cache, the launcher started with position "jersey 08" instead of "BIKF active runway".
After removing jersey again, and closing again with BIKF active runway selected, it reloaded to () rather than staying at "BIKF active runway".
This happened 3 / 4 times and does seem to be reproducible.
This occurs whether you select "active runway" or a specific runway at BIKF.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I found one way this could screw up for the case you dscribe: for the current location, we do use the datbase ID. So I should adjust that to use ident+lat+lon+type, as we do for the location history. If you were changing custom scenery, you could get a different location selected, at the moment, and that could indeed be an AWOS station. (Or any other weird type, such as a glide-slope or parking stand)
This never happened before, because we only had the primary data source and hence on rebuild, everything was in the same order; now we have custom data, the IDs can be different each time.
So that explains the thing you reported; the NavCache is fine, but the launcher needs to be a bit more paranoid, when the nav-cache has changed, about the saved location data.
This also gives a way the original reporter could see 'ATIS' ; if they somehow returned a comm station from the route-manager search. That should be impossible, since we only search on some restricted types (VOR, FIX, NDB, airport). But if someone can figure out a way to make it happen, that would be very interesting.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't understand this issue. Would you mind providing more details here (e.g. a specific example, possibly with screenshots)? The "ATIS" reference in particular is confusing.
It can be very tricky to input a point the way the route manager expects you to do. I had a lot of issues myself.
Just to be sure, can you please try to add a simple point like just KSFO there and see if that works?
If it does, then that might indicate a posible syntaxe mistake in your input.
The fact that it shows "ATIS" makes me think this user's nav cache is somehow badly corrupted. What made me think this was seeing "AWOS" on the launcher screen after a reload of the nav cache. Perhaps somehow a corrupted cache could cause this problem where the point they enter becomes "ATIS".
That sounds more like memory corruption (PUI showing the wrong string). Do we have fixes in the DB with 'ATIS' or 'AWOS' in the name? Otherwise they could only come from the radio / atc frequency dialog, which seems very weird.
Aren't the frequencies stored in the database too though?
Regardless the end user seems to have disappeared ...
The freqeuncies are in the DB, but the names aren't; we use integer codes to know if it's TWR, GND, ATIS etc. It doesn't 100% rule out the nav-cache, but it makes it seem fairly unlikely to me. Of course best thing would be if we had a test case we could reproduce (same for the AWOS thing you saw), but without that, it's a bit tricky to know what to suggest.
For my case what I was doing was making some change that triggers a cache rebuild and reloading the launcher. Afterwards, the selected airport that is shown becomes something entirely random. It's usually another airport but in this case was "AWOS"!
i.e. it's unreproducable :(
Hmm, we could still dig there a bit: if you do say 10 cache rebuilds, what do you see? I ask becuase you shouldn't see a rnadom selected airport as a result; that is emphatically not how that information is saved. We save locations as 'lat+lon+type+frequency', so that if the DB changes, we can find the location again. So I don't know why you are seeing a random location, it's a bit weird.
srory, brain fail, it's ident we save, not frequency :)
Now that I'm looking for it I can't reproduce it and it always shows () ... ( I presume that's a fallback).
1st: removing a custom scenery
2: re-adding it:
It goes right back to Jersey 08 so that works, but it doesn't work without the custom scenery since Jersey 08 doesn't exist then.
Since most of the time when I'm adding or removing packages, they'd be custom sceneries, that explains that I saw this somewhat ...
I'll keep an eye out however. I certainly did see AWOS come up at one point but its not happening now :/
Last edit: legoboyvdlp 2020-11-27
Another interesting symptom - I re-added the jersey custom scenery and closed flightgear with "active runway" BIKF selected. After reloading cache, the launcher started with position "jersey 08" instead of "BIKF active runway".
After removing jersey again, and closing again with BIKF active runway selected, it reloaded to () rather than staying at "BIKF active runway".
This happened 3 / 4 times and does seem to be reproducible.
This occurs whether you select "active runway" or a specific runway at BIKF.
I found one way this could screw up for the case you dscribe: for the current location, we do use the datbase ID. So I should adjust that to use ident+lat+lon+type, as we do for the location history. If you were changing custom scenery, you could get a different location selected, at the moment, and that could indeed be an AWOS station. (Or any other weird type, such as a glide-slope or parking stand)
This never happened before, because we only had the primary data source and hence on rebuild, everything was in the same order; now we have custom data, the IDs can be different each time.
So that explains the thing you reported; the NavCache is fine, but the launcher needs to be a bit more paranoid, when the nav-cache has changed, about the saved location data.
This also gives a way the original reporter could see 'ATIS' ; if they somehow returned a comm station from the route-manager search. That should be impossible, since we only search on some restricted types (VOR, FIX, NDB, airport). But if someone can figure out a way to make it happen, that would be very interesting.