Proposal: Modernizing Tactical UI and Communications

Feature Previews & Feedback Photon UI
1

1. The Problem: The Performance Trap

Currently, EVE’s mandatory Local Channel member list is the single biggest bottleneck for both the server and the UI. In a system with 2,000 pilots, every time one person jumps, the server must calculate standings and broadcast redundant metadata to the other 1,999 players. This exponential data flood clogs the network pipe, causing the “sticky” UI lag we experience when opening the Market, Wallet, or Assets windows.

2. The Solution: Tactical HUD & Unified Chat Console

  • Tactical HUD Counters: Completely remove the member list from the Local window. Replace it with five dynamic counters at the top of the HUD (Blue, Light Blue, White, Orange, Red). The server only sends tiny “Integer updates” (+1 / -1), reducing the broadcast load by over 90%.

  • Unified Chat Console: Replace the forced, separate Local window with a modern Unified Chat Console. This console allows players to customize their stream, showing messages from Local, Corp, Alliance, or Custom channels in one integrated view.

  • No Presence Rendering: By removing the requirement to render thousands of interactive player IDs, we free up the UI thread. Chat becomes about “content,” while the HUD handles “presence.”

3. Technical Optimization: Instant Response & Scalability

  • Server Relief: The Sol Node is freed from managing massive Local session groups. This allows the server to prioritize combat calculations, directly reducing Time Dilation (TiDi) in large fleet fights.

  • Network Optimization: Without the constant flood of player profiles, network synchronization for UI windows (Market/Assets) becomes instantaneous.

  • Client Fluidity: Removing the member list allows even low-end PCs or mobile devices to run smoothly in high-population hubs like Jita.

4. Gameplay Evolution: Restoring the “Dark Forest”

The current Local list provides too much “free” intel. By only showing a “Red +1” on a counter, players know there is danger but don’t know the exact identity or ship type. This restores the strategic depth of Directional Scanning (D-Scan) and scouting, bringing back the sense of mystery and risk that defines EVE.

5. Conclusion

EVE doesn’t need more hardware; it needs smarter, leaner logic. We need a system that prioritizes tactical performance over redundant social lists.

“We need a Radar, not a Passenger List.”

Proposal: Modernizing Tactical UI and Communications

“I’ve been thinking a lot about the current state of our UI, especially during large-scale engagements. I love this game and its complexity, but I feel our 20-year-old chat system might be holding us back from a more fluid experience. I’ve put together some thoughts on how we could modernize the interface to improve performance and tactical depth. I’m just one pilot sharing a vision, and I’d love to hear your constructive feedback on this.”

1. Tactical HUD Counter & On-Demand Indexing

Integrate a dynamic HUD Counter directly into the ship’s interface (near the capacitor/speedometer). This moves away from the inefficient “Server Push” model and focuses on constant-time category synchronization:

  • Precision Four-Color Counting: Displays real-time counts for Red (Hostile), Yellow (Neutral), Blue (Friendly), and White (No Standing/General).

  • Active Situational Awareness: When the Red count increases, the HUD element performs a subtle visual pulse/flash, triggering a pilot’s instinct without requiring them to scroll through a clunky list.

  • On-Demand Indexing Interaction: Clicking a specific count (e.g., the Red number) instantly filters the Overview. This fundamentally changes the underlying logic: instead of the server forcing detailed profiles of 2,000 pilots onto your client (Server Push), the client only requests and “indexes” specific target data when the player actually clicks (Client Pull). This drastically reduces the CPU/RAM overhead caused by constant UI updates.

2. Unified Communication Feed: From Multi-Window to Streamlined Social

Eliminate the legacy design of multiple overlapping windows in favor of a Unified Stream. All messages are categorized by color and prefix:

【Simulated Chat Feed】

[Local] abc: hello, o7

[Corp] 123: What time does the mining op start?

[Alliance] 666: Just spotted a hostile fleet in Jita, stay alert.

[Private] Hublot: Hey, was that your killmail just now?

  • Streamlined Interaction: Support instant channel switching via shortcuts (e.g., /l to Local, /c to Corp, /a to Alliance, /r to Private).

