Currently, passwords required on maps map be spread accross many different maps (eg, map A tells you the password that you need to use on map B).
This works fine, but makes it very difficult to change passwords - one must find all occurences, update all the maps, and then hope that future map changes don't create conflicts.
In addition, in some cases, the passwords themselves are not particularly unique words. In the case of the scorn town gate, the password is 'chain', which could match other messages related to chain mail, etc.
The idea here is follows: Passwords (or other phrases) are placed in the map msg fields with tokens, like $SCORN_PASSWORD There is a centralized file (map/passwords?) that enumerate these passwords, eg:
$SCORN_PASSWORD=chain $WHATEVER=foo bar
During server startup, it reads this password file and records these pairings. Perhaps it also re-reads this file on demand as a DM action.
When a map is first loaded from disk, the loader does special handling with any objects with msg fields - it looks for the keywords, and then does a substitution. I would suggest that it in fact looks for the $, and if it finds then, then matches up on the word.
Note that these phrases do not need to be a single word. EG, this would be valid:
$SKELETON1_RIDDLE=What is at the start of end and the end of time $SKELETON1_ANSWER=e
There should perhaps also be DM commands so that the DM could decide to change the scorn password. However, if this was to be persistent, then perhaps a secondary password file (stored in the var area) is needed, and server reads both on startup. The map file could be copied to the /var area on installation, but that could once again lead to messier merge issues - it is probably safer to have two password files - one distributed with the maps that list all the known variables with default (current) values, and then a second one that overrrides those default values.
As far as implementation steps:
- Update the server to do the substitutions - I suggest this is done in C code, as it can be done as each object is loaded (or perhaps even special handling in the msg/endmesg area of hte lex loader looking for $). Some shortcuts could be done, like 'if op→msg && op→msg != op→arch→msg { look for $, do substitution logic}'
- See if the editor can be modified/updated to handle this logic, to make it easier for map makers to set this up and manage it.
- Start updating the maps, making the changes for the keywords. I'd suggest doing it by passphrase and not map (eg, update all occurences of chain, and not do a map X is now clean, but still have other references on other maps. Reason here is that if a passphrase is only half updated, it can't really be tested (changing in the password file won't work). I'd suggest that perl script looking for all @match entries (or perhaps pull all msg/endmsg data) from the maps could be done, to make this task easier. A fair number of conversations are clearly not candidates for this (telling players about quests).
- Maybe extend this logic to the slaying field of objects, so what certain NPC wants to give information could easily be changed?
As far as DM or ability for players to change these passwords, there should perhaps be different access levels:
- Normal player, can't do anything special.
- Extended access granted through in game mechanisms (finishing quests, etc) which provide access to a limited set of changes (lords of scorn changing scorn password, or maybe changing business hours, or perhaps even shutting down shops temporarily). This adds some interest in that by doing some in-game stuff, you can have more noticable effects on the game world.
- Wiz access granted by server admin. These people would have access to everything/every region of #1 access (change passwords anywhere) plus some extended access (summon players, item creation, etc). There may be some wiz commands not available, like shutdown, which these people generally shouldn't have.
- Admin access, which can do anything provided through the crossfire interface (all dm commands)
