Fallout needs 64MB of XMS memory to load its ~500MB of data files.
DOSBox defaults to 16MB, causing a crash during loading after the
loading screen appears.
Also fixes a pre-existing bug in GameService.buildDosboxConfBytes()
and UploadResource.buildCdOnlyDosboxConf() where \n was used instead
of actual newline escapes, producing config files with literal 'backslash-n'
characters instead of real line breaks.
Cleans up all leftover code from previous fix attempts (fix-paths endpoint,
hardcoded CONFIG_PATH_FIXES map, etc.).
js-dos v8 uses the jsdos.json autoexec.script instead of the
dosbox.conf [autoexec] section. Without mount/imgmount in the jsdos.json
script, the CD image was never mounted — games loaded base data from C:
(bundle root) but crashed when trying to access CD-ROM content (videos,
audio).
Also removes the now-unnecessary fix-paths endpoint (both endpoint and
GameService implementation) since config path fixing is automatic during
upload via the game-agnostic scanner.
Iterable<Path> cast on dirStream::iterator method reference fails
in some Java environments. Stream.toList() (Java 16+) is cleaner
and guaranteed to compile.
Removes hardcoded CONFIG_PATH_FIXES map with Fallout-specific entries.
Replaces with generic scanner that:
- Scans all small text files (<100KB) for X:\... patterns
- Only processes C: drive paths (D:/E:/ left alone as CD-ROM refs)
- Uses case-insensitive filesystem checks to find what exists after flattening
- Progressively tries shorter path suffixes to find the stale prefix
- Rewrites C:\STALEDIR\ → .\ only when the leaf file/dir is found at root
- Works with both \ and / path separators
Also refactors the GameService fixBundleConfigPaths to build a ZIP entry
index and use the same logic for existing bundle patching.
The runner container can't access the compose file path on the host.
Use the compose file's parameters (network: dockernet, volume:
/mnt/cache/appdata/dostalgia) directly in docker run instead.
The Gitea Actions runner is a container; it can't see host paths.
The dostalgia compose dir is mounted inside the runner at /unraid/dostalgia,
so that's what the workflow must reference.
Uses docker compose -f /appdata/dockhand/stacks/unraid/dostalgia/compose.yaml
so the container matches the user's Unraid stack configuration (correct volume
mount at /mnt/cache/appdata/dostalgia, proper network, labels, etc.)
- Add both uppercase C: and lowercase c: variants to CONFIG_PATH_FIXES
- Add fixBundleConfigPaths() to GameService to patch existing bundles
- Add POST /api/games/{id}/fix-paths endpoint for existing games
Adds fixAbsoluteConfigPaths() which runs after flattening and cue fixing
during game upload. Detects known config files (FALLOUT.CFG, etc.) with
hardcoded C:\dir\ paths and rewrites them to .\ relative paths, so games
like Fallout can find their DAT files after flattening moves everything
to the bundle root.
Uses byte-level replacement to preserve original CRLF line endings and
encoding. Extensible via CONFIG_PATH_FIXES map — add new entries for
other games with the same problem.
G1HeapUncommitPercent is not available in this JRE build. The
MinHeapFreeRatio=10 and MaxHeapFreeRatio=20 flags are sufficient
to keep JVM committed heap from growing unbounded after uploads.
-XX:MinHeapFreeRatio=10 -XX:MaxHeapFreeRatio=20 -XX:G1HeapUncommitPercent=5
After large game uploads, the JVM committed heap stays high. These flags tell
G1GC to release free heap pages back to the OS after GC cycles, so Docker
memory usage drops back toward baseline instead of staying at peak.
Revert to commit 8108a66 (cue file fix + CD mounting fixes) and
apply only the Dockerfile JVM memory limit. All other changes
(StaticResource Range support, FileChannel transferTo) reverted.
CloneCD rips generate a .cue that references DOTT.bin but the actual
data file is DOTT.img. DOSBox fails to mount the CD when the referenced
file doesn't exist, causing 'Illegal command' for executables on the CD.
Now before bundle creation, we scan all .cue files and fix any FILE line
that points to a missing data file by rewriting it to reference .img
or .bin files actually present in the same directory.
Replace the broken descriptor-preference logic with a clean two-pass
approach: group images by parent directory, then pick the best format
per directory with priority .cue > .iso > .ccd > .img > .bin.
js-dos DOSBox's imgmount does NOT support .ccd (CloneCD descriptor)
natively, but .cue is widely supported. When both exist, .cue wins.
When only .ccd exists, it falls back to mounting the .img directly.
DOSBox's imgmount works best with descriptors because they contain track layout
info (audio tracks, subchannel data, copy protection). Raw .img/.bin mounts
lose this info, making the filesystem inaccessible and causing 'Illegal command'
when trying to run executables from the CD.
The bug: seenDirs.add(parentDir) was called BEFORE the descriptor-skip
check. When .ccd was processed first, it marked cd/ as seen even
though it was skipped. Then .img was skipped because cd/ was already
'seen', leaving zero imgmount lines.
Fix: use seenDirs.contains(parentDir) for the continue check, and
call seenDirs.add(parentDir) only after passing all checks, right
before the actual imgmount output.
CD-only games were failing because the second findCdImages() call
inside createBundle returned empty. Now detection happens once in
the upload method and the result is passed to createBundle.
CloneCD (.ccd) and cue sheets (.cue) contain internal FILE references
that may not match the actual filename on disk (case mismatch).
When a data format (.img, .iso, .bin) exists in the same directory,
it's mounted directly instead of the descriptor.
When no .exe/.com/.bat files are found but CD images are present,
the upload no longer fails. Instead it creates a CD-only game where
the autoexec mounts the CD-ROM image(s) and presents a DOS prompt
with instructions for the user.
- findMainExe returning null + CD images exist = CD-only game
- createBundle handles null exePath (generates CD-only config)
- New buildCdOnlyDosboxConf / buildCdOnlyJsdosJson methods
- Upload metadata handles null executable gracefully (empty string)
- Platform defaults to 'dos' when no executable to inspect
Since GameService now preserves CD images when regenerating configs,
the dedup logic is safe to re-add. Deduplicates by parent directory
so a .bin and .cue from the same folder only produce one imgmount.
Alphabetical sort ensures .bin (b) is mounted before .cue (c).
GameService.buildDosboxConfBytes() was rebuilding dosbox.conf with
only the executable path — CD image mount lines were lost.
- Added findCdImagesInBundle() to scan a .jsdos ZIP for CD images
- buildDosboxConfBytes() now accepts List<String> cdImages and
generates imgmount lines (same logic as UploadResource)
- Both setExecutable() and streamSetupBundle() now scan for
and include CD images when regenerating config
Removed the directory-level dedup and .bin-over-.cue preference
logic — it was causing imgmount lines to disappear entirely.
Now mounts every detected CD image (.iso/.cue/.img/.ccd/.bin)
with appropriate flags (.bin gets -fs iso for direct fs access).
.cue files contain an internal FILE reference (e.g. FILE "z.BIN")
that may not match the actual filename on disk (e.g. z.bin) due to
case differences. In js-dos's case-sensitive WASM filesystem, this
causes the imgmount to fail silently.
Changes:
- Added .bin to CD_EXT so findCdImages detects bin files
- When both .cue and .bin exist in the same directory, only the
.bin is mounted (with -fs iso flag for direct filesystem access)
- .cue files without a matching .bin are still mounted as before
- Deduplication prevents mounting both .cue and .bin from same dir
- Removed .iso, .cue, .img, .ccd from SKIP_EXT (they're now kept in bundles)
- Added CD_EXT set and findCdImages() method to detect mountable images
- buildDosboxConf() now generates imgmount D:/E:/… commands for each CD image
- Only .nrg, .mdf, .mds, .sub, .dmg are still stripped (unsupported formats)
Games with CD images will now work out of the box — DOSBox presents
them as CD-ROM drives and the game can find its disc.
Handles common Sierra game file layout issues:
- RESOURCE.CFG with directory paths pointing to \KQ6CD when
resources are actually at the bundle root (fixes paths to '.')
- INTERP.ERR/INTERP.ERRC files buried in subdirectories instead
of at root (copies them up so SIERRA.EXE can find them)
POST /api/games/{id}/patch-sierra triggers the fix on an existing
game bundle.
bundleFile changed from 'wolf3d.jsdos' to 'wolf3d/wolf3d.jsdos' when
bundles moved inside game directories. resolveSibling(bundleFile + '.tmp')
produced a wrong nested path. Now uses bundlePath.getFileName() to get
just the filename part before appending .tmp.
When a game ZIP is selected and IGDB returns no matches, the search
box is now pre-filled with the filename (minus .zip extension) so
the user can edit it rather than typing from scratch.
Setting body { width: 100vw; overflow-x: hidden; } means the body is
always the full viewport width regardless of scrollbar presence.
margin: 0 auto centers content within the body, which doesn't
change width when a vertical scrollbar appears — so the content
stays in place.
html { overflow-x: hidden; } clips any body overflow past the
viewport (body is 100vw while html content area shrinks with
scrollbar). No gutter discoloration since there's no gutter
reservation — the scrollbar appears naturally on the html element.
Replaces overflow-y: scroll with scrollbar-gutter: stable on html.
This reserves the scrollbar gutter space in the layout at all times,
so the content width never changes when a scrollbar appears/disappears.
The scrollbar itself only shows when content overflows (as desired).
Works on all modern browsers (Chrome 94+, Firefox 97+, Safari 15.4+).
Add overflow-y: scroll to body so the scrollbar is always present,
preventing the ~15px layout shift when a page exceeds viewport height
(e.g., games with long descriptions). Also add overflow-x: hidden to
guard against any horizontal overflow breaking the layout.
Before: data/games/{id}.jsdos (flat, alongside the game dir)
After: data/games/{id}/{id}.jsdos (inside the game directory)
Benefits:
- Delete is atomic — removing the game dir removes everything
- Cleaner data directory structure
- No orphan .jsdos files on delete
Also updated frontend bundleUrl() to use game.bundle_file from
the backend, making it path-agnostic. Old flat layout is still
served via StaticResource for backward compat.
replace('\', '/') is Java source for a char literal representing
a single backslash character. The previous commit had a single
backslash byte between quotes which made Java interpret it as
\\' (escaped single-quote) causing unclosed char literal errors.
- Add streamSetupBundle() to GameService — reads main bundle as zip,
replaces config files (.jsdos/dosbox.conf, .jsdos/jsdos.json) with
setup variants pointing to SETUP.EXE, streams directly to response
- Add GET /api/games/{id}/setup-bundle endpoint that calls the above
- Remove .setup.jsdos disk creation during upload — setupExe is still
detected and stored in game metadata, but no duplicate bundle is saved
- Update frontend api.js to point setupBundleUrl() to the new endpoint
- Fix pre-existing backslash escaping bug in UploadResource.java path
normalization (replace('\', '/') instead of replace('\\', '/'))
- Fixed: navigating back to library no longer re-opens file dialog
(prev-value guard in uploadTriggered effect)
- Added bundleSize field to Game, populated at load time from .jsdos file
- Game detail page shows file size next to DOS badge (e.g. 'DOS · 127 MB')
- Added 'executables' (full list) and 'executable' (selected) fields to Game
- Upload now stores ALL discoverable .exe/.com/.bat files in game metadata
- Added setExecutable() to GameService that patches the .jsdos bundle
(updates dosbox.conf + jsdos.json inside the ZIP) when changing executable
- GameResource PATCH handler delegates executable changes to bundle patching
- GameDetail edit mode shows a radio-button picker of all executables
- Heuristics remain as first-guess default, user can always override
- No re-upload needed to fix wrong executable selection
When the main executable is in a subdirectory but DOS4GW.EXE (or other
DOS extender) is at the ZIP root, DOS/4GW fails with 'No such file or
directory' because it only searches the current directory and PATH.
Adding 'path=c:\' before the 'cd' command ensures root-level DOS
extenders are always findable regardless of where the game EXE lives.
- Added 'sfx' and 'makesfx' to SKIP_EXE_NAMES
- Increased self-extractor detection buffer to 32KB
- Fixed false-positive risk: PK signatures only checked after offset 0x40
using proper signature comparison (not sequential byte matching)
- Fixed setupExe metadata: only set when setup bundle was actually created,
preventing phantom Setup button when setup exe is Windows