Paper: ajustar visión y simulación sin perder funciones
Para ajustar las distancias de un servidor Paper, prueba view-distance y simulation-distance por separado. Conserva un cambio cuando mejore el problema medido y mantenga las actividades que necesita tu comunidad. No hay una pareja de valores válida para todos: el resultado útil es una configuración acordada, con pruebas y una forma de volver atrás.
Este procedimiento sirve a comunidades Java establecidas que encargan o revisan un ajuste de rendimiento. Es una propuesta de ensayo, no un benchmark. No hemos ejecutado pruebas de servidor para este artículo y los valores del ejemplo no son recomendaciones de capacidad.
Separa las dos decisiones
view-distance regula hasta dónde envía el servidor datos del mundo alrededor de los jugadores. simulation-distance afecta al alcance en el que se actualizan las entidades vivas cercanas. Ambas se expresan en chunks. Consulta su definición en la referencia de server.properties de Paper.
Que un lugar resulte visible no demuestra que todas sus mecánicas funcionen. Redacta el requisito real: un monumento debe verse desde la plataforma del evento, o una granja concreta debe funcionar desde su puesto habitual. Comprueba cada requisito directamente, sin deducirlo del nombre del ajuste.
Esta guía se centra en Paper. Un modpack con sus propias reglas de carga necesita un ensayo de capacidad con el pack real. No conviertas un resultado de Paper en una garantía para otro software de servidor.
Averigua qué configuración se aplica
Anota la versión de Minecraft, build de Paper, Java, lista de plugins y distancias actuales. Guarda los archivos originales. Revisa cada mundo relevante: no des por hecho que la configuración del mundo principal se utiliza en todos.
Paper documenta ajustes de distancia en world-settings, dentro de spigot.yml. Los valores default o -1 heredan de server.properties; las secciones de mundos concretos pueden sustituir los ajustes generales de mundos. Revisa la referencia de configuración de Spigot antes de editar e identifica los plugins que cambien distancias expresamente.
Pide a quien haga el trabajo una diferencia breve entre archivos y una explicación del origen del valor efectivo. Encontrar el número deseado en un archivo no basta si otro ajuste lo sustituye. Aplica cada candidato mediante un reinicio controlado del entorno de pruebas y registra la configuración resultante.
Define qué debe seguir funcionando
Acuerda las comprobaciones con el equipo de la comunidad antes de interpretar gráficas. Por ejemplo:
| Requisito | Prueba repetible | Evidencia que guardar |
|---|---|---|
| Visibilidad del evento | Situarse en el punto acordado con los mismos ajustes de cliente | Captura y confirmación de que se ve el decorado necesario |
| Granjas existentes | Utilizar una granja identificada desde su puesto habitual | Comportamiento observado durante el mismo intervalo |
| Desplazamientos | Recorrer la misma ruta al mismo ritmo | Aparición del terreno, pausas y observaciones de jugadores |
| Juego repartido | Colocar a los mismos participantes en las mismas bases separadas | Registro de actividad y mediciones del servidor |
Elige requisitos reales, sin intentar abarcar todas las mecánicas de Minecraft. Especifica mundo, coordenadas, funciones de los participantes y duración. Mantén los ajustes del cliente al comparar visibilidad. Si no podéis reproducir un problema comunicado, déjalo pendiente; no declares segura la configuración por falta de reproducción.
Compara cambios de forma controlada
Prepara una copia aislada del mundo y separa sus integraciones de producción. El ensayo de restauración de backups explica cómo establecer un punto de partida recuperable. Acuerda aparte la intervención antes de llevar cambios a la comunidad en producción.
Mantén máquina, límites de recursos, estado del mundo, plugins, participantes y guion de actividad. Separa arranque y calentamiento del intervalo medido. No aumentes memoria, cambies plugins y reduzcas distancias en una misma prueba: no podrías atribuir una mejora a una causa concreta.
Este ejemplo hipotético separa las variables:
| Prueba | Visión | Simulación | Pregunta |
|---|---|---|---|
| A | 10 | 8 | ¿Qué ocurre con la configuración inicial? |
| B | 8 | 8 | ¿Reducir la visión mejora el problema observado? |
| C | 10 | 6 | ¿Reducir la simulación ayuda sin perder funciones necesarias? |
Los números solo ilustran el diseño del ensayo. C parte de A, no de B. Si ambos cambios parecen útiles, prueba su combinación como otro candidato antes de aprobarla. Recupera un estado comparable del mundo entre pruebas, especialmente si la ruta genera terreno. Volver por una zona ya generada representa una carga distinta.
Mide el problema y el coste para el juego
Registra TPS, distribución de tiempos de tick, pausas, errores y comprobaciones de juego en cada ensayo. A 20 TPS, el presupuesto medio es de 50 ms por tick; una media puede ocultar picos. La explicación de TPS y MSPT de spark aporta el contexto. Ver TPS estables no sustituye la comprobación de la granja o de la visibilidad del evento.
Cuando reproduzcas el problema, captura un perfil durante esa actividad siguiendo las instrucciones de profiling de Paper. Guarda el intervalo y las notas de actividad. Una captura del servidor vacío no explica una pausa que solo aparece al viajar. Si la queja es que el terreno tarda en mostrarse, registra también ese síntoma: los tiempos de tick no describen toda la experiencia del cliente.
Repite la comparación relevante. Conserva pruebas fallidas e interrumpidas con sus motivos. Si la mejora es irregular, no anuncies un porcentaje de ganancia ni traduzcas una sesión favorable en una promesa de jugadores simultáneos.
Decide qué desplegar y qué entregar
Acepta un candidato cuando mejore de forma consistente el problema medido y supere las comprobaciones de juego acordadas. Recházalo o revísalo si la ganancia exige perder una función necesaria. Si ningún candidato resuelve el síntoma, utiliza el perfil para orientar la siguiente investigación, en vez de seguir bajando distancias a ciegas.
La entrega debe incluir archivos iniciales, cambios aprobados, versiones, escenarios, mediciones, límites pendientes y responsable de recuperar la configuración anterior. Programa una revisión con actividad representativa tras el despliegue. Recuperar los ajustes no deshace los cambios que se hayan producido en el mundo durante la prueba; por eso el ensayo se hace en una copia aislada.
Para encargar una revisión de infraestructura gestionada, aporta el síntoma, las actividades imprescindibles de tu comunidad y las evidencias disponibles. Mineando acuerda cada proyecto de pago individualmente. Incluye ajuste, verificación y entrega en el alcance; el soporte continuado se acuerda aparte.
