Summary:
Test Plan:
Read any configuration values through bemanitools's
configuration API abstraction. This still had to be
hooked up when a hook dll is being loaded. The
current implementation relies on an environment
variable providing the path to the original inject
configuration file, then it extracts the relevant hook
configuration section for the currently loaded hook
library.
This adheres to the limitations of not having any
other entry points than DllMain for a hook library
(as of now).
**THIS IS A HIGHLY WORK/DEVELOPMENT IN PROGRESS VERSION**
**THINGS ARE BROKEN AND EVERYTHING IS SUBJECT TO CHANGE**
First cut after massive refactoring with most critical and fundamental changes implemented.
We need to start somewhere, and this might be as good as anything else, so we can get started
with testing, bug fixing and iterating for the next releases.
The following list is non-exhaustive, does not guarantee anything does work, yet, and is supposed
to give a high level idea of what all of this is about. Updated documentation will reflect all of
this at some later point in time in more detail.
* A common "core" now abstracts logging, thread, property and configuration infrastructure and
provides a common interface. This is used by bemanitools internally as well as all tools, hooks
and APIs provided and don't depend on the game, version of the game or AVS version available
anymore
* New bemanitools (public) API
* Versioned API allowing for handling incremental API changes as well as breaking changes by
providing a new/different version when necessary
* Unified interfaces for bemanitools core API, i.e. logging, threads, configuration
* SDK with examples (TBD)
* Dogfooding approach: Bemanitools uses its own (public) API to implement and provide fundamental
features like configurable keyboard implementations for IO or hooks for different games and
versions
* All bemanitools hooks and IO libraries have been or are about to be re-worked to use the new APIs
* New hook API allows for more fine grained runtime control when stages of the hook are to be
executed, i.e. pre AVS, before main game, iat hooking instead of relying purely on DllMain
(which is still a compatible option though)
* launcher as a replacement for bootstrap: Bring it significantly closer to the original bootstrap
by supporting completely vanilla data and bootstrap.xml configurations to run the games. Note
that bemanitools does not include any code or means to run DRM'd data, only decrypted
* inject is also being reworked to use as much of the same "infrastructure" as launcher to provide
a more seamless bootstrapping process for games that keeps pre-eapki data as vanilla as possible
Summary:
Test Plan:
Summary:
Test Plan:
Summary:
Test Plan:
Summary:
Test Plan:
Apply a simple heuristic to provide the user with more
specific information regarding which vcredist package
might not have been found on their system.
This is a common problem as different games require
different versions and different versions of windows
and installations might already come with some versions
already pre-installed.
Also improve the readme regarding that and provide links
to all versions that are required by one game or another
today.
Because we are using mingw, we can't just use window's
dbghelp library as the symbols created are in dwarf format.
Fortunately, the dwarfstack library already provides all the
facilities to easily print very descriptive stacktraces,
including function names, file names and line numbers,
when dwarf symbols are available.
This moves the incomplete exception handling portion from
signal to a separate module as well to improve scoping.
Move everything to new launcher.xml configuration
files. Adjust the bootstrapping of launcher in the
.bat files. Features such as copying the default
props/ files to nvram are now handled by launcher.
Using the PATH variable, bemanitools binaries can
live in their own dedicated bemanitools/ subfolder
next to props/ and modules/ now. All original
binaries are expected to be kept in a modules/
folder like on stock data.
This adds edge cases to the existing logic that checks the
vertex UV values to fix stretched BG videos on 11 to 17
already.
However, 9 and 10 also show this issue on modern GPU
hardware though it does not appear on all BG videos but
only on videos from 1st to 3rd style songs.
This commit addresses that issue by adding the missing
checks to the existing logic. Additional refactoring of
configuration naming etc. to match the extended
functionality is included.
Using the right combination of "flags", this addresses the
SQ-INIT error on 10th style as well as forces 10 to 13 into
using the D01 operation mode. The latter follows the approach that
14+ is also using the best/latest IO type supported (IO2 in that
case). Expecting that gameplay experience benefits from more
optimized/better maintained code paths.
Make 10 operate in D01 IO mode which forces security to using
the D01 dongle from a D01 dedicab setup. The alternative would
be using a C02 dongle from a C02 upgraded cabinet.
More details to follow in another commit with a dev journal
entry.
Provide an option for non final lincle revisions and
if the "modern" monitor check is not delivering stable
results on the final lincle revision, e.g. using the
original "pendual lcd" monitor.
