How to select the monitor a Unity game opens on, on the first try

Question

I want to specify which monitor (1? 2? ...) my Unity game opens on, when running its .exe from the command line.

As seen on the Unity Answers post here, this C# code does work:

PlayerPrefs.SetInt("UnitySelectMonitor", 1); // Select monitor 2

However, the setting does not take effect until you close the game and re-open it. (This flaw is acknowledged in that post as well.)

Is there a way to open the game on the desired monitor on the first try?

---

(Note: I assume the solution needs to be in the build step or a command-line arg to the .exe that starts the Unity Player. Because if the solution is in the C# code itself, as the above solution is, then the game will already be open and then it's too late.)

Answer 1

Since version 2019.3, use the -monitor command line argument. E.g.,:

 GameExecutable.exe -screen-fullscreen 1 -monitor 2

In Unity of versions > 2019.3.0b12, 2020.1.0a12, a related bug about running multiple instances of the same application simultaneously was fixed. From the bug tracker:

IMPORTANT: the "adapter" command-line argument has been replaced with "monitor" in 2019.3 (for consistency across Desktop platforms); the behavior is exactly the same.

NOTE: This issue also occurs for other "screen" command-line parameters: screen-width, screen-height, and screen-fullscreen which are also addressed by the fix.

The problem is caused because these command-line arguments will set/update PlayerPrefs, i.e. these values are persisted and applied the next time the app is launched. So, the second instance of the app essentially "inherits" the values from the first process, causing it to ignore it's own command-line arguments due to a race-condition with PlayerPrefs updating logic. However, if the second process is delayed by a few seconds, the race-condition doesn't occur and the command arguments work properly.

The fix address the race-condition by setting "override" values when these arguments are passed in, forcing the runtime to apply the command-line values and ignore those stored in PlayerPrefs.

However, PlayerPrefs is updated by the command arguments, which is still a race-condition, and there's no guarantee as to which values will actually be saved. That is, the values from the first instance of the app may get saved to PlayerPrefs and not the values from the second instance as you might expect. Unity cannot solve this problem as the race occurs externally to the runtime, and so if the final state of PlayerPrefs is important, then you must stagger launching each instance of the app.