Right, this one has been rewritten from scratch. The version that sat on this URL since October 2025 described a feature that does not behave the way it said, in a universe that does not exist, complete with invented example systems and an invented log format. I have gone back through the actual code in both repos and written down what the thing does today. If you read the old version and then went looking for buttons that were not there, that is why, and sorry about that.
Quick context if you are landing here fresh. EF-Map is a free interactive 3D map of EVE Frontier, and the map database holds 24,026 solar systems. Almost all of them are named like A4T-SL7 or A.062.E25, and only a hundred carry a proper pronounceable name, so after a few weeks of flying they genuinely do blur into each other. That is the whole reason visited-systems tracking exists. It is a dull feature. It puts a ring around the ones you have already been to.
The thing worth saying up front is that there are three separate ways to get those rings now, and they do not share any data with each other. One needs the desktop helper, one works off log files you drag into the browser, and one is you ticking boxes by hand. I will go through them in that order.
What the helper actually records
EF Helper is the small Windows app that sits alongside the game. It does not read the game's memory and it does not touch the network. It tails the chat log the client already writes to disk, and the specific line it cares about is the one the client emits when the chat channel changes, which looks roughly like Channel changed to Local : A4T-SL7. The helper pulls the system name out of that line and resolves it to a system ID. If the name is one it cannot map, it says so in the panel rather than guessing.
That resolved location is the only thing the visit tracker runs on. When the helper publishes a state update carrying a location, it records that system twice, once into an all-time file and once into the active session if you have one running. All-time tracking is off until you turn it on, which I think is the right default for something that writes a file about your play habits, and starting a session is a separate button again. So you can run sessions with all-time off, or all-time with no sessions, or both.
Where the data lives, which is not here
Everything goes to %LocalAppData%\EFOverlay\data on your own machine. There is one visited_systems.json for the all-time record and one session_YYYYMMDD_HHMMSS.json per session, written when you stop it. The web app gets at that data by asking the helper's own little HTTP server on localhost, which is the same bridge the rest of the helper features use.
Nothing is uploaded. I want to be blunt about that rather than dress it up, because it is the one thing people ask me about every time the helper comes up. EF-Map's servers never see which systems you have been to. I could not tell you your travel history if you asked me to, because it never leaves your PC.
What the map does with it
In the helper panel there is a toggle called "Show visited systems on map". Turn it on and two things happen to every star you have visited. The star itself gets recoloured, and that colouring takes priority over every other star-colour layer the map has, so visited systems win over star type, over route colouring, over the lot. Then an additive ring is drawn on top of the star.
The old article said the rings were orange. They are not, and they never really were once themes landed. The ring is whatever accent colour your theme is set to, and WorkSafe mode swaps in its own. The reason the ring exists at all is that on some accent themes, Ember especially, the recoloured star sits so close to the natural star colours around it that you cannot pick it out. The tint alone was not enough, so the ring got added on top, the same trick the jump-bubble in-range highlight uses. Rings are hidden in Cinematic Mode and in the solar system view, because they are a navigation aid and neither of those is navigation.
Hover a visited star and the label picks up the visit count alongside the name.
The visit count is not a count of arrivals
This is the bit I would not have found without reading it back properly, and it is the least flattering thing in here. The helper publishes a state update when your system changes, and it also publishes one every 30 seconds when nothing has changed at all, as a heartbeat. A visit gets recorded on every publish that carries a location. Both of those.
So if you park up in one system for an hour, that system's count keeps ticking up the whole time you sit there. What the number is measuring is closer to how long you spent somewhere than how many times you arrived. Treat it as a rough weight rather than a tally, because that is what it is. I am genuinely undecided about whether to fix it or rename it, since as a "where do I actually spend my time" figure it is arguably the more interesting number of the two, it is just not the number the label promises.
The other thing to know is the refresh rate. The map asks the helper for visited data every 30 seconds, not continuously, so a ring will not appear the instant you land. Give it half a minute. The helper panel polls on the same interval while its overview tab is open, which is why the counter there lags a little too.
Three datasets, one toggle
Once visualisation is on you get a choice of what the rings represent. All-time is the default. Active session only shows just the current session, and is greyed out when you have not started one. Past session gives you a dropdown of every stopped session, labelled with its date and time and how many systems it holds, and picking one replays that session's footprint on the map.
There are two reset buttons and they do different things. Reset all-time wipes the permanent record, and it sits behind a confirmation that tells you exactly how many system records it is about to delete, because it is not recoverable. Reset session clears the systems out of the current session but leaves the session itself running, which is the one you want when you realise you started tracking three jumps too early.
One small piece of plumbing worth mentioning, since it caused real bugs. The names the game writes in the chat log and the names in the map database do not always agree. So before anything is drawn, every entry from the helper gets resolved against the map's own system table and re-keyed by the map's ID, and if two entries resolve to the same system their counts get added together rather than one silently overwriting the other.
Without the helper at all
The helper is Windows only, so the second route is the Log Parser, which runs entirely in the browser and does not care what OS you are on. You point it at your chat logs, it parses them locally, and the Travel tab gives you visits per system out of the same log lines the helper reads live.
Its rings are a different module and look different on purpose. There is an inner ring saying you were here, and an outer ring drawn as an arc, where the length of the arc is that system's visits as a fraction of your busiest system, with a minimum fill so a single visit still shows up. It also has playback, which sorts every system by when you first saw it and then reveals them across a duration you choose, so you can watch your own route unfold across the map. Amusingly, the old version of this article listed route replay as a future enhancement. It has been there for a while.
The third route is the System Checklist, and it has nothing to do with logs at all. Pick a region, get every system in it grouped by constellation, and tick them off by hand as you go, with a running count and a percentage at the top. It saves per region in your browser's local storage. It is for the case where you have told your tribe you will scout a region and you want a list you can actually finish, rather than an automatic record of where you happened to end up.
So that is the honest version. Three tools that do not talk to each other, one count that measures something slightly different from what it says on the label, and a pile of files that never leave your machine. If the count behaviour bothers you more than it bothers me, or the 30 second refresh is too slow to be useful, let me know and I will have a look at it.
Related Posts
EF Helper: The Desktop Companion App for EVE Frontier covers the helper itself, what it reads and how to get it running.
Building the Helper Bridge: Native Desktop Integration for EVE Frontier is the architecture of the localhost connection between the helper and the web app.
Log Parser: Your Personal Flight Recorder for EVE Frontier is the browser-side route, including the Travel tab the rings come from.
Transparency Report: How Every Feature Works Under the Hood is the wider version of the "nothing is uploaded" claim, feature by feature.