This is the same code you get in the game — not a screenshot, not a mock-up. Drag the button, switch modules by tapping a satellite, resize it with the slider. A tap paints a sample label and sends nothing.
Extension documentation
OG-E OGame Expeditions
OG-E is purely a UI overlay — it doesn't automate the game, it isn't a bot, it doesn't monitor your fleet, it won't notify you when you're under attack, it doesn't click for you and it never keeps your account looking active.
UI overlay, not a bot
Zero requests of its own
Open source
Mobile-first
It also sends no requests to the game server. Every click remains a deliberate click by the player, with OG-E acting only as an intermediary: it presses the game's native UI element — even when it has hidden that element and replaced it with a clearer one of its own. OG-E never creates or modifies game requests; it only records and analyses the responses the game returns, and reads what is already displayed on the page.
The project is fully open source and entirely generated by AI.
Below, every feature is described one after another: what it does, how it works, what edge it builds and why it plays fair.
The OG-E Button7 features
OG-E's flagship hub: one floating button that fires all your everyday actions with a single tap.
A smart floating button you can hit easily with your thumb, driving all your everyday actions.
The floating button: one active button in the centre, the rest as orbs around it.The button bar in settings — tiles turn individual buttons on and off.
How it works
The FAB (Floating Action Button) is one floating button that makes fleet actions easier: Expeditions, Colonisation, Lifeform Discovery, Daily routes, Fleet Save, Activity Watch and Spying. Each button is described in its own section. You always see one active button in the centre and a few smaller "orbs" around it; tapping an orb switches the active button, and tapping the centre runs its action on the current page.
You drag the button anywhere you like (its position and your choice are remembered), and each button knows for itself which page you are on and what you can do there.
Why it exists
It is built mobile-first: on a phone OGame scales the page so its native buttons become tiny and hard to hit. The FAB gives you one big, comfortable target under your thumb and gathers scattered actions in one place — it works on desktop too, but the phone is the main scenario.
More details
Button bar — turn a button on or off if you do not use the feature and do not want to see it on the FAB orbits.
The button size is set with a slider (changes live).
Position and the selected button are remembered per device; after a reload the FAB returns to the same spot (clamped to the visible screen).
Long-press has a separate meaning depending on the active button (e.g. "skip this planet").
One of the orbs is Spyglass: you turn it on and manage it from the Spyglass tab in the OG-E Dashboard (the watch list, scan settings), while in-game it proposes the next look at the galaxy or a spy-probe send — see the separate "Spyglass — intelligence" chapter.
Fair play
The FAB sends the game no requests. It passes your click on to the same native interface element you would press yourself — if the game contacts the server in response, it does so itself, after your tap, exactly as with a manual click.
It only acts on what you already have open: it reads what the game already displays and does nothing in the background — it does not refresh the page, scan, or track the game.
Sending hundreds of expeditions from many planets every day? Now you do it with one big, comfortable FAB button, with an automatic jump to the next planet.
The "Expeditions" module — label depends on the page (Exped / Send).
How it works
The Expeditions button detects whether you are on the fleet page — if not, it takes you there. The next tap requires an expedition set-up in AGR. The fleet composition, target and mission type are decided by the AGR routine — OG-E merely presses the right native game button at the right moment. If the AGR expedition routine does not allow an expedition to be sent, the button reacts accordingly.
The button moves on to the next planet with a free slot by itself, until the limits are exhausted. It skips the ones it has already sent an expedition from, and jumps to the next one if the fleet is not sufficient.
You can long-press the button to explicitly skip the active planet and jump to the next one.
In practice the whole round is a rhythm of two taps per expedition: the first opens the fleet page of the right planet, the second sends. 30 taps = 15 expeditions sent — and all that without aiming at tiny native buttons.
Why it exists
Without it, sending expeditions from a dozen-odd planets is dozens of precise clicks on a tiny native button. Here you do the whole round with your thumb, without even remembering which planets you have already covered.
More details
Auto next planet — automatically open the next planet after a dispatch (you can turn this off in settings).
Max/planet — cap on simultaneous expeditions per planet (1 or 2).
Fair play
OG-E sends the game no requests: it clicks the AGR routine and the native "send" button — the same elements you would press yourself. The dispatch is done by the game, after your tap. The composition and target of the expedition are set by AGR, not OG-E.
The automatic jump to the next planet only hints to the game which page to show after a dispatch — it generates no traffic of its own to the server.
One button points to the next-best free slot on the whole server and sends a colony ship — a second helps you abandon colonies that came out too small.
The "Colonisation" module with an "N free" counter — how many chosen positions are still open.The "Colonisation" module with an "N" second counter, ticking down the gap between sending consecutive colony ships.The "Abandon colony" module when in a few seconds you need to refresh the page to check whether the new colony is large.The "Abandon colony" module when the colony ship has landed and the page needs a refresh.The "Abandon colony" module makes giving up a too-small new colony easy.The "Abandon colony" module when you want to confirm giving up the colony for good.The "Colonisation" module — settings for which planets to colonise and when to abandon them.
How it works
The Colonisation module points by itself to the next-best free slot in the whole universe (according to your preferences for positions and galaxies) and sends a colony ship there. It detects when a position is already taken and lets you set the next coordinates. Its "N free" counter shows live how many of your chosen positions are still open. Thanks to the minimum-gap counter between landing times, you can send dozens of missions one after another while keeping the time you need to abandon a colony that turns out too small.
The rhythm is simple: two taps is one colonisation mission sent — 40 taps = 20 missions flying one after another. Three taps are enough to abandon a colony that turned out too small.
The button is paired with an Abandon colony button. It detects colonisation missions about to land and offers to move to the new colony. It checks its size and runs the process of abandoning it if it is too small. That way the next colonisation mission can land just seconds later. Once abandoned, a slot only returns to the colonisation candidates after at least 24h (overnight, per the game rules).
Why it exists
Finding a big colony takes many colonisation attempts (hundreds, even). That means combing the galaxy for free slots — and that data is available from a free API. To send a whole wave of missions you must watch the gaps between landings and abandon the misses as fast as possible. This pair of buttons does that for you and runs the whole cycle, keeping it comfortable. You just tap.
More details
Free spots come from OGame's public API (the server's map of occupied planets) — candidate data, confirmed against the live galaxy view before a colony ship flies.
The button watches the minimum gap between landings — if the next one would fall too close, it shows "Wait Ns".
The landing countdown runs on server time and offers a refresh itself once the new colony is there.
Target positions, foreign-galaxy preference, minimum landing gap, "too small a colony" threshold (per-universe config in the Dashboard).
Password for abandoning colonies (required by the Abandon module).
Fair play
OG-E sends the game no requests — it clicks the native send and abandon elements, exactly the ones you would press yourself.
The free-spot data comes from a public, statistical API (the same one community tools use) — that is, the server occupancy map. We combine it with our own data about abandonments and refresh it once a week.
One button that knows where the nearest undiscovered system is and lets you discover it with a single tap, so you can easily gather lifeform artifacts.
The "Lifeforms" button in the galaxy view — ready to discover the current system.The signal for 8 discovery missions sent.
How it works
The Lifeforms button walks you through discovering systems: it points to the nearest undiscovered system, moves the view there and lets you discover it with a single tap. It skips recently discovered systems so you do not waste an action — and comes back to them once they are available again.
On top of that, when you visit the lifeform research page, it reads how many artifacts you currently have, and if you have not been there in a while it suggests going there. All to remind you that you already have 3600 of them or more.
Why it exists
By hand it is a tedious sweep of the galaxy looking for what is still undiscovered — the button takes that navigation off your hands and keeps you from clicking systems you have already discovered. It is also convenient on mobile.
Fair play
OG-E does not initiate a discovery itself — it clicks the native "discover system" button, only when you tap it, and the game sends the fleet, exactly as with your own manual click.
The artifact counter is read only from what the game already displays, during your natural visit to the research page — with no background queries.
A daily send-off of the same ships on the same routes from one button: it sends fixed ships to the same targets and pulls everything back to one chosen body.
The Daily Run button with two zones: top "deploy", bottom "collect".Route configuration in the OG-E Dashboard.
How it works
The Daily Run button runs your daily fleet moves. You define a route once (from where, to where, with which fleet and which mission), and then the button walks you through sending the defined routes. The top zone dispatches the defined missions to all targets defined for the active planet that is the starting point — you can pick multiple targets from one planet, different missions, multiple ships, and multiple routes.
The bottom zone sends everything to the chosen planet and moves on to the next one (Collect); if you long-press it, you change the target to the active planet. It sends ships and resources according to the options chosen in the Dashboard.
Targets a fleet is already flying to are skipped, so you will not accidentally send to the same place twice.
The button also lets you farm inactive players.
Why it exists
The daily routine is a tedious ritual: picking ships, missions, targets, and collecting the daily income by going through every body while keeping track of what is already done. Daily Run walks you through the whole round step by step, and you just tap one button. Great on mobile.
Fair play
This is player guidance, not a bot: OG-E does not send the fleet itself — it presses the native dispatch button, and the game performs the dispatch, after your tap.
The button reads from the list of flights you sent yourself — not from any background tracking.
An in-tab button reminding you that your fleet-save is back and sitting exposed, so you send it out again right away.
The "Fleet Reminder" button in the Fleet1 panel — the fleet is waiting to be re-dispatched.The "Fleet Reminder" orb lit up next to another active button — a signal that the fleet is still waiting.
How it works
When your fleet-save returns and is available on the planet, a prominent, new button appears reminding you about your fleet. You can turn it on manually from the Fleet1 panel, or it turns itself on when the FS lands.
You turn it off by re-sending the fleet with this button — it then uses your AGR fleet-save configuration — or manually: from the Fleet1 panel, or by long-pressing the button. Tapping it takes you to the right planet and lets you send the fleet out again immediately; after a longer idle spell the button starts pulsing to catch your eye.
It only works on the tab you are on — if you are on another tab, you will not be notified there. It plays no sounds.
Why it exists
A returned fleet sitting idle is easy prey, and it is easy to forget even while you are online, just busy doing something else. This button makes sure you send the FS before you go offline — so it does not slip by.
Fair play
It works only while the tab is open and does nothing in the background: when the tab is hidden it does not even pulse. It knows about the returned fleet from the event list the game displays anyway — not from any server tracking.
This is the in-tab layer; the optional push notification while you are offline is a separate feature, described honestly alongside the alarm clock.
The Spyglass orb on the FAB walks you through the galaxy and suggests who to look at and who to send a probe to.
mockup / screenshot: button
The Spyglass orb on the OG-E button — it suggests the next look at the galaxy or a probe to send.
How it works
Spyglass is one of the orbs on the OG-E button. It invents nothing on the spot — it works exactly according to the settings in the Spyglass tab in the Dashboard: that is where you keep the list of watched players, the re-scan deadlines, and whether you care about planets, moons, or both.
In game the button reduces that to a single tap: it helps you watch the galaxy (offering the next system worth a look) and send spy probes where the data has gone stale. The next tap leads to the next target on the list.
Why it exists
Without it, intelligence means clicking through the galaxy by hand and remembering who you looked at and when. The button turns that into a rhythm of taps, and makes the whole "what next" decision from the settings you defined once.
More details
Each intelligence feature — the threat ranking, the dossier, the routine, the map, the patrol — has its own description in the "Spyglass — intelligence" chapter.
You turn the orb on and off like any other: with a tile on the button bar in the OG-E Settings.
Fair play
The button sends the game no requests — it clicks the native galaxy-view elements and the native probe dispatch, exactly the ones you would press yourself. You set the pace: there is no loop running in the background or without your tap.
Everything the button knows comes from the screens you opened yourself and from the settings you saved in the Dashboard.
Game interface6 features
What you see directly in the game and switch on from the AGR settings panel: interface readability, fleet-status planet markers, the event and trader menu pulses, and the attack banner. Nothing that touches ads, premium menus or the game footer.
Every OG-E toggle lives as one tab inside AGR's existing options menu — one place, with no separate panel to hunt for.
The OG-E tab in AGR's options menu: the Dashboard button, the FAB button bar, and the Expeditions/Display groups.
How it works
OG-E attaches itself to the AntiGameReborn (AGR) options menu instead of putting up its own floating panel — the same menu that is already added to the game gets one extra tab. At its top sits an "Open Dashboard" button (leading to the full-page OG-E panel), below it the FAB button bar — tiles turn individual orbit buttons on and off (Expeditions, Colonisation, Discovery, Daily Run) — and a button-size slider.
Below that sit the configuration options for the Expeditions button and the Display group — interface changes inside the game itself. Every tile has a one-word caption and a longer description on hover; all of them are described further on.
Why it exists
Two separate settings panels are two places to remember. By sticking to the one menu AGR users look for anyway, OG-E adds no second mental model of "where do I turn this on" — all the more so since OG-E requires AGR to work properly regardless.
More details
Requires AGR to be installed — without it there is nowhere to inject the tab (settings can be edited by hand in localStorage, but that is not a supported path).
Fair play
This is purely a configuration panel — every toggle saves a value locally and sends nothing to the game or outward. Changing a setting is not an in-game action.
The AGR integration only appends a tab to the menu's already-existing DOM (#ago_menu_content) — nothing in AGR's interface is hidden or swapped.
Trims the wordy labels in the top game bar and gives you big galaxy navigation buttons — so what really matters on a small screen is bigger and easier to hit.
Before: the fleet-event box with full labels — the content drowns in captions.After: labels collapsed, countdown and slot status at full size.Galaxy view: big buttons for jumping a galaxy or a system, plus Start / Phalanx / Spy / Discovery.
How it works
The fleet-event box shows three pieces of information by default (mission count, next mission type + target, countdown), but wraps them in labels ("Missions:", "Next:", "Type:") that take more room than the content itself. Readability collapses those labels to zero and puts the countdown on the right at full size, with the rest in a left-hand column with a reserved gutter, so a long mission name never slides under the timer.
The same treatment reaches the fleet-movement link in the fleetdispatch header: the green colour lands only on the link itself (not its children), so the native red 'expedition limit reached' indicator inside it keeps working as intended.
The same switch also reveals big navigation buttons in the galaxy view: jump one galaxy or one system left/right, "Start", and Phalanx / Spy / Discovery as comfortable thumb targets. Moving system by system — for example when phalanxing a whole region — becomes calm tapping instead of aiming a cursor at arrows a dozen pixels wide. It works exactly the same on desktop.
Why it exists
On a phone, the native AGR/OGame layout squeezes the same information into space designed for desktop — labels eat the room the numbers should have. Readability gives that space back to the numbers, so the countdown to your next mission and your slot status are readable without squinting.
More details
Covers the fleet-event box (#eventboxFilled) and the fleet-movement link in the fleetdispatch header.
The same switch also reveals the galaxy navigation panel (see "Navigation buttons" in the "Other" chapter).
Toggled in the OG-E Settings panel, the "Readability" tile.
Fair play
This is purely CSS on already-displayed elements — no number or label is swapped for a different value, only restyled. The theme colours stay the game's own; only layout and size change.
On by default, but one switch in Settings turns everything off at once — with no flash of unstyled content at page start.
Tiny status dots next to every planet and moon in the right-hand bar — at a glance you see where an expedition is flying, where a fleet-save sits, and where an attack is inbound.
The marker legend under the "?" icon above the planet list.
How it works
Each body in the planet bar gets up to three small markers, one per category, ranked by importance: an inbound attack (red "!!!"), your own aggression in flight, a fleet-save in flight or a fleet-save that has already landed ("FR" — a fleet reminder), an expedition, logistics (transport / deployment / ACS defend), and recycling. Markers are dots with no count and no direction — a "something is happening here" signal that does not spoil your nice planet skins.
Everything is computed from what the game already displays on the event list — no extra request goes to the server. A "?" icon above the planet list shows the legend on hover/tap.
Why it exists
Without markers, the only way to know what is happening on which planet is to open the event list and spend time analysing it. Markers move that state to where you are already looking — the planet bar — so a glance replaces a separate check.
More details
Toggled in the OG-E Settings panel, the "Planet markers" tile.
Fair play
Purely cosmetic styling of DOM the game already renders — the source is the game's own event list (#eventContent) and planet bar (#planetList), both already in front of you. Zero requests of its own, zero background polling.
Highlights temporary event entries in the left menu that look identical to the permanent Trader/Officers/Shop items and are easy to miss.
mockup / screenshot: menu
An animated temporary-event entry in the left menu.
How it works
From time to time the game inserts temporary entries into the left bar (reward windows, contests, seasonal items) under the same class the permanent, always-present Trader/Officers/Shop entries use. Looking identical, they get lost in the background — Event pulse animates ONLY those temporary entries, so they stand out from their permanent neighbours.
The pulse clears itself once we detect that every daily task on the Rewarding page is already done — no need to dismiss it by hand for it to stop reminding you of something you have already finished.
Why it exists
Temporary events are easy to miss in the daily rush — they look exactly like the menu you ignore anyway. Event pulse makes them stand out so you never skip a day on which an event is already available — that way you always collect every reward you can.
More details
Toggled in the OG-E Settings panel, the "Event pulse" tile.
Fair play
This is purely a visual highlight of an already-existing menu element — strictly additive (AGENTS.md §1.7), hiding or obscuring nothing: Trader, Officers and Shop look exactly as they always do.
The "done for today" state is read from what the Rewarding page already shows after you open it yourself — nothing is polled in the background.
Two independent coloured highlights on the Trader menu — yellow reminds you about the auction, red about the daily import/export — and they clear only once you really do them.
The red pulse on the Trader entry in the left menu — Import/Export is still waiting.
How it works
The two daily Trader chores get lost in the background, because the menu entry looks the same whether or not something is waiting. Trader pulse adds two independent coloured glows on the menu button and on the Trader-overview tiles: yellow for the Auctioneer and red for Import/Export.
Neither pulse clears just because you opened the menu. It clears only after your actual action: a successful bid (for about 30 minutes) or taking the container.
Why it exists
Daily Trader micro-chores are easy to forget, and the menu does not say anything is waiting. Two separate colours tell you at once WHICH of the two chores is still open — no need to click in just to find out.
The point is that you do not forget about the Import/Export items — they can be available more than once a day — nor about bidding against other players.
More details
Import/Export has two modes switched with chips on the Trader page: remind once a day, or 6 times a day (while such an event is running).
The Auctioneer glows during typical auction hours (~06:00–23:00), not around the clock.
Toggled in the OG-E Settings panel, the "Trader pulse" tile.
Fair play
This is only a glow on an already-existing menu and its tiles — strictly additive (AGENTS.md §1.7). The Trader, Auctioneer and Import/Export pages look and behave exactly as always, with nothing swapped or covered.
The state is computed from what the Trader pages already show once you open them yourself, plus one locally-stored reminder-MODE choice — zero background polling, zero automatic bidding or purchase.
A loud, full-screen banner in the open game tab the instant OGame itself flags an inbound fleet — so you never miss what the top bar already shows.
The attack-banner preview triggered by the "Preview" button in Settings.
How it works
When the game marks an inbound hostile fleet in its own top bar, the banner turns that into something impossible to miss on a small phone screen — inside the SAME open tab. It is only a louder rendering of information the game already displays, nothing more.
Off by default. Settings has a "Preview" button that shows the banner for 10 seconds before you decide to turn it on.
Why it exists
On a phone it's easy to miss a small flag in the corner of the bar, especially mid-task elsewhere in the game. The attack banner gives that same information a size you cannot miss — as long as you happen to be looking at the open tab.
More details
Off by default — deliberately opt-in, with a preview before you enable it.
Toggled in the OG-E Settings panel, Display section.
Fair play
This is only a different rendering of data the game already shows in its bar — not a separate source of attack information and not a way around anything.
Zero off-tab signal: it never touches the tab title or favicon, plays no sound, and sends no system notification or push of any kind. A player who is not looking at the open game tab learns nothing — the banner exists only inside that tab, at the moment you would have seen it anyway.
OG-E Dashboard6 features
OG-E's own panel: best colony spots, the fleet-return alarm clock, daily routes, statistics and cross-device sync — all built from data collected during normal play. The Spyglass tab lives here too, with its own chapter below.
The Colonizations tab in the Dashboard: a histogram of the field sizes of the colonies you have found, and the configuration the FAB's Colonisation button needs.
The Big Colony Hunting tab: the field-size histogram and, below it, the colonisation settings — positions, landing gap, abandon threshold, password.
How it works
The "Planet sizes" histogram counts the sizes (field counts) of the planets you have colonised — so you can see at once whether your colonies so far are large, or whether it is worth hunting further.
Next to the histogram sits the settings editor the Colonisation button on the FAB reads from: target positions (a list or range, e.g. "8,10-12,15"), whether to prefer neighbouring galaxies, whether to aim for the farthest or the nearest free system within your home galaxy, the minimum gap between colony-ship landings, and the size threshold plus password for abandoning colonies that turn out too small. The password is there to auto-fill the field the game requires when you abandon a colony that is too small.
Why it exists
The histogram answers the question "are my colonies large at all". The settings next to it keep everything the Colonisation button has to know in one place.
Together with the FAB button, this is what makes hunting for big colonies possible. And hunting is far easier when you know how far you are from your dream planet size.
More details
Saving is automatic (debounced autosave) — there is no "Save" button.
These same settings (except the password) travel through opt-in cross-device sync — see the "Cross-device sync" chapter.
Fair play
This is purely a data view and a configuration form — the histogram counts from your own, already-saved observations, and the settings are plain values read later by the FAB module. Nothing here sends or saves anything to the game.
The abandon password is stored locally and used only to fill the native colony give-up confirmation form — the same one you would fill by hand.
A Dashboard analysis that scores the players in a galaxy and tells you where to settle in line with your strategy (safe, farm, pvp).
The analysis settings (profile, slots, ranges) and the server map in Occupancy mode.Details of a proposed spot: the system window, population, threats, and the most dangerous neighbours.
How it works
Best Colony Spots computes four independent channels for every neighbourhood: safety (the less hostile-fleet reach, the better), farm (how much inactive loot sits within reach), room (how many free slots remain in the window), and target (active-player density — PvP opportunity). You pick one of three ready-made profiles — Safe zone, Farm hub, PvP zone — each simply a different weighting of the same four numbers, so the result stays comparable across profiles and universes.
Two list modes answer two different questions. Best spots scores the area around every system where AT LEAST ONE selected slot is free — a quick "where is anything open". Longest streaks hunts contiguous runs where EVERY selected slot is empty — for several colonies close together. The data is fetched from the public OGame API and refreshed once a week.
Why it exists
Browsing galaxies by hand for a good neighbourhood means hours of scrolling and guessing "is it safe here". Best Colony Spots turns that into one sorted list led by your own criterion — and because it scores from the same data behind the server heat map, the ranking and the map colours always say the same thing.
More details
The three profiles — Safe zone / Farm hub / PvP zone — are ready-made weights; you do not have to tune any slider by hand to get a sensible ranking.
You say which slots interest you, and the algorithm looks for free positions among them.
The map has two modes: Threat / farm sums and averages to build the temperature of an area, while Occupancy shows each position separately — a player, a farm, or empty space.
Fair play
This is purely an analysis of data we get from a publicly available API (the same source community tools use).
The output is purely informational — a list and a heat map, with no send button. You decide where to colonise; sending the colony ship itself happens in the Colonisation FAB module through the game's own native form.
A reminder you set yourself for a fleet return — it rings on your phone at the time your own send-off determines.
mockup / screenshot: badge
The clickable alarm badge in a row's arrival-time cell on the event list.
mockup / screenshot: wave
A wave of returning expeditions controlled as a single series.
How it works
On the game's event list every fleet row gets a small, clickable badge in its arrival-time cell. You tap it to arm a reminder relative to that flight (e.g. the moment a fleet-save returns), and a second tap removes it. Waves of returning expeditions are detected and controlled as a whole — one badge for the whole series.
The push is queued on ntfy.sh (a notification service you configure yourself with a token in Settings) with a delivery time computed from your send-off. ntfy holds and delivers the message at the appointed hour — after you set the reminder OG-E keeps no watch.
Why it exists
A fleet return or the end of a fleet-save often lands in the middle of the night or the middle of a workday. Instead of doing the math in your head and coming back over and over, you set one reminder and your phone speaks up exactly when the fleet lands.
More details
A fleet-save is detected and scheduled automatically; a slot can only be cancelled inside its cancel window just before delivery.
Configuration and tokens live in the OG-E Settings panel; without an ntfy token the alarm sends nothing outward.
Fair play
Honestly: this is a borderline feature. We treat it with care and say so openly — below is why we still consider it defensible.
We say it plainly: this is our one knowingly borderline feature. That is why we keep it on the safe side and constrain it harder than the rules require.
It is a player-set reminder for one specific send-off — not an automaton reacting to in-game events. The ring time follows from your own action (your send-off), not from monitoring the server.
It is presence-gated: only ever armed while you are present in the game. OG-E does not watch the game on your behalf while you are away — no page reload, no reading the event list for hostile fleets, no audio, no blinking tab title, no system notifications.
OG-E reads the arrival time passively from the event list the game already renders — with no traffic to the game server. The push itself travels through ntfy.sh, a service you configured, off the game's channel.
A Dashboard editor for daily micro-fleet routes — define once where from, where to and with what, and Daily Run walks you through them in-game.
mockup / screenshot: editor
The routes editor in the Dashboard: sources, target list, fleet and mission.
mockup / screenshot: stale
A target flagged as "stale", removable in one click.
How it works
In the Dashboard you build transport routes per universe. A route is one or more source bodies (planets and/or moons) sharing one ordered target list, one fleet (ship + count) and a mission. A route can be paused with a toggle without deleting it.
Own-body sources and targets are picked from the list of your planets and moons (captured in-game), so a coordinate can never be mistyped; external targets are typed by hand. The same per-universe keys are consumed in-game by Daily Run, which then walks you along the route.
Why it exists
A daily fleet-save across many bodies is a tedious round. Defining the routes once in a readable editor turns the daily ritual into clicking through a ready-made plan instead of retyping coordinates from scratch every day.
More details
Own-body endpoints missing from the captured inventory are flagged "stale" and removable in one click; external targets never go stale.
Saving is debounced and flushed on universe switch and tab close, so your last edit is never lost.
Fair play
It is a pure configuration editor — it saves your routes to the extension's local storage. It does not contact the game server, sends nothing, and schedules no background send-off.
Own-body targets come from the list of your planets the game already shows. The actual send-off happens later, in the Daily Run feature, and always through a native click after your tap.
Your collected data (galaxy scans, colony history) travels between your computer and phone through your own private GitHub gist.
mockup / screenshot: settings
The GitHub token field in OG-E Settings — sync is opt-in.
mockup / screenshot: merge
Two devices see the same current data picture after merging.
How it works
In Settings you connect your own GitHub token (a classic PAT with the single gist permission), and OG-E keeps your locally-collected data in a private gist that belongs to you. Every device pushes and pulls through api.github.com — nowhere else.
Merging the two sides is additive and local-first: on a pull, remote entries are added to local (the newer scan wins), nothing is wholesale overwritten. Uploads are debounced by a 15-second window, so a burst of scans while scrolling the galaxy coalesces into one upload instead of a dozen.
Why it exists
You play on several devices, and the knowledge gathered by normal play — scan classifications, colony observations — drifts apart between them. Sync means every device sees the same merged, current picture after boot, with no manual transfer.
More details
Secrets (the GitHub token, the ntfy token) never enter the synced file or an export.
On GitHub rate-limit errors (403/429) the module backs off and does not hammer the API pointlessly — it stays inside GitHub's 5000 req/h budget.
Fair play
Sync never contacts the game server. All traffic goes to a service you control (your GitHub gist), off the game's channel. That is OG-E's position in the terms of service: we only read game pages rendered in your own browser, and your data syncs through a separate channel.
It is entirely opt-in: with no token pasted by you, nothing leaves your machine. The token holds the smallest possible permission (gist) and lives locally. Only your own data, gathered by playing, is synced — there is no background game tracking.
Save the selected universe's whole dataset to a JSON file, load it back by merging, and dump the colony history to CSV.
mockup / screenshot: buttons
The Export / Import / CSV buttons in the OG-E Dashboard.
mockup / screenshot: summary
The import summary: how many entries were added in each dataset after merging.
How it works
From the Dashboard you export the selected universe's data to a single JSON file and import it back. Import does not overwrite wholesale — each dataset is merged with the same reconciler as gist sync: additive, local-first. An Export → Import round-trip behaves exactly like a gist download.
Separately you dump the colony history to CSV to open it in a spreadsheet. Everything goes through local files (Blob) — the module never touches the network.
Why it exists
A backup, a transfer of your data to a new device without configuring a gist, or working the colony history in a spreadsheet — with no cloud and no account. You hold the file, you decide where it goes.
More details
The watch-list import rides its own LWW+tombstone merge: an un-star in a newer file propagates, exactly like sync.
The file carries only extension-storage data; per-universe settings stored in the game's localStorage remain gist-sync-only.
Fair play
Import/export is local only: no fetch, no contact with the game server or any other. Downloads go through a Blob, and loading reads the file you point at yourself.
The file is safe to hand over: secrets (the GitHub token, the ntfy token) and sync bookkeeping never enter it. It is your own data, gathered by normal play, packed into one file.
Spyglass — intelligence9 features
A large intelligence module: peek and spy, opponent dossiers, a threat model, enemy-routine analysis with offline windows, and a "who is spying on you" panel. All built from data you gathered by playing normally.
Full intelligence on the players of your server: who is dangerous, who is worth hitting, where the loot sits and when the owner is away from the keyboard.
The Spyglass tab: watch list, scan settings, the "who is spying on you" panel and the player ranking.
How it works
Spyglass has two sources of knowledge and one backbone. The galaxy channel (galaxy) is an ordinary visit to a system — free, invisible to the target, and it yields activity markers plus moon information. The probe channel (probes) is a normal spy report — it costs probes and the target sees it, but it shows fleet, defence and resources. The backbone is the watch list (Watchlist): whoever you put there is what the in-game button works on, and that is the player whose dossier grows.
The feature lives in two places. The floating button in the game proposes one next intelligence action. The Spyglass tab in the OG-E dashboard is a reading room: server ranking, dossiers, map and the "who is spying on you" panel — without a single send button. The danger ranking works from the very first run, off the public server statistics; scanning only deepens it.
Why it exists
Intelligence in OGame is normally manual labour: a hundred reports in your inbox, a notepad of coordinates, and memory of who was dangerous half a year ago. Spyglass turns that into six questions with ready answers — and that is all you need to know to use it. The rest of this chapter is detail for the curious, not a manual.
More details
Who to avoid and who can be touched? — the danger ranking (Danger).
What to look at next? — the Look / Spy / Strike button.
Is he worth hitting and where is the loot? — the player dossier.
When is he away? — routine and offline windows.
Who can reach me? — the position map and range.
Who is sniffing around me? — the "who is spying on you" panel.
Fair play
Everything Spyglass knows comes from three places: the public server statistics files (the same ones community tools use), game pages you opened yourself (reports, the galaxy view, alliance highscore) and what you sent yourself. There is no background scanning: with no game tab open OG-E does nothing, and the statistics files have a freshness deadline rather than being polled on a cycle.
The Spyglass tab is a reading room with no trigger — there is no sending in it at all. A probe can only be launched from the game, by a deliberate tap on a single body, through the native two-step fleet dispatch form. There is no "scan everything" button and no action that covers multiple targets.
The whole server in one table, sorted from the most dangerous down: a 0–100 number and a one-word archetype tell you who not to poke and who you can hit.
The player ranking sorted by the Danger column — the archetype next to the number, then the fleet ceiling, military points and hull class.The score breakdown inside the dossier: where the number came from and which signals raised it.
How it works
The Players table is the entire server ordered by the Danger column. That number does not measure "how many points someone has" but how many of those points can fly at you: military points include defence, and defence does not attack — so OG-E splits them into a mobile and an immobile part, judges hull quality (the cost of a single ship) and compares the result against the whole server. On top of that it adds predator signals: destruction percentage, bandit tier, colony spread (how much of the server he actually reaches) and alliance class.
Next to the number stands an archetype — one word instead of a table: Apex hunter, Bandit raider, Fleeter, Cargo swarm, Fortress, Turtle, Economist, Declawed bandit, Friendly. The Fleet column shows ≤, because it is a ceiling, not a measurement — only a complete set of your own reports brings it down to an exact number and the ≤ sign disappears.
Why it exists
The highscore lies in both directions: a turtle with a mountain of defence points looks scarier than a fleeter who would actually wipe you out, and a vault with no fleet looks like a predator. One column separates those cases, so picking a target and judging risk is a glance rather than an investigation — and you have it for the whole server before sending your first probe.
More details
Zero ships is always Danger 0; your own alliance and buddies are 0 as well. Anyone with something to fly has at least 8.
The cost of a single hull splits the fleet into classes: below ~20k resources — civilian (cargos, probes), 20–100k — combat, above that — capitals, or defence? if your scans have not confirmed it yet.
Aggressor bonuses (bandit, range, warrior class) do not stack without limit — they fill up the headroom to 100. That way a peaceful giant never becomes an "apex".
Apex hunter requires at least two of six signals, including at least one aggressive one (destruction, range, colony placement) — fleet size alone is not enough.
Filters: hide inactive, watch list only, a military-points range, top 50 / 100 / 200 / all. Searching by name also finds filtered-out players and shows why they were hidden.
Fair play
The whole table is arithmetic over the public server statistics files — the same ones community tools use. Nothing here is stolen: these are numbers everyone sees in the highscore, only arranged into an answer to "who is dangerous". The files have a freshness deadline and are read while you happen to be visiting the game, not on a cycle.
The table sends nothing and contains no in-game action — the + watch star only adds a player to your own note. Data from alliance mates (if you enable sharing) is view-only: by design it feeds neither the Danger number nor the scan plan.
The Spyglass button in the game offers one next intelligence action: a free look, a probe or a moon opportunity — always exactly that one.
The "Look" face: a free visit to system [galaxy:system], one visit refreshing two watched bodies.The "Spy" face once armed: you see who you are flying at — a second tap sends the probe.Scan settings: probe count, planets/moons, launch point, refresh deadlines, moon-hunting mode.
How it works
The button shows one proposal at a time, picked from the scan plan for the players you watch. Look is a visit to a system in the galaxy view — free and undetectable; the label carries the target [galaxy:system] and ×N, i.e. how many watched bodies that single visit refreshes. Spy is a probe on one body: the first tap arms it and shows who you are flying at, the second sends. Strike lights up when the looks alone suggest a fleet may be parked on a moon. N left tells you how many bodies in the plan are still waiting.
The plan order is danger × staleness × good moment: never-scanned and overdue bodies first, and if the local hour falls inside an observed activity window of the target, the proposal is promoted. You set the deadlines yourself (Re-scan, Re-look), and likewise the number of probes per scan, whether to scan planets, moons or both, and whether probes launch from the nearest planet or from the one you are standing on.
Why it exists
Running intelligence by hand is bookkeeping: who was scanned, what went stale, where a look is enough instead of burning probes, which planet you skipped. The button keeps that ledger for you and leaves you one decision — tap or not. It works especially well on a phone, where clicking through the galaxy is the most tedious.
More details
galaxy and probes on a watched player's card are two independent channels — you can run a player on looks only, in which case the target sees absolutely nothing.
Looks are always recorded for watched players while you browse the galaxy; the toggles only mute the *proposals*, not the recording.
Moon strike: off, lone (only the moon glows, the rest reads as quiet), newest (the freshest interaction on the account is on the moon), any. Before a strike the button asks you to complete the picture of the whole account first.
↻ on a card marks all of a player's bodies as "due for a re-scan"; never means "never spied on".
Bodies sent this session drop out of the plan, and bodies still within their deadline never enter it — you cannot accidentally double a probe.
A configured patrol radius adds the neighbourhood of your colonies to the look plan (see "Patrol").
Fair play
One tap is one action. OG-E does not send a probe by itself: it fills in the native, two-step fleet dispatch form and presses the game's own button — the one you would press by hand — and only for one body. There is no "scan everything" and no multi-target action. Look is simply a move into a system in the galaxy view, exactly what a player does with the arrows.
The scan plan is a queue of proposals, not a queue of jobs: there are no timers, no background sends, nothing starts without your tap, and with no game tab open the button does not exist at all. All the knowledge the ordering rests on is your own reports and your own browsing of the galaxy.
The expanded row of a player: a one-sentence verdict, the danger-score breakdown and a table of all his bodies with scan age, defence, fleet and loot history.
The full dossier: verdict, danger breakdown and the player's rhythm on the left, the table of all his bodies on the right.The body table: scan age, last interaction, defence, visible fleet and average plus peak loot — moons under their planets.
How it works
The left column is judgement. A header like loaded · heavily defended · loot ~16.27B · scan 25h old sums up the situation, and one sentence below it says what to do about it. Then comes the danger-score breakdown and the most interesting arithmetic: public military points minus the defence and fleet your reports have seen leaves a remainder nobody can see — that is the fleet in the air, usually on a fleet-save. Until you have the complete set of bodies, that number is marked as provisional.
The right column is evidence: one row per body (moons indented under their planet) with the age of your scan, the last interaction, defence, visible fleet, and the average and peak loot you have ever found there. A star marks the body with the largest visible fleet, a vault marker the home planet. Chips in the header say how many planets and moons you already have scanned and what is missing for a complete picture.
Why it exists
This is where you make the call: hit or pass, and if hit, which body. Instead of clicking through twenty reports from different weeks and doing the maths in your head, you get one table with history — you see not only what sits there today but also what *usually* sits there and where this player really keeps his wealth.
More details
Loot is the single best planet from the freshest report, run through the plunder percentage — never the sum of a whole empire, because a single raid takes from one body anyway.
The verdicts it can reach: RAID NOW, loaded · fleet risk, loaded · heavily defended, skip — empty, scan first, can't hit, friendly.
Civil baseline compares the player against the server median of "how many ships a builder with this economy has"; the surplus is a combat-fleet ceiling. It deliberately does not feed the danger score — it is a separate, more cautious hint.
A complete set of scans (planets and moons) turns the fleet estimate into an exact number and drops the ≤ sign in the ranking.
The Watch via galaxy | probes toggle and the per-body toggle let you cut out of the scan plan whatever you do not want to touch with probes.
Fair play
Every hard number — defence, fleet, resources, loot — comes exclusively from spy reports you opened yourself. The dossier does not acquire them: it remembers and organises them so you do not have to keep a notepad. The rest is arithmetic over public points and over your own browsing of the galaxy.
The dossier is a reading room: it holds no send button. The only thing you can "fire" from it is marking a body as due for a refresh — the probe itself you send deliberately, from the game.
From activity markers you see anyway, Spyglass reconstructs an opponent's day and weeks: when he is usually at the game, and when he is reliably away.
Routine and presence: the player's day with its activity peak, the coverage verdict and the week grid with offline windows.
How it works
The galaxy view and a spy report show one thing: how long ago something happened on that body. OG-E converts that age into a point in time and, after a few dozen such points, draws the player's day and names his peak — for example evenings 19–23. Markers caused by your own probes are subtracted, and several looks at the same session count as one.
The second block looks for silence, not movement: a quiet look with good coverage is strong evidence of absence. An offline window is only declared once three consecutive hours have both enough looks and consistent silence — otherwise the page says plainly "look more often". The same data can be viewed as weeks, as a day, as day×hour or as a monthly cycle, and a separate detector checks whether the player rotates shifts.
Why it exists
This is the difference between "I know he has a fleet" and "I know when he is not watching it" — and that difference is exactly what decides whether a raid pays off. Instead of guessing from a single report you get the opponent's rhythm, and when the sample is too small, honest information that nothing follows from it yet.
More details
The peak of the day is the best five consecutive hours; its name (nights, mornings, afternoons, evenings) comes from its middle. Below three observations there is nothing, and on a small sample only a "hint" without a label.
An offline window requires at least three consecutive hours, each with real coverage and practically no traces of activity. A one-off blip in the middle does not invalidate the window, but it is listed separately.
The shift detector needs at least five weeks with a recognised phase — on a smaller sample it says plainly "too thin". Weekends are judged separately (some people are only at the game every other Saturday).
The analysis range switches between 30d, 90d, 6mo and All, and days can be narrowed to Mon–Fri so the weekend does not blur a work rhythm.
In the grid a lighter cell means "few looks", not "quiet" — coverage and result are kept apart so missing data never looks like a conclusion.
Fair play
This block is purely passive and purely computational: it counts only the markers the game itself drew on pages you opened anyway. Zero probes, zero extra requests, zero timers — nothing "watches" for you in the background, and without your browsing of the galaxy the history simply does not grow.
Markers caused by your own probes are subtracted, so you do not measure your own rhythm. The page also does not pretend to knowledge it lacks: "activity" is the last interaction with a body, not an "online" status — and it is labelled that way. As long as the sample is too small, OG-E refuses to state a conclusion instead of drawing a chart anyway.
History is kept as an hourly "present / quiet" mask per day — no coordinates, no report contents. That makes it mergeable across your own devices and (if you enable it) with alliance mates, and the merged material is view-only: it affects neither the danger score nor the scan plan.
Watches the systems you live in: it tells you who has just moved in next door, and which neighbour already keeps a fleet inside several of your systems at once.
Home watch
Moved in (1)NEW clears itself a day after you read it
NEW2:143:4WrenD 0.31seen 8m ago
KestrelNOVA×32:117·2:119·3:301
NEWWrenNOVA2:143
BoroKRAB2:117
Tanhil2:117
IlexKRAB6:104
Together — NOVA reaches ×4 of your systems, ×3 for its best member alone.
The real OG-E component, rendered over invented data (nicknames, tags and coordinates belong to nobody). Row edge colour = Danger, ×N = how many of your systems that player sits in, a lit tag = an alliance that reaches further together than any of its members alone.
mockup / screenshot: card
The Home watch card on the Spyglass tab — a fresh arrival, one row per neighbour, and the alliance-coalition line.
How it works
Every look you take at the galaxy is compared with the previous one — and if somebody new has appeared in a system where you keep a planet or a moon, you are told once. Your own systems join the Spy button's "Look" plan on their own cadence (24 h by default, 0 = off): a neighbour does not move, somebody has to colonise first, so checking hourly buys nothing.
The card lists actors, not addresses. One row per neighbour: colour = their Danger, ×N = how many of your systems they already sit in. That second number is the escalation it is easy to miss — an account with a fleet in three of your systems can run a moon destruction on its own, in three places, with no travel time to plan around. Listed separately: alliances whose members together reach further than any of them does alone. Two people with the same tag in one of your systems is not an escalation (the reach is the same as one of them); four of your systems covered between them is.
Why it exists
Your neighbourhood is the one thing the highscore never shows: a hunter one system from your moon has no travel time at all, and sees your bodies in the galaxy view every time they open it. Home watch turns that into one sentence at the right moment — "the fleet-save you have been flying for months is no longer safe" — instead of something you learn from a combat report.
More details
The Home field in the Spyglass settings is hours (0 = off). 24 h by default — separate from Re-look, which is about watched players.
The first look at a system produces no arrivals — it only seeds the baseline. Otherwise day one would report a dozen "new" neighbours and teach you to ignore the alert.
Departures are not reported: a neighbour who left is good news, and the galaxy view cannot tell "abandoned" from "I looked at the wrong moment".
The same player in another of your systems is fresh news (their ×N grows). A second planet in a system they already occupy is not — they were already inside.
The Spy button points you at the dashboard only once the sweep of all your own systems is complete, and only when there is something to read. One tap, and the nudge retires itself.
Fair play
The observation is your own visit to the galaxy view — nothing is initiated in the background, there is no timer and no polling. The whole feature is a comparison of what OG-E already recorded from your browsing: who was in the system then, who is there now. It holds no in-game action and never proposes an attack — this card answers a defensive question only.
Nothing watches for you: if you do not open the game, you are told nothing, and that is by design. There is no phone notification, no sound, and no reading of hostile fleets outside the game tab. The baseline (the memory of "who lived here") is device-local and is never uploaded or shared.
Your own alliance and your buddy list are excluded by definition — they are company, not exposure. The NEW flag clears itself a day after you read it; there is nothing to click and nothing to acknowledge.
Every body of every watched player plus your own on a single galaxy grid — with rings around those who can reach you in under eight hours.
The position map: galaxy rows, a dot per body, size growing with danger, your planets in white.Player chips under the map and the "who can reach you in ≤8 h" toggle — colour, hiding, entry to the dossier.
How it works
The grid is the server seen from above: rows are galaxies, systems run horizontally, and vertically within a row — the position inside a system. A dot is a body; it grows with the player's danger, and you assign the colour yourself so you can recognise your regulars. Your planets are white. Hovering (on touch, the first tap) gives the name, coordinates and estimated flight time to your nearest planet.
The who can reach you chip computes, for every foreign body, the shortest distance to any of your planets — with map wrap-around per the server rules — and converts it into flight time for the slowest possible attacker. So a ring means: this player reaches you within eight hours even with his heaviest, slowest fleet. The threshold is deliberately pessimistic, because a faster fleet arrives sooner.
Why it exists
"Who is dangerous" and "who is dangerous to me" are two different questions. A player at the far end of the server with a monstrous fleet is a theoretical problem; an average one three systems away is a practical problem. The map answers that with geometry you read in a second — useful for planning a fleet-save, for picking a target, and for deciding where to put your next colony.
More details
The map holds only your bodies and players from the watch list — not the whole server, so the drawing stays readable.
The eye next to a chip hides a player from the map without unwatching him; the cross ends the watch entirely.
The colour chip is the one place where you set a player's colour — the same one then shows up on his watch-list card.
On touch, the first tap describes the body, the second opens the owner's dossier.
Fair play
Body positions come from the public server map — the same file community tools use. The map is therefore complete from the first run and needs not a single scan. Flight times are arithmetic over the game's published rules.
The map sends nothing and pokes nobody — it is a drawing over data that is public anyway, plus your own coordinates from the game. There is no in-game action here, not even an indirect one.
A card on the Spy tab watching your grounds: what is catchable to strike right now, and whether your observation coverage is healthy.
mockup / screenshot: card
The Patrol card on the Spy tab with the strike list and coverage summary.
mockup / screenshot: watch
Promoting a neighbour onto the watch-list with a single "star" tap.
How it works
Patrol treats your colonies as a coverage lattice and looks at every system within ±a few systems of your bodies (same galaxy, honouring the map wrap). The card answers two questions: what is catchable right now in the grounds (the strike list — the same signals the Spy OG-E button flags) and whether coverage is healthy (how many systems have a fresh, stale, or no look).
A neighbour on the strike list is promoted onto the watch-list with one tap (patrol → star → snipe). The card only shows while a patrol radius is set — at zero there is no UI at all.
Why it exists
The watch-list is the sniper's tool — one player, worked over. Patrol is the territorial predator's: the prey is whoever nearby slips (a returning fleet-save on a forgetful neighbour's moon), not a name hunted for months. The card shows whether the grounds are actually being walked.
More details
The patrol radius (in systems) is one knob, set on the Spy tab; 0 = patrol off.
Noise filters strip out self, vacation/banned/admin, buddies, your own alliance, and noob-protected players.
Fair play
Everything stays passive and propose-only. Patrol looks are your own galaxy browsing (undetectable), and a strike is still one deliberate tap per probe — OG-E sends nothing itself, it initiates a native click in the game's galaxy view.
The card is computed from data OG-E already holds — your scans and the public API read while a game tab is open. The grounds are a finite set of systems, so recording is bounded by nature. The card sends nothing; it only shows intel and has no "send-all" control.
A table on the messages page showing who has recently probed your planets — the freshest and closest at the top.
mockup / screenshot: panel
The "Who is spying on you" panel at the top of the Spy tab, above the AGR overview.
mockup / screenshot: same-system
A row flagged as a threat from your own system — at the top of the list.
How it works
On the messages page OG-E gathers "hostile fleet near your planet" alerts into one table: one row per spy, with who, how long ago, how often and from where they poke you. The freshest and closest threats are at the top, and a spy with a fleet in your own system is flagged separately (they reach you the fastest).
Why it exists
OGame scatters "who probed you" across individual messages that are easy to miss. The table answers one defensive question — is someone interested in me, and how close are they? — before it turns into an attack.
Fair play
The panel is purely presentational: it shows alerts you opened yourself during normal play. It initiates no click in the game, sends no requests, and has no timer or notification outside the tab.
It is the same knowledge OGame already showed you — just gathered into one readable table instead of scattered across messages.
Other3 features
Small conveniences and cosmetics on top of the flagship features: galaxy navigation buttons, no white background flash, and other interface details. Nothing that touches ads, premium menus or the game footer.
Big, thumb-reachable arrows and galaxy/system inputs below the table — because the native header is about 16px tall on a phone.
mockup / screenshot: panel
The navigation panel below the system table: galaxy/system steppers and the Start / Phalanx / Spy / Discovery buttons.
How it works
The galaxy view is a desktop-first layout: switching galaxy/system, the arrows, and the Start / phalanx / spy / discovery buttons in the header render at roughly 16px tall on a phone — practically impossible to hit without zooming. The OG-E panel mirrors those same controls again, below the system table, with ~50px touch targets: galaxy and system steppers on the left/right, a "Start" button in the middle, and the rarer Phalanx/Spy/Discovery buttons tucked under a collapsible lid.
The panel re-implements nothing — it clicks the same native buttons and fields that live in the header. The galaxy/system step nudges the native arrows (wrap-around and deuterium cost stay the game's own rules), and "Start" fills the native inputs and clicks the native submit. If a button is disabled in the header (e.g. phalanx unavailable on this body), the panel shows the same.
Why it exists
Without this panel, browsing several systems on a phone means constant pinch-zooming to hit a microscopic arrow, then panning back to the table. The panel keeps navigation within thumb's reach, right where you're already looking.
More details
The same "Readability" switch in OG-E Settings (Display) turns this panel on and off.
A separate, always-on fix: arrow keys inside a phalanx/spy/discovery dialog sometimes lose focus and hop a system twice instead of once — the panel corrects this independently of everything else.
Fair play
The panel adds no action that wasn't already in the header — every button clicks the same native element you would press yourself. The request count to the game is identical to navigating by hand.
Button state (enabled/disabled) is copied from the header, not recomputed — so it can never show anything the native UI isn't already saying.
AntiGameReborn's otherwise-idle logo button gets the OG-E icon and opens the options menu together with the OG-E Settings tab in one click.
mockup / screenshot: logo
The OG-E icon in place of AGR's default logo, in the corner of the bar.
How it works
AGR has a logo button in the corner that does almost nothing by default when clicked. Instead of painting a second, separate button on the bar, OG-E takes over this one — swaps its image for the OG-E icon and wires the click to two things at once: opening AGR's options menu and auto-expanding the OG-E Settings tab inside it.
This is purely a cosmetic image swap plus one click listener — the rest of AGR's menu behaves exactly as it always has.
Why it exists
One click instead of two (open the menu, then find the OG-E tab) — and as a bonus you can tell at a glance the extension is active, since the icon in the corner is no longer AGR's default logo.
Fair play
This is purely an image swap and a shortcut into an already-existing menu — it adds no new function or request to the game, just a faster path to settings that were already reachable through AGR.
If AGR doesn't load within 10 seconds, the module silently does nothing — the AGR logo stays unchanged, no error shown on screen.
Kills the white flash between one page reload and the next — painful on a dark theme, especially at night, especially on Firefox mobile.
mockup / screenshot: compare
A page reload with and without the injected black background.
How it works
OGame reloads the entire page on nearly every action — clicking a planet, switching tabs, dispatching a mission. The browser's default white paint between closing the old page and the new page's first render reads like a flash of light on a dark theme. OG-E injects a black background before the browser has a chance to paint anything, and removes it about 300ms after the page fully loads — once the game/AGR's real background has already taken over the screen.
Why it exists
Dozens of reloads a day mean dozens of white flashes if you play with a dark theme — tiring on the eyes, especially at night or on a phone. This fix is invisible when it works: the flash just isn't there any more.
Fair play
This is purely one temporary CSS style for the duration of the page reload — nothing is hidden for longer than the first full render, and the game content underneath is not changed in any way.
Zero logic beyond that — no dependencies, no requests, no state to save.
