Hi all. Since my last post, my team has convinced me to switch to Unity3D from my own homebrew engine. So, I'm in the process of reimplementing some features that I had completed in my engine. Specifically, automatic doors and ladders. I'm using a pair of raycasts, one in either direction from the player center (at least, I think its from the player center) to detect appropriate "interactable" objects as follows:

Physics.Raycast(thisTransform.position, -Vector3.right, out hit, rayInteractableDistX, InteractableNonGroundMask) for left and

Physics.Raycast(thisTransform.position, -Vector3.right, out hit, rayInteractableDistX, InteractableNonGroundMask) for right

Where thisTransform is the player's transform. The problem I'm having is that these raycasts don't seem to work when the player overlaps the target object (ie: When the player is standing in the middle of the doorframe). Because one of the ways of exiting climb mode is to not be touching a climbable anymore, this is entirely preventing climbing from working, and seems to cause the door to close on the player as well.

What am I doing wrong?

Update: I've read that Physics.LineCast should do the trick, because it will detect anywhere on the line, however it doesn't seem to be working.

My objects are all configured as triggers so that won't work. I did, however figure it out after some experimentation and research. It seems, and I'm not quite sure why, that LineCasts don't like to detect things approaching from the side of their start (ie: line from left to right, it didn't want to detect things coming from the left). The way I got around this, in a way that allows detection from any position within the desired area (including the center) was to do two line casts, one from either side of the desired area and spanning to its opposite. This is quite functional, though admittedly rather inefficient.

That's an interesting thought. It would probably be a bit more complicated to code, since it would need to distinguish between the various types of colliding objects and figure out which ones it cares about after the fact, but doable. I don't what, if any, practical benefit there'd be, but its worthy of some research. <bookmarks discussion for future reference>

Because the interactions involved aren't simple if collided do this. There are other characteristics and controls involved (though nothing unmanageable). However, any difference in complexity is probably not terribly big, since I'm already using SendMessage -- the piping for figuring out when/how to send the messages would just be different. I'll almost certainly end up rewriting bits of the code for greater efficiency as I add more capabilities to it, so who knows what the final form will look like.