- C++ 91.1%
- CMake 8.9%
* lib: preserve MxDSSelectAction list extension through Read/Write
MxDSSelectAction child lists ('Act_'/'RAND') replace the regular list
count with a null-terminated selector string (e.g. "RANDOM_3"), the
actual count, and one null-terminated value string per child. Read
previously consumed this extension only for the description stream
(assuming single-character values) and Write always emitted a bare
child count, corrupting select actions in rewritten files.
Retain the raw extension bytes on the object and re-emit them verbatim
on write. Verified byte-exact roundtrip of the extension on the four
retail SI files that use it (COPTER.SI, DUNECAR.SI, JETSKI.SI,
RACECAR.SI).
* lib: fix buffer-boundary corruption when rewritten objects change size
Three defects conspired to corrupt rewritten SI files once object sizes
changed from the source file (any replacement shifts every downstream
chunk):
- Object::CalculateMaximumDiskSize did not account for RIFF odd-size
padding of nested chunks, so the pre-MxSt padding projection could
undershoot the actual object tree by one byte per odd-sized chunk.
- The projection did not include the MxDa LIST header that follows the
object tree, so that header could land within the last bytes of a
buffer, where both the game and Interleaf::Read skip it (chunks must
not straddle buffer boundaries), desyncing the entire parse.
- WritePadding silently no-ops for gaps smaller than a pad_ chunk;
WritePaddingIfNecessary now fills such gaps with zeroes instead.
Also preserve the MxOf object count field through Read/Write instead of
rewriting it with the top-level slot count (retail files store the total
object count there; e.g. ISLE.SI says 3708 while having 1186 slots).
* ci: pass an absolute FFMPEG_ROOT on Windows
The runner image's newer CMake resolves the relative root against the
app/ subdirectory when find_package(FFMPEG) runs, so configuration
fails with the include paths reported under app/. Resolve the path in
the workflow instead of relying on version-specific behavior.
|
||
|---|---|---|
| .github/workflows | ||
| app | ||
| cmake | ||
| include/libweaver | ||
| lib | ||
| packaging | ||
| .gitattributes | ||
| .gitignore | ||
| CMakeLists.txt | ||
| LICENSE | ||
| README.md | ||
SIEdit
SIEdit is a fully graphical viewer and editor of the SI streaming asset pack format used by LEGO Island. It can view, extract, and replace data in all of the game's SI files, allowing textures, sounds, animations, path information, FMVs, and even some game logic/metadata to be modified. It is currently still under development, but should work with all files.
libweaver
All of the SI-specific code is contained in a separate C++ library called libweaver, enabling other projects to re-use the discoveries here and work with SI files too. Currently there is no documentation or stable API, however it should be fairly straightforward, and I plan to add those things in the future.
Building
SIEdit and libweaver use the fairly standard CMake build system.
SIEdit requires Qt 6+ and FFmpeg for the UI and media playback respectively.
libweaver uses only standard libraries from C++98, and shouldn't require anything special.
Future
Here's a non-exhaustive list of things I'd like to add in the future:
- Auto-conversion/conforming when replacing files. Right now, when you replace files, you have to manually convert them into the right format before doing so (e.g. 256-color bitmap with specific paletting, Smacker 2, FLIC, WAV, et al.) It would be nice if SIEdit did this automatically.
- Stable API for libweaver. The library is fairly usable as-is, but it isn't the cleanest thing in the world right now, and I'd like for other people to be able to use it with as little headache as possible. This is my first time providing a library for use in other projects so I also may have made some mistakes.
- Ability to create SI files from scratch. Currently any changes made must use an existing SI as a base. It would be interesting to be able to load completely custom SIs into the game. This may require some more reverse engineering, though I think we have most of the work down.
- As a corollary from this, also the ability to add/delete objects, as opposed to just replacing what already exists.
- More packaging options. Currently we only provide a Windows build, which is ironic since I'm not even a Windows user. We may add a build for macOS and an AppImage for Linux, and I might try setting up a package on the AUR since I use Arch (btw)
