Report crashes for every player, not only those running under Wine's WINEDEBUG.
A last-chance UnhandledExceptionFilter is no good: faults on the message-pump /
WindowProcedure path have no game __except on their stack, and under Wine the
WndProc dispatch swallows them before they ever reach "unhandled". Install a
vectored handler instead -- it runs first-chance, ahead of every frame handler,
records the fault and returns EXCEPTION_CONTINUE_SEARCH, so normal SEH is
unaffected.
The dump is deliberately heap-free. The crash most worth reporting is often heap
corruption, so anything that allocates (the game Logger, std::vector, DbgHelp's
Sym* family) would fault again and take the report down with it. Using only stack
buffers and raw Win32, writeExceptionBacktrace writes the registers, the faulting
address, a UTC timestamp, the build id, the loaded-module table and a
bounds-checked manual EBP walk into a fresh numbered crash_report_NNN.txt.
The module table is what makes the addresses mean anything. Our executables are
linked /DYNAMICBASE and keep their .reloc section, so the loader is free to move
the image: Wine leaves it at the preferred base, Windows ASLR does not. A report
listing only runtime addresses is symbolizable by luck, and silently wrong once
the luck runs out. Recording where each image actually landed turns the offset
into arithmetic:
llvm-symbolizer --obj=JA2.exe --adjust-vma=$((<JA2.exe base> - 0x400000))
It is walked off the PEB loader list because both alternatives -- EnumProcessModules
and DbgHelp's module APIs -- allocate, and this path must not. Having the table
also frees the backtrace from restricting itself to our own module's return
addresses: a fault inside ddraw/fmod/bink is exactly the case worth seeing, and
an address belonging to no module is recognizable as the frame-pointer debris it
is.
Two things go into the report beside the machine state. czVersionString stamps
the build, so a report matches the exact PDB it has to be symbolized against, and
the optional HANDLE from Ja2 Settings names the player, so a report can be tied
to whoever raises it with us. The handle is sanitized where it is set rather than
where it is used: it is player input that lands in a line-oriented text report,
so anything that could forge a line (CR/LF, control and non-ASCII characters) is
dropped and the length is capped.
Finally the player is told. The message is composed in the handler, while the
fault details and the report's filename are still in hand, but shown from
SGPExit: first-chance means the exception may yet be handled downstream, and a
message box pumps messages, which on the heap that just faulted is a second
crash. It replaces the generic "Unhandled exception. Unable to recover." box
rather than adding to it -- it says more, and it names the file we need attached
to the bug report.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
JA2 v1.13
Preamble
Jagged Alliance 2 v1.13 is a modification for the Jagged Alliance 2 game.
Original development was done through SVN, this however ended abruptly in 2022, to keep the development going the step to Github has been made.
Feel free to participate in the development!
For more information you can visit the following locations:
- The Bear's Pit Forum
- Jagged Alliance 2 v1.13 - Starter Documentation
- How to get: latest 1.13, 7609, feature-descriptions and more
- JA2 v1.13 pbworks wiki (outdated)
- The Bear's Pit Discord
In case of any issues, look at Reports or Participation
Downloads
Note
All-in-one releases come for different languages and include JA2 v1.13, the Map Editor and JA2 Unfinished Business.
Visit the releases page to download the latest all-in-one.
Installation
-
Install the original Jagged Alliance 2
-
Download the latest all-in-one release and copy its content to JA2 game directory. Overwrite when asked.
-
Modify ini settings if you like.
-
Play the game.
Some additional information on can be found in folder "docs" inside download.
If you face issues with higher resolutions, alt+tab not working, blackscreen, etc.,
run the "cnc-ddraw-config.exe" in game-folder and adjust settings to your liking.
(those issues can occur due to the combination of old game and modern OS/hardware, cnc-ddraw helps to avoid those)
Visual Studio setup
- Run
Visual Studio 2019or newer. - Clone and open the location with the source code using one of these two options:
- Click
Clone a repository- Enter
git@github.com:1dot13/source.gitorhttps://github.com/1dot13/source.gitin the Repository location field, select the path you want to clone the repository to and clickClone. - Double-click on
Folder Viewin theSolution Explorer
- Enter
- Click
Open a local folder- Use this option if you already cloned the repository yourself.
- Click
- Visual Studio will automatically detect the CMake configuration files and will run the CMake generation. There will bet a CMake error in the logs saying
No existing preset was found, copied a preset template to [some_path]. This is normal and only happens once. - Click on the dropdown that says
x64-Debugand selectManage configurations.... This should trigger Visual Studio to load theCMakeUserPresets.jsonfile it just copied. Now you can close the window for managing the configurations. - The
x64-Debugoption should have been replaced by1dot13 Debug. Click it and selectManage configurations...again. Here is where you configure the language for the built executables as well as which ones to build, Most important, here is where you setCMAKE_RUNTIME_OUTPUT_DIRECTORYto the path to your JA2 1.13 installation. This will be used for debugging. Note that the path needs to have a working 1.13 installation, and that includes the 1.13 game data. - You can use
Build -> Build Allto build the executables you selected in the configuration.
Reports
For more information and reports, visit Bug reports at Bear's Pit Forum or join the Bear's Pit Discord
Participation
Feel free to participate on GitHub. If you want to know how, or simply wanna share your thoughts on a topic join the Bear's Pit Discord
