WIP: feat: bemanitools 6, wip (TBD needs splitting and reviewing) #305

Draft
icex2 wants to merge 90 commits from bemanitools-6-alpha into master
icex2 commented 2024-06-12 19:40:17 +03:00 (Migrated from github.com)

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
**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
mon commented 2024-08-15 07:02:03 +03:00 (Migrated from github.com)

Unsorted thoughts, mostly based around "hey this is a new major version, so maybe we should do some other big semver things"

  • #260 is a big breaking change, might be nice to bring it in for a 6.0
  • I've never liked how similar our library names such as aciomgr.dll, geninput.dll and eamio.dll are when placed next to the other game DLLs. My opinionated suggestion here is to prefix all shipped bemanitools DLLs and files with bt- so it's both blindingly obvious and lexicographically grouped separately.
  • Thoughts on meson? I could spearhead this, but at the same time I don't really mind the current build system because it's small in scope.

Other extremely early thoughts on the changes made so far:

  • Versioned API is very very nice, as long as we maintain backwards compat (i.e. "version 0")
  • Launch XMLs look good so far, I haven't done a deep dive yet. I like how using them avoids colliding with commandline args. I already imagine people (myself) asking for the ability to layer them (base config, then certain combos of hooks).
  • Making inject less janky will be great too, it never felt like a first-class citizen
Unsorted thoughts, mostly based around "hey this is a new major version, so maybe we should do some other big semver things" - #260 is a big breaking change, might be nice to bring it in for a 6.0 - I've never liked how similar our library names such as `aciomgr.dll`, `geninput.dll` and `eamio.dll` are when placed next to the other game DLLs. My opinionated suggestion here is to prefix *all* shipped bemanitools DLLs and files with `bt-` so it's both blindingly obvious and lexicographically grouped separately. - Thoughts on meson? I could spearhead this, but at the same time I don't really mind the current build system because it's small in scope. Other extremely early thoughts on the changes made so far: - Versioned API is very very nice, as long as we maintain backwards compat (i.e. "version 0") - Launch XMLs look good so far, I haven't done a deep dive yet. I like how using them avoids colliding with commandline args. I already imagine people (myself) asking for the ability to layer them (base config, then certain combos of hooks). - Making inject less janky will be great too, it never felt like a first-class citizen
This pull request has changes conflicting with the target branch.
  • GNUmakefile
  • Module.mk
  • src/main/iidxhook9/Module.mk
  • src/main/iidxhook9/dllmain.c
This pull request is marked as a work in progress.
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u origin bemanitools-6-alpha:bemanitools-6-alpha
git checkout bemanitools-6-alpha
Sign in to join this conversation.