The AGENTS.md is not a rulebook for you, it's there so your AI coding agent behaves. The official rules are here on the forum, see pinned threads. Especially:
Read first: Do I need to submit my tool? (Submission Guidelines)
Is a client like this tolerable in principle?
No.
Hi, please review the pinned API thread: API Access Applications – Required Procedure (Updated)
I just installed the script. I opened my expedition message and the script said "nothing to send".
The script will only send expedition messages that happened after you installed the script.
Every few months the same argument goes around: expeditions got nerfed, DM finds dried up, the big resource hauls stopped showing up. And every time it's the same evidence — "feels like it", "I used to get more", someone's daily 200 expeditions collected across months with no record of which days had which boosters, which lifeform bonuses, or which game version was live.
That's the actual problem. It isn't only sample size — it's that nobody writes down the conditions. A 200-expo sample where the context is unknown can't tell you whether your results shifted because the game changed or because your ExpoComputer expired. You can't separate the two after the fact.
So: a userscript that records expedition results together with the conditions they happened under. Every result is stored alongside the buffs active at the time, your lifeform bonuses, class, universe speed, and game version. That's what makes comparison possible.
What it collects
Runs on the overview and messages pages:
A small status indicator in the messages tab bar shows what it's doing.
What happens with the data
To be clear about what this is right now: a backend that collects and aggregates. There's no dashboard, no login, nothing to look at yet. I run the analyses and post results.
What I'm building toward is tooling where analyses run automatically rather than me writing queries by hand. Once that exists, per-player analysis becomes cheap — which is the interesting part, because the most common version of this complaint isn't "expeditions are nerfed", it's "my expeditions are nerfed". With enough of your own trips recorded against known conditions, that becomes checkable: either your distribution really does sit off from comparable players on the same universe and class, or it doesn't and you've had a rough stretch.
A frontend might happen eventually. No promises. If you want that now, this isn't it.
What gets sent, and where
Data goes to api.antiga.me, run by me.
The script sends:
The server additionally records a hashed form of the IP address the request came from. That's not something the script reads or transmits — every HTTPS request carries the sender's address by necessity, the same as any website you visit. It's hashed with a key that rotates and is then discarded, so past hashes stop being linkable to anything. Basic abuse measure, nothing more.
On the player ID: this is the one that looks intrusive, so — it does two jobs. It's what makes per-player analysis possible at all, and it's how I can delete your data if you ask. Without an identifier there's no way to locate your rows, and "sorry, can't find your data" is a bad answer to a deletion request. No player name, no email, no credentials. Anything I post publicly will be aggregate; I'm not putting up a leaderboard of who loses the most fleets.
Your data, your call
Legal basis is legitimate interest (Art. 6(1)(f) GDPR). Participation is voluntary in the plainest sense — don't install it and nothing happens, uninstall it and collection stops immediately.
Want a copy of everything stored under your player ID, or want it deleted? DM me on the Origin board, or on Discord (Discord handle: _rivenscryr).
Expedition results are kept for as long as the project runs, since long-term comparison across patches is the entire point.
Honest caveats
Install
If it misses a result type, breaks on your universe, or does anything surprising, post here with your server and what you saw. This is also the place you can ask questions, and where I will post results.
Every few months the same argument goes around: expeditions got nerfed, DM finds dried up, the big resource hauls stopped showing up. And every time it's the same evidence — "feels like it", "I used to get more", someone's daily 200 expeditions collected across months with no record of which days had which boosters, which lifeform bonuses, or which game version was live.
That's the actual problem. It isn't only sample size — it's that nobody writes down the conditions. A 200-expo sample where the context is unknown can't tell you whether your results shifted because the game changed or because your ExpoComputer expired. You can't separate the two after the fact.
So: a userscript that records expedition results together with the conditions they happened under. Every result is stored alongside the buffs active at the time, your lifeform bonuses, class, universe speed, and game version. That's what makes comparison possible.
What it collects
Runs on the overview and messages pages:
A small status indicator in the messages tab bar shows what it's doing.
What happens with the data
To be clear about what this is right now: a backend that collects and aggregates. There's no dashboard, no login, nothing to look at yet. I run the analyses and post results.
What I'm building toward is tooling where analyses run automatically rather than me writing queries by hand. Once that exists, per-player analysis becomes cheap — which is the interesting part, because the most common version of this complaint isn't "expeditions are nerfed", it's "my expeditions are nerfed". With enough of your own trips recorded against known conditions, that becomes checkable: either your distribution really does sit off from comparable players on the same universe and class, or it doesn't and you've had a rough stretch.
A frontend might happen eventually. No promises. If you want that now, this isn't it.
What gets sent, and where
Data goes to api.antiga.me, run by me.
The script sends:
The server additionally records a hashed form of the IP address the request came from. That's not something the script reads or transmits — every HTTPS request carries the sender's address by necessity, the same as any website you visit. It's hashed with a key that rotates and is then discarded, so past hashes stop being linkable to anything. Basic abuse measure, nothing more.
On the player ID: this is the one that looks intrusive, so — it does two jobs. It's what makes per-player analysis possible at all, and it's how I can delete your data if you ask. Without an identifier there's no way to locate your rows, and "sorry, can't find your data" is a bad answer to a deletion request. No player name, no email, no credentials. Anything I post publicly will be aggregate; I'm not putting up a leaderboard of who loses the most fleets.
Your data, your call
Legal basis is legitimate interest (Art. 6(1)(f) GDPR). Participation is voluntary in the plainest sense — don't install it and nothing happens, uninstall it and collection stops immediately.
Want a copy of everything stored under your player ID, or want it deleted? DM me on the Origin board, or on Discord (Discord handle: _rivenscryr).
Expedition results are kept for as long as the project runs, since long-term comparison across patches is the entire point.
Honest caveats
Install
This tool is tolerated. 16.09.2026
Where should the tool fetch these public XML files from? Should I fetch them directly from the game server's /api/*.xml?
Yes, directly from the game domain. The proxy only fronts the access-controlled endpoints — reports and statistics — which is why those are the only two paths in its spec. The public XML API never needed a key, so there's nothing for the proxy to do there.
Mind the update intervals — they're in the API thread. Requesting a file more often than it changes just costs the server, so cache accordingly.
If so, does fetching them directly from the game domain count as a background call under §4 (i.e., does it generate game activity)?
That one you can answer yourself in about two minutes: make the request, then look at your own planet in the galaxy view from a second account. Do that before you ask.
I'll be blunt, because it'll save us both time later: there is no complete documentation of the ingame endpoints and there won't be. Third-party tools are tolerated, not supported — that's the whole meaning of the word. Working out what an endpoint does, what it touches and what it signals is the job. If the plan is to ask about each endpoint before using it, this isn't the right project to be starting.
Also, does reading it exactly once at login count as an acceptable background call?
Once per login session, yes — hydrate from it once and then track changes by reading the DOM as the player navigates.
And you do have a login event to hook: the game appends &relogin=1 on login.
en_808 is Singularity.
Hello RiV-,
Thank you for the detailed clarifications and the references. I will definitely include AGENTS.md in my project and use the community proxy as instructed.
Before I start testing the code locally, I have a quick question regarding the development environment:
- Is there a specific server (like a PTS universe) that you recommend for developing and testing the extension?
- Is it permissible (and safe regarding the anti-bot system) to test the early, local versions of the extension on my main playing account, or would you strongly advise creating a separate test account in a different universe to avoid any accidental bans if the code misbehaves during development?
Thanks again for your time and guidance.
Hello,
The PTS universe (Singularity) is in the Pioneers Lobby: https://lobby-pioneers.ogame.gameforge.com/
Note that you can copy your live account over: in your live account go to Options -> Extended -> Singularity -> copy / merge. That gives you realistic data to develop against without touching the live account itself.
To your second question: no. Don't test non-tolerated code on a live account, and not just because it might misbehave during development. A tool that hasn't been reviewed has no business running on a live universe at all — that applies to your own account exactly as much as anyone else's. Develop and test on Singularity, submit, and use it live once it's tolerated.
Hi everyone,
I've built a small userscript and I'd like to offer it to the community as shared infrastructure — not as a finished product, more as an experiment I'd like your feedback on.
Repository: https://github.com/Rivenscryr/origin-exporter (MIT)
The problem it tries to solve
If you want to write a calculator or simulator, you don't need toleration — as long as it works on manually entered data or the public API. But the moment you want it to work with real account data, you end up writing your own userscript to scrape or export it. And that script needs toleration, which means your otherwise review-free tool is suddenly sitting in the review queue waiting on me.
That cost gets paid over and over again, by every developer, for essentially the same piece of code.
So: one exporter, reviewed once, with a documented output format. You consume the JSON, you skip the scraping entirely.
What it does
The player installs the userscript, clicks the Empire icon in the game menu, and clicks Export account data. The script fetches the account snapshot and the lifeform bonus breakdown from the game, merges in planet/moon name, diameter, fields and temperature from the page, and hands the player a single JSON object to copy or download. They paste it into your tool.
Contents, roughly: player identity, class, officers, research levels; per planet and moon the resources, production, buildings, ships, defences, lifeform buildings and researches, active buffs; the full lifeform bonus breakdown plus a flattened bonusByType aggregate for convenience.
The output format is documented in docs/schema.md, and there's a JSON Schema in docs/schema.json you can validate incoming exports against. schemaVersion tracks changes to my transformations — check it and reject versions you don't handle.
What it deliberately does not do
This exports your own account and empire state — nothing else. It is not a source of live gameplay data about the universe or other players, and it isn't intended to grow into one.
One scope note for consumers
This exporter removes your need to write your own scraper. It does not change what your own tool may do with the data afterwards.
Whether your tool needs toleration is unchanged by where the data came from — check the submission guidelines and if you're unsure which side of the line you're on, ask before you build rather than after.
The actual condition: bring your own bugfixes
This is the part I want to be blunt about, because it decides whether this is worth doing at all.
OGame will break this. A DOM change, a renamed field, a changed endpoint — it's a matter of when. When it happens, every tool consuming the export breaks at the same moment, and you will all be looking at the same repository.
If this gets used, I would be maintaining this in my spare time, on best effort, with no response time promised. If you build something on top of it, please be willing to fix it yourself. Open an issue with the actual error and the relevant response snippet, or better, open a pull request.
Realistically this only works as shared infrastructure if two or three people other than me are willing to touch it.
On my own role here
I wrote this as a developer, not in my Origin admin capacity. Treat it as one developer's offer, not an officially blessed pipeline — I'm not making any promises here about how the game's endpoints will behave in future or how long this approach stays viable.
If it turns out nobody wants it, that's a perfectly good result for an experiment.
Feedback, criticism and "this is solving the wrong problem" replies all welcome.
Your tool is tolerated. However, you're fetching the highscore.xml API on every page navigation.
highscore.xml only updates once per hour: OGame API
The API provides a timestamp from which you can calculate the next update and only fetch when an update is due.
This tool is tolerated. 26.08.2026
Hello,
Thanks for asking before writing code — that's the right order.
One correction on your premise: "read-only" doesn't exempt a tool from toleration. Anything running on top of the game page needs review.
Also, "read-only" isn't the reassurance you might think it is: background calls are read-only too, and there's a lot to get wrong there.
There's no PTS pre-approval stage — review happens on the submission itself. Please read the following threads:
And if you're developing with an AI coding agent: AGENTS.md — keep your AI coding agent within the tool rules
Worth checking it out even if you don't, as it elaborates on the Forbidden features.
Are there any specific technical limitations or restricted APIs that I should be aware of?
For the public XML API and the reports API: OGame API
On ingame endpoints, the AGENTS.md linked above has some examples on what to do and what not to do.
However there is no exhaustive list. You're a developer and you're expected to have an understanding of game mechanics, ingame endpoints and their implications. If you don't, you should probably not be developing ingame extensions.
Is there a preferred environment or standard layout you require for submitting tools for review?
Everything is in the Submission guidelines above. Including the submission template.
Moved to correct forum.
Update — clarifications to this thread
I've made a few edits above, following a case that made clear the original wording left room for interpretation. Nothing here is a new rule; it's spelling out what was already meant.
Where the line is on using other tools' code. Section 2 previously warned that feeding a codebase to an AI will produce a copy. That was framed as a risk. It's now explicit that it isn't acceptable regardless of how the output turns out: other developers' code has no place in your development process — not as input to an agent, not as a working model, not as material to restructure. Rewriting the result afterwards doesn't change that.
How we find out about it. Section 3 said we work on a report-and-verify basis. That still holds — we don't audit repositories or run background checks on new tools. But it now also says we act on what we see: if a toleration review turns up appropriated work, we don't need a report to act on something we found ourselves.
Consequences. Section 4 now lists suspension or loss of the ability to submit tools, which was missing, and no longer reads as though it only applies to repeat offenders. A single serious case can be enough.
As always, my PMs are open. If you're unsure whether something you're planning falls on the wrong side of any of this, just ask — I'd much rather have that conversation before you've written the code than after.
Same as when this thread first went up: use AI to automate the boring parts, learn a new stack, speed yourself up. Just build your own tool.
This tool is tolerated. 17.08.2026
To make sure I implement this correctly: if I only enable background monitoring when the tab is active, so that the DOM is only read when the tab is actively focused by the player, is it acceptable to keep displaying that static "last seen" snapshot in the SidePanel when switching universes tabs?
Under this model, no background extraction or updates occur while a tab is inactive—the SidePanel simply retains the last state the player actually saw when they were viewing that tab, as a reminder.
Yes, this is fine.
Thank you for your cooperation.
Hello Boubou,
Thank you for submitting OGame Multiverse for toleration. The review of the v1.1.0.0 source is complete, and the extension is generally well-built. There is one item that needs to be changed before toleration can be granted.
The issue
The event-monitoring feature surfaces information from OGame tabs the player is not currently viewing.
The extension continuously monitors the event box of every open OGame tab — including tabs sitting in the background that the player isn't looking at — and forwards hostile/friendly/own fleet counts and unread message/chat counts to the side panel. Those counters are then displayed for every universe that has a tab open in the current window, not just the one the player is actively viewing. The "sync paused" state only kicks in when no OGame tab is active at all; the moment any one universe tab is focused, indicators for all other same-window universes light up, fed by data collected from background tabs the player isn't looking at.
Why this is a problem
The game is meant to be played through its own UI. Normally, to notice that a given universe has incoming hostile fleets, unread messages, or unread chat, you have to be looking at that universe's tab. This extension removes that requirement: it continuously extracts event-box state from unfocused tabs and aggregates it into a cross-universe monitoring surface the game does not provide. The hostile-fleet counter in particular functions as a multi-universe early-warning system without the player needing to watch each universe.
To be clear: the concern is not that the extension makes background calls to the game server — it does not, and that part of the design is good. The concern is that reading already-loaded DOM from tabs the player isn't viewing, and surfacing it elsewhere, circumvents the normal gameplay requirement to be actively viewing a universe's tab to notice its events.
What needs to change
Event-box counters (hostile/friendly/own fleets, unread messages, unread chat) for a given universe must only be read and surfaced while that universe's tab is the active, visible tab. When the tab is hidden or not active, the extension should stop extracting and forwarding event-box data for that universe.
The inactivity/last-refresh tracking and the tab-management features (open/activate/refresh/close/move) are fine as-is and do not need to change.
Once the event-monitoring change is made, please post the updated source/build here and I'll take another look. Happy to answer any questions about the above.
Best regards
This tool is tolerated. 15.08.2026
AntiGameReborn — v13.1.0
Compatibility: OGame 13.x · AGR feature release 1
[Feature]
[Bugfix]
New versioning schema
13.1.0 = OGame 13.x, AGR feature release 1, no patches yet.
