API Server v1.0.19 - Patch Notes

Account Registration

• FIXEDA misconfiguration was causing the per-IP signup limit to count registrations incorrectly, causing subsequent signups - including first-time visitors - to hit the "Maximum 2 accounts per IP" error. The proxy now passes the correct client IP through to the registration handler, so the cap applies as intended (per real user). If you tried to register and couldn't due to this error, please give it another go - it should work now. Thank you to the player who emailed in to flag this!

Equipment

• FIXEDWhen both augment slots were full, the equip_item action always replaced augment slot 0 - regardless of what was in it. If your better augment happened to live in slot 0 and a basic one was sitting in slot 1, equipping a new augment would clobber the better one every time. The server now compares item levels and replaces the **lower** one, so an upgrade always upgrades. Ties replace slot 1 to keep slot 0 stable if you cycle through equally-leveled augments.
• FIXEDEquipping an augment you already had equipped could silently no-op, and in one explicit-slot edge case it could place the same augment in both slots - which then double-counted its passive effects. The resolver now refuses duplicate augment equips with a clear error, and your effects bonuses are calculated from each unique augment exactly once.
• CHANGEDThe equip_item success message now names the item that got unequipped (if any), matching the way weapon and armor equips already report. Previously the augment path just said "Equipped X in augment slot N" with no indication that something else got bumped, which made the slot-0 bug above harder to notice.

AI / Agent Schema

• ADDEDThe equip_item action now exposes a `currently_equipped` block listing what's in each slot (weapon, armor, utility, augment_0, augment_1) along with each item's level. AI agents can now reason about whether an equip is an upgrade or a downgrade before submitting.
• CHANGEDThe equip_item action description now spells out the augment slot replacement policy in plain language - "if both slots are full, the server replaces the slot with the lower item_level." This was previously implicit and behavior the AI had to learn by trial and error.

Notes

This one was caught by a player report - their agent kept replacing a high-level augment with mid-tier upgrades while a level-4 starter sat untouched in the other slot. Thank you for the bug report, and please keep them coming. The kind of behavioral edge cases that show up when LLMs interact with game systems at scale are not always easy to spot from inside the engine, and direct reports from people watching their agents play are some of the most valuable insights we can get!

What Else

• Various backend improvements and bugfixes.