Alternative, no human intervention injection mechanism. (Supporting Steam Overlay on Non-Steam Games)

[cheatfreak47]

Games launched through pseudo-launchers don't seem to allow Steam overlay to attach, might be worth a look into sometime, especially after #14 is implemented. Lot of people like the Steam Overlay for Big Picture mode.

[Sewer56]

Problem

Reloaded does not currently possess a mechanism that allows for auto-injection without human intervention to a target processes that leaves the target executable untouched (including renaming/Pseudo-Launcher).

This may impact certain applications that don't detect 3rd party application launches automatically and require you to launch the 3rd party application from their client to perform actions on the launched executables directly; such as injecting an overlay.

Specific Use Cases

Steam

If you want to use the Steam Overlay on a non-Steam game, you need to add it as a "non-Steam game" from within the client and launch the target application from Steam.

After launching, Steam then tries to find a known graphics API within the process it launched and inject the Steam overlay into it.

However, if the launched executable isn't the true game executable (e.g. Pseudo-Launcher, or game's own launcher), the overlay will never show up in the intended process.

Note: This does NOT affect Steam games; games using the Steam API; only old non-Steam games or games from another supplier, e.g. Origin, uPlay launched via Steam.

Current Workarounds

Attach/Auto-Attach

The current existing workarounds for this problem are the "Attach/Auto-Attach" features; however it requires; human intervention. The person needs to specifically CTRL+Click "Launch" in the launcher and either hit "Attach" after the target game has already been launched or "Auto-Attach", and then launch the game.

This is unoptimal. Think of someone sitting in a couch wanting to run an old/non-Steam game with the overlay and mods using the Steam Big Picture. The last thing you want is for them to stand up, get their mouse, hit Auto-Attach in Reloaded and then go back to Big Picture and load the game.

The Goal

Optimally, there should be some way to set up Reloaded in the future, an alternative to the Pseudo-Launcher that performs the same task; loads Reloaded in a foreign process without user intervention, but without touching the target executable.

[Sewer56]

Proposal A

Auto Auto-Attach

(Probably needs to be renamed to "Super Auto-Attach", or similar)

An instance of Reloaded sits idle in Windows' task tray, if it detects a game registered under it has been launched and tries to attach to it automatically without any user intervention.

Advantages

• In practice mods inject, initialize and execute earlier in the game's boot-up process than with DLL Hijacking (but still not before the game executes any instruction; as with regular launch via Reloaded-Launcher :/).

Disadvantages

• Requires that the Mod Loader is running in the background (would probably need a toggle to "Start Reloaded with Windows" somewhere).

• The time during which Reloaded is injected is not guaranteed unlike Standard (before target process executes anything) or DLL Hijacking (game's bootup process) but as noted in Advantages is still in practice earlier.

Other Notes

• To ensure that Reloaded injects mods as early as possible into the target process, additional research/improvements to libReloaded current threading code will be necessary for more safe process level suspend-resume (WITHOUT AFFECTING MOD DLLs). This is however already planned for Reloaded 3.

• I prefer this one personally over "Proposal B".

[Sewer56]

Proposal B

DLL Hijacking

The classic way of mod loaders that Reloaded chose not to follow in favour of the DLL Injection.

The user, or Reloaded instead drop a "fake" DLL such as dinput.dll into the application directory; when the application tries to load the DLL as part of its startup process; our "fake" DLL initializes, and then just continues passing on functions to the real DLL.

Advantages

• Requires for no programs to run in the background.

Disadvantages

• Results in slower injection times on average than Proposal A.
• This violates one of the core principles of Reloaded; which is to make zero filesystem/file modifications to any programs or their libraries.

Extra Notes

• Will require some kind of launcher location tracking as the location of Reloaded-Loader is not fixed. The update system used under the hood (Squirrel.Windows), causes for the Loader/Launcher EXE location to change on every update.

[cheatfreak47]

Proposal B

Disadvantages

• This violates one of the core principles of Reloaded; which is to make zero filesystem/file modifications to any programs or their libraries.

I'd like to go on the record and say I actually really like the idea of implementing Proposal B here regardless for whether or not it solves #15 or if Proposal A is also implemented.

While this does go against the principles of Reloaded, for some games the use of DLL Injection has nearly zero negative impact to modders or to the end users, provided you are taking over a DLL that is loaded early enough. As a result, having this available as an option stands to do nothing but gain functionality.

In addition, the DLL takeover method, in most cases will only be adding a file to the game filesystem that can easily be deleted, which is obviously less of a problem than modifying the game executable of any of the other files in the game filesystem or whatever. Because of this, it only violates these principles as much as the current pseudo-launcher system already does.

The real problem with this is going to be making it easy to explain to the user and implementing a GUI.