[crossfire] Maps passwords/phrases text

[Mark Wedel]

Nicolas Weeger wrote:
> Hello.
> 
>>   The real solution here is to use keywords instead of the actual word,
>> like $SCORN_PASSWORD.  So you'd have something like:
>>
>> @match $SCORN_PASSWORD
>> you look ok, ...
> 
> Agreed there, shouldn't be too hard. Also makes everything way more souple, 
> not linked to maps.
> Of course, there should be appropriate warnings when a variable isn't found in 
> the substitution file.

  True - as long as some special character is used, that is easy enough to do. 
$ may be just as valid as anything.


>> Method 2:
> <snip>
> 
> I like that method.
> 
> IMO, that could even be done through a small plugin - intercept the 
> EVENT_MAPLOAD and do the substitution.

  I should look at the plugins further.  But right now, there is a 'check 
object' type function in loader.l that is called each time after the object is 
loaded.  Its original purpose was to catch things that changed in various versions.

  Adding the substitution there would be easier, and perhaps faster than a 
plugin, simply because that substitution would be done right after the object is 
loaded, so more likely to have stuff in local cpu cache, vs having to iterate 
through all the objects in the map later.  Plus, you'd have a lot of cases where 
op->msg is null, and checking for that in that function would be very fast - 
while also fast in a plugin, you'd still get the overhead of having to iterate 
through the map objects, so you're spending some extra just going through the 
object points, going through inventories, etc.

  But as I think further, if some defined character, like $ is used to denote 
these, then I think the actual msg parsing code in the lex loader could be used 
to find these, perhaps make it even faster (could get the variable name from the 
lex parser, do a simple btree type search to find what it subsitutes to, and 
copy that in the temp buffer right now - better than doing it later and having 
to make a new buffer because the size is going to be different, and 
copy/substitute at that point).


> 
>> Method 3:
> <snip>
> 
> This method has one drawback, in that it adds some overhead to every NPC 
> talk / magic ear/mouth.
> Note that this is similar to what I did for the quest management stuff, btw 
> (change the message dynamically).

  The related problem with that is that it also means a lot more code needs 
updating - anything that references the op->msg probably needs to be updated, 
where as with method #2, none of the other code has to be touched - everything 
is handled at load time.


> I like both methods #2 and #3, because they give DM some more power over the 
> world. IMO we should move to that kind of system for game-related options - 
> let DMs customize.
> Arguably, it's the role of the server administrator, but he doesn't always 
> have the time for everything, and currently many options require a server 
> restart.
> For instance, if we ever implement shop opening hours, that'd be something I'd 
> let DMs tweak ingame directly :)

  I'd almost say there should be different access levels:

0) Normal player, can't do anything special.
1) 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.
2) 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.
3) Admin access, which can do anything provided through the crossfire interface 
(all dm commands)

.