Log spam cause increased CPU usage when a game has twice the same exe running

[Fr0stX76]

Some Unreal engine games have 2 exe running at the same time, carrying the same name. The game main one and a smaller one.

Ex: Hogwarts Legacy and Dragon Quest 3 remake.

Most devs are smart enough to name them differently (Ex. Bravely default has Bravely_Default_II.exe vs Bravely_Default_II-Win64-Shipping.exe) but some devs are just dumb enough to only store them in 2 different folders but use the same name (DQIIIHD2DRemake.exe is present in the main folder of the game and in the binaries/win64 folder).

The issue is that the smaller one (as in not the main exe) is some sort of launcher needed for the game to start, then it`s irrelevant. Since they both are running at the same time, and stay loaded (even if it's not needed...),

At this point, Autoactions goes into a weird state where it spams the log with "lost focus", "load profile" every 500ms or so. After 30 minutes to an hour of this, the result is that it increase the CPU usage, even after closing the game, since it seems to just be trying to catch up in writing the log. The only solution is to exit and restart Autoactions.

A similar thread was opened but closed as "not planned"

#138

My solution is not elegant, but works with Dragon Quest 3 remake, not sure about Hogwarts Legacy. I created an autohotkey script that is launched by Autoactions (ironically):

#NoTrayIcon
GameFolder := "D:\SteamLibrary\steamapps\common\DRAGON QUEST III HD-2D Remake"
ExeName := "DQIIIHD2DRemake.exe"
WaitBeforeKill := 2000
Loop {
    Loop, Files, %GameFolder%\%ExeName%
    {
        Process, Exist, %ExeName%
        pid := ErrorLevel
        if !pid
            continue
        Sleep, %WaitBeforeKill%
        Process, Close, %pid%
        ExitApp
    }
    Sleep, 250
}

Obviously, the folder path and the .exe name need to be adjusted. Also, the WaitBeforeKill:=2000 might need more time, something like 5000 (5 seconds) for some games.

It might also need to be run as an admin.

But this is just a workaround. The real solution would be to make Autoactions aware of the exe location, in order to limit the state change detections to the exact version/location of the exe that the user selected when setting up the application.