Skip to content

Onslaught CE V0.1.11

Choose a tag to compare

@dlprentice dlprentice released this 29 Oct 13:47

Getting 0.1.11

If you have 0.1.8, 0.1.9 or 0.1.10: start Onslaught CE as usual. It finds this update, checks its signature and asks you; say yes and
it installs 0.1.11 inside its own folder and restarts. Your careers and settings are kept, and running the launcher with --rollback
(how) takes you back to the version you had if you need it. (On Linux the update check needs the system curl.)

On Linux, the 0.1.8 and 0.1.9 launchers can crash before they ask anything when zenity is not installed and the 32-bit libXrandr
is missing: the dialog they fall back to calls into that library without checking that it is there. If yours closes at once, install
zenity (or your distribution's 32-bit libXrandr) and start it again, or set update_check=0 in ce.ini (in your user folder, ~/.local/share/onslaught-ce by default; --no-update-check or
BEA_NO_UPDATE_CHECK=1 does the same) and download 0.1.11 by hand as below. The 0.1.10 and 0.1.11 launchers check first, show their questions on the terminal when no dialog works, and otherwise never install
anything without your answer.

If you have 0.1.0 to 0.1.7: these cannot update themselves, so download 0.1.11 once by hand:

  1. Close Onslaught CE.
  2. Back up your careers and settings: copy the folder ~/.local/share/onslaught-ce (Linux) or %APPDATA%\Onslaught CE (Windows; paste that into the Explorer address bar) somewhere safe.
  3. Download the 0.1.11 package for your system below.
  4. Extract it into a new, empty folder.
  5. Run onslaught-ce (Linux) or onslaught-ce.exe (Windows) from the new folder. Your careers and settings are picked up automatically. Point your shortcut at the new folder.

Never run the old launcher again (why). From then on it updates itself.

New players: download the package for your system, extract it into a new empty folder and run it. You need your own PC
copy of Battle Engine Aquila (testing uses the Steam edition); no game files are included.

What's new

  • Mods (experimental, Linux). Onslaught CE can read replacement game files, such as textures, from mods in the mods folder of your user folder,
    and a mod can supply a level's world file. Every file is checked when the game starts against the mod's mod.json (size and SHA-256, no links, a file
    the game has or a world file); a mod with any problem is not loaded at all and the log says why. There is no mod menu yet. The checks cover where a
    file is and what its bytes are, not what a texture or archive does, so install mods only from people you trust. See the
    README.
    On Windows mods are not active in this release: a mods= line in ce.ini is ignored, the log says so, and nothing else changes.
  • Sharper text on wide screens. On a wide screen where the menus' and HUD's text is drawn at twice its original size or more (a 4K screen,
    for example), the game draws it from a sharper copy of its letters instead of stretching the original's soft pixels. The letters keep their
    shapes, sizes and places; the text looks sharper and brighter than the original's. A font's sharper copy is made the first time it is used,
    which can pause the game for about a tenth of a second. Off in recordings and replays, on 4:3 screens and when BEA_PORT_WIDESCREEN=0.
    What was looked at, on which system, and what was not, is under Validation and limits below.
  • A save that fails now says so. Saving from the pause menu's Continue or after a
    language change used to fail without a word (the failure went to the log). They now show the game's own save error message ("An error occurred
    during saving." in English, and in the language you chose): at the bottom of the screen for a few seconds in a level, and in the usual message
    box in the front end. The career you had is unchanged, as before. The game's other automatic saves of settings (leaving the Options page, after loading
    a career, a display reset) stay quiet. Never in recordings and replays.
  • A tape that cannot be started stops cleanly. BEA_PORT_TAPE naming a file that does not exist (or set
    together with BEA_PORT_RECORD, or BEA_PORT_PROBES naming a file that cannot be written) printed its message and then crashed on some graphics
    drivers (a segmentation fault, status 139); it now prints the message and exits with status 3. These are developer settings: ordinary play is unaffected.
  • Predicted aim, one more calculation matched to the original. The lead time of a weapon
    that aims ahead of its target sums the speed's squares in the original's order. The original sets predicted aim on exactly three weapon modes (the mech's two
    Vulcan cannons and its blaster) and no recorded check reaches them (measured: the tests that call the lead time ran 57,028 times in the nine recorded levels and
    199,095 times in 28 more levels that have original references, none with predicted aim set), so the change is by the original's instructions and the
    recorded checks cannot show it; they still equal the original on every compared row.
  • The Coming soon / ideas page says what this version does. Its mods, map tools and HUD entries now describe the current state: mods are experimental and work on Linux only, a level
    editor is being built outside the game (in the separate Onslaught Companion app), and text drawn at twice its size or more on a wide screen already uses a sharper copy of the font.

