01/08 Update - Why r colliders???

So a few hours of work today has primarily been focused on COLLIDERS. Everything is just smashing into each other all the time, both in the game and IRL as I am sitting at my desk and repeatedly hitting my controllers off the desk as I frantically grab at virtual chicken wings. (I have nothing if not my dignity.) Everything smashing together and yet nothing works the way I want. 

Some more specific notes:

FRAMEWORK ISSUES: I've spent a lot of time tonight tackling issues relating to the actual placement of the XR rig and how it shows up in-game. This is partially because I'm unfamiliar with this particular character controller (there's height, and in another area min and max height, and in yet ANOTHER area,  a Y offset), but also because there are SO many colliders happening in very close quarters.  The table, the chair, the floor, the player. Your arms are only so long so you have to be pretty close to the table to be able to grab anything, and it feels very uncomfortable to have all the food/drinks teetering right at the edge of the table.  The solution ended up being removing the collider from the chair and dramatically shrinking the player colliders -- the body doesn't really matter anyway for this. It's also annoying because IRL I'm sitting at a pretty high table and kept needing to reaching underneath the table to get to the height of the wings, which obviously the Quest 2 does not like as it does not have X-Ray vision. 

There's also a lot of finessing to be done with the grabber/grabbables. They feel okay, but not great. I don't think it's worth messing with it until I have the actual models I'll be using for the final because a lot of it is about hand position and grab points and those will need to reflect the actual mesh. 

STATIC VS. NON-STATIC: This is something that has plagued me in other projects (usually I just randomly makes things Static until it kind of works) and cropped up again very early here. I've created a Game Manager script that is a central location to store things like the wing count, impressiveness, heat level, etc. My thinking is to store all that info in a single place so that all the GOs that need it can access or change it there. However, when adding a script onto my chicken wings that would increment the wing count on collision with the PMZ, I got my old nemesis: "Unity cannot access a non-static variable in a static context." Excuse me? I didn't tell you to make the chicken wing a static context! You decided that all on your own! 

However, a friend told me that I am, indeed, telling Unity that it's a static context by the way I'm referencing it - directly (e.g. GameObject.staticThing) instead of a new instance of it. I really need to spend more time understanding this, but after considering it more (and being told that it's fine) I've decided to just make it static. This solved the problem of not being able to access it, but for some reason the script isn't successfully changing that field (it does successfully change the heat and impressiveness, though.) That is probably for tomorrow to figure out. 

This is what the script looks like so far:

void OnCollisionEnter(Collision col)     
{        
 if (col.gameObject.CompareTag("PMZ") /*&& isEaten == false*/)         
    {             
        Debug.Log("yummy");             
        GameManager.wingCount +=1;             
        isEaten = true;             
        flesh.SetActive(false);            
        GameManager.impressiveness += 10f;             
        GameManager.heatLevel += 10f;        
     }     
}

This code SHOULD, in theory, detect a collision between the wing and the PMZ, write "yummy" to the console (yes), add 1 to the Wing Count UI (no), increment the impressiveness and heat level bars (yes), and turn off the Flesh component of the wing to expose the bone (yes). 

COLLISION DETECTION: This has been a big day of learning on some of the specific ins and outs of collisions. Once I made my wing object and set it up, I could actually test the above. But all of that functionality depends on a successful collision detection. I first made a PMZ with a semi-transparent material so I could better place it in game. I added it as a child of the Tracking Space, which is a child of the Camera on the player controller. Basically, it moves with the headset. 

At first I set it up as a trigger because I didn't want the hands to be blocked. FIRST TEACHABLE MOMENT - After it failed, I researched and found that if one object is set up with colliders as a trigger and the other is not, a collision will not be detected. No problem - honestly, it makes sense anyway that the player's hand would be stopped by THEIR HEAD, so I decided to change it from trigger collision to a regular collision. 

Didn't help. Nothing happened. SO, I decided to make another little box to see if the issue was with my script or my collider or my GO (there's a lot of fields in the Grabbable component of this framework and they do mess with collisions so it could possibly have been that). 

You can see in the video the flesh disabling -- due to the camera you can't see the UI elements incrementing, but they are. SO I knew the script is doing most of its job. But why was this random cube working and my original GO not?

I have yet to test this out but I think it's because of a SECOND TEACHABLE MOMENT: Collisions made with CHILDREN don't function the same way as they do when the collision is made with the PARENT. In this case, in order to tie the PMZ to the camera, it's a grandchild of the XR Rig. So, I think I need to figure out a workaround - I've read I can add a rigidbody to the parent to solve this problem, but it feels reckless to add a rigidbody to the XR rig wholesale. I will figure this out tomorrow.