-
Notifications
You must be signed in to change notification settings - Fork 12
Features
- Theme Files (Interchangeable)
- Dynamically Editable Help Files
- OLC/In-Game Editor
- In-Game Mail System
- In-Game Message Boards
- Account System
So, what's a theme?
A theme is a configuration file that defines some basic world related stuff, like:
- which motd/banner file you want (example path: \motd<filename>)
- the starting room to drop new players into (a crude way of handling this)
- the world directory to use
- which database file you'd like to have loaded
- calendar definition (number of days: in a month, in a year; date reckoning; start year and season)
- a reckoning (you know like A.D - Anno Domini and in the case of D&D, DR - Dale Reckoning) currently limited in length.
- month names (hardcoded to 12 for now in the source code), year names (specifically name a year)
- named dates (i.e. holidays, etc)
Okay, so a primitive line editor is fairly painful to use (boo!), but if you have direct access to the game's files you can just use a normal text editor (yay!). Once you've edited the file to your heart's content, you can type 'help @reload' from inside the game (or if you want to, you can restart the game) and it will reload the help files. Just test the changes with 'help <command/command alias>' to see the changes.
- Help files only exist at present for commands.
- Help files are currently named after the name of the command, so '@dig''s help file would be named '@dig.help'
- Generally speaking, you must know the full name of the command (not the alias) to access the help file for it.
Only staff with BUILD or higher permission (access) level can reload help file.
There is support for editing certain types of MUDObjects inside the game, although it only works reliably for Room(s). It is command based, but operates within it's own mini-environment. When you type '@redit <room name/dbref' you are placed in editing mode and provided a restricted set of commands that only apply to the room editor. Changes are temporary unless saved ('save' or 'done') and a successfully executed command outputs 'Ok'. It's important to note that none of the normal game commands will work within this environment even though you are logged in.
This system resembles, vaguely, Diku/Smaug OLC in that you are permitted to edit a certain subset of an object's properties/fields. However rather than typing the whole command at once like they do (see example1), my system requires you to enter "room editing mode" and then use room editor commands to modify the room, and then (after saving?) finish and exit the room editor (as seen in example 2).
Example 1
redit name The Captain's Room
Example 2
@redit room
name The Captain's Room
done
The 'done' command both saves the room and exits the editor.
For more information and details, see: Room Editor
Again, a bit primitive, but it's there. Accounts can be created via the @accounts command, but it has to be done so by hand and the player must also be manually linked to it. Obviously, that is a somewhat painful process, but as noted this is a work in-progress. Once an account exists, however, it is possible to login to it in the same manner as you'd connect to a player at which point you can select a player from the menu presented and get into the game.
At the present times, Account(s) are not persisted well across server reboots. They are, however, saved to files (nasty Java serialization) and recreated from those files. Unfortunately accounts loaded in such a manner don't do the greatest job of ensuring the appropriate characters are linked to them.
Spells - I'd like to make it so that having a 'passwall' spell is actually viable. [Passwall] (http://www.d20srd.org/srd/spells/passwall.htm) is a D&D spell, you can see some information at the link. Some framework creation will be necessary, since at the moment only spell objects and a couple instanteous effects are implemented. For instance, there is no hook into the time loop for a timer on a spell. That means there is no convenient way to track when the spell will expire. Perhaps it could be marked with a start time and that time cross checked against duration whenever necessary to determine the remaining time or if the spell should dissipate.