Feature Request - Door locks

Bugs & Features
1

I feel like I’ve seen this mentioned before, but can’t find it.

A method of whitelisting/blacklisting users from using certain exits in an area/room would be nice - It would make banning users from an area for rule violations easier (IE, just blacklist them from the exit entering the area) or allow for ‘lockable’ doors such as a door in a business going to an Employee’s Only area, or someone keeping their dorm/bedroom locked, etc.

2 Likes
2

That would be this topic. The issue, as mentioned, is how to do it.

In Fuzzball MUCK, locks on exits (usually not rooms per-se) are a feature of the environment and can take a combination of characters and properties on them, with boolean operators.

@lock <object> = <key>
Locks to a specific key(s). can be specified as or #, or as me' or here’. Boolean expressions are allowed, using & (and), | (or), ! (not), and parentheses (( and )') for grouping. To lock to a player, prefix their name with *’ (ex. *Igor). A key may be a player, an object, or `property:value’.

Characters don’t have arbitrary configurable properties here, but they do have IDs. And the latest room scripting updates offer means to lock an exit - even an example!

Some caveats, though: you need to be a pioneer, subscriber or builder to install a script - the first two at least must [temporarily] have ownership of it. The example also doesn’t lock out or allow specific users - that’d require a script testing the character ID within onExitUse of this and cancelling the event if it did or didn’t match depending on what you wanted.

That script could be simplified to call Room.listenExit(exitId) in onActivate(), cutting out the other script and messaging. Or it could lock multiple exits in the room to multiple owners; then you get into array handling. It could be made configurable like the listen script I wrote, rather than hardcoded - that’d be harder but a more sensible approach long-term.

export function onActivate(): void {
	let exit = Room.getExit("EXIT_KEYWORD")
	if (exit) Room.listenExit(exit.id)
}

export function onExitUse(addr: string, exitIntercept: ExitIntercept): void {
	if ('CHARACTER_ID' == exitIntercept.charId) {
		exitIntercept.cancel("The door seems to be locked.")
	} else {
		exitIntercept.useExit()
	}
}

There is a problem in that as far as I am aware you cannot determine whether a character is being puppeted by someone via Room.getChar(id), only via an event (where it’s displayed). On some MUCKs a flag or property can be set to deny puppets access to an room/exit.

There also seem to be a slight issue determining the exit ID, in that list exits does not give the exit ID, while get exit X gives me Access denied, even when I own the room.

This might be a bug because help get exit suggests it should be possible:

get exit <Keyword>
Get info about a visible exit in the room.
Room owners may also get info on hidden or inactive exits.

Perhaps there is an issue with the code added to handle the new type of exits.

Also a bug, at least in my understanding: following characters aren’t tested against the lock. This might be desired or at least acceptable behaviour for a bedroom lock, but probably not an area lock - rather, it should check all parties (since you could make a puppet bring you in, unless it checked, or create/use a secondary character to do it, or ask/trick someone else).

1 Like
3

I assumed someone would come in with ‘Scripting can do this!’.

That’s not… Really a solution though, is it? I mean sure, if it works, it works… But why can’t there be a property on the exit that allows you to select if it’s a white list or a black list, and you type a user name into it. It then grabs the username/ID, same way changing ownership of a room does, and keeps it in the list. Then an if/then statement - If blacklist, and if user uses exit, then display ‘lock’ message.

Or something like that. I’m no programmer, and I don’t know and coding languages - Relying on a script to do it doesn’t seem feasible, as a user like myself wouldn’t be able to easily update/modify the blacklist.

2 Likes
4

Frankly, I agree – locks should be a UI-level feature of the software, or at least adjustable via text commands. This is what can be done now, and perhaps over time a version will become integrated, such that it is more usable without such ‘magic incantations’.

I imagine if we went back to the creation of MUCKs and MUDs we’d see a similar evolution.

For what it’s worth, scripts can be made configurable, as I mentioned. From my noises script:

GreenKai ooc says, “noises”
⌈Usage: ooc noises list — list current noises
ooc noises add <text> — add noise to the end of the list
ooc noises del[ete] <n> — delete noise at index n
ooc noises chance [<n>] — get/set 1/n chance for message to trigger a noise
ooc noises delay [<n>] — get/set seconds to delay until allowing a new trigger
ooc noises sleep [<n>] — get/set seconds from trigger to noise⌋
GreenKai ooc says, “noises add The wind whispers in the leaves above you.”
⌈33: The wind whispers in the leaves above you.⌋

Something like that may be more palatable, especially if available to the whole realm.

1 Like
5

I actually think it’s good enough in that regard, hm. It’s a very specific feature that not anyone needs – most people are just fine with hidden exits. As for the latter, I’d imagine we will see more posts like these that are basically copy-and-paste so that you’re not figuring the scripting yourself.

6

Maybe we should have a ‘Scripting’ category in the forums where such posts can get put and thus found more easily?

1 Like
7

Perhaps. Technically it doesn’t fit the Development category mandate, but I suspect that is just because they didn’t exist at the time, which is why I reported a script issue there last month.

The original poster also did not consider this a request for a script, but for a general feature.

8

It would need to be something easily editable though. Say, for example, if I’ve got a list of banned users to an area - Having to enlist someone else who A.) knows how to script, and B.) can implement/change the script is… Offputting (Speaking as someone with social anxiety who finds it hard to reach out to people for any task, menial or not) , when it could be a feature of the UI that’s easily updated as needed.

In general, I agree about hidden exits - It works fine, except for if you’re actively trying to keep a specific user out. Hidden exits are only as secure as the keyword, and once a user gets that, you’d have to change it.

1 Like