Idea: exit and program restrictions about fuzzball

[tanabi]

We can't deprecate the guest/vehicle/zombie flags for rooms - that is widely used (I use it on my own MUCKs and I've seen it used elsewhere). That's one of those things that would sneakily break something :) And it doesn't hurt anything to keep it.

Regarding flags on exits, I largely agree to the utility -- I am unsure what "cannot be forced" would stop on an exit ? Because you can't force exits or programs? -- and I don't think any of those flags are currently used on exits so we might just want to straight up implement it. I don't see a harm or need to make it tunable; if anyone can do it for a room today, they may as well be able to do it to exits too.

Devil's advocate time - the alternative would be to improve @lock to be able to lock on flags and/or MPI. I believe we already have an issue to make locks work with MPI. If locks worked with MPI, then {flags} and a somewaht clunky set of string comparisons (... MPI doesn't seem to have a check-if-flag call) could be used to do the same thing.

That said ... as the kids say, por que no los dos? Doing it one way doesn't exclude the other, and implementing flags on exits is relatively simple from a code perspective.

Anyway, I'm rambling now: the TL;DR: I think we should implement the flags on exits and this is a good idea, and I don't think they need any proplist/@tune parameters, just implement it straight up. Not everything has to be configurable, and this is expanding on an existing idea of the same ilk with no potential harm that I can see.

[wyld-sw]

Agreed on the room flags; I should have thought about that more before suggesting. Lots of early-morning obfuscation in this Idea.

For clarification:

• "cannot be forced" should have been stated as "cannot be used by an object being forced"
• programs with a no-vehicles or no-zombies mark would be a second line of defense against people linking their own exits.

But probably those are limited use cases. Not doing them solves the "these flags are already used by these objects" problem that made me suggest a property to track them.

We can certainly add an MPI-parsing option to @lock, and an easier "check_flag" function.

[tanabi]

Oh I see, I think I misunderstood your proposed scope.

I was thinking you were going to add these flags just to exits, which don't use any of the proposed flags I don't think.

You're talking about putting them on programs and other objects that DO use those flags, too? Hmm. I'm not sure that's practical or even necessary ... to block a zombie from a MUF program, for instance, is a simple:

me @ "z" flag? if exit then

While I know not everyone is technical enough to know how to do that, I think the audience that would care about zombies using a program probably would. Or simply don't allow people to link to the program :)

If we do add an MPI call, should probably call it {flag?:...} to make it match the MUF. :D

[wyld-sw]

That's fair. Ok, this becomes:

• Add lock-parsing to MPI (already an Issue)
• Add a {flag?} MPI function (this probably will initially have duplicated code in it)
• Add G, V, and Z to exits to prevent their use by those flagged objects a la rooms.

[tanabi]

Perfect! {flag?} is a different issue, I'll go ahead and put this in. And then this issue can become bullet 3 on your list there.