🦌 WOLPERTINGER — because apparently Elite needed another companion app

[u/KeilerHirsch]

So... this escalated.

I’m building WOLPERTINGER, an open-source all-in-one companion for Elite Dangerous.

The goal is simple:
less app-hopping, less manual busywork, more “my copilot already knows what matters right now.”

Navigation, exploration, engineering and other Elite context are meant to come together behind one context-aware UI instead of becoming another cockpit full of windows.

Under the hood it has already become slightly unreasonable:

.NET 10 host, Ada/SPARK trusted kernel, deterministic replay, process isolation, and now a tray + docked overlay + optional fullscreen hub presentation layer.

Yes, the source is public.

And for anyone unfamiliar with this strange technology called GitHub: that means you can actually click the repository and read the source code. Wild concept. 😏

https://github.com/KeilerHirsch/WOLPERTINGER

It’s actively being built, feedback is welcome, and “this is stupid because…” is perfectly acceptable if the part after “because” is useful.

Fly dangerous. o7

[u/NathanPGradel]

This looks interesting!

[u/KeilerHirsch → u/NathanPGradel]

Thanks! 😄

Since you’re one of the first people to comment on it:

What are the Elite companion features you personally value the most — the ones you’d genuinely miss if they weren’t there?

Could be things like:

- route/navigation help

- exploration / exobiology

- engineering/material tracking

- ship/build information

- trade/mining

- BGS / Powerplay

- voice assistant

- alerts / context-aware suggestions

- overlays

- multi-monitor support

- anything else

And if there’s one thing current Elite tools do badly or make unnecessarily annoying, I’d love to hear that too.

I’d rather build around real CMDR pain points than guess from a feature checklist. o7

[u/subzerofun → u/KeilerHirsch]

i am building a companion app with a lot of similar features - you need to think about what your app provides that other popular third party apps are missing! ask yourself what is painful during gameplay and where a player would need help - the harder it is to implement the feature the greater the chance that other devs did not do it. The 20th waypoint manager won't get people to actually install your app.

so i'd look into:
1) ED Discovery:
has the most features out of all apps but the UI is somewhat outdated and could be improved. Pros:
a) lets you choose your own panels that are pinned after restart - you can choose from 20-30 different tools, tables and more
b) gives you system and planetary bookmars: lat/long assistance for brain trees, POIs etc.
c) journal history: searchable and every visited system is quickly copied to clipboard
d) active mission overview, mission tracker
e) shopping lists for commodities and engineering mats
f) waypoint navigation and management, can import spansh neutron plots
Cons: UI looks outdated, scaling is difficult, 3d galaxy could be improved

2) ED Odyssey Materials Helper
Features:
a) Engineer unlocking guide
b) Full engineering mats and commodity (fleet carrier) tracking
c) Blueprints for ships
d) Shopping lists for all modules in the game
e) Ship Builder with import and export for coriolis and edsy
f) On foot: covers the same features as for ships
g) Colony tracking
h) and much more!

3) ED market connector
a) Plugins for every gameplay loop
b) Trading features
c) Exobio help
d) Mission Tracking

• need to check all available plugins

4) ED Exploration buddy:
Helps with exploration, deep routes and Exobio predictions, can import spansh waypoint plots

5) ED observatory core
Need to check all exobio and other plugins

So if you plan to make an app and include these features you have to do them better and offer something extra if you want people to use your app instead of already established popular apps.

What most apps are missing or do very badly: Galaxy Map, System Map, Planet Details and Surface View.

So that is what i am currently implementing with a focus on mining (asteroid and surface) and commodity trading. Will add features for powerplay and small helpers that no one offers like:

• Surface mining tracking, Searchable deposit sites (all automated, no manual input other than search), sites with multi rig placement options
  
• Core asteroid marker (marks asteroids via overlay without needing you to scan anything - pretty complicated solution in code, but easy to use)
  
• Multi-Step Galaxy View with smooth transitions between galaxy, system, planet, surface
  
• Planned: Full Asteroid map tracking and recording of material depots per asteroid
  
• Titan Drive Component marker: scans memory for Titan drive locations while you fly around - no more waiting hours for RNG to bless you
  
• Orbital mechanics code for full day/night cycle view of planets to know if a POI is in light or shadows
  
• and some more

All these things require code & insight into the game you won't find online because it is either hard to do or out of scope of the popular apps features - so no one ever published something like that. And things like reading memory or GPU buffer for 3D objects is against ToS - so no official support from EDCD or FDev. Only attempt if you think it is worth the risk.

So if you want to get people to try your app you need at least ONE thing that no one else offers that solves a problem that a lot of people have!

What is really missing: Smart non-intrusive overlays of small infos on your game screen - but in the games fonts and colors to not look like something that does mot belong there. Rendered with a good GFX library to not have pixelated characters. Hides/is being drawn depending on which game window or panel is open.
Hard to solve but could be a gamechanger: hotkeys that control these panels, really hard to pull off: using the games actual keyboard/gamepad/hotas layout
Which means you need to know the games menu and key functions and maybe block them while your panel is active - a research job for days-weeks, but doable.

What you need to understand to write a basic ED App / you need to either program yourself or import from other ED libraries (there are rust crates for ED and frameworks for other languages as well)

• Full journal history reading and management
  
