Neb on 13/12/2016 at 21:08
MissionScreen gets called with (1) and MissionScreenOn gets set true, returns, and then it's true for the check, so fires again with (0).
edit: or ignore me, i might be talking bollocks. So tired.
Quote Posted by henke
Shouldn't Input.GetKeyUp take care of this? So only the first one is executed on one frame?
I don't know C# or Unity, but the code looks like it should do what you say it's doing. All of it is in one frame, and I'm assuming that a method checking whether a key is up will not secretly set it to false behind the scenes, because that would be evil.
Pyrian on 13/12/2016 at 21:41
I think Neb's got it, bollocks notwithstanding. The first call sets MissionScreenOn to true, which pretty much guarantees that the second call gets made as well. "Input.GetKeyUp" will give you the same result every time you call it in the same frame. Any particular reason you didn't simply stick an "else" before the "if (MissionScreenOn == true)"?
WingedKagouti on 13/12/2016 at 21:42
Quote Posted by Neb
MissionScreen gets called with (1) and MissionScreenOn gets set true, returns, and then it's true for the check, so fires again with (0).
Looks like that's exactly what happens.
Renzatic on 14/12/2016 at 00:47
I have graduated from the beginner tutorials to the intermediate!
This should be a big day for be, but I'm so scared...
Yakoob on 14/12/2016 at 03:32
Quote Posted by Pyrian
Heh. I'm pretty sure collision detection works on a search algorithm, meaning that the more colliders you have, the more efficient it is per-collider. 1 collider:1X; 10 colliders:2X; 10000 colliders:5X; sort of thing. The documentation wants everyone to use edge/surface colliders, but I've always found volume colliders to be so much more robust - it's so easy to clip through a surface, and you see examples everywhere of models that partially clip through something and just go nuts.
Yea I was using Bullet Physics which does spatial partitioning that speeds things up quite a bit. It was also AABBs which are the easiest to test against.
henke on 14/12/2016 at 05:20
Thanks Neb, Pyrian, WK.
Quote Posted by Pyrian
Any particular reason you didn't simply stick an "else" before the "if (MissionScreenOn == true)"?
D'oh! Of course the solution would turn out to be something that simple. :p
Renzatic on 15/12/2016 at 03:36
Really dumb question here. I mean like, real dumb. Straight up Duh 101 type stuff here.
== is something like a true or false comparison, right? As in "a == b" would read like "if a is/is like b"
I'm doing more annotations, and I need to know if this is right...
Code:
void Start ()
{
GameObject gameControllerObject = GameObject.FindWithTag ("GameController");
if (gameControllerObject != null)
{
gameController = gameControllerObject.GetComponent <GameController> ();
}
if (gameController == null)
{
Debug.Log ("Cannot Find 'GameController' script");
}
}
// Code that looks for an object tagged with Gamecontroller.
// Reads:
// GameControllerObject is (find object tagged "GameController")
// if you can find the object tagged with "GameController"
// (!= means 'does not equal' or 'is not')
// then grab the GameController component, and activate it.
// or, if you can't
// (== is a comparison, or 'if this is true or false')
// then send the message "Cannot Find 'GameController' script" to the console.
Pyrian on 15/12/2016 at 04:04
Yeah, that's right, "a = 2" assigns the value 2 to the variable a (and returns that value as well, so you can chain "a = b = 2"), while "a == 2" returns true if a is 2, and false otherwise; "a != 2" is the inverse, returning true if a is anything but 2.
Renzatic on 15/12/2016 at 04:17
Cool, thanks. :D
Renzatic on 15/12/2016 at 07:29
Just about every instance of it I've seen of it so far can be boiled down to "if this matches up with this, then..." type situations.
I tell ya. I've gone through 6 pretty good sized scripts tonight, adding my notes to each one of them. I can actually read simpler code now fairly comfortably, but damn...this cramming of minute information is burning me out already. :P
