Etapa 3: publicar mapas en vivo sin reiniciar el server

[leocagli]

Parte de #2 (modo construcción). Depende de todas las issues de mutación.

Esta issue es la que hace que el modo construcción se sienta "en vivo" en vez de "editá y reiniciá".

Lo que ya existe

El server del juego hidrata game data desde la DB al arrancar y reporta la versión aplicada:

[GAME DATA] Objs hidratados desde DB: 1062. Version aplicada: 4875.
[GAME DATA] NPC templates hidratados desde DB: 340. Version aplicada: 4872.
[GAME DATA] Balance hidratado desde DB: 1. Version aplicada: 3811.

Ese mecanismo ya existe para objetos, NPCs, crafteo, fundición y balance. Falta el equivalente para mapas, y falta que ocurra sin reiniciar.

Alcance

1. Endpoint para publicar los cambios de un mapa (pasar de borrador a vivo).
2. El server de juego recarga ese mapa sin reiniciar el proceso.
3. Los jugadores que están parados en ese mapa reciben la versión nueva.
4. Separación entre borrador y publicado: se puede editar sin que los jugadores vean el trabajo a medias.

El problema difícil

Recargar un mapa con jugadores adentro no es trivial:

• Un jugador puede quedar parado donde ahora hay una pared
• Un NPC borrado puede estar en combate con alguien
• El cliente cachea los mapas y hay que invalidar ese caché

Hace falta decidir la política. Opciones razonables: reubicar a los jugadores afectados al tile caminable más cercano, o rechazar la publicación si hay jugadores en las zonas modificadas.

Criterios de aceptación

• Publicar un mapa aplica los cambios sin reiniciar el server
• Un jugador dentro del mapa ve los cambios sin reconectarse
• Un jugador que queda sobre un tile ahora bloqueado no queda atrapado
• Los borradores no son visibles para jugadores comunes
• El caché de mapas del cliente se invalida correctamente
• Tests de integración

Archivos relevantes

• server/src/loadObjs.ts, loadNpcs.ts, loadBalance.ts (patrón de hidratación a replicar)
• La invalidación de caché es del lado del cliente

[Nabeel-javed]

Hola @Bitcoindefi. Estoy buscando una contribución remunerada con asistencia de Codex desde @Nabeel-javed. Leí CONTRIBUTING.md, la recompensa de 100 USD para #11 en #2 y la propuesta existente #346 de @Aduersarius.

¿Sería útil y remunerable un alcance separado de pruebas de integración para cerrar la verificación pendiente de #346? El plan sería coordinar primero con su autor y probar el recorrido completo publicar → recargar servidor → actualizar cliente, incluyendo un jugador sobre un tile recién bloqueado y la visibilidad exclusiva de versiones publicadas. En frontend/utils/gameLoader.ts, comprobaría loadMapData, mapRequestCache y mapValueCache con una carga en vuelo durante la publicación, para verificar que una respuesta antigua no restaure el mapa anterior. Las pruebas usarían una instancia local y datos sintéticos, con evidencia reproducible del resultado.

No he implementado ni reservado este trabajo. Antes de avanzar, ¿pueden confirmar si necesitan ese alcance, su importe y asignación, si la campaña todavía acepta contribuciones y el enlace oficial de la plataforma donde @Nabeel-javed debe registrarse para cobrar? La recompensa de la implementación existente no se da por compartida. Si #346 ya cubre todo, no abriré una PR duplicada.

[bilhokista]

Hello, I would like to apply for this issue.

I read api/schema.sql and server/src/socket.ts before writing, and I think part of this is already seeded in the schema, which changes how I would scope it.

game_map_tile_overrides has status TEXT DEFAULT 'draft' CHECK (status IN ('draft','published')), and status is part of the primary key (map_num, x, y, layer, status). That means a draft row and a published row for the same tile can coexist rather than overwrite each other. So publishing is not a new concept to invent — it is promoting the draft rows for a map into published rows, and the schema already allows both to exist during that transition. I would build on that rather than add a second publishing mechanism.

Scope as I would approach it:

• A publish endpoint per map that promotes draft rows to published in one transaction, so players never observe a half-applied map.
• Reload on the game server without restarting the process, following the hydration pattern already used for objects, NPCs, crafting, smelting and balance — the same shape as the startup logs "[GAME DATA] Objs hidratados desde DB: 1062. Version aplicada: 4875", but scoped to a single map rather than a full boot.
• Pushing the new version to players currently standing on that map through the existing socket layer in server/src/socket.ts, rather than introducing a new transport.
• Keeping draft and published strictly separated so an unpublished edit is never visible in game.

Two questions before I start, since they change the design:

1. When a map is republished while players are standing on it, do you want them to see the change applied in place, or to be re-sent the map so the client rebuilds it? The first is smoother but needs a tile-level diff sent over the socket; the second is simpler and more predictable.
2. Should publishing be all-or-nothing per map, or should it be possible to publish a subset of edits? All-or-nothing is what the current primary key makes natural, so that is what I would default to unless you want otherwise.

I understand this issue depends on the mutation issues upstream, so I am happy for it to be sequenced after those rather than started immediately. I have also applied to #3, which is the foundation this sits on.

I can have a PR ready within three days of the dependencies being in place.