Configuración de NeoForge: qué ajustes usa tu mundo
Si un modpack de NeoForge se comporta de forma distinta en el servidor del evento y en el ordenador de un participante, identifica primero quién controla el ajuste, qué tipo de configuración utiliza y qué archivo se aplica realmente. Tener los mismos JAR no demuestra que las reglas coincidan. Antes de aceptar la entrega, comprueba el comportamiento en una copia del mundo previsto, tanto con un cliente limpio como con una instalación ya utilizada.
Esta guía está pensada para responsables de comunidades y equipos que encargan un modpack o un mod a medida. Propone un ensayo de aceptación de la configuración; Mineando no ha ejecutado estas pruebas. El ejemplo es ficticio. El alcance son los ajustes que utilizan el sistema de configuración de NeoForge: los mods con sistemas propios requieren su documentación específica.
Empieza por la regla que debe experimentar el jugador
Describe un requisito observable antes de hablar de carpetas. Por ejemplo: «Durante el evento, el objeto de teletransporte encargado debe rechazar su uso mientras siga activo el tiempo de espera». Identifica la acción, la respuesta esperada y quién la aprobará. Una captura del editor de configuración no demuestra ese comportamiento.
Pide al responsable del pack que identifique el mod, su versión exacta, la clave, el valor válido y la documentación o el código que explica su efecto. Incluye las versiones de Minecraft y NeoForge. No deduzcas una clave a partir de otro mod parecido ni supongas que conserva su significado después de actualizar.
La lista de entrega de un modpack para eventos permite identificar el paquete. Añade un registro independiente de los ajustes que gobiernan las reglas esenciales. Así podrás comprobar por separado que se instaló la versión correcta y que se observó la respuesta prevista.
Determina qué lado controla el ajuste
La documentación de configuración de NeoForge distingue CLIENT, COMMON y SERVER: los ajustes del cliente son locales, los comunes no se sincronizan automáticamente y los del servidor se sincronizan con los clientes. Son tipos del framework; no garantizan que todos los mods los utilicen ni que archivos con el mismo nombre contengan valores iguales.
Para cada regla importante, pide al desarrollador que complete este registro:
| Campo | Información que necesita el operador |
|---|---|
| Comportamiento | Acción y resultado observable que se aceptarán. |
| Responsable | Mod y persona que mantienen el ajuste. |
| Origen | Ruta real, clave y tipo de configuración documentado. |
| Activación | Procedimiento de reinicio o recarga admitido para esa opción. |
| Evidencia | Forma de comprobar el valor efectivo y su comportamiento. |
Si no se puede identificar el origen, deja el caso pendiente. Copiar toda la carpeta de configuración del cliente al servidor no resuelve esa incertidumbre. Mantén las preferencias personales de imagen y controles fuera de los ajustes obligatorios del evento, salvo que exista una razón documentada para gestionarlas.
Revisa el mundo que se abrirá, además de la instalación
La referencia de NeoForge para 1.21–1.21.1 documenta las sustituciones de configuración SERVER por mundo mediante serverconfig. Por eso importa el mundo existente. Consulta la documentación de tu versión exacta y pide al responsable que confirme qué archivo tiene prioridad en esa instalación.
Haz un inventario del despliegue candidato y del mundo que se utilizará. Anota todas las copias relevantes del ajuste, su ubicación y su valor. Si la plantilla indica una cosa y el mundo desplegado otra, resuelve la diferencia de forma explícita. No borres el mundo ni su directorio de configuración para forzar un inicio limpio.
Investiga sobre una copia aislada. Conserva los archivos originales y un registro de cambios para poder volver al estado inicial. El ensayo de restauración cubre la recuperación del entorno; editar una configuración no constituye por sí solo un plan para recuperar los datos del mundo.
Ensaya una discrepancia deliberada
Imagina un mod de teletransporte encargado para un evento. El tiempo de espera acordado es de 30 segundos, mientras que una instalación antigua del participante conserva un valor local de 5 segundos. Son requisitos de ejemplo, no tiempos medidos ni valores recomendados para un mod existente.
Pide al desarrollador que explique dónde se toma la decisión definitiva y cómo la representa el cliente. Después, ensaya estos casos sin modificar otras variables:
- Arranca el servidor candidato con la copia del mundo prevista y la configuración documentada. Registra la versión y los archivos iniciales.
- Entra con un cliente limpio. Utiliza el objeto, vuelve a intentarlo durante la espera y comprueba la respuesta acordada.
- Repite con la configuración antigua del cliente. Anota por separado lo que muestra la interfaz y si el servidor acepta la acción.
- Desconecta y vuelve a entrar durante la espera. Comprueba la regla acordada para la reconexión, sin dar por hecho que el contador deba reiniciarse o conservarse.
- Aplica el procedimiento de reinicio documentado y repite los casos pertinentes. Confirma qué ajustes siguen siendo efectivos.
En este diseño propuesto, una indicación desactualizada no debe permitir saltarse una regla que aplica el servidor. Si la interfaz y la acción discrepan, registra ambas observaciones. La corrección podría afectar a la distribución de archivos, a la sincronización o al código del mod; el síntoma no demuestra por sí solo la causa.
Compara instalaciones nuevas y utilizadas
Prepara una matriz pequeña: cliente limpio y cliente existente, cada uno frente a un mundo de prueba nuevo y frente a una copia aislada del mundo del evento. Registra un resultado para cada combinación. Mantén las versiones del pack mientras investigas los ajustes; cambiar también los mods vuelve ambigua la comparación.
Si solo cambia el comportamiento en la copia del mundo del evento, revisa su configuración específica y el estado guardado pertinente. Si la diferencia aparece únicamente con el cliente existente, revisa sus ajustes conservados y su historial de actualización. Son líneas de investigación, no pruebas de que un archivo concreto sea el culpable. Cambia un único valor documentado, repite el caso y conserva las evidencias.
Si distribuyes un launcher a medida, la guía de aceptación de actualizaciones explica por qué los archivos del jugador necesitan una política explícita. Define el límite entre configuración obligatoria y preferencias personales. No soluciones una discrepancia aislada restableciendo silenciosamente todas las instalaciones.
Exige una entrega que otro operador pueda utilizar
Acepta este trabajo cuando otro operador pueda localizar los ajustes efectivos, aplicar el procedimiento documentado y reproducir las reglas esenciales. Guarda con la versión la identidad del mundo ensayado, los estados iniciales de los clientes, los cambios de archivos, los resultados y las excepciones pendientes. Marca como «no ejecutado» todo caso sin probar.
Esta comprobación no acredita capacidad de jugadores, compatibilidad con cualquier mod ni corrección de todas las mecánicas. Selecciona las reglas que pueden impedir el evento y amplía la cobertura cuando cambie la versión. Si hay formatos de configuración propios, acuerda también el trabajo necesario para verificarlos.
Para un proyecto de desarrollo de mods y modpacks a medida, trae las reglas necesarias, las versiones admitidas y este registro de aceptación. Mineando presupuesta los proyectos de pago según su alcance. El mantenimiento y la cobertura del evento se acuerdan por separado, incluida la persona que podrá aprobar cambios después del ensayo.
