Visited stars the same in Legacy and Live?

[Lhorndra]

Commanders,

I think the "visited stars" filter in the Galmap doesn't distinguish between Legacy and Live mode. I don't like that and to me, it seems like a bug. So far, I'm not sure enough to open a ticket in FDev's issue tracker, so feel free to see for yourself and comment.

My understanding is this: the visual filter "visited" / "not visited" stars in your Galmap does not rely on server data, but rather on the local cache file %LOCALAPPDATA%\Frontier Developments\Elite Dangerous\{cmdr_id}\VisitedStarsCache.dat. If you rename or delete that, your Galmap will not show any stars as visited anymore. The Galmap does not fetch your flight log from the servers.

Well, I thought, I wonder what happens now after Update 14 when I visit unvisited systems in Legacy mode. So I did that. The cache file was indeed updated, and my legacy Galmap looked like expected. Then I logged into Live mode, looked at the Galmap and voilà: all the systems I visited previously in Legacy, but never in Live now showed up as "visited".

More evidence: usually, you can view the system map of a visited system. In my case, the "View system map" button in my Live Galmap is greyed out for those systems. So, even if the Live Galmap shows those systems as "visited" (because it just reads VisitedStarsCache.dat), it still knows that I didn't visit these systems, otherwise I should be able to open the system map for these systems.

I haven't tested this the other way round or thoroughly in any other way yet, but I don't want the same single source for my visited stars filter in both Legacy and Live mode. Meh.

 

[Neilski]