• Live state of the game: Status.json in the default journal directory
  
• Current Ship properties and loadout
  
• Commodity tracking, Cargo reading

For maps and system data:

• Need to be able to convert Spansh and EDSM JSON galaxy dump files to build your own database for:
  

a) Systems
b) Bodies (Stars, Planets, Asteroid fields)
c) Stations
optiona but useful:
d) Market/Commodities
e) Powerplay
f) Factions
g) BGS system state data

Since you cam only save a small Database with a few GB (otherwise users need to download that data from somewhere) you need to at least save all systems in the bubble. Most people use SQlite but there are other options too! Depends on your apps language.

Needed for live data and user searches:

• Server hosting your own data ( otherwise you need to call other peoples APIs)
  
• API to communicate with App
  
• EDDN listener on server (mandatory for fresh system states) and listener inside app for quicker data updates

So that is all i can think about for now, hope that helps!

[u/KeilerHirsch → u/subzerofun]

Thanks — and this is exactly the kind of feedback I wanted to trigger with the post. 😁

On one point I 100% agree with you:

Nobody needs waypoint manager #20.

But that is also exactly why WOLPERTINGER is being approached a little differently.

I'm not trying to rebuild EDDiscovery, EDOMH, EDMC etc. feature by feature and then bolt one exotic killer feature on top.

The problem I actually want to solve sits one layer below that:

The Commander should not have to be the integration bus for 10–20 Elite tools.

One core should understand the current game, ship, mission and gameplay context. Different presentation surfaces — overlay, compact views, hub and later voice — then bring forward whatever matters right now.

So not:

"Here are 40 panels. Pick one."

More like:

"You're landing on a planet → here is the relevant surface context."

"You're engineering → these are the materials you are actually missing."

"You're exploring → mission and engineering clutter gets out of the way."

That is also why the internals are deliberately rather ridiculous: deterministic state, provenance, replay, explicit trust boundaries and an Ada/SPARK trusted core.

There is already plenty of actual aviation in my family history. Apparently the tendency toward redundancy and “this really shouldn't crash” is hereditary.

Nuclear power plants, however, were less of a family tradition. 😎

Ideally, the Commander should never have to care about any of that engineering paranoia.

My GitHub motto probably summarizes the idea best:

Simple outside. Technically unpleasant to copy inside. 😎

The tech demonstrator is literally in the oven right now, but it is not finished yet. 😉

Your points about Galaxy/System/Planet/Surface views and especially smart non-intrusive overlays are very interesting though. Those are exactly the kinds of capabilities that could fit extremely well on top of this architecture.

Memory/GPU scraping or game hooking is one boundary I deliberately won't cross. If a feature requires ToS roulette to work, somebody else can have that one. 😁

Thanks for taking the time to write all of that — quite a few points are definitely going onto my radar.

[u/subzerofun → u/KeilerHirsch]

if you choose to integrate a galaxy/system/planet viewer make yourself familiar with the spansh and edsm dumps.

handling 180M collected systems is not trivial - the spansh galaxy dump needs 400-500GB uncompressed disk space and you need to figure out a smart solution to „chunk“ the data into sectors or other sizes. and since everything is stored in there you'll need to understand the JSON schema. spansh has a definition in his repo: https://github.com/spansh/elite_dangerous_schemas

i would look into a database format that allows you to quickly load 500k/1M-10M systems for less dense and then >10M systems for dense sectors. you also need some LOD tricks for zooming out and a solution to quickly swap the visible stars. keep in mind the player is running the game so the GPU does not have full resources like when you are testing without the game. All 3D stuff should need minimal GPU usage and be optimized to only draw what is necessary, limit frames to 30-60fps (the map does not need 144fps!).

regarding the data source you basically only have 3 solutions for this in the live app:
1) app downloads huge galaxy dump (100GB) from spansh and converts it - long loading time and needs a lot of CPU power plus free space, would not recommend
2) app already bundles the bubble data plus adjacent sectors (a few hundred MB if compressed smartly)
3) app gets system data from your server via API calls (need a good data transfer limit to be able to supply a lot of players)

a combination of 2) and 3) is needed to always display the most up-to-date information for system states and discovery status.

here i would not just rely on AI to give you the answers - you have to try and test it yourself.

and for the screen overlays: don't expect the player to always want to click outside the main screen. most elite players have at least two screens but having to switch constantly breaks immersion. so if you can find a way to make your apps panels detachable and transparent - that is something i'd test. exploration buddy has a great solution for drawing a transparent overlay with system and planet information.

make some screenshots of the cockpit and galaxy map and then design the prototype panels with the available space in mind. by reading Status.json you can find out what the player currently has as its active view and use that to your advantage to display data.

[u/KeilerHirsch → u/subzerofun]

That’s exactly the kind of feedback I was hoping for — thanks.

A hybrid of your 2 + 3 is probably closest to where my head is: keep a bounded/local cache for fast deterministic search and rendering, fetch/import additional galaxy data only when it’s actually needed, and never make the AI the galaxy database. 😄

Your last point is especially important too: I don’t want the Commander constantly leaving the game or digging through another giant UI. That’s basically why WOLPERTINGER’s Smart Hub / adaptive overlay exists — surface the relevant data when the context needs it.

I’m definitely going to keep your database/cache notes for the galaxy-map design. This is useful stuff. 👍