While going through this lecture and creating the Primary & Secondary box colliders for my triggers, I first had issues with the Primary Box collider being triggered at the start of the scene straight away. It seems that it is being fired from intersecting with the ring mesh giving me about 20 collisions at scene start and every time the ball hit the rim or collider. I left my print statements in my code, and this behavior was revealed in my console (I think Sam may have had the same behavior, but his console was never visible during the lecture).
This also lead me to a secondary issue: when the ball was thrown in such a way that it hit underneath the rim, yet hit both colliders, a score would be recorded. After a while of trying different colliders (sphere worked “best” but wasn’t ideal) I was finally able to get the desired behavior by moving the Primary Trigger above the rim and making a bit smaller. I needed it far enough above the rim so that a thrown ball that hit the rim from underneath wouldn’t crash into the Primary trigger
Another way you could tackle it is for the triggers to check which object is colliding with them.
@sampattuzzi Ah, ok. I also found out that you could also use the trigger based on how fast the collision is with a conditional. I still don’t think this will get rid of the issue of a ball triggering both colliders if thrown from “underneath” though. Even so, this was a fun bug to try to think about; I think moving the upper one above the rim, also uses the rim as a separator between the two so that it is very difficult for the ball to trigger both without going through the rim
Yes, I think your solution seems like the most robust.
i’m struggling with the whole concept of the two triggers.
So step 1: I have a ‘hit the top of the rim’ trigger… basically the first trigger as defined in the course
step 2: I create a variable (secondary trigger based) where I call Getcomponentinchildren
step 3: on that variable, I call the ExpectCollider function and pass in the handle to the collider which came from the OnTriggerEnter(Collider collider) method of the primary trigger
okay so far, nothing different from the lecture
in the secondary trigger:
step 1: the expectcollider function, I save the incoming handle of the passed through collider into a variable I call ItHitTheTopFirst
step 2: in the onTriggerEnter procedure:
…and hit reply too soon
on the OnTriggerEnter(Collider OtherCollider) (note, same as lecture),
I then check if ItHitTheTopFirst is equivalent to the ‘otherCollider’ passed in by the OnTriggerEnter Event on the secondary trigger.
so my secondaryTrigger compelte code looks like this:
Collider ItHitTheTopFirst;
public int ScorePerHit = 1;
public float TimePerHit = 1.0F;
public void ExpectCollider(Collider HitTheRim)
{
ItHitTheRimFirst = HitTheRim;
}
void OnTriggerEnter(Collider OtherCollider)
{
if (OtherCollider == ItHitTheTopFirst)
{
ScoreKeeper scoreKeeper = FindObjectOfType<ScoreKeeper>();
scoreKeeper.IncrementScore(ScorePerHit);
scoreKeeper.IncrementTime(TimePerHit);
print("Hit the top basket trigger box!");
print("Hit the bottom net too");
}
}
I do not understand the logic check… the ‘otherCollider’ should be the handle to the bottom trigger box… So they will never be equivalent!!!
shouldn’t we be doing a Boolean check on ExpectCollider? e.g. its called because the primary trigger was hit. So if its true, then the assumption is the ball is now passing into the interior of the net, on its way to hit the secondary trigger.
So my code should be something like this:
void OnTriggerEnter(Collider OtherCollider)
{
if (ItHitTheTopFirst) // the top trigger has been hit so we now check to see if the 2ndary trigger is hit
{
ScoreKeeper scoreKeeper = FindObjectOfType<ScoreKeeper>();
scoreKeeper.IncrementScore(ScorePerHit);
scoreKeeper.IncrementTime(TimePerHit);
print("Hit the top basket trigger box!");
print("Hit the bottom net too");
}
}
confused…
…and I potted plant this thing.
what I didn’t realize is that the Collider handle being passed around willy-nilly, was the handle to the object that did the colliding. in this case, the basketball.
so the logic is the following:
- something collided with the ‘top’ trigger — top trigger is above the rim and detects possible entry to the net
- the something that collided is the basketball. It could have been a scimitar if I had a scimitar object in the game
- upon collision, I call the child secondary trigger and pass through the ball handle (the object doing the colliding)
- inside the secondary trigger routine, i’m checking to make sure that the ‘thing’ that collided with the top trigger is the same ‘thing’ that collided with the bottom trigger.
- the algorithm assumes that whatever hits the top trigger and bottom trigger had to pass through the net ‘mesh’. and if the ‘thing’ that hit both triggers is the same basketball object, its a score (as opposed to scimitars being lobbed at it).
okay, got it.
why can the trigger detect the motion vector it entered? e.g. a vector the requires it to pass through the net. that’d solve everything simply right?
That is an interesting idea about vectors. It appears we can do that with Collisions (Not triggers). Not sure we can find a direction in this context.
I solved the issue of ball passing upward through hoop with “Tags”. First I created two tags, “ScoreBall” which I put on the Ball prefab, and “DeadBall” which I mark the ball with when it hits the Second trigger.
Code for first trigger:
void OnTriggerEnter(Collider thisCollider)
{
if (thisCollider.gameObject.tag == "ScoreBall")
{
myHoopSecondaryTrigger.ExpectCollider(thisCollider);
}
}
Code for second trigger:
void OnTriggerEnter(Collider thisCollider)
{
if (thisCollider == saveCollider)
{
myScoreKeeper.UpdateScore(scoreValue);
}
thisCollider.gameObject.tag = "DeadBall";
}Interesting solution. I guess a dead ball can never then bounce into a hoop in any realistic senario.
I think the motion vector should be interesting. Give it a go and tell us if it works.