3. Surgical Removal of “Dead Weight”: Impact on Botting Ecosystem

By delegating intel to the HUD and social to the Feed, the static Member List can be entirely removed from chat channels.

  • Killing the “Auto-Intel” Pipeline: Removing the list leaves bots with only a “count” and no “identity,” breaking the automated intel-scraping chain that relies on constant profile syncing.

  • Return to “Active Recon”: Intel becomes a “Tactical Resource” earned through gameplay (D-Scan/Visuals), not a “Passive Gift” from a legacy UI.

  • Performance Leap: Eliminates the massive data broadcast storms that slow down the client. By removing the need to sync thousands of portraits and standings, we ensure maximum FPS during heavy TiDi fleet fights.

Conclusion: This proposal evolves EVE from “Spreadsheets in Space” to a modern “Tactical Space Combat” experience. It is time for a high-performance UI that respects the player’s screen space and the CPU’s limits.

2

It sounds like this is an issue that would be better solved by caching, and then only having the client actually request an up-to-date list of orders/wallet entries/assets once a category is requested. Display the cached version immediately, then silently update as soon as the up-to-date version arrives. The UI would feel perfectly snappy, and in most cases the new data would appear before the player has time to start reading outdated entries.

This is going to be a no-sell to the players. We already saw what happened when local was removed from null, and this change will be on par with that. I also don’t think your integer update idea actually saves any server load, the member list is already being sent over IP packets, the actual payload of a packet has very little impact on how quickly the packet is received, what matters is the latency for each packet, and the number of packets. I can’t see EVE needing more than one packet for a local channel user list, so the difference between sending an array of user IDs vs sending just a single integer would be negligible.

God no. Who are you, Satan? Don’t give them ideas for new Photon UI “features”.

This is not a significant workload on any computer remotely capable of running EVE.

I don’t think this is a large load. Do you have a source that says it is? The local list only needs to be updated once per tick if a session change (jump in/out, log on/out) occurs that tick, and the same local list can be sent to every client in that system. If performance impact of the local chat is a huge issue, rather than making all these other changes, it would be more sensible to just start doing local updates less frequently in systems under TiDi.

This would also be achieved with caching.

I’ve never had any issues in Jita playing on my laptop, once I turn the graphics down. How low-end of a device are we talking?

I do agree that local encourages people to avoid fights, which is not ideal.

3

This is NOT a Blackout. The 2018 Blackout failed because it provided zero info. My proposal provides instant situational awareness. You still get the “Red +1” alert immediately. The only difference is you have to use your D-Scan to see who it is. It balances the “Safety” of Null-sec with “Performance” and “Active Gameplay.”

Is wanting a modern UI a sin now? I’m not asking for fancy effects; I just want to see my messages in one place without playing “Window Management Simulator.” Having five windows for five channels is a 2005 design. Consolidating them into one stream is common sense—it lets me focus on the space in front of me, not the clutter on my screen.

It’s not about whether a PC can handle it; it’s about why it should have to. Just because you have a fast car doesn’t mean it’s okay to drive with the handbrake on. Rendering 2,000 redundant interactive IDs is a handbrake on EVE’s performance. By stripping the ‘Passenger List’ and moving to a ‘Radar’ (HUD Counter), we fix the architectural flaw instead of just throwing more hardware at a bad design.

Your ‘once per tick’ theory ignores the fact that EVE has to calculate standings for every single recipient in that system. A 2,000-man fight isn’t just one list; it’s 2,000 unique versions of that list being calculated by the standing engine. That is why TiDi exists—to give the CPU time to finish these redundant calculations. My proposal deletes the need for those checks entirely. Why fight the symptoms with ‘lower frequency’ when you can cure the disease by removing the list?

Caching is a 20-year-old answer to a 20-year-old problem. It doesn’t solve the fact that the UI thread still has to manage and render a massive, bloated list of interactive objects. Why spend resources ‘caching’ a list of 2,000 names you aren’t even reading, when you can have a single, high-performance integer that tells you exactly what you need to know? Let the Market and Assets windows have the bandwidth they deserve instead of fighting for scraps with a redundant member list.

