I need a line (generated by the a LineRender), that when left-clicked to 1) toggle a isHasLineAttachedToMouse bool to false, before 2) destroying itself. This is simple enough. The following script works great.
if (isPin1Placed == false)
{
if (Input.GetMouseButtonDown(1))
{
gameManager.isHasLineAttachedToMouse = false;
AudioManager.Play(AudioClipName.RemoveLine);
Destroy(gameObject);
}
}
But, I also want the line to change color, to red, and then wait for a small window of time, before being destroyed. This seems simple enough. However, when implementing this with the following code, the isHasLineAttachedToMouse bool fails to toggle to false.
if (isPin1Placed == false)
{
if (Input.GetMouseButtonDown(1))
{
gameManager.isHasLineAttachedToMouse = false;
Color startColor = Color.red;
Color endColor = Color.red;
lineRenderer.startColor = startColor;
lineRenderer.endColor = endColor;
AudioManager.Play(AudioClipName.RemoveLine);
Destroy(gameObject, 0.05f);
}
}
The only differences are the addition of the Color classes, assigning the colors, and the added float timer to the Destroy method.
Is there something obvious that might be causing the issue? Is this perhaps a side-effect of using the float timer in the Destroy method?
I highly doubt that “isHasLineAttachedToMouse” is not set to false, since it is. However you may want to focus on the code where you set it to true. Because the gameobject is not destroyed immediately, is it possible that some other code somewhere else is setting isHasLineAttachedToMouse back to true?
Thanks for the response. However, this is what is happening. The reason I posted a question here is because I can’t figure out why.
When I first tried debugging this, I had Debug.Log(isHasLineAttachedToMouse) run in the update. When the first example script above is used, isHasLineAttachedToMouse does in fact switch to false as expected.
However, when the second example script is used, isHasLineAttachedToMouse stays at true.
I considered that. But, again, the only changes made in the entire game are the Color classes, assigning the colors, and the added float timer to the Destroy method.
if (isPin1Placed == false)
{
if (Input.GetMouseButtonDown(1))
{
gameManager.isHasLineAttachedToMouse = false;
Debug.Log(gameManager.isHasLineAttachedToMouse);
Color startColor = Color.red;
Color endColor = Color.red;
lineRenderer.startColor = startColor;
lineRenderer.endColor = endColor;
AudioManager.Play(AudioClipName.RemoveLine);
Destroy(gameObject, 0.05f);
}
}
After you replaced your code, what the console says?
Here is what was happening:
you set this value to false
you destroyed the game object
at the end of the frame Unity destroyed the game object, none of your code on this game object ran anymore
Here is what is happening right now:
you set this value to false
you say, you want to destroy the game object after 50 milliseconds (you’re setting the t in seconds)
your game is running until this time elapses (at 60FPS it’s a couple of frames, 1 frame is 16.67 milliseconds at 60 FPS), in the mean time, all of your other code is running (Updates and whatnot)
when the time elapses, Unity waits for the end of the frame and destroys your game object
Well, if you can not figure out where you set your variable back to true, you may want to go to your GameManager class and replace
public bool isHasLineAttachedToMouse;
with
[System.Serializable]
private bool m_isHasLineAttachedToMouse;
public bool isHasLineAttachedToMouse
{
get { return m_isHasLineAttachedToMouse;}
set {
Debug.Log("isHasLineAttachedToMouse is being set to " + value+ " previous value was: " + m_isHasLineAttachedToMouse, gameObject);
m_isHasLineAttachedToMouse = value;
}
}
Note this is the only replacement you should do. All your code should work exactly the same. This log statement has several goals:
First of all you see when the variable gets changed, to which value it is set and also what the previous value was.
Second, thanks to the stack trace of the log you can exactly trace back which method of which class is actually setting the property.
Finally I’ve added the “gameObject” of the GameManager as context object. This has the advantage that when you click on the log message in the console, Unity will highlight / ping that object in the hierarchy or project view. When you do that, pay close attention which object is actually involved. A common mistake is calling method or setting variables on prefabs in the project rather than instances in the scene.
We can not do the debugging for you. We don’t have your project and we also do not have your code. As we already said, when the line where you set your variable / property to false is executed, it will be set to false. This is a fact. The only case when this would fail is when the gameManager reference is null. However in that case you would get an exception. Also since that happens before you even reach the Destroy line, it’s happening before that and therefore is independent of the Destroy call. So if the variable is somehow true after that code ran, it got set back to true somewhere else.
Again, debugging is your job. Knowing how to debug your code is more important than writing the code. This is your main task as programmer. Programmer are problem solver. If your solution does not work, you just have created a new problem that you need to solve.
So if you’re still struggling with that issue after you’ve done that property replacement, you have to share more code, specifically all places where you set that variable to true.