Back to Blog

EVE Frontier Cycle 7 Fog of War: What It Could Mean for EF-Map

Today's Frontier Friday, 11 September 2026, was about Fog of War. The short version is that in Cycle 7 you will not see the whole EVE Frontier universe any more. The demonstration showed a player sitting in one system with a small cloud of stars around them, and beyond that, nothing. The rest of the 24,000 or so systems were just not there.

That breaks the oldest assumption in EF-Map. Since the first build in August 2025, everything I have done has started from a complete universe. I extract the map data from the client files, build a database with all 24,026 systems in it, and every other feature sits on top of that. Routing, filtering, the System Finder, the killboard putting kills on stars, all of it assumes I know where every star is before anybody opens the site. Cycle 7 may take that away.

A couple of weeks ago, in the EO-Map article, I wrote that Fog of War did not sound like a fun time for a map. Having watched the stream, I think I had that backwards.

What was actually shown

I want to keep what Fenris said and showed separate from what I am reading into it, so this section is the stream and nothing else.

The line that stuck with me was "data needs to be earned and it needs to be controllable." Stars and the internals of solar systems will be obfuscated when they are far away from you. From what was said, that goes beyond hiding where a star sits. Things like feralisation classification, asteroid belt types and other system properties appear to be part of what stays hidden until you have earned it. Players will be able to name things. Scanning will create actual data items that exist in the game.

The visual demo showed a player seeing only a local bubble of stars around their current position rather than the whole map. In the initial Cycle 7 version, that knowledge does not appear to persist as you move. You see what is near you now, and when you move on, the old area goes dark again. They said persistence is something they intend to do later rather than something in the initial brief.

The EVE Frontier in-game map during the Frontier Friday Fog of War demonstration, showing a small cluster of visible stars around the player's current system and empty space everywhere else.
The Fog of War map demonstration from Frontier Friday on 11 September 2026. The player sees a local cluster of stars around their current system and nothing beyond it. Open the image for the full-resolution view.

I am not going to put a number on the size of that bubble. I had a guess while watching, but it was visual guesswork from a stream, and that is not good enough to publish. If Fenris states a range, I will update this. That is the whole of what I am treating as fact. Everything from here on is me thinking out loud.

The awkward bit first

Cycle 7 is expected at the end of September. There is a real chance that on day one I do not have a complete Cycle 7 map, and I would rather say that now than have people find out by loading a half-empty site.

At the moment I do not know what will still be in the static client files, what the World API will expose, what will be delivered dynamically as you move, what might be persisted locally, or what legitimate export or share mechanisms Fenris will provide for those scan data items. I will only know once the Cycle 7 client and services actually exist.

I also want to be clear about the approach. The plan is not to read the game's memory, reverse engineer the client, or otherwise bypass Fog of War. If Fenris wants information to be earned, a map that hands it out for free is a cheat, not a tool. The question that matters is whether there is a sanctioned or otherwise permitted way for discovered data to leave the game and be used by a third-party tool. When the client lands I will look at official APIs and public data first, then whatever the game itself supports, which after today may include those scan data items, then normal local files, caches and logs where that is permitted. Only after that would I be asking Fenris whether there is a gap that needs a straight answer.

So yes, the first few weeks might be messy. I think they might also be the most interesting weeks the project has had.

Why I think this is good news

Until now, EF-Map has been useful mostly because the in-game map was limited and because I added better routing, filtering and tooling around the same universe everybody could already see. The data itself was never the value. Anybody with the client had the same 24,026 systems I had. What I added was what you could do with them.

Fog of War changes that. If each player only ever sees a small bubble of the universe, then for the first time there is an actual gameplay reason to collate universe knowledge outside the client. Not because the in-game map is clunky, but because no single player has the information in the first place. EVE Frontier has always been pitched as a game where third-party builders extend the world, and this is the first time I have felt that the universe knowledge itself is something a third-party tool can legitimately add to rather than duplicate.

Not everybody wants to be an explorer

