[Crossfire-wiki] [Crossfire DokuWiki] page changed: dev_todo:centralized_map_passwords

[no-reply_wiki at metalforge.org]

A page in your DokuWiki was added or changed. Here are the details:

Date        : 2007/04/01 01:14
User        : 
Edit Summary: 

@@ -6,31 +6,31 @@
  
  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
+   $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
+   $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}'
+ 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?
  
- 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?
+ 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)
  


IP-Address  : 209.204.178.229
Old Revision: http://wiki.metalforge.net/doku.php/dev_todo:centralized_map_passwords?rev=1175407607
New Revision: http://wiki.metalforge.net/doku.php/dev_todo:centralized_map_passwords

-- 
This mail was generated by DokuWiki at
http://wiki.metalforge.net/