Esta guia esta escrita para que alguien pueda entender el proyecto sin haber vivido la conversacion original.
Crear una experiencia Minecraft modded privada donde el operador controla el servidor desde macOS y los amigos usan un launcher Windows portable.
- Operador: sabe abrir el panel, arrancar servidor y actualizar pack.
- Amigo: no sabe instalar Java, Forge ni mods; solo quiere pulsar jugar.
- Mantenedor: programador o IA que debe poder reconstruir, validar y publicar.
El servidor es Minecraft Forge 1.20.1. No se debe mezclar el mundo real con el repo. El mundo y logs son runtime, no codigo fuente.
El cliente es un launcher portable. Su contrato principal es no tocar .minecraft
del usuario. Todo vive en ScoobCodingClient/conf.
El payload contiene mods, configuraciones, assets, natives, Forge y lo necesario para abrir Minecraft. Es pesado, asi que GitHub debe llevar manifiestos y no necesariamente los binarios.
Minecraft 1.20.1 necesita Java 17. El launcher debe detectar Java o incluir runtime. Si se incluye runtime, debe estar dentro del payload o ser descargado/verificado con hash.
No uses toda la RAM del equipo. En portatiles de 6 GB, dar demasiada RAM al juego puede hacer que Windows se ahogue. Mejor elegir perfiles seguros:
- 6 GB totales: 2.5 GB aprox.
- 8 GB totales: 3 GB aprox.
- 12 GB totales: 4 GB aprox.
- 16 GB totales: 5 GB aprox.
- 24 GB o mas: 6 GB aprox.
El launcher puede detectar y recomendar GPU dedicada, pero Windows/NVIDIA decide la asignacion final. El check con RTX dedicada ya se cerro fisicamente: Cristo probo el launcher portable final en su portatil Windows con RTX y funciono perfecto, sin errores ni bugs reportados. Conserva igualmente la guia de forzar alto rendimiento para otros portatiles Windows que puedan elegir integrada.
Playit evita abrir puertos. El repo nunca debe contener la clave real del agente. La direccion publica puede cambiarse en build/payload.
Si online-mode=false, el servidor confia en nombres. Eso sirve para grupo privado,
pero no para abrir a desconocidos. No prometas seguridad publica sin autenticar.
Este proyecto dejo whitelist desactivada porque asi lo pidio el operador. Si otro entorno la necesita, activarla es una decision explicita, no automatica.
Las acciones del panel deben traducirse a comandos que Minecraft entienda. La
consola del servidor no usa / delante; el chat del jugador si.
Si se quiere /tp sin OP, debe existir soporte real por mod/config/permisos. La UI
no debe mentir: si el servidor no lo soporta, el boton debe avisar.
Servidor y cliente deben tener versiones compatibles. Un solo jar distinto puede
romper la conexion. Usa server/MODS.md y client/MODS_CLIENTE.md.
No publiques logs reales. Para debug, crea reportes filtrados que oculten rutas, IPs y datos personales.
El laboratorio debe probar lo automatizable: arranque, ping, comandos, TPS, hashes, payload y apagado. Windows RTX no debe simularse: se valida con hardware real, y el check de Cristo ya esta cerrado.
La UI debe ser simple: nombre, RAM, estado, boton jugar. El amigo no debe entender Forge para jugar.
Ideal futuro: payload incremental. Enviar 300 MB por cada cambio funciona, pero no escala.
Un certificado autofirmado ayuda a identificar builds locales, pero Windows solo confia plenamente en certificados de CA reconocidas.
Sube codigo, docs y manifiestos. Usa Releases para .exe, .zip, mods o payloads
grandes si tienes permisos/licencias para redistribuirlos.
No busques FPS maximo si rompe estabilidad. El objetivo es que el amigo entre y no se queje.
Windows 10 y 64-bit es el objetivo realista para Minecraft moderno. 32-bit no es un objetivo sano para packs grandes de Forge 1.20.1.
Cada build debe poder explicar: version de Minecraft, Forge, mods, config, runtime Java, direccion publica y hash de payload.
Todo experimento va en 03_laboratorio/ o lab/, nunca mezclado con runtime vivo.
No ocultes errores importantes. Convierte errores tecnicos en mensajes entendibles, pero deja logs reales para diagnostico.
No prometas "100% sin bugs" si no se ha probado fisicamente ese entorno. Promete solo lo que puedas demostrar con logs, capturas y pruebas repetibles.