Hice funcionar un servidor de Space Engineers en macOS. El bloqueo que todos citan no es el correcto.
Lo que todo el mundo responde, y por qué no da en el blanco
Quería jugar a Space Engineers con un amigo que juega en consola. Yo tengo un Mac. Cada respuesta que encontraba decía lo mismo: consíguete un PC con Windows, o alquila un servidor.
Ninguna de las dos me convencía, así que comprobé si la afirmación era cierta. No lo es. El servidor funciona en macOS, con un mundo con mods y un jugador de consola conectado.
Aquí está el método, y sobre todo las tres trampas que más tiempo me costaron.
El servidor no es el juego
Busca "Space Engineers en Mac" y encontrarás una avalancha de resultados explicando que el juego no funciona en macOS. Esos resultados son correctos, y responden a otra pregunta.
El servidor dedicado es un binario aparte, SpaceEngineersDedicated.exe, que se distribuye junto al cliente. No tiene motor de renderizado. Nunca abre una ventana, ni carga un shader, ni toca la GPU. Simula física, mantiene el estado del mundo y habla con los clientes por la red.
Toda la historia está en esa distinción. El cliente es difícil de portar porque es una aplicación DirectX 11 haciendo trabajo gráfico real. El servidor es una aplicación .NET sin interfaz haciendo cálculo. Bajo Wine, uno es un proyecto de investigación y el otro es una tarde.
Yo mismo perdí una hora con esta confusión. Había leído "el juego no funciona" y dejé de pensar.
Conseguir los archivos sin cuenta de Steam
No hace falta Windows para obtener los binarios, y tampoco hace falta una cuenta de Steam. SteamCMD tiene una versión nativa para macOS, y el servidor dedicado se descarga de forma anónima:
steamcmd +force_install_dir "$PWD/game" +login anonymous \
+app_update 298740 validate +quit
La app 298740 es el servidor dedicado. El +login anonymous no es un truco: así es como Valve publica los paquetes de servidor dedicado. Sin cuenta, sin licencia del juego en la máquina. Tus amigos sí necesitan tener el juego. El servidor no.
La trampa que se come la tarde: .NET Framework
El servidor apunta a .NET Framework 4.8. El consejo estándar, para cualquier aplicación .NET bajo Wine, es instalar el runtime real de Microsoft con winetricks dotnet48.
No lo hagas en Wine 11.
El instalador de .NET Framework 4.8 es un ejecutable de 32 bits. Wine 11 incorporó una capa WoW64 reescrita, la pasarela que ejecuta código Windows de 32 bits dentro de un proceso Wine de 64 bits. El instalador y esa capa nueva no se llevan bien. No falla. No da error. Se queda ahí, sujetando un bloqueo, indefinidamente.
La solución es no instalarlo en absoluto, y además es el comportamiento por defecto. Wine Mono, la implementación .NET del propio Wine, viene dentro del cask wine-stable y se instala sola al crear el prefijo:
export WINEPREFIX="$PWD/prefix"
wineboot --init
wineserver -w
Eso es todo. Wine Mono es de 64 bits, tarda segundos, y al servidor le da igual con qué implementación de .NET está hablando.
Un detalle convierte la tarde perdida en noche perdida. El verbo dotnet48 de winetricks borra Wine Mono lo primero, antes de instalar nada. Así que si pruebas esa vía y se bloquea, no vuelves al punto de partida: te quedas con un prefijo sin ningún runtime .NET, y un servidor que ahora falla por un motivo completamente distinto del que perseguías. Borra el prefijo y vuelve a crearlo.
El único componente de Microsoft que realmente necesitas es el redistribuible de Visual C++ 2015-2019 x64, que es un instalador de 64 bits y se porta bien.
El crossplay con consola, y su precio
Dos ajustes en la configuración del servidor:
<NetworkType>EOS</NetworkType>
<ConsoleCompatibility>true</ConsoleCompatibility>
EOS cambia el transporte de la red de Steam a Epic Online Services, que es lo que hablan los clientes de consola. ConsoleCompatibility restringe el mundo a lo que las consolas pueden soportar.
El precio son los mods. Con la compatibilidad de consola activada, el Workshop de Steam deja de estar disponible. Toda la lista de mods tiene que venir de mod.io, cuyo catálogo es más pequeño y con identificadores distintos para un mismo mod. Si tenías una colección de Workshop cuidadosamente montada, vas a rehacerla.
Calcula tú mismo el hash de la contraseña
La configuración no guarda la contraseña, guarda un hash, y el formato no está documentado en ningún sitio oficial. Varias webs se ofrecen a generarlo por ti.
No las uses: estás escribiendo una contraseña en el formulario de un desconocido.
El formato es estándar y cabe en diez líneas en local. PBKDF2 con HMAC-SHA1, 10000 iteraciones, clave de 20 bytes, sal aleatoria de 16 bytes, sal y clave concatenadas y luego codificadas en base64:
import base64, hashlib, os
def hash_contrasena(contrasena: str) -> str:
sal = os.urandom(16)
clave = hashlib.pbkdf2_hmac("sha1", contrasena.encode(), sal, 10000, 20)
return base64.b64encode(sal + clave).decode()
Tres lecciones sobre la vida de los procesos
Aquí es donde una instalación que funciona pasa a ser una instalación usable, y donde cometí todos los errores disponibles.
El servidor muere con la terminal. Evidente a posteriori. La solución es una sesión desacoplada con tmux, y a partir de ahí vive por su cuenta.
Que el Mac se duerma se lleva el servidor por delante. caffeinate resuelve eso, atado al PID del propio servidor para soltarse solo cuando este se detiene. Y cometí exactamente el mismo error otra vez: había escrito esa línea dentro del script de arranque, así que caffeinate era hijo del script, así que moría en el segundo en que el script terminaba. No había funcionado ni una sola vez desde que lo escribí. El arreglo es el mismo principio que con el servidor: desacoplarlo de verdad, con start_new_session=True.
Y cuando aun así se cayó, la culpa no era de la suspensión. El servidor se cayó dos veces la misma tarde. Acababa de escribir la protección contra la suspensión, así que pasé una hora demostrando que funcionaba. Funcionaba. El servidor seguía muriendo.
La causa real era un proceso de fondo sin ninguna relación, en la misma máquina, que tocaba la instalación. Lo que la ocultó fueron las marcas de tiempo: el servidor escribe en UTC, mi reloj es local, y dos horas de desfase bastaron para que la correlación nunca saltara a la vista. En cuanto llevé ambas al mismo huso horario, los eventos encajaron al segundo.
La lección va más allá de este juego. Cuando acabas de construir un arreglo para el problema X y X sigue ocurriendo, tu certeza sobre la causa es lo menos fiable de la sala. Normaliza todas tus marcas de tiempo antes de teorizar.
Una salvaguarda no lo es si algo la esquiva por defecto
El servidor dedicado de Space Engineers no tiene apagado limpio. Ni comando de "guardar y salir", ni señal que gestione correctamente. Matas el proceso, y todo lo construido desde el último guardado automático desaparece.
Por eso el script de parada se niega a ejecutarse si el último guardado es demasiado antiguo, salvo que pases un --force explícito.
Esa salvaguarda ya me salvó una vez, y cómo me salvó resulta instructivo. Tenía un panel de ajustes que paraba el servidor, escribía los cambios y volvía a arrancar. Para que fuera cómodo, hacía que llamara al script de parada con --force. Funcionaba perfectamente, descartaba en silencio un trozo de mundo sin guardar, y yo había construido justo el atajo que dejaba inútil mi propio control.
El arreglo no fue quitar la opción, sino obligar al humano a pedirla: forzar pasó a ser una casilla explícita en el panel, desmarcada por defecto, justo al lado de la antigüedad del último guardado. Conservas la salida de emergencia, simplemente ya no puedes tomarla por accidente.
Lo que realmente te aporta
Un servidor dedicado no existe para que dos personas puedan jugar juntas. Los jugadores de consola llevan años alojándose entre ellos.
Lo que aporta es lo que una sesión alojada en consola estructuralmente no puede hacer. Microsoft y Sony prohíben ejecutar scripts personalizados en consola, así que el bloque programable, el sistema de scripting de Space Engineers, no está disponible ni en un jugador ni en multijugador alojado en consola. En un servidor dedicado funciona, y los jugadores de consola lo obtienen al unirse. La restricción es sobre quién aloja, no sobre quién juega.
Además obtienes un mundo que sigue simulando cuando no hay nadie conectado, una lista de mods que controlas tú, y una treintena de ajustes modificables sin pasar por la tienda de nadie.
El código
He dejado todo esto limpio en un repositorio público: script de instalación, arranque y parada con la salvaguarda de guardado, un panel de ajustes local para los ajustes del mundo que si no obligan a editar XML a mano, y un README donde cada callejón sin salida está documentado en vez de omitido en silencio.
github.com/Stark-52/se-server-macos
Con licencia MIT. Si estabas buscando esto y solo encontrabas "consíguete un PC con Windows", espero que te ahorre la tarde que a mí me costó.