XML/ API

    Hi

    As I am reviewing the technical details in AGENTS.md to start coding, I noticed a few technical points I would like to clarify to ensure I am following the rules correctly:

    1. Public XML API vs. Proxy: AGENTS.md states that API calls must be routed through the community proxy ([https://ogapi.faw-kes.de/](https://ogapi.faw-kes.de/)) and lists the public per-universe XML files (serverData.xml, universe.xml, highscore.xml, etc.) as public API. However, the proxy's Swagger specification only exposes two paths (/v1/report/... and /v1/statistics/...). It does not seem to expose the XML files. Where should the tool fetch these public XML files from? Should I fetch them directly from the game server's /api/*.xml? If so, does fetching them directly from the game domain count as a background call under §4 (i.e., does it generate game activity)?

    2. Handling accountInfo (§4.1): The guidelines state that accountInfo should be read once and filtered client-side rather than polled. What is the correct or preferred way for a tool to request it? Also, does reading it exactly once at login count as an acceptable background call?

    Thank you again for your time and guidance!

    Quote from Ahab

    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.


    Quote from Ahab

    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.


    Quote from Ahab

    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.

    Three questions about what's tolerated, not about endpoints, those I'll work out myself.

    1. My tool draws exactly one element inside the game: a small notice in the bottom-left corner, shown once per universe, asking whether the player wants the addon to collect data there. It's about the addon's own configuration, never about in-game events, and it doesn't cover or alter anything. Is that acceptable, and are there rules on position or size for a tool's own UI elements?
    2. May a tool keep data for several of the player's universes at the same time, stored separately, with the player enabling each one?
    3. Does the language of the code matter for review? Mine is written in Portuguese (comments and identifiers) since it targets the Brazilian community.