Full rewrite of Hytale yolk with OAuth2 , no downloader and integrated backup system

[Xytronix]

Full rewrite of the yolk based on https://github.com/Xytronix/yolks/tree/hytale
required for pterodactyl/game-eggs#477

• Plan-based update system:
  • Flow: staged update → backup check → Maven version resolution → API download
• Patchline-aware server backups:
  • Configure SERVER_VERSION as latest, previous or a specific version to restore
• OAuth2 device flow for server authentication:
  • Single device-code auth upon startup, then refresh-token based reuse (~30 days)
  • Tokens exported as env vars for the server JAR
  • Session cleanup on exit
• Removed hytale-downloader binary — downloads go through the official endpoint directly
• Migration from previous images — migrates legacy layout to the new Server/ subdirectory
• Earlyplugins toggle — renames earlyplugins/ ↔ earlyplugins.disabled/ to work around the server loading the directory unconditionally
• QUIC UDP buffer warnings — warns at startup if rmem_max/wmem_max are below 2 MiB
• Hardened startup template:
  • Var placeholders resolved via envsubst
  • Proper signal forwarding (TERM, INT, HUP, QUIT) to the server process group
• Supports ARM without emulation due to direct API endpoints
• Faster startup — no downloader binary to boot

[WilliamVenner]

Good lord I'm sorry you had to write all of that in Bash.

I really don't think anyone would have an objection with installing a light scripting language of your choice to make that way more maintainable?

For example, Rust's game egg uses node for its wrapper script. Which does a hell lot less than this does 😆

[Xytronix]

Good lord I'm sorry you had to write all of that in Bash.

I really don't think anyone would have an objection with installing a light scripting language of your choice to make that way more maintainable?

For example, Rust's game egg uses node for its wrapper script. Which does a hell lot less than this does 😆

I implemented it in python, decreasing the yolk further would require stripping features such as the backup and migration logic. I do believe both of these are useful due to the game being unstable and there being no endpoint for receiving previous versions. I also fixed the aot logic, it appears they ship aot compiled for different JWK.

One update can break your server and without backups you can't go back to previous pre-release.

[WilliamVenner]

Great - could you describe what the backup/migration logic does? Are you sure it's something that the base pterodactyl yolk would be responsible for? It sounds like something that should be offered as a third-party yolk (which uses this one as a base) - people might already have similar systems implemented into their own panels (for example)

[Xytronix]

Migration Logic: moves files over to a new layout, makes the migration to the new image stress free.

Staged Updater: There is an ingame /update command, the plan update system takes this into consideration and stages files correctly (otherwise the game uses weird start scripts which aren't compatible and mocks when trying to update the server)

Backup System: only backups server files (assets.zip, server.jar and server.aot), the game backup system already handles world backups. Users can either use the current, the latest, the previous or a custom version they have saved. It will load whatever version is configured, the alternative would be doing a full backup via the Panel or downloading manually. In Minecraft you can download whatever version you want, here you can't and need to make backups. The game will be unstable for months until they establish a clear deprecation policy to avoid breaking mods, prior systems and worlds.

Auth System: Downloader and Session Management for the Server, including session cleanup. It checks whether an update is available as well if enabled.