[dgibbs64]

Description

Adds Battlefront Eternal as a new server: bfeserver, shortname bfe. Battlefront Eternal is a GPL-3.0 engine for STAR WARS Battlefront (Classic, 2004), with a native headless Linux dedicated server that runs on Node.js. It is a new project and still in development preview, so expect its releases to change often.

Fixes #5112

Affected servers: bfe

Needs GameServerManagers/Game-Server-Configs#164 (the default config.json) merged first. Install downloads that file, and the Details Check job fetches it.

How it works

• Retail game (SteamCMD): every server prepares its game data from an owned copy of the 2004 game. appid is 1058020 with steamcmdforcewindows="yes" (the app only has a Windows depot), and steamuser must own the game, as with Running With Rifles. The ~2.8 GB game lands in serverfiles (GameData/). Nothing from the game is redistributed.
• Install and update (update_bfe.sh):
  • Reads SHA256SUMS from https://get.battlefronteternal.com/downloads/latest, the project's release feed, and picks the server-only archive for the machine (battlefront-eternal-server_<version>_linux-<amd64|arm64>.tar.xz, published since preview 327 at our request). The version comes from the file name (0.1.0~preview.327 today) and is stored in lgsm/data/<instance>-bfe-version for check-update and update. force-update works because appid is set.
  • Downloads the archive (about 117 MB), verifies its SHA256, and extracts it into serverfiles/bfe with fn_dl_extract: host-runtime/ (engine and server), tools/, toolchain/ (a bundled Python), bfe-tree.json and legal/. The desktop client is not downloaded.
  • Installs Node.js 24 into serverfiles/node from nodejs.org, checked against its published SHA256. The server needs Node 22.13 or later, which no supported distro ships (Debian 13 has 20). update and check-update check for a newer 24.x on every run, not only when a new release is out, so Node fixes land without waiting for a release. A Node-only update stops and starts the server like any update and sends the update alert. The new Node is extracted into node.new and only replaces node once it extracts, so a failed download or extract leaves the old one in place.
  • Prepares the game data with the release's own tools/prepare.py --core-only into serverfiles/bfe-data (about 2.2 GB, a few minutes). It is only prepared again when the release's tools or toolchain change: the key is a hash of their entries in bfe-tree.json, the same inputs the project's own updater uses. Preparation runs into bfe-data.new and replaces the old data only on success, and its log is log/script/<instance>-prepare.log.
  • update and check-update follow Battlefront Eternal releases. validate checks the retail game and leaves the server files alone.
• Config: config.json comes from Game-Server-Configs#164 and lives in serverfiles/bfe-state, the server's state directory (BFE_STATE_DIR), which also holds its identity key, operator token and stats database. New servers do not accept the project's online notice, so they are LAN or direct-connect only until the operator sets "onlineNoticeAccepted": true to list publicly. details reads the server name, max players, game port and LAN discovery port from it.
• Start: executabledir is serverfiles/node/bin and executable is ./node. preexecutable sets BFE_STATE_DIR, BFE_ENGINE_DIR, BFE_DATA_DIR and PORT with env, then node runs bfe/host-runtime/server/src/main.js --serve. A new healthport setting (default 18450) is the server's loopback health and admin port, so more than one instance can run on a machine.
• Ports and query: game port 18451 UDP, with the server's HTTP /info on TCP 18451, and LAN discovery on UDP 18452. gamedig has no protocol for this game, so monitor uses querymode 5 (TCP) on the game port. The port diagnostic command greps for MainThread, the name Node's main thread shows in ss.
• Stop: stopmode 2 (CTRL+c). The server shuts down on SIGINT.
• steamclient.so fix (shared, fix_steamcmd.sh): the sdk32 and sdk64 link steps now create the link only when SteamCMD's steamclient.so exists, and otherwise skip quietly. Battlefront Eternal updates from its own feed, so on a fresh install it reaches start before SteamCMD has ever run, and the old code printed "Could not copy any steamclient.so" twice. Steam games are unchanged: their SteamCMD files exist by the time they start, and the link is created as before.
• Dependencies: none beyond the base list. Minimum RAM 2 GB, the project's own production budget for one server.