The obvious slogan to take from today is something like "mapping the universe becomes part of the game." I don't think that is quite the interesting bit.

The more interesting point is who needs the map and who makes it, because they are not the same people. Somebody running a tribe does not want to personally visit thousands of systems to work out how to move their people around. A logistics player wants routes. Somebody running infrastructure needs to know what exists around them and what has changed. And the explorer who genuinely loves finding systems probably has no interest at all in building a routing engine or maintaining a shared database for everybody else.

That gap is exactly where third-party tooling starts to matter. EF-Map could become the layer between the people who earn information and the people who need to use it. Explorers would have somewhere to put what they find and decide who gets to see it. Everybody else would get routes, filters and answers built on knowledge they did not have to collect themselves. The stuff I have built over the last year becomes more useful rather than less, because it would be running on information that is actually scarce.

Public, personal and tribe cartography

I have not designed any of this yet, so treat this as sketching rather than a roadmap.

The obvious shape is three tiers. Public knowledge that anyone can see. Personal discoveries that stay yours. Tribe knowledge that is shared only with authenticated members of your tribe. It is not a big leap from how EF-Map already works. At the moment there are public Scout Reports anybody can read, personal marks that live only in your browser, and tribe bookmarks shared with members of your current tribe. The tribe check is real. You sign in with your Sui wallet, the server reads your character from the chain and checks your current tribe against the World API on every request. So the permission model for three tiers of universe knowledge already exists. What does not exist is any way to feed discovered systems into it, because until today there was nothing to discover.

Now, there is a more interesting layer beyond those three tiers. If discovery data is genuinely earned and controllable, and Fenris used both of those words, then a player who has scanned a region has something of value. They might release it publicly. They might share it with their tribe. They might trade it, or sell it. An information brokerage layer, where EF-Map is the marketplace rather than assuming everything discovered becomes public the moment it is uploaded, is something I now think is worth exploring properly. I am not saying I will build it. Once I understand what Fenris means technically by controllable data and by scan data items, that is the first thing I want to look at.

Stars do not move

There is an obvious long-term problem with positional Fog of War, and I would rather raise it than pretend it is not there. Star positions are static. Once a system's coordinates have been discovered and published, they are known. You cannot make the community forget them. So a public community map will, over time, fill in, and the positional part of Fog of War will gradually disappear from it regardless of what anybody does.

I don't think that makes the mechanic pointless. It moves the valuable information from "where is this star" to "what is in this system". What are its current properties, what resources or structures have been found there, what has changed since somebody last looked, and whatever future observational data Fenris adds on top. Fenris can also add or alter content over time, and if system properties can change, a scan from three weeks ago is not the same as a scan from today. So a community map can gradually become positionally complete while the intelligence layer on top of it stays useful. EF-Map already has a fair bit of that layer in the killboard, the structure tracking and the Intelligence tooling, so I am fairly comfortable with the map itself becoming the boring bit.

Rediscovery might be slow

There is a practical wrinkle I have not seen mentioned. Cycle 6 deliberately constrained travel. There are no ship jump drives in the live client this cycle, so getting between systems means stargates, player-built Smart Gates and Catapults. Even with every star visible to everybody, players have not travelled anywhere near as broadly as they did in some earlier cycles. That is a broad pattern I have been seeing all cycle rather than a statistic I have worked out properly.

If Cycle 7 really requires physical presence before a system is revealed, then rebuilding a community map is not a weekend job. It could be slow and patchy even with a lot of players contributing. I am not going to put a number on it, but a discovery-driven map could take meaningful time to fill in.

I am not worried about hiding that. I think it makes the whole thing more interesting. A public EF-Map might genuinely have blank areas for a while. Different tribes may know different parts of the universe. Route availability may depend on what the viewer knows, so the same two systems might be routable for one tribe and not for another. Up to now my routing has always known about every edge in the graph. That is a class of problem I have never had before.

The bit I keep waiting to hear

