So, I have an object, an animal pen that contains animals. It is basically an enclosed fence.

I do not want the player to be able to open or close the pen, but it makes sense to give them that option to try it. I cannot add a verb 'open/close' which makes the most sense to me because it conflicts with the built-in open/close. I know I can edit 'built-in' responses but that won't work with multiple containers that I want to function normally.

Once I add the container feature, I must click on an option similar to 'can be open' and 'can be closed' because if I don't, the built-in version tells me that it cannot be open or closed when I try to do so. If I do check the box, I can get the custom message to print, but now if I try to open it twice in a row, the built-in message rears it ugly head again and prints the built-in 'it's already open' message instead of my customized message.

And to boot, whenever you change to a different type of container it does not wipe the old container attributes away, but stores them in the attributes which really gum up the effort. Whenever I mess with a non-traditional container, I usually end up just deleting the whole thing and starting over. Repeat. Repeat. Repeat until I stumble on to a working solution or give up on it and pursue a different route.

I just want a container that responds to 'open [container]' with a customizeable message but will not trigger the built-in open object scripts.

It's late. I'm rambling. The answer is probably quite simple.

If you run a script with your customised message " You cannot open it " plus another script closing the pen, the pen will reclose. The scripts will run almost simultaneously.The player will never be any the wiser that it opened briefly.

Clicking the container feature only changes what you see in the editor; it has no effect in the game.

I too had noticed that old attributes hang around with containers and an mess them up. A solution of sorts is to go to the Attributes tab and delete them yourself, if you can work out which they are (the ones in grey are inherited, so ignore them).

With some container types when the player does OPEN, Quest will open them first and then run the custom script if it exists. Openable/closeable are different, they open if there is no script, and only run the script, without opening the thing, if there is. So in fact this is easy to do, just set it so it can be opened, but give it a script that does not set isopen to true.

@ Father, if I understand you correctly, I printed a custom message message with a close pen script as a result to the player typing open pen. It crashed. I thought it was a coincidence so I did it again and again and again and it crashed each time. lol

@Pixie, I will delete my pen object and select it as an openable/closeable container and do as you suggest. I will let you know that it works.

EDIT: Well, opening it gives me the proper response, but if I try to close it, it spits out the "It is already closed" built-in response. If I set it to 'open' in the GUI, the reverse happens. Would it be easier just to set my responses as a command? I set it as a command and things are working fine. Should have considered it less than 30 minutes into my frustration! =/

I find that quite a few things other than containers still hold on to mistakes deleted and corrected. I too find it best to delete the whole object and start again. Verbs messed up are impossible to delete on line.