Fixed bug in create_object that sometimes caused rooms to be created with a location !=None
Expanded @destroy to better handle names and not just dbrefs.
/Griatch
Added the permission genperms.admin_nostate so that builders can avoid entering a state when working on a room with a state-changing parent. Superusers have to set the flag ADMIN_NOSTATE on themselves to achieve the same effect (this is necessary since superusers always have all permissions, so they would otherwise never be able to enter states).
/Griatch
The main drawback of multi-word commands are that they can not have any switches; they are intended for in-game use (in states and on objects). Use normal one-word commands for administration and more complex commands with many options.
/Griatch
The help entry database structure has changed! You have to resync or purge
your database or your will get problems!
New features:
* Help entry access now fully controlled by evennia permissions
* Categories for each help entry
* All entries are created dynamically, with a See also: footer calculated
after the current state of the database.
* Indexes and topic list calculated on the fly (alphabetically/after category)
* Added auto-help help entries for all default commands.
* Only shows commands _actually implemented_ - MUX help db moved into 'MUX' category
which is not shown by default.
* More powerful auto-help markup - supports categories and permissions (and inheritance).
* Global on/off switch for auto-help, when entering production
* Auto_help_override switch for selectively activating auto-help when developing
new commands (like the old system).
* Refactored State help system; no more risk of overwriting global help entries.
* State help now defers to main help db when no match found; makes system more transparent.
* State help entries also support categories/permissions (state categories are not
used much though).
Other updates:
* Added more commands to the batch processor
* Many bug-fixes.
/Griatch
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
You can also view all groups and their permissions. At the moment groups have no permissions assigned to them from the onset though, so groups are not very useful out of the box.
.
Griatch
are the commands:
entermenu (shows a simple menu system)
enterstate (enters one of six different states with descriptions and hints of usage)
Leave all states with @exit.
/Griatch
* Added @copy command (builders only)
* Moved the greeting for first-time logins into a hook in basicplayer
* Fixed bug in @set to handle whitespace better
* Added the /drop switch to @create
/Griatch
The @dig command now accepts the specification of parents for all entries (room and all exits). In principle it also supports ALIASes for each exit, but the ALIAS attribute does not seem to be operational at the moment.
/Griatch
Other small bugfixes, fixes to @dig to properly call creation hooks of all newly created objects (it was not setting anything before). Also fixed some of the annoying bugs around using several of the building commands that didn't properly handle spaces around the separator = symbol.
/Griatch
of any desired attribute. Default is searching by name, as before. This
makes it easy for admins to search for objects and also for using other
attributes than names as primary identifiers (short descriptions comes to
mind).
/Griatch
after one another several times. IMC is not seeing the IRC channel name anymore, output should be on the standard
simple name@MUD: msg format as far as IMC is concerned.
/Griatch
from a special-format batchfile. It is intended for large-scale offline world creation (especially things like room descriptions),
where a real text editor is often easier to use than online alternatives. The @batchprocess also has an /interactive mode which allows
stepping through the batch script, allowing to only execute selected entries; e.g. for editing/updating/debugging etc. There is
an example batchfile in the gamesrc/commands/examples directory.
/Griatch
This uses exact-match-first fuzzy matching as discussed in previous commits. It also
use the match order to present a list of options to narrow the selection down - the user can
then specify the choice by appending the correct number to the query.
Example: objects: [box,box]; searching for "box" gives a multiple match error, which presents
a list looking like "1-box, 2-box". The user can now just write "2-box" to choose the second
box. Showing dbrefs is perhaps even more universal, but revealing the underlying data structure
to the normal user is not really good practice - dbrefs is only something builders and admins
should have to know about ... (IMHO).
/Griatch
For example, before the fix, you could face the following issue: Create a bunch of boxes with @create:
box, box1, box2, box3 ... Now try to examine 'box'. This would not work - the game would tell you that there
were multiple matches - it just found "box" in all entries and went with that. So despite there only being one
thing named solely "box", you could not target it! This fix resolves this by giving precedence to exact matches
whenever they exist. I have only done it for the support routine behind local_and_global_search() though, there
are other search functions that uses django directly for fuzzy __in searches. I don't know how to add a similar
functionality to them.
/Griatch
At the moment this only works with the initial IRC channel (the one set in preferences),
those channels you add later with @ircjoin does not add as Services; when setting it up
they add just fine, but the bot does not connect - I don't know why (code is commented out
in src/commands/irc.py).
/Griatch