I have a longer-standing concern, and I want to make it carefully because it is a concern rather than a complaint. Today's stream talked about players earning and controlling data, naming things, and scan data items existing in the game. As far as I heard, there was no mention of the blockchain side of EVE Frontier being used for any of that. Nothing about discovery data being an on-chain asset, or transferring it, or proving you own it.

That feels like an unusually good use case for the chain. If a discovered piece of information is meant to be a player-controlled asset, then owning it, proving it is yours, transferring it, selling access to it, and using it from third-party software are almost exactly what the architecture Frontier has been talking about is meant to do. If scan data ends up as an ordinary in-game item that never touches the chain, it can only leave the game if Fenris builds an export for it, and tools like mine can only read it if Fenris builds an API for it.

This connects to something I have felt for a while, and I want to phrase it as my impression rather than a measured fact. From where I sit as a builder, gameplay features sometimes seem to arrive before the builder-facing or on-chain primitives that would let people like me extend them, and the gap feels like something in the region of three to six months. I might be wrong about the size of it. That is how it looks from outside the studio, working from public information.

The constructive reading is that maybe the gap is intentional. Maybe Fenris expects builders to create the infrastructure between the game's primitives and the player-facing experience, and the reason there is no discovery sharing system in the game is that they are leaving that space for us. If that is the opportunity, I am absolutely interested in having a bash at it. EF-Map already has wallet authentication, tribe membership checks, an indexer and a paid entitlement running on frontier-commerce, which is a decent chunk of the plumbing you would need. What is missing is the thing to plumb.

EF-Map stopped being just a map a while ago

One more thing worth saying, because "what happens to EF-Map" is really several questions. There is the killboard, the live universe events feed and the weekly State of the Frontier report. There is Smart Gate and structure tracking, Shared Storage, and the Solar System View with assemblies in it. RootFit, the fitting planner, lives on the same site at ef-map.com/fit, and so do CivilizationControl and the Open Market. Then there is the Intelligence side with the Query Console and custom panels, plus the Scout Optimizer, the Yeet Planner and the embed API.

Most of that runs on chain data and indexed activity rather than on the static universe database. If the static map is temporarily incomplete in Cycle 7, the killboard still records kills, the market still lists orders, and RootFit still fits ships. Some things will need the map to know a star before they can place anything on it, and I will have to work out how that behaves when the star is not known yet. But the wider ecosystem does not suddenly stop.

The other useful thing is EO-Map. EVE Online gives me the much easier version of this problem, because its universe dataset is fully exposed. Rendering, routing, UX, Creator Mode and the rest of the full-map technology can keep moving over there while the Frontier data model changes underneath me, and that work has already started flowing back. I am not abandoning Frontier for EVE Online. EO-Map is just a second proving ground where I do not have to wait for a cycle to find out what a map is allowed to know.

What happens next

So yeah. I do not know exactly what EF-Map will look like in the first few weeks of Cycle 7. It might have blank areas. Routing might be limited to what people have found. The pipeline I have spent a year on might need to become something that grows over time rather than something I run once after a patch.

But for the first time I might have a genuinely interesting mapping problem rather than another complete database to extract. Once the Cycle 7 client is out I will go and look at what is actually there, in the order I set out above, and write up what I find. If you were on the stream today and heard something I got wrong, or you have thoughts on how the shared knowledge side should work, let me know.

Related Posts

I Cloned EF-Map to Make an EVE Online Map, and It Mostly Worked is where I first wrote that Fog of War did not sound like a fun time for a map. This article is me changing my mind.

Two Databases, One Universe: How EF-Map Rebuilds Its EVE Frontier Map Data is the complete-universe pipeline that Cycle 7 may turn into something that grows over time.

Public Scout Reports and Tribe Bookmarks in EF-Map covers the public, personal and tribe tiers that already exist, and the wallet and World API tribe check behind them.

Halfway Through Cycle 6: Seven Weeks of EVE Frontier Data is the activity data from the cycle whose travel constraints I think will make rediscovery slow.

eve frontier cycle 7 fog of war ef-map frontier friday exploration third-party tools tribe intelligence