Summary:
Test Plan:
Summary:
Test Plan:
Summary:
Test Plan:
Summary:
Test Plan:
Summary:
Test Plan:
Summary:
Test Plan:
Summary:
Test Plan:
Summary:
Test Plan:
Summary:
Test Plan:
This solves the problem have requiring nested configuration for
several IO modules in bemanitools, e.g. com port configuration
for p3io.
Don’t make this a part of the specific IO API, e.g. iidxio, to keep the
IO interface clean and independent of bemanitools. Any bemanitools
functionality is composed as separate interfaces into a final module.
This concept was already applied to all modules with providing the
API vtables for threads, log and config.
There are several cases across configuration files where
optional values are reflected as values such as 0, -1 or empty
strings. Provide explicit means to handle optional configuration
values which can be easily reflected in the xml style configuraion
as empty nodes.
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).
Module to handle environment setup for hooks that use DllMain and
calls the bemanitools 6 API for hooks. This way, all hooks that use inject
(no AVS available) can be refactored and use the same API as any hooks that use launcher (with AVS available).
Remark: Module namespacing is not proper. This should move to a separate
part of the project that’s purely holding SDK related code that can be used
by other developers on other projects without requiring the whole
bemanitools project checkout. This problem is considered out of scope for now.
- Split into modules similar to launcher to improve overall structure
- Use property (node) API for configuration
Remark: "MVP" without IAT hooking working, command line arguments and overriding. Will be added (again) later
Add wrapper functions that fatal on any error.
Saves a lot of error checking code on occasions
where we want to fail anyway because some
configuration value could not be retrieved
successfully.
To provide a unified backend for all games, no
matter if they have AVS 2 available or now, use the
property (node) abstraction for any means of
configuration. This is somewhat annoying and a pain
because the property API isn't amazing. However,
the past has shown that having different means of
providing and handling (structured) configuration
data isn't great either.
Thus, have a non AVS implementation that allows
AVS independent applications/old games to use
the same core bemanitools API.
Summary:
Test Plan:
Summary:
Test Plan:
