Added AttrKeys and FlagKeys - locks depending on the value of the unlocker's attribute or if they have a flag set.
Finally I updated @lock to handle all these lock types. There are a large amount of possible configurations though, so more testing is needed.
/Griatch
The main command to use is @lock, which accept three types of locks at the moment, and three types of keys:
Locks: DefaultLock, UseLock, EnterLock
Keys: ObjectIDs, Groups, Permissions
This offers the most useful functionality - stopping people from picking up things, blocking exits and stopping
anyone from using an object.
If the attributes lock_msg, use_lock_msg and enter_lock_msg are defined on the locked object, these will be used
as error messages instead of a standard one (so "the door is locked" instead of "you cannot traverse that exit").
Behind the scenes, there is a new module, src/locks.py that defines Keys and Locks. A Locks object is a collection
of Lock types. This is stored in the LOCKS attribute on objects. Each Lock contains a set of Keys that might be
of mixed type and which the player must match in order to pass the lock.
/Griatch
- changed @chperm to @setperm to avoid confusion with channel commands
- added @setgroup command for adding user group permissions
- Moved permissions/group setup into settings file to allow admins to tweak without going into evennia engine.
- Add all new players to default permission group (defined in settings)
- Defined a basic group hierarchy, removed permission 'genperms.builder' in favour of a group named builders instead, containing all relevant permissions.
- Filtered out all django's automatic permissions in @setperm/list to make permission system more controlled by admin.
- Probably fixed bug that caused new users to not be signed up to channels (more testing needed)
- Added Exception handler in unloggedin method create, this was killing tracebacks upon user creation.
/Griatch
- Made it so user #1 is also affected by the on_player_creation() function.
- Added an event folder for custom events, including a working example
- Expanded the example commands and parents to include the changes to how they should be initialized.
- Added an optional ansi scheme (not active by default)
any arguments to the default static mux topic list instead. The dynamic index
is a bit overwhelming. It's reachable from "help index" See also "help help" and "help help_staff".
- expanded help command, allowing adding, deleting and appending to help the help database
- auto-doc functionality using the __doc__ property of commands
- markup in help text for creation of multiple help subtopics at once
- dynamic help index (use 'help topic' to get the normal mux topic list)
/Starkiel
As a side-effect of all of this, logging in more than once acts as behaves now. Also, this will allow things/rooms/exits (IE: not players) or un-logged in players to run commands or be forced to run them via @fo. All of this will bring us more in-line with MUX behavior.
It is important to note that these are currently un-modified MUX2 help files. There are a lot of things that are not applicable, incorrect, or only partially correct. It will be an ongoing project to clean these up.
- The command handler has been drastically simplified. We were doing way too much processing in the handler that should have been done in the individual command functions themselves.
- The 'cdat' dict we were previously passing around has been replaced with a Command object that has useful methods for performing some of the parsing command functions will probably want to do from time to time.
- All commands were updated to use the new Command object, tested, and cleaned up in general.
- A lot of formatting was cleaned up.
- A lot of previously un-found bugs and limitations were fixed.
- The 'page' command has been broken out into its own file, since it's going to have a number of functions that would otherwise clutter commands/general.py.
Expect a commit (probably later today) that will clean up the second half of cmdhandler.py.
