Lock/unlock doors?

GeometriX

Hi everyone,

I'm struggling to wrap my head around what I thought was a simple challenge: I want to be able to lock certain doors (hinged moveables, created by following the AC tutorial) (and probably also drawers at some stage) to prevent the player from opening them.

I've positioned a hotspot around the door mesh and made it the child object of the draggable, so that it rotates with the door. I can use this to trigger a use event: something like "play dialogue about locked door, then set the track back to 0 position", but the player can always wiggle the door open with some creative clicking.

In short, I suppose something as simple as being able to enable and disable the moveable would be what I need, or being able to set the max speed for the moveable at runtime (toggling between 0 and 200, for example). Does anyone know how to do this?

Thanks!

Xidore

The physics demo has locks. Have you looked at it to see how it is done?

GeometriX

Thanks @Xidore, I hadn't looked into it too much, actually. Doing so gave me some decent clues, but for the life of me I can't figure out how to replicate it.

I dug through the actions and it looks like simply sending a "turn on/off" message to the moveable object enabled the dragging, but I can't determine what turned it off in the first place. When trying to replicate it in my own project, I tried sending a "turn off" message on start, and I set the moveable state on start to off. Neither works - the moveable can always still be manipulated by the player.

GeometriX

Okay, I've done some more digging and I think I have a better idea of what's going on: in order for the locking to work, the child mesh object has to be in the same layer as the moveable object (via that tickbox "Place children on the same layer"). But when I do so, turning off the moveable (either through the initial state or an action) moves both the moveable and the mesh to the Ignore Raycast layer; I guess that's what "turn off" means - makes sense.

Now I have two problems, one of which I suspect is a bug:

1) With the mesh inheriting the placement on the Ignore Raycast layer, it's now invisible, although it at least still blocks the player. Is there any way to force it to be visible?

2) What I suspect is a bug. I also have a hotspot in the hierarchy: it's the child of the mesh. This hotspot is parented to the mesh so that it moves with the door as it swings open. When the player doesn't have a key for the door, it pops up a dialogue saying "it's locked", but the player can click blast through this to force the door open. It's as though interacting with a hotspot that's the child of a physics object actually affects the physics object. This happens whether or not there are any actions assigned to the hotspot. If the hotspot is moved above the moveable in the hierarchy, this doesn't happen.

ChrisIceBox

1) Placing a mesh on the Ignore Raycast layer won't cause it to be invisible - something else must be contributing to it.  How are you changing it's layer, and does the mesh have any other scripts attached?

2) I don't know what you mean by "click blast", but if de-parenting the Hotspot works then I'd recommend doing that.  Adding colliders in parent-chains in Unity causes them to contribute to parent Rigidbodys etc, so you sould keep them separate if possible.  A simple script attached to the Hotspot could keep it's position relative to the moveable object, making it appear parented in-game.

However, know that you can also assign an "Interaction on move" ActionList to your Moveable that runs whenever the player controls it.  This has to be a non-blocking Interaction (set to Run In Background in it's properties), so that it doesn't interfere with gameplay.  But in it, you can do a Variable: Check to see if the door is locked, and then run a new ActionList that closes the door and gives an "It's locked" response.

GeometriX

1) Oh, damn, I see what's causing that. I'm using UFPS, I had to hack it to put its player into the Ignore Raycast layer to prevent the player collider from blocking hotspots that were very near to the player. Doing so has obviously had a knock-on effect where the UFPS camera is told to cull the whole layer on which the player is, to prevent the player model from popping up in the camera. I'll deal with that separately.

2) Okay, no worries then. I wasn't aware that children objects affect parent objects in physics parent-chains. I'll follow your advice and manually move the hotspot.

I did what you suggested and set up an action list to run on move, together with a separate action list to close the door. It's working now! Many thanks, as always!

ChrisIceBox

You're welcome.  I don't know if will help with 1), but you can change the layer that Hotspots are placed on when active in the Settings Manager (by default, it's "Default').