v0.3.0 - Rc 1

If there are no reported problems with this version, this is probably the last rc before a full release.

Changes since Beta 2

(also see previous beta 2 and beta 1 for full 0.3.0 changelog)

• Refactored multithreaded communication and process shutdown system
• Added tray icon to injector as well
• Added tooltips to tray icon to see which tool is running
• Made our own custom win32 event loop and removed winit dependency
• Slightly decreased binary size by using a lighter cli arg parsing library (also removed the help and version flags since I doubt they're needed anyways; --cli will still spawn a cli window as usual)
• Fixed long-time bug with the injector where after starting it, the mouse showed a busy loading icon for a long time even though the process worked normally. This was because we didn't run the event loop on this tool - now we do

Full Changelog 0.2.6-b2: v0.2.6...v0.3.0b2
Full Changelog b1-b2: v0.3.0b1...v0.3.0b2
Full Changelog b2-rc1: v0.3.0b2...v0.3.0rc1

v0.3.0 - Beta 2

Changes since Beta 1

(also see previous beta 1 for full 0.3.0 changelog)

• Added better documentation on what loader.dll is and what to do with it; added as a text file asset distributed with the zip
• Properly set logging level in loader.dll by passing data to the thread. Fixes a weird issue where logging level was not properly set in release mode
• Fix weird issue in loader.dll with logs suddenly missing if target was set to false.
• Made logging clearer and better
• Added log level to config file to allow easily adjusting the level. No need to launch as cli or use an env var anymore to get trace level information
• Added warn popup to loader.dll if it was not loaded in support application. Reminder that loader.dll is not a native plugin and should not be used as such. It should stay bundled alongside the main exe files.
• If api call in patch check failed, sleep a little bit to let process catch up before retrying again. If it's still failing after a set timeout period, it's considered a hard error though. (Error in the sense that process injection is aborted; the program will continue working normally)
• Greatly improved all the warning messages to clearly state what's happening, and that you can press OK and the app continues normally.
• Lots of general misc fixes and improvements

Full Changelog 0.2.6-b2: v0.2.6...v0.3.0b2
Full Changelog b1-b2: v0.3.0b1...v0.3.0b2

v0.3.0 - Beta 1

Notes

This comes with a file loader.dll. No special setup is required. Just keep loader.dll in the same folder as the 2 exe's and everything will work. I have added notes on this in a text file in the zip for the next release to avoid confusion.

Changes

Did a massive refactoring of most of the codebase¹. Plugin loading logic was separated out into a separate loader dll to allow for more complicated logic which was not possible (or very very difficult) using the previous method.

• Faster plugin loading. Once the loader is injected, it does the work of the actual plugin loading at full speed from within the actual process.
• Also multi-threaded plugin loading to load plugins in parallel. Before this, they only loaded sequentially, so technically it could be slower.
• The loader now calls any exported Init fn so that any plugin developers can properly program their plugin.² (P.S. as a plugin dev, your init function can take as long as you want. Though at that point it's probably more recommended to just spawn your own thread so Init can finish in a timely manner)
• Additionally to the above, developer plugins can also detect when yabg3ml is running vs other mod loaders. This allows you to do things like not run Init code in DllMain, and instead let my mod loader call Init. Otherwise, if it's not mine, you can Init from DllMain to keep compatibility with other mod loaders. See the plugin template for how to do this.
• Note to plugin devs / mod loader makers: If you were using an old commit of native plugin lib, please update asap. There has been dev work on it and the previous metadata macro is incompatible with this version.
• native plugin template for plugin devs has been updated and improved. Check it out if you used a previous version.
• More robust dirty module check, which is accurate cause it checks windows file identifier.
• Improved process watching code.
• Use default config values if config is malformed. This will allow it to load if entries are missing, though note if you're doing default values it may load the wrong one since you haven't configured it. Also added popup if loading config failed so it's clearer what happened.
• Grant SE_DEBUG_NAME if running as admin just to ensure we get extra permissions. This will ensure the program succeeds if it didn't work in non-admin mode
• General stability improvements due to the refactor and testing.
• Various ux improvements to not crash but rather display a popup with better information
• Updated visual style of popups to look more modern.
• Many many many dependency updates and other misc fixes

Full Changelog: v0.2.6...v0.3.0

---

1. There were 49 changed files, 139 commits, and 3,479 additions and 1,242 deletions. ↩

2. Why? Because actually doing anything non-basic inside DllMain is a very bad idea. Deadlocks, UB (even silent UB), and a whole host of other nasty things can happen if you use DllMain for anything except simple tasks. An Init function is the proper way to do it, so now we support it! This is also reflected in some updates to the plugin template. Also, if you're a dev, the Rust signature is extern "C" fn Init(); if you use C, it is void __cdecl Init(void). See articles below.
   https://devblogs.microsoft.com/oldnewthing/20070904-00/?p=25283
   https://devblogs.microsoft.com/oldnewthing/20040128-00/?p=40853
   https://devblogs.microsoft.com/oldnewthing/20040127-00/?p=40873
   https://devblogs.microsoft.com/oldnewthing/20100115-00/?p=15253
   https://blog.barthe.ph/2009/07/30/no-stdlib-in-dllmai/
   https://learn.microsoft.com/en-us/windows/win32/dlls/dllmain?redirectedfrom=MSDN (see warning section)
   https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-best-practices ↩

v0.2.6

• Fix improper dirty check against <game_dir>/bin/NativeMods folder

Full Changelog: v0.2.5...v0.2.6

v0.2.5

What's Changed

• Tools now automatically detect root bg3 installation path if placed in <bg3_root>/bin or <bg3_root>/bin/subfolder (install_root will not require configuring in this case)
• Placed zipped files inside bin folder to allow installation via Vortex engine injector
• Dependency updates

Full Changelog: v0.2.4...v0.2.5

v0.2.4 - More robust error handling

• Even more robust error handling and better user facing messages in case something went wrong
• More possible sources of crashes eliminated, and in some cases error recovery is possible and handled transparently
• If winapi still failed to inject into process, user will get a nice popup message instead of a crash (you can just retry again)

Full Changelog: v0.2.3...v0.2.4

v0.2.3 - Crash fixes

• Fix invalid module handle in the process dirty check causing a crash #38
• Fix case insensitive disabled plugin comparisons a136fba

Full Changelog: v0.2.2...v0.2.3

v0.2.2 - Injection Detection

• Fix some more case sensitive comparison parts of file paths
• Add a bunch of traces + console mode with --cli flag to allow users to print trace output at any time (used for ease of back and forth debugging)
• Injection detection protects your game from accidents by intelligently aborting plugin injection if game instance has already been patched. This means that you can't accidentally inject plugins into a game instance that's already been injected into. If you added new plugins to your folder while you were playing the game, then you'll need to restart your game before you can reinject all the new plugins.

Full Changelog: v0.2.1...v0.2.2

v0.2.1 - Minor bugfix update

This is a minor bugfix release

- Config install_root folder path now uses case-insensitive comparisons
- Config install_root folder path now resolves to the target path

Full Changelog: v0.2.0...v0.2.1

v0.2.0 - Major update

Major rewrite

The entire codebase underwent a major rewrite, optimizing performance, user friendliness, and improving overall stability.

Debug profile problems are now a thing of the past

That's right! And that's because the previous mechanism of using launchers is now deprecated! A new, more efficient and reliable system takes its place.

Watcher Introduced

• A new watcher binary has been introduced to replace the deprecated launchers.
• The watcher binary runs in the background, seamlessly patching the game process whenever it starts.
• You can exit the watcher by going to the system tray, right clicking on the mod loader icon, and clicking "Quit"

Injector Tool for Non-Persistent Patching

• For users who prefer not to have a persistent program running in the background, the one-time-use injector tool remains available.
• When the injector tool is opened, it will either wait 10 seconds for the game to launch or, if the game is already running, it will promptly patch it. If 10 seconds have passed, then it will timeout with an error.

Steam and GoG are both compatible

This is because we are no longer acting as a launcher. It's easy to patch the game process, no matter what store you bought your game from. Just start your game up as you normally would do, and the tools take care of the rest!

---

Note: The tools probably won't see a process if it requires greater permission access than the user it was executed under. For example, if you started your game as admin, but the watcher only as your user. This is a limitation of the winapi. If you need to run your game as admin, then run the tool as admin also.

Full Changelog: v0.1.3...v0.2.0