Doorstop still doesnt work on first launch

[CptMoore]

version: v4.0.0 release
platform: Windows
game: BattleTech
distribution: Steam

Issue;
Doorstop uses ENV variables to keep track if it already ran, but dynamically set ENV variables are copied by steam during a restart of the games process.

Steps to reproduce:

• make sure steam is not running
• launch BATTLETECH directly via BattleTech.exe (have steam not running)
• steam code detects that it needs to restart, that happens apparently after doorstop already ran
• the game restarts with env variables set from the previous run, that includes env variables set dynamically by doorstop
• thus doorstop thinks it doesnt need to run anymore

Workarounds not working:

• ignore_disable_switch does not work, because the ENV variable DOORSTOP_INITIALIZED is set too, and that leads to skipping of calling the entrypoint
• using a steam_appid.txt file so steam does not restart the game, however steamworks is broken and the game does not work properly (NRE etc..)
• Always use the steam launcher: There are wrappers / launchers that ignore that and run the exe directly, and users who run the exe directly too.

Fix ideas?

• Clear all dynamically set doorstop env variables if doorstop detects that it is in a new unmodified process, leading to doorstop to run again.

Reference for RogueTech Discord: #rogueticket-7596

Logs when using the ignore_disable_switch workaround:
log before restart
log after restart

[ghorsington]

Greetings!

Clear all dynamically set doorstop env variables if doorstop detects that it is in a new unmodified process, leading to doorstop to run again.

Unfortunately that's what the DOORSTOP_DISABLE and DOORSTOP_INITIALIZED are already meant for. To my knowledge, it's the only platform-agnostic way to save process state so that

• it allows passing the state to child processes (this was originally meant for games that launch duplicate versions of themselves as e.g. server)
• it doesn't involve disk IO.

The former point was originally made when BepInEx (the first tool that used Doorstop) didn't have mitigations against the game running multiple versions of itself in different modes (e.g. client + dedicated server). Nowadays, BepInEx is able to handle those situations fairly well, so I think that a better solution is to

• Add an extra option ensure_unique_instance (or better name) that works the same as ignore_disable_switch but applies to both DOORSTOP_DISABLE and DOORSTOP_INITIALIZED.
• Default ensure_unique_instance to false, i.e. ignore both above env vars
• Leave ignore_disable_switch as is for now; default it to true instead

These combined, Doorstop would allow multi-instance runs. It will then be the responsibility of Doorstop users to make sure their code can handle the same game being run in multiple instances at the same time (should be a nonissue, really).

[CptMoore]

That would work for us as we dont have servers or expect multiple concurrent instances to be valid.
The name of the new variable is ok, i use enforce_single_instance for a similar use case, but that quits the process hard.
The defaults also make sense due to end user friendliness for steam users.

[Shilo]

I didn't find an official fix for this problem, here is my workaround:

private static void UnsetDoorstopEnvVarsIfNotSteamRunning()
{
	if (SteamAPI.IsSteamRunning())
		return;

	Environment.SetEnvironmentVariable("DOORSTOP_DISABLE", null);
	Environment.SetEnvironmentVariable("DOORSTOP_INITIALIZED", null);
}

I only unset the environment variables if the game is launched before Steam is running. This has to be executed before SteamAPI.RestartAppIfNecessary() is called. So patching the Steamworks method isn't an option.