Stores move to the world named "world" after a restart
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 3/5
- Tiempo estimado
- 1-2 días
- Aptitud para principiantes
- 68/100
Línea de trabajo
Start by reading CuboidSerializer, WorldSerializer, and the save/load path through Warehouse, then inspect the existing serialization tests. Reproduce the round trip with a world named custom_world and check how a missing world is handled. Done means the world survives save and load, missing worlds are logged without being saved as blank, and a test covers the round trip.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Problem
A store's world isn't restored when stores load. After a restart, every store with a location is placed in the world named world, whatever world it was created in.
data.shops saves the right world (world="custom_world"). CuboidSerializer passes the world node to WorldSerializer, which then reads node.node("location").getString("world"). That child doesn't exist, so the lookup falls back to its default, the literal string "world".
The effects depend on the server:
- Stores in the Nether, the End or custom worlds move to the overworld at the same coordinates.
- If the server has no world named
world, the location's world isnull, the store stops working, and the next save drops the world from the file.
Steps to reproduce
- Create a store in any world not named
world. - Restart the server.
- The store is now in
world, and it's no longer reachable where it was built.
Reproduced with a save and load through Warehouse: a store in custom_world loaded with the world world.
Done when
- A store keeps its world across a save and load.
- A store whose world is missing is reported in the log and isn't overwritten with a blank world on save.
- A test covers the round trip with a world not named
world.
- Lenguaje dominante
- Java
- Estrellas
- 1
- Forks
- 0
- Merge medio
- 2 h 35 min
- PR fusionados (30 d)
- 14
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de BrendonButler/Shops
-
dependencies enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
BrendonButler/Shops#79 ·
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
BrendonButler/Shops#70 ·
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
BrendonButler/Shops#69 ·
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 77/100
BrendonButler/Shops#68 ·
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 77/100
BrendonButler/Shops#67 ·
Los mantenedores suelen responder en 1 día
Todos los issues de BrendonButler/Shops
Issues similares
-
type: dependency-upgrade
Dificultad 2/5 1-3 horas Aptitud para principiantes 61/100
spring-projects/spring-graphql#1556 ·
-
hermes-queue
Dificultad 1/5 Menos de una hora Aptitud para principiantes 91/100
chrisalunlloyd2-sudo/mindpalace#373 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
Los mantenedores suelen responder en 1 día
-
bug priority: lowest
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
SkriptLang/Skript#8953 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
quality-assurance
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
Paul-Austin-Oswego-CSC480-HCI521/gift-app#228 ·
Los mantenedores suelen responder en 1 día