Lowering graphics helps your GPU, but it doesn’t fix the UI thread. The ‘Jita Lag’ isn’t just about textures; it’s about the client choking on 2,000 interactive player objects in your Local list. You might be fine with a sluggish UI on your laptop, but for multi-boxers or players on handhelds, this is a real barrier. Why should we keep a high-overhead legacy system just because ‘it works if you turn everything to low’?

4

Then ask them to let you group channels together. I absolutely do not want channels mixed, and I suspect I’m with the majority on this. And we all know if CCP did add this they would only give us the option to split them back out into separate windows after many months of player rebellion.

The server doesn’t have to calculate standings, it just has to send the character, corp, and alliance IDs to the client, which then colours the icons based on the standings list (presumably downloaded once on logon).

Because it’s nice to look at the local of your home system and recognising a couple names. It’s nice to say “Oh hey there IMFOB.” if you run into someone you disagreed with on the forums or remember from years ago.

I still hold that the UI thread is a negligible load. I also think multiboxing is already bad enough without catering to them specifically by worsening core features for everyone else for what is unlikely to be a performance improvement in the first place. Your Steam Deck can handle EVE’s UI just fine, what it chokes on is shaders.

A better fix for multiboxers would be to add two sliders to the settings, “Active Window Framerate Cap” and “Inactive Window Framerate Cap”. Set the active to 120 or whatever you monitor does, and the inactive to 30, and suddenly your performance would be vastly better even on high graphics settings, simply because you’re not wasting cycles rendering a client that is only visible in a tiny preview window anyway.

5

You are arguing against a choice I haven’t even taken away from you. A “Unified Stream” should be an option, not a forced mandate. If you love having 5 windows cluttering your screen, keep them. But don’t block a common-sense UI feature for the rest of us just because you’re cynical about CCP’s implementation

That’s factually incorrect. If the server didn’t calculate standings, the Overview, Gate Guns, and Aggression timers wouldn’t know who to shoot. The server must track every player’s relationship to the local node to manage grid security and broadcast lists. Even if it “just sends IDs,” sending 2,000 IDs to 2,000 people every time a session changes is an O(n^2) broadcast storm. That’s exactly what kills the Sol Node.

Nostalgia is nice, but it shouldn’t dictate engine architecture. You want to say “Hi” to one person once a year, so we all have to suffer 10% TiDi and UI lag every day? If you want to find a friend, use the Search function or join a Link channel. We shouldn’t sacrifice the performance of a 5,000-man battle for the sake of a “warm fuzzy feeling” in local chat.

A “Framerate Cap” only helps the GPU. It does nothing for the CPU usage of the underlying UI objects. 10 clients running at 1 FPS still consume massive RAM and CPU cycles to keep 10 separate Local member lists synced in the background. My proposal reduces the Data Complexity, which is far more effective than just capping the render rate. You’re trying to fix a leaky pipe by painting the wall; I’m trying to fix the pipe.

You’re dismissing architectural bottlenecks as ‘negligible’ based on personal feeling, while ignoring the mathematical reality of $O(n^2)$ data broadcasting.

Suggesting FPS caps for multiboxers is a band-aid for the GPU; it doesn’t touch the CPU/RAM bloat of syncing thousands of interactive IDs across multiple clients. We shouldn’t keep a broken, high-overhead system just for the sake of ‘seeing a name you recognize’ once in a while.

EVE is a game of massive scales. If we have to choose between ‘Nostalgia’ and ‘Performance,’ Performance must win for the game to survive the next decade.

6

To clarify: I am NOT suggesting we remove the ability to talk in Local. If ABCDE types ‘Hello,’ everyone in the system should see it in their chat stream.

What I am proposing is removing the redundant Member List that tracks every single pilot’s identity automatically. By moving tactical intel (the count of reds/neutrals) to a simple HUD element, we kill the O(n^2) server lag and the UI clutter.

You get to keep your ‘social’ game, but we finally get a ‘functional’ engine that doesn’t choke during a 2,000-man fight just to tell you the name of every pilot you aren’t even looking at.

7

You may be new, but that’s not how CCP works. If they add unified chat, they’ll do it by removing the old chat everyone but you prefers. After a week with the unified chat I’m sure you’d be sick of it and want to go back, too, I know that’s what WoW is like for me.

