Unity Shutdown without any Response

Hi,
so i have this problem now, and i really don´t know what i did wrong or what causes it. Unity freezes right after the Gameobject/Skript is initialized and i can only close Unity via Task Manager. I know exactly that my Skript “Guest” is the problem, because when i delete the Gameobject out of my Scene everything else works fine. I want the skript to handel my incoming Guests, and so to Instantiate them via a GuestController Gameobject with Skript. I put some lines in Comments to be sure no external method produces my bug.

The Script:

using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public class Guest : MonoBehaviour
{
    float timer=0f;
    int waitingTime=15;
    bool dishBool=false;
 
    // Start is called before the first frame update
    void Start()
    {

        GuestController guestController = GameObject.Find("GuestControllerGo").GetComponent<GuestController>();
        if(guestController!=null)
        {
            Debug.Log("Here Shouldnt be Any Mistakes.");
        }
        Vector3 platz = new Vector3(0,0,0);
        while(timer<waitingTime || platz== new Vector3(0,0,0))
        {
            //platz = guestController.PlatzAnfrage();
            timer += Time.deltaTime;
        }
        if(timer>=waitingTime)
        {
            UnhappyCustomer();
        }
        else
        {
            timer=0f;
            while(timer<waitingTime || dishBool!=true)
            {
                //guestController.EssenAnfrage(platz);
                timer += Time.deltaTime;
            }
            if(timer>=waitingTime)
            {
                UnhappyCustomer();
            }
        }
    }

    // Update is called once per frame
    void Update()
    {
     
    }
    void UnhappyCustomer(){Debug.Log("A Guest was Unhappy and left without service.");}
}

I hope i did everything else (right Forum, Script etc) right, this is the first time i ask for help here.

Line 21 and Line 33… NEVER EVER EVER EVER do a loop like that in Unity unless you are yielding within it, eg it is a coroutine.

Unity locks up solid until you return from your functions, by design and for the very good engineering reason of simplicity.

Here is some timing diagram help:

If you need to wait, generally use coroutines, or else poll in Update().

So what is the problem of my loops? I have a counter (timer) that works like a for loop and i have a additionally break condition if the loop is earlier finished. I don´t understand the problem here, i mostly only know Java and there shouldn´t be a problem with this design (or am I completely wrong?).
The timing thing is only to ensure that a Guest doesn´t wait to long and leaves after a spezific amount of time and not to wait.

This is a busy wait. Unity doesn’t support such a thing. From the standpoint of ALL your code, there is one thread. You have locked it up waiting. Assuming Time.deltaTime happened to be nonzero, this would ONLY lock up for a brief moment.

But during that time nothing is happening: no frame is rendered, nothing else runs, no input is possible, nothing.

Again, review the timing diagram above and go look at any number of examples how to poll wait in Unity. Remember, from your standpoint, Unity locks up SOLID until you return from your function.

1 Like

Yeah but why there should be busy-waiting. I could reform my loop like:

while(platz== new Vector3(0,0,0))
        {
            platz = guestController.PlatzAnfrage();
        }

There is a method called in the loop which i put in comments, to ensure the problem does not resolve from this. Why should i redesign my loop into a Coroutine? I need to call this method guestController.PlatzAnfrage() everytime until its (0,0,0).

Or do you mean by this, that i can`t do long loops with much computationally work, because everything else cant be computet and is set to sleep?
So i need to put it in a Coroutine so it is computet but everything else can be computet “simultaneously” also?

Correct.

Also, comparing floating point numbers for equality (in this case a Vector3) is also a bad idea. It might work but it might fail for reasons of floating point imprecision.

1 Like

Ok you really helped me and i thing i can now work on to fix my bugs. Thanks a lot and have a great friday evening.

1 Like