Type of change

• Bug fix (a change which fixes an issue).
• New feature (a change which adds functionality).
• New Server (new server added).
• Refactor (restructures existing code).
• Chore (CI, workflows, tooling or other maintenance).
• Comment update (typo, spelling, explanation, examples, etc).

Testing

• Commands/tests run:
  • ./linuxgsm.sh bfeserver and auto-install from this branch, with a Steam account that owns the game. SteamCMD installed app 1058020, Node v24.22.2 and release 0.1.0~preview.323 were downloaded and passed their SHA256 checks, and the game data was prepared with no failed steps. The config.json download returns 404 until Game-Server-Configs#164 merges, so for the test that file was put in place by hand.
  • start: the server came up with /healthz reporting running and multiplayerReady: true, and /info answering on TCP 18451. ss shows UDP 18451 and 18452 on IPv4 and IPv6, TCP 18451, and TCP 18450 on loopback.
  • details: server name, max players and all three ports read from config.json, each listed as listening.
  • monitor: TCP query on 18451 OK.
  • check-update: "No update available" (0.1.0~preview.323 on both sides).
  • force-update while running: stopped the server (graceful CTRL+c in 2 s), downloaded and extracted the release, kept Node and the prepared game data, and started the server again.
  • Node update with no new release: with Node v24.0.0 in place and the latest release installed, check-update reported the release current and Node v24.0.0 to v24.22.2 available. update downloaded v24.22.2, passed its SHA256 check, replaced node, cleared tmp and sent the update alert. Running update again reported no Node.js update.
  • force-update with the stored data key changed: prepared the game data again and wrote the new key.
  • After switching to the server archive: update from 0.1.0~preview.326 to preview.327 on a running server stopped it gracefully, downloaded and verified the archive, extracted it, kept the prepared game data (the data key is unchanged, as the archive carries the same bfe-tree.json), and started the server again. /info answered from outside the host afterwards.
  • steamclient.so fix: with SteamCMD's steamclient.so absent, restart printed no steamclient lines and no FAIL. With it present, restart created both links (hardlink count 2). A further restart with the links in place did nothing.
  • validate: Steam validated app 1058020, and the bfe, bfe-data, bfe-state and node folders were untouched.
  • stop: graceful CTRL+c, no server process left.
  • serverlist-validate.sh and serverlist-validate-game-icons.sh pass. shellcheck is clean on the new and changed modules.
• Result: all of the above pass. Not tested: joining from the game client, an ARM64 host, and listing on the public master server (needs onlineNoticeAccepted).
• Environment used (distro/version): a clean gameservermanagers/linuxgsm:ubuntu-26.04 container on a test server.

Risk and rollback

• Risk level: low. All changes are new or limited to bfe branches in shared modules, apart from the steamclient.so step in fix_steamcmd.sh, which now skips instead of printing a failure when there is nothing to link.
• Rollback plan: revert this PR.

Breaking changes

• No breaking changes.
• Breaking changes included (describe below).

Documentation

• No documentation update required.
• User documentation update required (LinuxGSM-Docs).
• Developer documentation update required (LinuxGSM-Dev-Docs).

A Battlefront Eternal game server page (game ownership, game data preparation, the online notice) is still to be written.

Checklist

PR will not be merged until all steps are complete.

• This pull request links to an issue ("Fixes", or "Related to" for a partial fix).
• This pull request uses the develop branch as its base.
• This pull request subject follows the Conventional Commits standard.
• This code follows the style guidelines of this project.
• I have performed a self-review of my code.
• I have provided a detailed enough description of this PR.

Thank you for your Pull Request!