- Home /
c# Ignoring conditional statement?
Basically I want "StartCoroutine(DigItBike()));" to only run if canDiveBike is true, but it seems like my code is just ignroing my bool statment!? Even when it == false, I can still execute StartCoroutine(DigItBike()));???
Any tips would help me a lot! I've been struggling with this for the past week now. Heres the code:
public bool canDiveBike = false;
public int item;
void OnTriggerEnter(Collider other)
{
if (other.gameObject.tag == "stuffBike")
{
if (canDiveBike == true)
{ ///////
sound.SetActive(true);
}//////
if (Input.GetKeyDown(KeyCode.E))
{
digBike();
}
}
/*
else if (other.gameObject.tag == "stuffMusic")
{
if (Input.GetKeyDown(KeyCode.E))
{
digMusic();
}
sound.SetActive(true);
}
*/
else
{
sound.SetActive(false);
black.SetActive(false);
}
na.SetActive(false);
parts.SetActive(false);
bags.SetActive(false);
seat.SetActive(false);
Wheel.SetActive(false);
shoes.SetActive(false);
}
void OnTriggerStay(Collider other)
{
if (Input.GetKeyDown(KeyCode.E) && other.gameObject.tag == "stuffBike")
{
digBike();
}
/*
else if (Input.GetKeyDown(KeyCode.E) && other.gameObject.tag == "stuffMusic")
{
The code you posted does not contain a call to StartCoroutine(), nor the function DigItBike(). I am unfortunately unable to help unless you edit your question to include the code you are actually concerned with.
If, by DigItBike(), you meant DigBike(), you should be aware that
A, DigBike is not being run as a coroutine in the code you provided
B, Your if statement for canDiveBike does not contain the call to DigBike().
C, You're calling DigBike in both OnTriggerEnter and OnTriggerStay, which is unnecessary. Putting it in OnTriggerStay will have the same result.
Good day.
As @Zarenityx says, "The code you posted does not contain a call to StartCoroutine(), nor the function DigItBike()."
In your title, you say this twice : StartCoroutine(DigItBike())); wich have 1 ")" more than necessary (maybe its part of a big code but we dont see this part).
Your code have parts marked as comment, so are not funcitonal, so is innecessary to post them, making the code longer and slower to read...
Please, edit your post and try to solve all this things, then someone will give you a good answer.
Good bye.
This looks like a duplicate of
https://answers.unity.com/questions/1553519/c-disregards-my-bool-as-if-it-doesnt-exist.html
Answer by JVene · Sep 14, 2018 at 11:00 PM
I'm going to assume that digBike is a method that starts the coroutine you mention.
This may be a poor attempt at humor, that I can't resist whenever I encounter a question like this, which also conveys a bit of wisdom accumulated in several decades of programming, I've never seen a computer ignore an "if" statement. In my first few years I would have sworn it was ignoring me, just for spite. I can't count how many times I just "knew" the computer was failing at basic math, or ignoring some obvious logical test, but alas it has never been true. Under the hood these statements translate into just a few machine language instructions, so it is very close to direct action and control at the CPU, and if that only worked occasionally the entire operating system would never function. It has always been something else. So, like it was for me in those first few years, whenever you have that sense that the computer is just plain ignoring you, it isn't. It is something else.
Take this portion of your code to study:
if (other.gameObject.tag == "stuffBike")
{
if (canDiveBike == true)
{ ///////
sound.SetActive(true);
}//////
if (Input.GetKeyDown(KeyCode.E))
{
digBike();
}
}
This section has an outer "if" clause which only executes when other.gameObject.tag == "stuffBike". All else between the brackets associated with this clause executes only when that tag matches. However, look at the next two "if" clauses. You mentioned the bool, which I believe is canDiveBike == true. When that is true there is a call to sound.SetActive(true), but that is all that applies to the condition that canDiveBike is true. The next test, a check for the "E" key, is outside the brackets enclosing the block of code associated with the test for canDiveBike. This second test is performed no matter what the state of canDiveBike. In this second clause, for KeyCode.E, if the key is down there will be a call to digBike (which I assume launches your coroutine), and that test passes no matter what canDiveBike may be. If you want this key tested and digBike called only when canDiveBike is true, that code (the if( GetKeyCode...)) must be inside the brackets associated with the "if ( canDiveBike == true )".
There's another place you show where digBike is called, in the OnTriggerStay method. Here, too, there's no check for canDiveBike, so there's a second place where digBike can be called no matter what the state of canDiveBike may be, as long as the tag on "other" is "stuffBike" and the "E" key is held down. You would have to also add the test for canDiveBike, either just before you call digBike or as a third clause in the "if" statement in this method.
With that said, if I assume that digBike is a method which starts the coroutine, you could move the test for canDiveBike into that method (only start the coroutine when it is true), and therefore wouldn't have to concern yourself with ensuring that check is made in two separate locations like you're doing. For that matter, if the checks for E and "stuffBike" are also required, you could put those in digBike, and just rely on calling digBike without any test, so that digBike performs all 3 tests no matter how many times you call digBike. This latter point is about organization of code. Any time you find yourself repeating things, you're leaving behind the chance that you also have repeated locations to fix the same bug. Wrap those repeated things into a method (functions in other language), so there is only 1 place that work is done, only one place to debug and fix if it's incorrect.
Just took some of your advice, ended up changing my code a bit (thank you!). Here's what I have now but the issue is still present, reguardless of canDiveBike's true or false value it still runs, almost as if it's completely ignorng that canDiveBike is a thing?
Here's my code: https://pastebin.com/VyPe664p
Here's a few things that strike me.
If I were debugging this, I'd prove to myself the state of canDiveBike with a debug output inside the clause testing for canDiveBike == true in method DigItBike(). This will show you that when that code fires canDiveBike isn't being ignored when false.
Next, I don't see anything that changes canDiveBike. It is initialized to false, but how is it ever made true? I'm not seeing that, so I can't say how it may be that canDiveBike is confusing the matter. If canDiveBike is ever manipulated from a thread (which can happen if it is set in response to some input callbacks), then canDiveBike might be true at the moment a test is made, but change while code is running that requires canDiveBike to be true. Further, if there are threads, such values have to be protected to work correctly, and must likely be declared volatile.
An extension to that point is the fact that coroutines complicate the matter. They're not threads, but many of the same problems can happen because a loop like you've constructed is "paused" and "resumed" between cycles of Update, such that many of the same problems can happen, such as a value changing state between loops. In your case, you're checking for canDiveBike only at the start of the function, but that won't check canDiveBike within each loop. If canDiveBike is ever set to false after the routine starts, there's no way for this algorithm to discover that fact as the loop continues.
The last thing that strikes me is that while you have wrapped code in a common place (DigItBike), you'll notice that because the clause it controls is quite long, it isn't immediately clear. The logic looks like this:
if ( canDiveBike )
{
.....do lots of stuff....
}
However, when the close bracket is so far away, a reader isn't sure and has to search for the enclosure. When clarity is paramount, such a construction is usually written so that "do lots of stuff" is a method, making the block short and obvious. While this may sound at first like a stylistic complaint, I can't count how many times this has actually spawned subtle bugs we just can't see.
Your answer
Follow this Question
Related Questions
How Do I check if a Bool was True a few moments ago 2 Answers
Could use some help on making my runaway/chase/follow/patrol script cooperate with each other 1 Answer
Scavenger Hunt List Bools Question 1 Answer
Use a #if statement to check if a script exists in project? 0 Answers
my button dosent work, became a light switch instead of a normal button (like a bell) 1 Answer