4c2648046bd5bebb2cbbef5ff0bd52216bd446ae
MB_STATIC_BUILDINGS picks the static building source (World Boot Plan 2.4): - DB: today's load; static zones keep their tree UIDs. - PARITY: DB load, then the JSON buildings are built with the IDs a JSON boot gives them, compared with the DB rows and discarded. The match runs three passes (exact zone/mesh/x/z; hand-moved rows by mesh and name in the zone or its parent; rows of dropped twins onto the kept twin) and writes maps/<map>.migration.sql, the old UID -> static ID table the migration script reads. Every unmapped DB row is logged. - JSON: static zones take negative IDs, static buildings come from the CZONE props, and the DB loads only what is left (player buildings, mine towers). Boot aborts when the mode does not fit the DB: JSON needs the static obj_zone rows gone, DB and PARITY need them present. Static IDs, fixed from here on: guilds, then zones in tree order, then buildings zone by zone in tree order, each top-level prop followed by its children, in JSON order. Every mode takes the zone IDs, so the manifest of a PARITY boot equals the JSON boot's. A prop with the same mesh, name, local position and yaw as an earlier sibling is dropped with its children and takes no ID; the name keeps Swampstone's four stacked vendor halls. Static buildings keep the factory's parent x local world location in runAfterLoad. CITY props are owned by the leader NPC of the DB guild with the seed guild's name, an interim until static guilds get leaders (2.5/3.2). Value changes in JSON mode (decided in 2.3 unless noted): - every static zone and building ID becomes negative (W10); - children take their CZONE local Y; 9,362 children move up to 160 units on the server once the parent yaw applies (the client gets local values); - Swampstone halls, the Silverlance shop and the Sea Dog's Rest tree follow the JSON; owners follow the CITY key (13 props unowned, Junktown owned by Greyman's Band); prop:1276/18 rank 0 -> 1; - stacked twins are gone (7 top-level with their children, ~446 children; counts logged per zone at boot). DB mode: no value changes. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Magicbane Open-Source MMO Project
The Community written Shadowbane emulator
Magicbane
Public Repository
magicbot@magicbane.com
Magicbane is an emulator for the long dead but much beloved Ubisoft MMO, Shadowbane. The project was founded in 2013 with the concept of free availability of gameplay; players unencumbered by any factor other than a desire to again play a game they once loved. A game where the developers do not play is guaranteed to be the fairest game.
The Magicbane Team has wanted to open source Shadowbane for half a decade. We are excited to now finally have the opportunity, along with some new technology, to truly democratize Shadowbane.
- Written in some 80k lines of Java 8 and bash.
- Project with real infrastructure; Production and development servers supporting multiple containerized apps.
- MagicBox container technology enables instant deployment and trouble free development on modest hardware.
- MagicBox plugin capability allows for new and interesting player experiences.
Contributing
- Project is released under an MIT license. Please see the LICENSE file.
- Inbound == Outbound.
- IntelliJ is the supported IDE.
- Write code today see it running on the Magicbane production server tomorrow.
Support
Documentation is available through the Magicbane Wiki and Discord server.
Description
Public Repository for the Magicbane Shadowbane Emulator
87 MiB
1 Stars
434 Watchers
6 Forks
Languages
Java
100%
