#471 NPC 'match' facility wildcard '*' badly implemented.

server (365)

Out of self defense during a map editing session, I wrote a bit of controversial documentation in "Section I. NPC's Speak out" of server/*/doc/Developers/objects. Some outcry was generated that a faulty behavior was now documented. To address the documentation issue, and to offset the fact that buggy behavior is "documented", and, as at least one developer puts it, is "now part of the specification", I hereby open this bug tracker.

When this issue is fixed, please fix the documentation to accurately describe the corrected implementation.

I include here the relevant documentation entry as a description of the bug, but, succinctly, to fix the bug, the match facility should implement use of the wildcard character to better emulate simple regex rules.

Some discussion was had on IRC that mentioned a possibility of using a GPL regex library to properly implement regular expressions altogether. One was identified as a possibility, but presently I do not have a link/reference at the ready.


I. NPC's Speak out

The message structure in a monster may contain:
@match <key>|<key>[...]

This identifies what the monster will say if talked to with a text that matches
any keys. They keys are processed as primitive regular expressions, so some
characters act as match operators or metacharacters. The asterisk, caret,
square braces, and dollar characters are useful to some degree.

An example of usage:

@match hello|hi
Welcome, good friend!
@match bye
@match sss
Whasssamatter? You got a lisssp or sssomething?
@match yes
Sssorry, me too.
@match ^no$
You're lucky!
@match *
What did you sssay?

a. Wildcard Character

BUG ALERT!!! A key containing only '*' will match anything, but it is not handled in the same way that regular expressions are normally handled! This can only be considered erroneous behavior. The following paragraphs in this section shall not be construed to be an acceptable design for the server. For immediate best immediate results, do not use the wildcard character except in the form '@match *' to avoid setting up conversations that do not function correctly. On the other hand, do use it in expected regular notation form, and do fix the server code bug.

If a message does not contain an '@match *', then the first key that contains an asterisk will be treated as though the key was '*'.

In the example below, if the player says anything, the NPC will say 'Nice tune...' no matter what the player says, even if it does not end with 'bug'. It will not be possible for the NPC to say 'Bah, humbug to you!'.

@match hum*
Nice tune...
@match *bug
Bah, humbug to you!

Avoid using '*' except in the form '@match *'. If the above conversation were amended to also contain a '@match *', neither the 'hum*' nor the '*bug' keys would work.

In fact, '*' is not needed as used in the above examples since '@match sss' operates the same way as '@match *sss*' would be expected to operate in a
regular expression. Because of this, be especially careful with short word matches like yes/no answers to questions. '@match yes' triggers when the
player enters any word with 'yes' in it! If a conversation contains the word 'yesterday' or 'nobody', the player might type one of these words and the NPC
might think they said 'yes' or 'no'.


  • Mark Wedel

    Mark Wedel - 2007-09-18

    Logged In: YES
    Originator: NO

    I suspect the correct answer is to use proper regexp for all NPC conversation. It probably wouldn't be much work to write a simple script to clean up all the @match * lines to be @match .* for example.

    I'm not sure how complete the regexp routines in the common/regex.c file are - I believe they were originally pulled from glibc many years ago, or some other open source.

    My linux system has regexec() as a library routine, and it appears part of POSIX, so should be pretty standard. Might be best just to use that.

  • David Delbecq

    David Delbecq - 2007-11-20

    Logged In: YES
    Originator: NO

    There seems to be a windows port of it:

    so we could use it without breaking windows compatibility (just one more GPL dll to windows installer)

  • David Delbecq

    David Delbecq - 2007-11-25

    Logged In: YES
    Originator: NO

    There is a problem, if we implement regex, regarding messages in the form

    @match hi|hello

    This would match the following strings:

    but neither hi nor hello, because the '|' character is used at character level. So it need to be changed to

    @match (hi)|(hello)
    and a fixing script might take longer to write, not to mention problems for mapmaker where this notation is less immediate.

  • Kevin R. Bulgrien

    Logged In: YES
    Originator: YES

    It seems appropriate to have the freedom to state that the match strings be preprocessed to a small extent to avoid a need to over complicate the OR matching currently in use to avoid the issues tchize describes.

    It should not be that hard to transform

    @match hi|hello


    @match (hi)|(hello)

    before passing the @match string to the regex handler. In fact, this doesn't even have to be that smart as regex treats ()|() the same as (())|(()).


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks