koobas.hobune.stream
Force player to keep crouching
I have a script where my controller shrinks when ctrl is pressed and held, and when it is released then the controller is reset to the original size. The only problem is when I make an instance where player has to crouch to overcome an obstacle, if the crouch is released while in a "vent" or "tunnel" the player stands straight up, clipping through the overhanging wall. Is there a way to resolve this?
You could try using a raycast for this.
Instead of having only two states (crouched and uncrouched), you would add a third state, 'uncrouching'.
When the 'crouch' key is pressed, transition to the 'crouch' state. When the 'crouch' key is released, transition to the 'uncrouching' state. When in the 'uncrouching' state, cast a ray straight up from the player; if there is no hit within a specified distance, transition to the 'uncrouched' state.
Note that your player could still clip into geometry by uncrouching while partially under an obstacle (that is, if the player is partially under an obstacle but the raycast misses the obstacle). You could use multiple raycasts to catch some of these cases, or (perhaps better), instead of using a raycast use a box or capsule trigger collider attached to the player while in crouch mode to determine whether there are any obstacles overhead.
I would use a trigger. The player can still hit the button, it just won't do anything. Put a box collider or a collection of box colliders fully taking up your tunnel. Then I would do something like this:
var playerScript : PlayerController;
function Start () { playerScript = FindObjectOfType(PlayerController); //Link to the script that //controls playerCrouching. I can't remember if you need a cast in js. //I normally use C# }
function OnTriggerStay (col : Collider) { if(col.tag == "Player") { //Is the collider the player? playerScript.crouched = true; //keep them crouched. } }
While, that would probably work, I actually think this method may be cleaner. All's you need to do is add a boolean to your player script that will cause the crouch button to be overridden with a false. So, when the user clicks control, you would check that it has not be cancelled by overrideCrouch. So this script, turns it on when you enter, and off when you exit. The only problem I can think of is with overlapping triggers. To fix that, either change the arrangement or put playerScript.overrideCrouched = true in OnTriggerStay which would cost you performance, but always work.
var playerScript : PlayerController;
function Start () { playerScript = FindObjectOfType(PlayerController); //Link to the script that //controls playerCrouching. }
function OnTriggerEnter (col : Collider) { if(col.tag == "Player") { //Is the collider the player? playerScript.overrideCrouched = true; //keep them crouched. } }
function OnTriggerExit (col : Collider) { if(col.tag == "Player") { //Is the collider the player? playerScript.overrideCrouched = false; //keep them crouched. } }
and your player script might look something like:
if(Input.GetButtonDown("CrouchButton") {
if(!overrideCrouch)
crouched = !crouched;
}
Note that this method would require manually placing colliders in all 'crouchable' areas. One advantage of the method I described earlier (assu$$anonymous$$g it works - I haven't tried it myself) would be that no additional design work would be required to support it. You would just build your level geometry as usual, and the rest would be taken care of automatically.
Yes, but this method is more efficient than shooting out multiple rays, and it does not take much effort to place colliders approximately because the messages will be sent no matter how small the trigger collision is.
Edit, and the amount of time it takes to write the raycast script or using Physics.Overlap sphere script, could be used to place the colliders, so the design overhead is negligible.
I would question both those points. Regarding your first point, I highly doubt that performance would be an issue (don't have room here to elaborate though). As for your second point, I think the probability (assu$$anonymous$$g a non-trivial game) of it taking more time to code the system I described than to place colliders manually is low. Plus, there's the burden of having to remember to place a collider in every 'crouch-able' location. But, it doesn't really matter - the OP now has both suggestions, and can use whichever he or she prefers :)
Fair enough. Your points are valid; I'm not sure I completely agree with you, but as you said, the OP has both opinions so whatever works for them.
well i tried the box collider ontop of the player, and the raycast, but to no avail. Im not so experienced with Unity, and certainly not scripting. for me, well atleast for the time being, it would be easier for me to just make colliders and place them in every crouchable location. But as you said, this would be tedious and it would be so much more effective to have it scripted to the player. Im not so good at scripting, but Ill keep trying, if all else fails, I suppose I could place colliders everywhere. :/
You could also try doing a collision check using a projection of the characters true (Idle state) box at the crouch transform position. Or you could mathematically project a fake transform over the positive y axis to determine if increasing the value to that of the original box would create a collision, if so it should maintain the current state rather than return to Idle state.
If you do try this, maybe slightly complex method, be sure you never get conflicting data on which box had what size. Get the information from the source, don't local variable, hardcode or magic number any of them or you will undoubtedly get bugs.
This suggestion puts the work on the script side of the story, not the level generators side, which is a choice you might need to evaluate aswell.
Doing the raycast can be a needle thin line that doesn't match the collision area so you may end up doing again in some thin pipe
