koobas.hobune.stream
If statements with a greater/less than than symbol not working but greater/less than or equal to symbol is
I realize this problem is basic, and I just want to say that I've looked around for the solution, and even looked on this site to see if I could find the answer, but couldn't. So I'm now wondering if it's a bug causing this.
In my if statements within my IEnumerator, if I have a greater/less than symbol (> or <) my if statement has been skipped, but if I have a greater/less than or equal to symbol (>= or <=), it works fine. I added Debug.Log statements to each if statement within the IEnumerator to see whether or not they are running.
Here is my code:
using UnityEngine;
using System.Collections;
public class ChangeColor : MonoBehaviour {
public Renderer enemy1DGreen;
private Renderer rend;
void Awake(){
rend = GetComponent<Renderer> ();
}
void Start () {
StartCoroutine (changeColor ());
}
IEnumerator changeColor(){
GameObject player = GameObject.Find("Player");
while (player != null) {
if (transform.localScale.x > player.transform.localScale.x) {
Color color = Color.yellow;
rend.material.SetColor ("_Color", color);
Debug.Log ("Color Yellow");
} else if (transform.localScale.x <= player.transform.localScale.x) {
Color color = Color.green;
rend.material.SetColor ("_Color", color);
Debug.Log ("Color Green");
} else {
Debug.Log ("No color change");
}
yield return new WaitForSeconds (0.1f);
}
}
}
This code will print "Color Green" to the console every time the while loop loops, no matter the size of the player's transform, but if I were to take the "=" out of the "else if" statement (change "<= to <") then both the "if" statement and the "else if" statement will be skipped and it will run the "else" statement and print "No color change" to the console every time it loops.
Well, that most likely means your two object are exactly of equal size. Where is this script attached to? Is it possible that you attached it to your player? Because in this case "player.transform" and "transform" reference the same object. So no matter what size your object has you always compare it with itself. So obviously both x-scales will be equal at any time.
Just to make that clear: There is no bug in the less / greater than operator. When you start debugging a problem your first assumption should be: "Did I something wrong?". Have you already tried printing the actual scale of each of your objects? If they are equal, try printing the object names. When you add "Debug.Logs / prints" make sure you print meaningful and distinguishable text. For example just printing the scale of both is just a mess since you can't tell which one is which.
Try something like this:
while (player != null) {
Debug.Log("this object: " + gameObject.name + " scale:" + transform.localScale);
Debug.Log("player object: " + player.name + " scale:" + player.transform.localScale);
Thank you so much. Your suggestions helped me find the error. Though now I feel that I wasted a question on this small problem. I was really loathed to consider this a bug in Unity, because my years in using it have taught me that it is always me, not the software I'm using. Especially since I'm not advanced enough to come across anything in Unity that could have a bug.
I tried your suggestions. I checked to make sure the script is attached to the object I'm comparing to Player, and it is. I then checked to make sure that a copy of the script wasn't also on Player, and it wasn't. I then checked to see if both objects were printing the same scale, and surprisingly enough, though I was changing the scale of Player, its scale was still the same as the other object's, who's scale I didn't change.
I found out that what my error was, was that I had a child of the Player gameobject that was also named Player. When I did GameObject.Find("Player");, it was finding the child. I thought that wouldn't matter, since it's a child of Player. I thought that when Player changed scale that its children would to, but I remembered that Unity doesn't work like that and the child will still have scale of (1,1,1). I renamed the child of Player to player, and that fixed the issue.
And thank you for suggesting that I print meaningful text, I thought I did, but I see now that their transforms would've been much more meaningful than what I was printing. I will take this program$$anonymous$$g practice with me, as it could save me lot of time.
"Wasted a question"? :D That sounds like you can only ask three questions and now one is gone ^^.
About localScale:
localScale is, like the name says, the local scale of the object. A child of a scaled parent will be scaled as well since coordinate system of the parent is scaled. So everything within that coordinate system (childs) are also affected. However the local scale of the child itself doesn't changed as it controls the scaling of the coordinate system of the child (so it affects the childs of the child).
Think about quadrille paper. At normal scale the grid on the paper has a certain spacing. The distance from one line to the next is simply "1 unit". If you scale the parent down in one axis then the lines would simply be closer along that axis. So a "child" / object that lives inside that paper that is 3x3 units is still 3x3 but appears smaller
Ins$$anonymous$$d of localScale you could use lossyScale. It gives you an appriximation for the "worldspace scale" of an object. It's called "lossy" because it's not necessarily an exact scale. If the child is rotated inside the parent it's not possible to calculate an exact worldspace scale since the parent and child scaling axes are not aligned.
Scaling a parent in only one axis while there's a rotated child inside that parent will deform the child