Gameplay is the faithful port as before. Keep a custom BEA_USER_DIR separate from the original game, and avoid editing
ce.ini while Onslaught CE or another settings tool is running: concurrent settings writes can overwrite one another.

Fixes

  • Two copies of the game saving the same career at the same moment. When two processes replaced one career
    at the same instant, the one that lost could be told "save failed" although the other had saved a complete career; nothing was lost. A save now waits
    for the other's rename (50 microseconds, doubling, 25.55 ms at most) before it looks the file up again. Measured with the repository's own test driver (several
    processes replacing one 8 KB career in a loop; every round left one complete career and no temporary file): without the wait, 0.41 % of the replaces failed with
    4 writers, 2.16 % with 8 and 3.23 % with 16 on tmpfs, and 0.083 % with 4 on btrfs; with the wait, none failed in 57,600 replaces for each of the three tmpfs
    counts and none in 9,600 on btrfs. An independent review's own runs of the same wait had none fail in 288,000 on tmpfs and 9,600 on btrfs. Zero in a
    count bounds the rate, it does not make it zero: a rename that takes longer than 25.55 ms is still refused, with the career intact and no temporary file
    left, and the save-failed message above shows.
  • Package text. The Windows notices name all three files that carry llvm-mingw's build paths (bea.exe, SDL3.dll, libz.dll), the packaged
    README.txt gives photo mode's limits as the README does and lists the optional Linux tools and libraries (curl, zenity, the 32-bit X11
    libraries), and the Windows text no longer speaks of "earlier" builds.

Downloads

Linux needs the documented 32-bit Vulkan driver and system libraries. The Windows executable is unsigned, so SmartScreen may warn you (More info, then Run anyway).

