[Crossfire-wiki] [Crossfire DokuWiki] page added: dev_todo:centralized_map_passwords
no-reply_wiki at metalforge.org
no-reply_wiki at metalforge.org
Sun Apr 1 01:06:49 CDT 2007
A page in your DokuWiki was added or changed. Here are the details:
Date : 2007/04/01 01:06
User :
Edit Summary: created
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:
1) 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}'
2) 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.
3) 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).
4) Maybe extend this logic to the slaying field of objects, so what certain NPC wants to give information could easily be changed?
IP-Address : 209.204.178.229
Old Revision: none
New Revision: http://wiki.metalforge.net/doku.php/dev_todo:centralized_map_passwords
--
This mail was generated by DokuWiki at
http://wiki.metalforge.net/
More information about the crossfire-wiki
mailing list