Object commands used to require re-adding every call in the script parent's __init__ or factory functions, adding the commands to a new command table directly on the object. Since all other attributes can be set up in at_object_creation(), this was both inconsistent and a bit confusing to work with. There is now a method add_commands() directly defined on all objects. It takes the same arguments as the normal add_command()o but use a reserved attribute to create and update a command table on the object. This has the advantange of completely removing the __init__ call in the script parent, all definitions can now be kept in at_object_creation() and are, more importantly, persistent without having to be recreated every call.
- I updated the examine command to show all the commands defined on an object (if any).
- I updated gamesrc/parents/examples/red_button.py considerably using the new command methodology and also using the updated Events.
.
Griatch
- Set up a global cleaner event to clean all @destroyed objects every 30 minutes (makes their dbrefs available).
- Added the @recover command for recovering @destroyed objects up until the point that the cleaner runs and actually destroys them. This can recover @destroyed objects, rooms and exits to the same state as before @destroy. It could easily be made to recover player objects too, but I'm thinking this would be a security issue.
- Added to @dig in order to allow for creating rooms with a particular parent. Also auto-creates exits in each room if desired. The only things that is not implemented is the aliases of the exits, I don't really know how to do that.
- Changed the @create command format to match the @dig (it uses : to mark the parent instead of = now, since MUX' @dig reserve = to the exit list.)
- Added extra security in the example event to guard against the bug that causes the whole scheduler to freak out if the event_function() gives a traceback.
- Changed many instances of type to point to the defines_global.OTYPE instead of giving the integer explicitly.
/Starkiel
- 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)