Validation and limits

  • Both packages were built twice from the public source and are byte-identical; a third clean build, made from a fresh clone of the public repository at the commit this release is tagged at, reproduces them byte for byte.
  • Gameplay matches the original game on every available reference row of the recorded checks for levels 100, 200, 221, 400, 512, 521, 611, 800 and 860 (RC-REPORT.txt gives the row counts, including the rows the original's reference does not have). A longer recorded session of level 100 (8,882 frames) also matches on every compared value. It does not compare pointer values (834,626 of them are listed as unverified in RC-REPORT.txt) or the full CPU floating-point state, and it excludes the unused padding words of 32 matrix fields in the battle engine's data (295,657 bytes, three more than in 0.1.10, all in the same padding words): some of those words differ even between two runs of the original game, and an independent reviewer accounted for every excluded byte. The Windows build was checked under Wine in an isolated sandbox on level 100, directly (to frame 3,000) and through the launcher (to frame 600). The sharper text, the mods code and the save-failed message are switched off in recorded runs, so these checks do not exercise them (the entries below say what was looked at instead); the predicted-aim change is in the code the recorded runs execute, on a branch none of them takes.
  • Mods on Windows (Windows 11 virtual machine, software rendering; level 100 run to frame 400): with no mod listed the log says nothing about mods. With a valid mod
    listed it says once that mods are off on Windows until mod path safety is validated, and nothing is loaded or replaced. With a hostile list (a folder junction that points
    outside, a missing id, an id with bad characters, twenty ids) it says the same single line, and object-access auditing in the guest showed no access by the game to anything
    under the mods folder or the folder the junction points at (the auditing saw the control read it was given, so it works). With BEA_PORT_CLOCK set the log gives the other line
    (the run is fenced: the listed mod is not loaded). Two mods= lines, and a user folder that does not exist yet, log nothing about mods and start as before. The battle
    engine's hull stayed blue in all 45 frames saved from each of the eight runs (a recoloured hull would be magenta, and a Linux run with the mod active shows it). Frames from two
    real-clock runs are not pixel-identical even for the same package (the heads-up display and small flyers follow real time), so the frames were not compared pixel for pixel.
    The ordinary runs on the same package, which list no mod (the normal launch, the shadow-overwrite case and photo mode), behaved as before. Mod activation itself was not tried
    on Windows: it is off in this release.
  • Sharper text. Linux (offscreen driver): the front end's list and title bar, the Coming soon dialog at 1080p and 4K and the live in-game radio text at 4K were looked at by the author of the change, at 1:1 against the same build without it: the glyph positions are equal, the edges crisp and the text looks brighter; an independent reviewer went through the change and its limits. The 640 x 480 front end, a 4:3 1920 x 1440 front end and the level-100 recorded tape draw the game's own texture, and the tape's 24 pictures are byte-identical to before. Windows 11 (virtual machine, software rendering): the release tester looked at the main menu, the Options page, the level-100 HUD and the pause menu at 1920 x 1080 and at 3840 x 2160 (whole frames, and the menus' text at native pixels): the letters are crisp and whole (no hollow, clipped or doubled glyphs), and at 1080p they are visibly crisper than in the control, the same screens with BEA_PORT_WIDESCREEN=0 (which lays the screen out differently, so only the softness of the letters was compared, not their places). The log says the font copies were made (512 x 512 in 47 ms and 256 x 256 in 32 to 47 ms at 1080p, in two boots; 47 ms and 15 ms at 4K; on a lightly loaded host) and, in the control, that none was. The Windows frames are the game's own back-buffer captures, not screen captures: the virtual machine's display (QEMU's standard VGA, 16 MiB) cannot show 4K, so the game, run in a window larger than the desktop, wrote each frame itself; they show what the game drew, not a 4K display, a graphics card or a driver. A device reset (Apply in Video Options, after changing VSync) was tried at 1080p: the log says the reset succeeded, no font copy was made again (the copies are kept through a reset and are rebuilt only for a new device), the text stayed crisp and the game carried on. A new device could not be made from the menus in the virtual machine (Screen mode offers one entry), so that rebuild was not exercised on Windows, and its Direct3D code has no automated test. Not seen: a real display, the text in motion, text at scales between 1.5 and 2 (it keeps the bilinear texture on purpose), and the first-use pause on real hardware (about 150 ms for the largest font, measured on the development machine).
  • Career saves, checked on the release packages. Linux: the real game was driven through New Game with a name that exists both in the original game's savegames folder and in the Onslaught CE folder. It asked once; Yes wrote the new career into the Onslaught CE folder (10,004 bytes) and left the original byte-identical, and No went back to the name screen with both files unchanged. Windows 11 (virtual machine, NTFS): the same route gave one question, the message "A new game has been created.", the new career in the Onslaught CE folder (10,004 bytes) and the original byte-identical; and the replace code ran natively against NTFS in 38 cases (new and existing names, writes that fail, stop short or read back wrong, a rename refused while another program holds the file and then released, the process killed at each of seven steps, a reader and a writer on the same career at once): each left the new career or the old one whole, never a partial file, and no temporary file listed. The Windows replace is unchanged in this release; those runs are the check that it still is. A failing write, a short write, a disk that fills, a failed read-back, a refused rename and a process killed between the temporary file and the rename each left the previous career byte-identical in unit tests (Linux, and the Windows code under Wine, which is not native Windows). Not exercised by a person: antivirus holding a career while it is saved, and a physical disk that fills or disappears.
  • A save that fails now says so, looked at on Windows 11 (virtual machine) and on Linux (offscreen), with the career file read-only. Windows: Continue from the pause menu showed "An error occurred during saving." at the bottom of the screen one and three seconds later and not nine seconds later, and the log said career was not saved: the file cannot be written (Windows error 5); the previous file is unchanged; changing the language showed the game's message box in French ("Une erreur est survenue pendant la sauvegarde.") in the front end until it was dismissed; with a writable career Continue showed nothing and wrote the file; a recorded session showed nothing; the read-only career was byte-identical throughout. Linux: the same routes drew the note and the message box (looked at), and their frames differ from those of a successful save only inside the box where the note or the message is drawn; with the Onslaught CE layer off, as in recorded and replayed runs, the failed save and the successful one give the same frame.
  • The tape stop. On Windows 11 (virtual machine) and on Linux, a tape that does not exist, a tape set together with a recording and a probe file that cannot be written each printed their message and exited with status 3: no crash dialog, Windows error report or Application-log event on Windows, and no core dump on Linux; the control run exited 0.
  • Moving from 0.1.10 and from 0.1.9 was tested on Linux (from 0.1.10) and on Windows 11 (from each, in a virtual machine, software rendering): with the old version's user folder and a real career save, 0.1.11 in a new folder found the game on its own and showed the careers in Load Game; on Linux it also took the game folder and the windowed setting from ce.ini. The save and ce.ini were byte-for-byte unchanged, and the old install and the folders, files, links and junctions beside it were untouched.
  • The update from 0.1.10, tested right after publishing, on Linux and on Windows 11 (in a virtual machine, online): the published 0.1.10 found this release's signed update, asked, and after Update downloaded it, checked its size and SHA-256 against the signed list and installed it beside 0.1.10; --version then showed 0.1.11 (build 65179f1), and --rollback returned to 0.1.10. The career save and ce.ini were unchanged throughout (on Windows byte-identical after the update and after the rollback), and the old install's files were untouched (on Linux the folders beside it too). Updating from 0.1.8 and 0.1.9 uses the same updater and signing key; it was not run against this release.
  • Offline, the launcher reaches nothing and installs nothing (Windows 11 network capture: no connection attempt and no traffic beyond DNS lookups, which get no answer offline; the firewall log has no row for the launcher or the game): --update-only reports that no feed was reached, and --apply is refused. A normal start with the update check on also looks up the feed's host (github.com), so such a lookup can appear in a capture; offline it goes unanswered.
  • Photo mode is unchanged since 0.1.10. On Windows it was tried again, only in a virtual machine with software rendering. On the release package, in level 100: F11 hid the cockpit and the HUD, F12 saved a 640 x 480 PNG without them or the on-screen note, and the second F11 brought everything back; the game then quit normally. It has not been seen on a physical Windows graphics card.
  • Bonus levels. On Windows 11 (virtual machine), Aquila Prototype, Defence A and Defence B each loaded and played, paused and quit back to the menu (the co-op levels in split screen, drawn with the virtual machine's software renderer, so their terrain colours there are not what a graphics card shows); the career save and ce.ini were byte-for-byte unchanged afterwards.
  • The Windows 11 and update runs above were separate from the release-candidate checks that RC-REPORT.txt lists. Controllers were tested with simulated devices, with no window on a screen.

Not tested: physical gamepads, flight sticks and rumble motors, physical AMD, NVIDIA or Intel graphics on Windows, other Linux distributions with these packages, and audible sound on a real device. RC-REPORT.txt also lists what its runs did not exercise (fullscreen and the Wayland-only window path, the folder-picker and message-box dialogs, opening a browser from Report a problem, session recording and the log file on Windows); the Windows 11 runs above looked at the Windows log file and the normal game exit, not at those.

If a problem occurs, choose Onslaught CE > Report a problem (or open an issue on the Issues page), say what happened and roughly when, and attach onslaught-ce.log from your CE user folder (details). Look the log over before sharing it.

Related work: Companion, Godot rebuild, decompilation, preservation documentation.