Posts by RiV-

    Hi everyone,


    More and more tools these days are built with the help of AI coding agents (Claude Code, Cursor, Copilot, Codex, and so on). That's a good thing overall — it lowers the barrier to building useful stuff. The catch is that these agents don't know OGame's rules or how the game actually works, so they'll happily implement things that are flatly forbidden: automation, scheduling, attack alarms and Discord pings, direct probing from custom target lists, hiding ads, background polling, and so on. A fair number of recent submissions have failed review for exactly these reasons.


    To help with that, I've put together a resource you can drop straight into your project:


    https://github.com/Rivenscryr/origin-tooldev-agents


    What it is

    It's an AGENTS.md file — a standard instructions file that most modern AI coding tools read automatically. This one encodes our forbidden-features and toleration rules as hard constraints, so your agent knows the boundaries while it's helping you build, instead of finding out at review time.


    What it does

    • Makes the agent refuse forbidden features — automation & macros, scheduling, auto-refresh & polling, automatically registered alarms/notifications/webhooks, direct probing, imitating Dark Matter features, blocking monetization, paywalls, silent data scraping — and explain why in plain language rather than quietly building them.
    • Flags the gray-area features that need a ToolDev admin's approval before you build them.
    • Enforces sane API and background-call behavior (the community proxy, page-load-only calls, the accountInfo and cp pitfalls, and what "activity" actually is and why it matters).
    • Includes a "does my tool even need toleration?" guide, a pre-submission self-audit checklist, and a quick request → verdict table.


    How to use it

    1. Copy AGENTS.md into the root of your project's repository.
    2. Most agentic tools pick it up automatically. If yours expects a different filename, copy or symlink it (CLAUDE.md, .cursorrules, .github/copilot-instructions.md), or just tell your agent at the start of a session: "Read AGENTS.md and follow it strictly."
    3. Build. When you ask for something forbidden, the agent should push back and explain — don't override it. If you think you have a genuine exception, ask a ToolDev admin first.


    A couple of important notes

    • This is a recommendation, not a requirement, and it is not a guarantee of toleration. Tools that need review still get reviewed on their own merits. The file just makes it far less likely you'll build something that gets rejected on sight, and it makes reviews quicker for everyone.
    • The forum threads remain the source of truth for the rules. The file only encodes them.
    • AI agents still make mistakes. Read what yours produces, and when in doubt, ask.


    Feedback wanted

    This is a first version and I'd genuinely like your input — especially from experienced tool devs. If a rule is stated inaccurately, an example is unclear, or something important is missing, please open an issue or PR on GitHub, or just reply here. The rules have a lot of nuance, and more eyes will make this better for everyone.


    One thing to keep in mind if you'd like to contribute: the file only encodes the rules, it doesn't set them. Anything that changes what's actually allowed has to come from an official decision, not a personal preference — so if in doubt, open an issue and let's discuss first.


    Thanks, and happy building.

    This tool is tolerated. 09.07.2026


    Please take a moment to review the requirements once your tool has been approved:


    Thanks for the thorough testing and clear write-up. Going through your points:


    1) Undocumented header + inconsistent error handling

    Noted, I'll forward it. Honest heads-up though: I wouldn't hold my breath on this one. The error handling is likely a deeply nested structural thing rather than something they can cleanly fix for this one endpoint, so a targeted fix here may not be feasible.


    2) technologyQuantities + cp side effect

    This isn't an API bug to fix — it's expected behavior you need to design around. cp stands for "change planet," and it does exactly that: it switches the account's active planet, same as clicking that planet in the sidebar. Using it in a background call to read another planet is not permitted for tools (see the forbidden features list) precisely because it triggers a real state change rather than a read.


    You don't need it anyway: accountInfo already returns per-planet data for all planets in one call, so there's no reason to use cp with technologyQuantities for cross-planet reads.


    3) accountInfo — jumpgate cooldown

    I hear the use case, but I don't think accountInfo is the right place for this, and I'd push back on the underlying approach a bit: accountInfo is a heavy endpoint (it's effectively a full account snapshot) and isn't meant to be polled continuously to keep external state fresh. Doing that repeatedly to "catch" a timer changing:

    • puts unnecessary load on the server for something that's fundamentally an event you either observed or didn't, and
    • refreshes the highscore for everything across all your planets at once, rather than just what a normal single-planet action would trigger — which for an observer is a giveaway that you're online and actively refreshing.

    If a player switches devices/tabs and your tool wasn't running to see the jump happen, that's a gap in what your tool can know — not something the API should compensate for by making every consumer poll a heavy endpoint. A tool is expected to track what happens while it's active, not be omniscient about actions taken elsewhere.


    That said, the actual ask — a cooldown end timestamp — is reasonable on its own merits, just not via accountInfo. A good fit would be an inline data attribute on the planet list in the normal page markup, so it's available without a background call. I'll forward that specific suggestion to the devs.


    5) Empire standalone JSON — hourly/per-second bug

    Forwarded as a clear beta regression — good catch comparing against the resource bar and accountInfo.


    On the itemNames note: can you clarify what you mean by "now maps item UUIDs to names instead of technology id → name"? Items are identified by UUID, not technology ID, so I'm not sure what mapping you were expecting or where you'd previously seen a technology-id-keyed version. A before/after example (or the exact field) would let me pass it along accurately.

    BDhWXSVoBi.png


    AGRbot v2 is here!


    AGRbot has been completely rewritten from the ground up — faster, more reliable, and with a much cleaner Discord experience. Every command is now a proper slash command and there is a lot of new stuff packed in.


    Add to your server | Join the community server




    What's new in v2


    Slash commands everywhere

    Every command is now a proper Discord slash command with autocomplete, inline descriptions, and permission checks built in. No more guessing at prefixes or argument order.


    Consolidated settings

    All bot configuration lives under a single /settings command with an interactive UI — no more typing set-* commands one by one. Three subcommands cover guild-wide, per-channel, and news channel settings.


    Spy report overhaul

    Spy reports now render directly in Discord using Components V2 — structured panels showing ships, resources, defences, and lifeform bonuses. Each report also has a full HTML view you can open in your browser. Reports are cached for one year, so rendered views keep working even after the key expires on OGame servers. Prefer the classic look? The legacy code-block renderer is still available and can be toggled per channel via /settings channel.



    Simulator integration

    After rendering a spy report, hit the Simulate button to open a pre-filled TrashSim link on simulator.ogame-tools.com. The bot pulls fleet and tech data for all tagged participants automatically — no manual entry required. Also available via right-click → Apps → Sim as Attacker / Sim as Defender on any message containing a report key or a rendered spy report.


    In the popup, select participants and — if you wish — how many slots per participant the simulator should prefill. Perfect for splitting in ACS scenarios.



    OGotcha integration

    Use /ogotcha to upload a combat report to OGotcha with full options — your role, debris collected, follow-up raids, and harvest reports. The bot presents an interactive form before uploading and then posts the resulting link.



    Report auto-detection

    Paste any sr- or cr- key in a watched channel and the bot fetches and renders it automatically — no command needed. Combat reports are auto-uploaded to OGMem or OGotcha depending on your guild configuration. Use /api instead if you want manual control, or if other bots on your server also auto-detect keys and you want to avoid triggering them.


    Broadcast news channel

    Configure a channel via /settings news and the bot will deliver changelogs and announcements directly to your server. Make sure the channel is readable by all members so nobody misses updates.


    Multi-language support

    Currently supported: English, German, Spanish, French, Dutch, Italian, Portuguese, Russian, Turkish, Polish. Configured per guild via /settings guild. Slash command descriptions are also localised and appear in your Discord client's own language where available.

    Native speakers: looking for reviewers to refine translations. Found a mistake or want a new language added? Drop by the support server.




    Full command reference


    Command Description
    /api <key> Fetch and render a spy or combat report from an OGame report key (sr- / cr-). Use this for manual control or when other bots also auto-detect keys.
    /ogotcha <key> Upload a combat report key to OGotcha with full options — role, debris collected, follow-up raids, harvest reports. An interactive form opens before uploading.
    /costs <category> <item> <level> Calculate resource costs for a building, research, ship, or defence at a given level. Category and item both have autocomplete.
    /md <moon-size> <rip-count> [waves] Calculate moon destruction probability for a given moon size, number of Deathstars, and optional wave count.
    /servers list List all known OGame universes across all communities with their key settings.
    /servers show <uni.com> Show detailed settings for a specific universe (e.g. Quantum.en).
    /servers filter <flags> Filter universes by settings using expressions like fleetSpeedWar=1 economySpeed>=5. Run /servers help for the full list of filter keys and operators.
    /set-techs <key> Save your technology levels using a spy report key from a self-probe. The bot caches the report and links it to your account per universe. Required for accurate simulator pre-fill.
    /settings guild (Admin) Guild-wide settings: interface language, report rendering mode (Components V2 or classic code-block), preferred combat report service (OGotcha / OGMem), OGMem API token, and trust role for sim access.
    /settings channel (Admin) Per-channel settings: report rendering mode override, sim button visibility, and spy report verbosity level.
    /settings news (Admin) Choose the channel that receives bot changelogs and announcements.
    Right-click → Sim as Attacker Context menu command on any message — extracts the report key and opens a pre-filled TrashSim link for the attacking fleet.
    Right-click → Sim as Defender Same as above, pre-filled for the defending fleet.
    /invite Get the bot's invite link.
    /info Show live bot health: gateway status, uptime, RAM usage, database health, and server count.
    /stats Aggregate usage statistics — top commands, active guilds, and cached data counts.



    How to add AGRbot to your server

    1. Invite the bot. Click the invite link at the top of this post (or run /invite on any server that already has the bot). You need Manage Server permission on the target server.

    2. Configure guild settings (admins). Run /settings guild to set the server's language, report rendering mode, preferred combat report service, and optionally a trust role that restricts who can trigger simulator links.

    3. Configure channel settings (admins, optional). In each channel where you want to override the bot's behavior, run /settings channel to override the rendering mode, toggle sim buttons, or adjust spy report verbosity.

    4. Set up a news channel (admins, optional). Run /settings news and pick a channel that all your members can read. Future bot updates and changelogs will be posted there automatically.

    5. Save your tech levels (everyone). Run /set-techs <key> with a spy report key from a self-probe in each universe you play. This lets the bot pre-fill your tech levels when building simulator links. Repeat once per universe.

    6. Start using reports. Paste any sr- or cr- key in a watched channel and the bot renders or uploads it automatically. Use /api <key> for manual per-command control.


    One-time migration notice: Guild settings and saved tech levels do not carry over from AGRbot v1. Admins need to re-run /settings guild, and every player needs to re-run /set-techs for each universe they play.




    Support & community


    The bot is free to use. If you find it useful, any support to help keep it running is appreciated.

    Got a feature request or found something broken? Drop by the support server — feedback is always welcome.




    AGRbot © 2026 by RiV- (_rivenscryr) — Privacy Policy

    Hello tool developers,


    some new data export endpoints have recently been made available on the PTS server Singularity for testing and feedback.

    Available Endpoints

    Species Bonuses

    /game/index.php?page=componentOnly&component=externaldataexport&action=speciesBonuses&asJson=1

    • Method: GET
    • Response format: JSON

    Account Information

    /game/index.php?page=componentOnly&component=externaldataexport&action=accountInfo&asJson=1

    • Method: GET
    • Response format: JSON

    Technology Quantities

    /game/index.php?page=componentOnly&component=externaldataexport&action=technologyQuantities&asJson=1

    • Method: GET
    • Response format: JSON

    Note: This endpoint returns only the currently active quantities of selected technologies. If a technology is inactive (for example because it is not selected or because population requirements are not met), the returned quantity will be 0.

    Import / Export Information

    /game/index.php?page=componentOnly&component=externaldataexport&action=importExportInfo&asJson=1

    • Method: GET
    • Response format: JSON

    Important

    These endpoints are currently available on Singularity and should be considered Beta. Their structure and contents may change before they are made available on live servers.


    The endpoints are only accessible from within an authenticated game session and cannot be accessed externally without being logged into the account whose data is being requested.

    Feedback & Requests

    Feel free to explore these endpoints and provide feedback on their structure, contents, and usability.


    If there is account data that you currently cannot access, or if you have suggestions for additional endpoints, please post them in this thread. Constructive and technically feasible suggestions can be forwarded for consideration.


    Thank you for helping improve the tooling ecosystem around OGame.

    As of version 1.1.3, this tool is not tolerated anymore.


    4. Background Requests, Polling, or Automated Data Collection

    Checks sync status every 60 seconds.
    Automatically triggers a background AJAX sync process every 5 minutes if the player is active and has an active tab open.
    Automatically schedules a retry 1 minute later if a sync operation fails (e.g. due to server/session timeout issues).

    This is an automated background call every 5 minutes that will cause an activity star in the Galaxy View automatically without the player manually refreshing the page.


    Please refer to the Forbidden features thread, especially:

    Excessive background calls & Polling

    Background calls are useful for retrieving necessary information but must be reduced to an absolute minimum.

    Tools may not use continuous, automated polling loops to constantly check the server for updates.
    Background calls that cause uncontrolled or unwanted activity (triggering an “activity star” in the Galaxy view) or cause unnecessary server load are strictly forbidden.

    Hi,


    thank you for your toleration submission.


    However, at the current state, I cannot grant toleration for your script.


    These issues must be fixed in order to be granted toleration:

    • startAutoExport() uses setInterval for scheduled data transmission every 10 minutes. This is timer-based delayed execution. Export can be manual and/or once per page load.


    The following issues are security concerns that are recommended to be fixed:

    • unsafeWindow is unnecessary — The script already has GM_getValue/GM_setValue for persistent storage. Using unsafeWindow.localStorage instead is suspicious because it provides access to all page localStorage when GM_getValue/GM_setValue would suffice for record storage.
    • innerHTML XSS vector via stored URL — line 206 — value="${SHEETS_URL}" inserts the user-configured Google Sheets URL directly into innerHTML without escaping. A crafted URL could execute arbitrary JavaScript. While the URL is self-provided (user sets their own), this is still a stored XSS vector. The same pattern appears in line 203 with ${SERVER} (lower risk since SERVER comes from window.location.hostname).

    Hi,


    this tool does not require toleration, so moving to Community Showcase.


    Current limitation and API key request:

    The combat report converter currently uses the community proxy (ogapi.faw-kes.de) as recommended. However, the JSON response provided by this proxy does not include per-round fleet composition data (i.e. the state of each fleet after each combat round). As a result, it is currently impossible to determine:

    • The exact number of ships destroyed per player during the battle
    • The surviving fleet of each participant after combat
    • Whether a defender was fully destroyed or still has ships remaining

    This information is present in the full combat report response available via a private API key, which includes detailed round-by-round data. Without it, the converter can display the initial fleets, loot, debris and summary statistics, but cannot render a complete "after battle" fleet breakdown as tools like OGotcha or OGameDB do.

    This is not true. The community proxy returns the same data as a private API key. Detailed round data is present in both.



    Please be aware, that if you should at some point create a userscript / browser extension to scrape data and send to your tool, that would require separate toleration.


    Thank you for your contribution to the community.

    This tool is tolerated. 04.06.2026


    3. The Review Process & Updates

    Once your tool is reviewed and tolerated, it will be moved to the "Tolerated Tools" section. If this is your first tool, and you aren't already part of the "Community Projects" group, please apply to the group so you can post in the "Tolerated Tools" section.

    • Changelogs: Your official thread in the "Tolerated Tools" section must be kept clean. Use this thread only to post your official updates and changelogs for every new version. Omitting changes or adding hidden features may result in the loss of your toleration status.
    • Discussion & Feedback: Once your tool is tolerated, you are free to open a separate thread in the "Community Showcase" section so users can ask questions, report bugs, and give feedback. You must include a clear link to your official "Tolerated Tools" thread in the opening post.
    • Future Features: Toleration is only for the current state of your tool. If you plan to add new features, confer with a responsible ToolDev first to ensure they won't break the rules.


    ⚠️ What "Toleration" Means

    Toleration simply means the Origin Team has reviewed the features and determined it does not violate OGame's rules or Terms of Service. It is NOT a guarantee that the tool works correctly, nor is it an absolute guarantee of security. Gameforge and the Origin Team do not verify the correctness of the results or provide a warranty. Users install and use all third-party tools at their own risk.

    Hi everyone,


    With the rapid rise of AI-assisted development tools, creating new utilities and features for OGame has become faster and more accessible than ever. We love seeing the influx of fresh ideas and modernized tech stacks in the Community Showcase.


    However, as technology changes, the core values that keep our development community healthy must remain rock-solid. We want to take a moment to discuss the culture we want to foster here and outline some practical guardrails for using AI responsibly.

    1. Our Culture: Transparency & Respect

    The OGame tool development community has thrived for years because creators generously share their time and code. To maintain this, transparency and mutual respect are non-negotiable.

    • Give credit upfront: If your tool relies on an open-source baseline, say so clearly in the first few lines of your thread.
    • Respect active projects: Building on history is great; copying an active peer's current, distinct work without their permission is not.
    • Cooperation over competition: For years, developers in this community have discussed tricky logic, shared solutions, and actively pointed users to each other's tools. We are a collaborative ecosystem, not a cutthroat marketplace competing for users. We succeed by lifting each other up.


    2. A Reality Check on AI Agents & "Inspiration"

    We need to talk about how AI agents actually behave. If you feed a live community website or codebase into an AI tool and tell it to "take inspiration from this" or "make this better," the AI isn't going to just learn from it—it is almost certainly going to copy it outright.


    As a developer, your use of AI must be conscious, aware, and responsible:

    • You cannot hide behind the AI and claim ignorance if it hands you a plagiarized layout, specific custom features, or exact code structures.
    • "Vibe-coding" a tool in a few minutes is fine, but you are entirely responsible for auditing the final output before you publish it as your own work.


    3. Our Enforcement Policy: We Are Not Code Police

    To be completely transparent: the admin team is not going to actively police this section. We do not have the time or the desire to proactively audit every GitHub repository or run background checks on every new UI that gets posted.

    • We operate on a report-and-verify basis. If a creator brings a plagiarism or licensing issue to our attention with clear evidence, we will step in and look into it.
    • First-time offenses: If a tool is found to be an unauthorized clone or an uncredited replica, the thread will be locked or removed until the issue is properly resolved with the original creator.


    4. Escalated Consequences for Repeat Offenders

    While we prefer to resolve things amicably, we will protect our community's integrity. Repeated offenders or those acting in clear bad faith will face strict, escalating consequences, including:

    • Permanent removal of all their project threads from the Showcase section.
    • Complete revocation of the tool's official "tolerated" status.
    • Being permanently blacklisted from private API access and community developer resources.


    Moving Forward

    We want to keep this space collaborative and exciting. Use AI to automate the boring stuff, optimize your performance, and learn new stacks - just don't use it to appropriate the hard work of your fellow community members.


    Thank you all for helping us keep Origin a space built on trust, respect, and true innovation!

    I appreciate the amount of work and enthusiasm going into the project, however the tool is currently expanding very rapidly in both scope and complexity.


    The intention behind the toleration system is not to block development or require approval for every small feature. We generally trust developers to use good judgment and want to keep friction low.


    That said, when a tool starts evolving far beyond its original purpose it becomes much harder to properly review and maintain from a toleration perspective.


    At the moment, the official tolerated thread is also becoming difficult to follow due to the extremely frequent and highly detailed update posts. The thread is intended to serve as a clear and auditable changelog for reviewers and users, not as a live development blog.


    Please try to keep future changelogs:

    • concise,
    • technically focused,
    • grouped into larger releases where reasonable,
    • and limited to actual functional changes.


    Marketing-style descriptions, repeated UI wording, and extremely granular patch separation should be avoided in the tolerated thread. Those are better suited for a separate showcase/discussion thread.


    Additionally, while we do not normally require developers to discuss every new feature with a ToolDevs admin beforehand, I would strongly recommend checking in first before introducing major expansions or experimental systems that significantly broaden the tool’s scope.


    This is not meant as a restriction on development, but rather to help keep the project reviewable, understandable, and within the spirit of the toleration system over time.

    Please add a note about the supported languages, as the tool currently only provides Polish translations and appears to function properly only when the game language is set to Polish.


    Also, please add proper credits to the original authors of any external works or resources used within the tool (for example the Lifeform build strategies).


    Please also read:

    3. The Review Process & Updates

    Once your tool is reviewed and tolerated, it will be moved to the "Tolerated Tools" section. If this is your first tool, and you aren't already part of the "Community Projects" group, please apply to the group so you can post in the "Tolerated Tools" section.

    • Changelogs: Your official thread in the "Tolerated Tools" section must be kept clean. Use this thread only to post your official updates and changelogs for every new version. Omitting changes or adding hidden features may result in the loss of your toleration status.
    • Discussion & Feedback: Once your tool is tolerated, you are free to open a separate thread in the "Community Showcase" section so users can ask questions, report bugs, and give feedback. You must include a clear link to your official "Tolerated Tools" thread in the opening post.
    • Future Features: Toleration is only for the current state of your tool. If you plan to add new features, confer with a responsible ToolDev first to ensure they won't break the rules.


    ⚠️ What "Toleration" Means

    Toleration simply means the Origin Team has reviewed the features and determined it does not violate OGame's rules or Terms of Service. It is NOT a guarantee that the tool works correctly, nor is it an absolute guarantee of security. Gameforge and the Origin Team do not verify the correctness of the results or provide a warranty. Users install and use all third-party tools at their own risk.


    This tool is tolerated. 28.05.2026

    ## Bug Title ️ ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------

    Military ships in fleetdispatch missing stockAmount and data-value when 0 units are stationed




    ## Account Nickname/ID ----------------------------------------------------------------------------------------------------------------------------------

    n/a



    ## Account Type ----------------------------------------------------------------------------------------------------------------------------------------------------------------------

    General




    ## Device & Environment ---------------------------------------------------------------------------------------------------------------------------------------------------------

    - Device: PC

    - OS: CachyOS

    - Browser: Helium Version 0.12.3.1 (Official Build, Chromium 148.0.7778.167) Arch Linux (64-bit)

    - Scripts/Extensions: no




    ## Steps to Reproduce ------------------------------------------------------------------------------------------------------------------------------------------------------------

    1. Visit fleetdispatch on a planet/moon with some military and civil ship types having 0 units

    2. Look at military ships, look at civil ships

    3. Inspect both in browser's DevTools




    ## Expected Result ------------------------------------------------------------------------------------------------------------------------------------------------------------------

    All ships should have stockAmount and data-value set just like it is the case for civil ships.




    ## Actual Result ----------------------------------------------------------------------------------------------------------------------------------------------------------------------

    Military ships have no stockAmount / data-value when the unit amount is 0.




    ## Frequency --------------------------------------------------------------------------------------------------------------------------------------------------------------------------

    always.




    ## Evidence ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------

    Screenshot_20260521_224423.png


    Screenshot_20260521_224639.png



    ## Additional Notes -----------------------------------------------------------------------------------------------------------------------------------------------------------------

    -

    Please take note:


    3. The Review Process & Updates

    Once your tool is reviewed and tolerated, it will be moved to the "Tolerated Tools" section.

    • Changelogs: Your official thread in the "Tolerated Tools" section must be kept clean. Use this thread only to post your official updates and changelogs for every new version. Omitting changes or adding hidden features may result in the loss of your toleration status.
    • Discussion & Feedback: Once your tool is tolerated, you are free to open a separate thread in the "Community Showcase" section so users can ask questions, report bugs, and give feedback. You must include a clear link to your official "Tolerated Tools" thread in the opening post.
    • Future Features: Toleration is only for the current state of your tool. If you plan to add new features, confer with a responsible ToolDev first to ensure they won't break the rules.