Good spot (and a bit of an odd decision by FD, or perhaps more likely it's accidental).

Can you tell if this "sameness" also applies to the Codex entry for the number of stars you've visited? (E.g. if you visit a bunch of new systems in one, does the figure rise in the other...)
I expect that if the Codex figure is NOT handled the same, then it's going to cause problems with the game rejecting the cache file once the discrepancy reaches some threshold.

 

[Esteban]

...or perhaps it is intentional and just another nudge to encourage users to play the live galaxy. That is a supposition, of course.

My experience:
Yes, the data for visited systems comes solely from the VisitedStarsCache file. It does not come from logs or from server data. I believe that this is well known.

I had been playing 'Horizons' (that would be 3.8) until I had to move to 4.0 recently. When I installed Horizons 4, I first backed up my VisitedStarsCache file just in case it wasn't carried over to the new game. I didn't want to lose that data just because I was changing versions. When I first ran the program, I noted that the visited stars showed properly in-game, so my preparations for maybe having to move that file to the right place (or restore it for whatever reason) weren't needed. The file was there.
I updated (installed) the Legacy Horizons right after installing 4.0.

Searching my local Appdata directories now, I found only one VisitedStarsCache file.* The file is shown as last-modified when I last finished playing Horizons 4. This tells me that, indeed, the game uses only one VisitedStarsCache file. It does not keep a separate file for Horizons 4 and Horizons 3.8.

If you desire to maintain two VisitedStarsCache files, I suggest that this could be done with a batch file or manual movement of files when launching one of the two versions of the game. Clearly this won't be done by the game. I don't think it's an odd decision by FDev, I think it's a predictable one. They are leaving 3.8 behind. If you choose to run it, they're not keeping you from doing that (as they stated), but also not supporting it with features or effort.

more guesses...
If a discrepancy arises between the VisitedStarsCache file and the codex, I think it's a guess what may happen, Whether it rejects the codex figure or the other can't be guessed unless you know something about the code. It's even possible that the possibility hasn't been addressed in the code. That could possibly mean the program would suffer an exception (it would crash). All supposition, so not really worth hashing over. You could likely do the experiment pretty easily. Just lop a bunch of entries from a temporary version of your VisitedStarsCache file, put the file in place, run the game, and see what happens.
NB: That experiment is on you or whoever reads this and decides to try it. I will not encourage anyone to do so, nor will I try it. I just want to play. Have fun with the experiment!


* NOT counting the 'beta{cmdr_id}' file from April, 2020

 

[Evoflash]

Two different games so should be two different visitedstarscache.dat in my view. But I have no knowledge of how such a thing is implemented so it’s easy for me to say that.

 

[Neilski]

If a discrepancy arises between the VisitedStarsCache file and the codex, I think it's a guess what may happen, Whether it rejects the codex figure or the other can't be guessed unless you know something about the code. It's even possible that the possibility hasn't been addressed in the code. That could possibly mean the program would suffer an exception (it would crash). All supposition, so not really worth hashing over. You could likely do the experiment pretty easily. Just lop a bunch of entries from a temporary version of your VisitedStarsCache file, put the file in place, run the game, and see what happens.

You mean remove some entries from the cache? I'm thinking of the opposite situation - where the cache is too big (see other thread, where people are seeing a cap which has been conjectured to be linked to the Codex entry for how many stars they have visited).

Scenario: you play for a while in Legacy, visiting a bunch of new stars (say 1000, for fun). Let's assume the Codex entry doesn't update in Legacy, but we know that the cache does. So then you fire up Live, and I'm guessing it's likely to decide that your cache is fake because it has more stars in it than the Codex says you have visited...?

 

[Jack Winter]

What if the codex is the same for the 2 versions too..

If they forgot about splitting the stars cache file, maybe they did the same (mistake?) with the codex

 

[nemolomen]

What if the codex is the same for the 2 versions too..

If they forgot about splitting the stars cache file, maybe they did the same (mistake?) with the codex

Is the codex a local file like the visited stars cache or does it come from a server?

I couldn't find any obvious files in the data cache folders.

 

[Jack Winter]

I don't think it has any local files, but it would have been thoughtful to create 2 local files for the visited stars cache.

 

[Esteban]

You mean remove some entries from the cache? I'm thinking of the opposite situation - where the cache is too big (see other thread, where people are seeing a cap which has been conjectured to be linked to the Codex entry for how many stars they have visited).

Scenario: you play for a while in Legacy, visiting a bunch of new stars (say 1000, for fun). Let's assume the Codex entry doesn't update in Legacy, but we know that the cache does. So then you fire up Live, and I'm guessing it's likely to decide that your cache is fake because it has more stars in it than the Codex says you have visited...?

Interesting scenario. Since we don't know whether there's any checking of the two or what the check might be, it's hard to say what the result would be.

Is the codex a local file like the visited stars cache or does it come from a server?

I couldn't find any obvious files in the data cache folders.

Good question. I don't believe I have seen any obvious files locally either.

 

[Neilski]

What if the codex is the same for the 2 versions too..

If they forgot about splitting the stars cache file, maybe they did the same (mistake?) with the codex

Well yeah, that was exactly the point of my original question to @Lhorndra

Is the codex a local file like the visited stars cache or does it come from a server?

I'm certain it's from the server, based on what I've read in other threads. (E.g. you can install on a completely fresh machine and the Codex has the same info.)

Interesting scenario. Since we don't know whether there's any checking of the two or what the check might be, it's hard to say what the result would be.

Yes, I reckon there's no hard evidence yet that there's a check of this kind, but (see above) info in the other thread about the cache (posts before and after this one) might indicate that the apparent cap is linked to the Codex "stars visited" value (or whatever it's called there).
We could readily convert this to hard evidence or disprove it with a few simple tests, but we'd need to find someone who cares enough

 

[Lhorndra]

Can you tell if this "sameness" also applies to the Codex entry for the number of stars you've visited? (E.g. if you visit a bunch of new systems in one, does the figure rise in the other...)

Good point! I totally forgot to check that during my initial short test. But… see below.

We could readily convert this to hard evidence or disprove it with a few simple tests, but we'd need to find someone who cares enough

Sorry CMDRs, my real life in the distant past of 2022 is currently a bit busier than expected, so it might take a while for me to get back to that – if at all. I mean, I do find it mildy annoying, but not game breaking. There are other, more pressing issues with the game. cough

What baffles my mind is that the visited stars filter seems to be the only filter in the Galmap that gets its data locally, client side. Why? I can’t imagine it being more CPU/bandwidth hungry than all the other filters. Why are the Codex stats and this Galmap filter being treated differently? I don’t get it. Even if they completely forgot to implement a visited stars interface (or whatever), it would be easy to download this small file at the start of every session from the server, cache the ongoing process locally and then re-upload it after the session ended.

 

[Neilski]

What baffles my mind is that the visited stars filter seems to be the only filter in the Galmap that gets its data locally, client side. Why? I can’t imagine it being more CPU/bandwidth hungry than all the other filters.

Good question. I can only guess that the database query may be horribly expensive...

 

[Neilski]

More evidence: usually, you can view the system map of a visited system. In my case, the "View system map" button in my Live Galmap is greyed out for those systems. So, even if the Live Galmap shows those systems as "visited" (because it just reads VisitedStarsCache.dat), it still knows that I didn't visit these systems, otherwise I should be able to open the system map for these systems.

I've just realised that I misread this bit of your post (and got the meaning totally inverted!).
Now that I've reread it, I reckon this observation leaves no doubt that the behaviour is accidental.

It also seems like a good moment to have a rant about the name of the damn file in the first place: a developer absolutely shouldn't call a file VisitedStarsCache if it's to be the one and only copy that the user will ever be given of some really important data. ("Cache" implies that it's a copy, to save some time, but in fact if you lose it then you're done, tough cookies.) You also really shouldn't store it in the Local part of the user's AppData. But I suspect that rant has been had quite a few times already on this forum.

 

[robbyp]

Hmm https://www.merriam-webster.com/dictionary/cache

I think they are within their rights to call it a cache.

 

[Fnord Velkor]

Deleted by me...


(EDIT - Sorry, percolator broke, coffee-deprived morning, tea is not a good substitute.)

 

[Northpin]

"Cache" implies that it's a copy

In computing it is the storage aspect that is meant of course, not the hidden aspect.

i'd say you are both sort of right

normally a cache will be a temporary, really fast storage, used to hold copies of data (from the main storage), so they can be accessed faster

FDev can name their files as they want, but in this case "cache" is not entirely correct.
But maybe in the initial plan it was correct - maybe they initially wanted that file to be a local copy of a cloud based save.

Too bad now it's only a local file, easily to miss when doing backups, but (IMO) extremely important for Explorers

 

[Neilski]

Call me old school but nope, in computing speak a cache is not a file in which anyone ever puts stuff that matters. If you put "cache" in the name of a file, it better be ephemeral and users should be able to delete it with total impunity. Storing it in the Local section of Appdata declares pretty much the same thing, no?
It's certainly plausible that FD changed their minds about how to handle this data, and it thus became just one more of the countless slightly broken things about ED.

 

[Lhorndra]

Too bad now it's only a local file, easily to miss when doing backups, but (IMO) extremely important for Explorers

This.

 

[Frankymole]

I'm a bit confused. All these folders (well, most of them) with numbers as the folder names, contain a "VisitedStarsCache" file.

Are they all different - separate chunks of visited stars lists, or does the latest one contain ALL the visited stars?

Basically: what do I have to back up?

Directory / location is c:\<username>\Appdata\Local\Frontier Developments\Elite Dangerous\<userid, i.e. all those gobbledegook digits in the folder name>\VisitedStarsCache.dat

 

[Neilski]

Are they all different - separate chunks of visited stars lists, or does the latest one contain ALL the visited stars?

Basically: what do I have to back up?

Pretty strange that you have more than one - do you use more than one account/commander?

No harm in backing them all up I suppose but I'd bet on the "real" one being the file that was updated most recently. The most recently updated folder is also the one with the smallest number, and since you've been around here for a long time your commander number (which may be what the number of the folder represents) would be pretty small, I imagine.

My understanding (based on nothing bulletproof) has been that there's only one cache for any given commander.