koobas.hobune.stream
Odd behavior changing another script's variable via coroutine
Following a Unity tutorial (the coconut shy minigame in Will Gladstone's Unity 3.x Game Development Essentials), I've created a game in which there are three targets. These targets stay "down" for 3 seconds after being hit. If you hit all three targets before any come back up, you win.
The code, boiled down to its essence, is:
// in a script attached to each target
public class TargetCollision : MonoBehaviour {
void OnCollisionEnter(Collision col) {
StartCoroutine("targetHit");
}
IEnumerator targetHit() {
WinDetector.targets++;
yield return new WaitForSeconds(3.0f);
WinDetector.targets--;
}
}
// in a script attached to a separate GameObject
public class WinDetector : MonoBehaviour {
public static int targets = 0;
void Update () {
Debug.Log(String.Format("targets = {0}", targets));
if (targets == 3) {
Debug.Log("You win!");
}
}
}
When run from within Unity, the game works in the sense that reaches 3 and the win is counted. However, something strange happens: after reaching 3, targets gets decremented down to -3, not back to 0 as intended (which can be seen from Debug.Log output).
When run from a Mac standalone non-dev build, the win condition never gets triggered, as targets never reaches 3. In this build, targets also ends up getting decremented down to -3.
When run for a Mac standalone dev build, things start to fall apart, in the sense of getting the Mac pinwheel and eventual hanging of the application after I hit a few targets.
My guess is that I'm doing something wrong with the coroutine and there is some kind of race error in the way targets is incremented, decremented, and read.
What's going on?
How are you detecting collisions on the target? It could also be that even when your targets are down, they're still checking collisions and firing off the coroutine.
@dannyskim -- I'm using the OnTargetCollision method above to detect collisions. In the actual code, this checks to see if the target is already down, in which case it doesn't increment/decrement WinDetector.targets again. But in any case, why would targets ever go negative? Why would its behavior be different when running within Unity versus in the builds?
Something else must be decrementing targets - I can think of a way it would get higher and not decrement, but not lower.
@whydoidoit -- I'm not familiar with how to debug Unity scripts -- is there a way to watch a variable for change? If so, I could see if there's some other script messing things up. Also, any guess why the behavior would be different running within Unity versus in a build?
I'm not sure you can set a "watch point" might be easier to continually log the value and then specifically log where you think you are adding and removing it. I'm guessing (because these things usually are bugs in the code not Unity) that the difference between build and editor is in the ti$$anonymous$$g of some other script which is affecting this value. But it's certainly odd.
