Launcher de Minecraft: actualizar sin perder archivos del jugador
Antes de aceptar un launcher de Minecraft a medida, exige un ensayo de actualización sobre una instalación que ya contenga archivos del jugador. Interrumpe la descarga, introduce un archivo inválido y vuelve a intentarlo. La entrega debe conservar los datos locales acordados y dejar una versión identificable del modpack, sin mezclar silenciosamente archivos antiguos y nuevos.
Esta comprobación interesa a comunidades y equipos de eventos que encargan un launcher para utilizarlo de forma continuada. La instalación inicial puede funcionar y la siguiente actualización borrar ajustes o añadidos personales. Lo que sigue es una propuesta de requisitos para el encargo: no describe una implementación de Mineando probada ni un comportamiento común a todos los launchers.
Distingue el launcher del paquete que instala
Registra dos versiones: la aplicación del launcher y el modpack. Actualizar el programa que muestra el botón de descarga es una operación distinta de sustituir mods y configuraciones dentro de una instancia del juego. Cada una necesita plataformas admitidas, canal de distribución y procedimiento ante fallos.
Por ejemplo, si la aplicación utiliza Electron, su documentación de autoUpdater contempla actualizaciones de la aplicación en Windows y macOS; no incorpora soporte para Linux y exige firma para las actualizaciones automáticas en macOS. Eso no determina cómo se actualizan los archivos de Minecraft. Pide que el proveedor documente también ese mecanismo.
Parte de una entrega identificable del modpack. Después añade la pregunta que falta: ¿qué ocurre con una instalación que alguien lleva varias semanas utilizando?
Acuerda quién controla cada archivo
Antes de desarrollar, define tres grupos. Las rutas y comportamientos siguientes son ejemplos para el encargo, no reglas universales que Minecraft aplique por sí solo.
| Grupo de archivos | Política de actualización propuesta |
|---|---|
| Mods y configuración obligatoria gestionados por el paquete | Sustituir según la versión aprobada; retirar archivos antiguos solo si constan como gestionados. |
| Partidas, capturas y añadidos personales | Conservar e identificar conflictos sin borrar archivos del usuario en silencio. |
| Ajustes compartidos entre el paquete y el jugador | Acordar una migración por campos, un restablecimiento documentado o una resolución del conflicto. |
Evita pedir simplemente «que toda la carpeta quede igual que la descarga». Esa frase no distingue los archivos obsoletos del paquete del contenido personal. Conservar todos los JAR antiguos tampoco resuelve el problema: puede dejar juntas dos versiones de un mod. Exige un registro de los archivos instalados por la versión anterior y una respuesta definida cuando el usuario los haya modificado.
Incluye un ejemplo concreto en el encargo. La versión r4 elimina un mod gestionado y cambia la configuración del evento. La persona que prueba ha modificado una tecla y añadido una captura. Indica qué desaparece, qué cambia y qué debe conservar exactamente sus bytes. Si un mod personal no está admitido, el launcher puede explicar el conflicto y ofrecer una instancia limpia separada; no debería borrarlo sin avisar.
Comprueba las descargas antes de activarlas
La especificación de Modrinth para .mrpack define rutas y hashes de los archivos descargados y archivos de sustitución que se copian a la instancia. También advierte contra rutas que salgan de ella. Define un formato, pero no demuestra cómo se recupera un launcher tras un fallo.
Para el encargo, exige preparar las descargas aparte de la versión activa y contrastarlas con el registro de entrega de confianza antes de activarlas. Un hash incorrecto debe producir un fallo claro, no un mensaje de instalación completada. Que coincida identifica los bytes esperados; no demuestra por sí mismo que un editor desconocido sea fiable.
Incluye la extracción del archivo comprimido y los archivos de sustitución en la revisión. El proveedor debe demostrar que las rutas del paquete no escriben fuera de la instancia prevista, tampoco mediante enlaces del sistema de archivos. Pide pruebas controladas en un directorio desechable, sin utilizar archivos personales reales. Una barra de progreso completa no acredita estas comprobaciones.
Define cómo queda la instalación tras un corte
Escribe el resultado exigido antes de elegir la solución técnica. Si falla la descarga antes de activar la actualización, la versión completa anterior debe seguir intacta e identificable. La candidata incompleta no debe poder arrancarse como si estuviera terminada. Al abrir de nuevo el launcher, el usuario debe poder reintentar o cancelar por el procedimiento documentado.
Un corte durante la activación necesita otra prueba. Pregunta cómo se detecta un cambio incompleto y cómo se vuelve a un estado coherente. Pueden utilizarse directorios por versión, un registro de recuperación u otra solución; la aceptación depende de demostrar el comportamiento en los sistemas operativos y sistemas de archivos admitidos. Llamar «atómica» a una operación no prueba una actualización completa de varios archivos.
Exige impedir actualizaciones simultáneas sobre la misma instancia y aplazar los cambios mientras esa instancia esté ejecutándose. Acordad cómo informar de la falta de espacio o de un archivo bloqueado. La prueba debe revisar los archivos resultantes, no limitarse a comprobar que apareció un aviso.
Ensaya sobre una instancia ya utilizada
Prepara una copia desechable con datos representativos y registra el inventario inicial. Nunca interrumpas una instalación real de un participante para probar la recuperación. Ejecuta, al menos, estos casos por cada vía de instalación admitida:
- Actualización normal desde la versión anterior soportada: comprueba el inventario final y los datos conservados.
- Corte de conexión durante la descarga: abre otra vez el launcher y reintenta.
- Archivo preparado con un hash que no coincide: comprueba su rechazo antes de activarlo.
- Interrupción durante la activación con el método controlado del desarrollador: comprueba la recuperación al reiniciar.
- Espacio insuficiente y archivo que no puede sustituirse: verifica la respuesta acordada.
- Petición repetida de actualización e intento con el juego abierto: verifica que no se solapan operaciones incompatibles.
Anota versiones del launcher y del paquete, sistema operativo, estado inicial, resultado esperado, resultado observado y evidencias. Marca «sin ejecutar» lo que no se haya probado. Calculad el espacio necesario midiendo el paquete real, incluidos temporales y versiones conservadas; aquí no se propone ningún multiplicador universal.
Cierra la entrega con límites de recuperación claros
Guardar un paquete antiguo no demuestra que ese cliente pueda entrar en un servidor actualizado. Volver a los mods anteriores tampoco deshace los cambios escritos por una versión nueva en un mundo local. Define qué versiones siguen admitidas y separa recuperar el paquete de recuperar la partida. Comprueba esos límites antes de ofrecer un botón de «volver atrás».
La entrega debe incluir política de archivos, recorridos de actualización admitidos, pruebas de fallo ejecutadas, instrucciones de recuperación para el usuario y procedimiento para retirar una versión defectuosa. Los registros deben identificar la fase y la versión que fallan sin exponer tokens de autenticación ni rutas personales ajenas al problema.
Para encargar un launcher a medida, aporta los equipos admitidos, la política de actualización y los criterios de aceptación. Mineando presupuesta individualmente proyectos pagados. Si forma parte de un evento, acordad quién puede detener la distribución y quién ayuda a los participantes afectados; el mantenimiento y la cobertura en directo se pactan aparte.
