Search Unity

  1. Welcome to the Unity Forums! Please take the time to read our Code of Conduct to familiarize yourself with the forum rules and how to post constructively.
  2. Dismiss Notice

Force single instance toggle doesn't work with fast clicks

Discussion in 'Windows' started by KpowKaEHoT, Dec 20, 2014.

  1. KpowKaEHoT

    KpowKaEHoT

    Joined:
    Dec 18, 2014
    Posts:
    3
    When i'm doing windows build with checked "Force single instance" toggle it can be started more than once. You should just press enter when executable selected twice for example and game will run twice(or more). It works correct only when application started, but it can take a long time on old PCs.
    I'm using latest version 4.6 and windows 7 x64.
     
    GalxyzStudios likes this.
  2. Aurimas-Cernius

    Aurimas-Cernius

    Unity Technologies

    Joined:
    Jul 31, 2013
    Posts:
    3,627
    Please report a bug.
     
  3. GalxyzStudios

    GalxyzStudios

    Joined:
    Jul 15, 2015
    Posts:
    31
    Is this issue fixed ? Still facing the same error on Unity 5.6.1 f1
     
  4. Peter77

    Peter77

    QA Jesus

    Joined:
    Jun 12, 2013
    Posts:
    6,414
  5. AlanMattano

    AlanMattano

    Joined:
    Aug 22, 2013
    Posts:
    1,500
    @Aurimas-Cernius 4yr pass and is still there, but now the priority is 7
    At the moment has only one vote ?!

    Where is the link to the workaround for this problem?
     
  6. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,491
    This issue isn't 4 years old. The bug in question was reported January 29, 2018.

    We don't have a workaround at this time yet, but we are looking into fixing it.
     
    AlanMattano likes this.
  7. AlanMattano

    AlanMattano

    Joined:
    Aug 22, 2013
    Posts:
    1,500
    @Tautvydas-Zilys thanks for the answer but why you say that? We still face the issue in latest Unity5.6.3p2. probably you are talking about the bug but the issue is 4 years old and can emerge repeatedly. Bugs and issue are two separate things. You can resolve the 2018 bug and still have the same issue in 2019 or Unity5. I hope and pray: there must be e a way to prevent some issue to reemerge. So you are suggesting that I report a Unity5 bug? Can do so?

    While we are waiting for the fix, if there will be one for Unity 5

    can we look to the Windows registry key every second?

    One solution idea was to have an int key value, name "running"...
    If the key running is equal to 0 means that there is no instance running
    If the key running is equal to 1 means that is running the first instance

    Code (CSharp):
    1.  
    2. private void Awake()
    3.     {
    4.         if (PlayerPrefs.GetInt("running") == 0)
    5.         {
    6.             //Let know to other instannce that this is running
    7.             PlayerPrefs.SetInt("running", 1);
    8.             PlayerPrefs.Save();
    9.         }
    10.     }
    11.  
    You must know that each time the application closes it set this "running" key value to 0

    The second instance will not pass the if statement and will finish into the else
    It will try to change the value to 0

    Code (CSharp):
    1.  
    2.         else
    3.         {
    4.             // Let's try to change it to not running...
    5.             PlayerPrefs.SetInt("running", 0); // key 0 means not running...
    6.             PlayerPrefs.Save();
    7.  
    8.            // more code .... IEnumerator... yield WaitForSeconds(5)...
    9.         }
    10.  
    If the first instance did not crush leaving the value to 1,
    then it will revert it from 0 to 1 using the update function
    The second instance will notice the change,
    realizing that other instance is running and will quit.

    THE PROBLEM here is that I do not know if looking a key so often (each second) can be wrong because of the mechanic HDD temperature. Or is demanding in some way.

    Code (CSharp):
    1.  
    2. void Update ()
    3.     {
    4.         i = i + 1;
    5.  
    6.         // look after 120 frames if key running or key value change
    7.         if (i == 60)
    8.         {
    9.             i = 0;
    10.  
    11.             // Look if other instance is changing "running" to 0
    12.             if (PlayerPrefs.GetInt("running") == 0)
    13.             {
    14.                 // "running" == 0 and was change by the second instance
    15.  
    16.                 // restablecerlo a running 1
    17.                 PlayerPrefs.SetInt("running", 1); // key 1 means running...
    18.                 PlayerPrefs.Save();
    19.             }
    20.         }
    21.     }
    Now the other second instance is checking if the "running" 0 is reverted to 1
    (in the section "// more code...") And if so, it quit closing itself without changing the value to 0.

    Code (CSharp):
    1.  
    2.         // inside an IEnumerator
    3.  
    4.         // wait for 300 frames to confirm if is still 0 or was changed to 1
    5.         yield return new WaitForSeconds(5);
    6.  
    7.         // in case is 1, close this application
    8.         if (PlayerPrefs.GetInt("running") == 1)
    9.         {
    10.             // close this app without changing anything.
    11.             Application.Quit();
    12.         }
    13.  
    If the value is still there for few (5) seconds then it was left from a crash. A bad close that did not save the value to 1. So it set the running key to 1

    Code (CSharp):
    1.  
    2.  
    3.           PlayerPrefs.SetInt("running", 1);
    4.  
    5.  
    This script must be the first script to run (Edit > Player Settings > Script Executable Order > this script N: 1°)


    Can we look to the Windows registry key every second?
    Ones a second, every 60 fps means that the player HDD will be very on high demand?
    If not How often we can look to the registry key?
     
    Last edited: Feb 10, 2018
  8. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,491
    The reason I say that bug isn't 4 years old is because the forum post fell through the cracks, and we weren't fixing it because we forgot about it (forums is a really bad place to track bugs). Now that it's properly reported, it will be added to our test suite and fixed, and we will do our best this will never regress again.

    The right way to workaround this on your side is to try to open a file with exclusive write permissions (and never close it - Windows will do so automatically when your process exits). If the open fails, that means that another instance is running and you should exit. That is the optimal solution and doesn't requiring continuous querying of anything.
     
    Cathero and AlanMattano like this.