The overview is put together client-side, and gate guns/aggression timers have nothing to do with player standings. Even so I’m sure those are also handled mostly client-side, the server obviously handles the mechanics involved, but colouring them hostile on the overview is very much done on the client, and is again as simple as the client knowing your standings to various NPC factions, and those gate guns being tagged as belonging to x NPC faction.

The compute also isn’t O(n²), it’s O(n). You put together the array of character, corp, and alliance IDs, then send that to every client in the system. Again, the server doesn’t colour icons in the overview and local channel, I’m 100% sure that’s done client-side, anything else would be asinine.

You’re not suffering 10% TiDi because I have a list of people in-system. Even in a 5000 man battle the local channel list is going to be absolutely negligible compared to the actual combat math of determining tracking, angular velocity, range, and generating a random number for the damage, etc, all of which depend on the skills and fits of both characters involved (plus boosts and environmental effects if it’s in a WH, plus probably dozens of other things I can’t think of right now). It’s orders of magnitude more work than putting together an array (which the server is already tracking anyway and can’t not track because that’s how multiplayer games work) and broadcasting that to each local client.

No, you’re patching a pipe that sometimes maybe gets a trace of condensation on the side, while I’m slapping a patch on a pipe that’s leaking like a sieve. Multibox performance is bad because of the graphical load of rendering 5+ clients, not because of local chat member list.

8

Local chat is not handled by the main EVE server by the way, this is already offloaded to a separate system so loading chat has no impact on game performance.

This means the problem of this thread is no problem.

I do however agree that decoupling chat from unavoidable instant intel is a good thing to explore. Not because of performance reasons, but for game balance reasons: all other types of intel have counterplay. Chat doesn’t.

It might be interesting to add a new ship role that can fly unnoticed by local chat, like certain ships can also hide from dscan, probes or overview.

9

I absolutely love your point about Counterplay. You hit the nail on the head—EVE is a game of ‘cat and mouse,’ but currently, the Local list acts like an unblockable GPS. Decoupling chat from intel isn’t just a tweak; it’s a necessary evolution for the game’s tactical depth.

Your idea about a ship role that is ‘invisible’ to the Local counter is brilliant. Imagine a Force Recon or a Blockade Runner that doesn’t trigger the +1 on the counter. It creates genuine paranoia and rewards active scouting. It turns Local from a ‘Perfect Safety Net’ into a ‘Tactical Tool’ that can be fooled.

Regarding the performance: even if we set the server-load debate aside, removing the redundant Member List is what makes your ship-role idea technically feasible. It’s much easier to tell a counter ‘don’t add 1 for this ship type’ than it is to selectively hide a name from a legacy list being synced to 2,000 people. By fixing the UI, we open the door for exactly the kind of deep gameplay you’re suggesting.

10

That “problem” is imho better adressed via changing the Killmail System. You don’t get that much “intel” from seeing a name in local, you get that intel from tools like zkill or even more advanced applications that screen killmails for acitivity, fittings, fleet compositions and so on.

If Killmails would be anonymized in a way hat you can track your kills and losses as “personal record”, but no further info about other characters or specific time is included, you would have completely solved the “intel issue”. You either know the guy/group or you don’t. You either remember their tactics and fits or you don’t. And you can be surprised any time if they change something. You can’t just check if they have killed something else just 15 minutes ago and what they used for it.

If you then add a default delay of at least 1 hour to any api/esi function around mails, you also solve the “live tracking” issue.

A removal of newly jumped in players appearing in local can never be sold to the majority of the players. They would rather stop playing than adapting to that. So we can safely assume CCP will never try to mess with that feature again after witnessing the desaster last time.

3 Likes
11

The UI feels laggy because the responsiveness is tied to the 1s server ticks. This can be solved with some client side voodoo.

12

The skill queue is easily the worst UI performance in the game. Some issues seem to be the client/server communicating in a one by one manner despite skill movements of many at once. Applications should use batch requests to reduce network traffic and eliminate the lag that comes from the client having to wait for the server to confirm one skill change before the next change is attempted.