How to test NPC Parser

• Play
  • Manual
  • Beginner's Guide
  • FAQ
  • Ask for Help
  • Events
  • Videos
  • Rules
  • Groups
• World
  • Atlas
  • Dungeons
  • NPCs
  • Levels
  • Creatures
  • Items
  • Quests
  • Games
  • History
  • Achievements
  • Houses
• GMs
  • Administration
  • How to be a GM
  • Scripts
  • Guide for admin
• Contribute
  • Chat
  • Bugs
  • Testing
  • Graphics
  • Sound
  • Item Ideas
  • Atlas
  • Creature Ideas
  • Quest Ideas
  • NPC Ideas
  • Events Ideas
  • Achievement Ideas
  • Open Tasks
• |
• Extend
  • How to add items
  • How to add Creatures
  • How to add quests
  • How to add NPCs
  • How to create maps
• Develop
  • CVS (Source Code)
  • Bugs
  • Meetings
  • Testing
  • Code Design
  • Jenkins
  • Ideas
  • Open Tasks
  • Patches
  • API Reference

• Build & Host
  • Building
  • IDEs
  • Hosting
• |
• Misc.
  • Third Party Projects

Stendhal Quests

• Contributor's Guide
• Existing Quests
• New Quest Ideas
• Coding Quests
• Testing Quests
• Quest Histories

After you designed a new NPC conversation, you have to implement it in the server code and test if the NPC understands all the user input like you planned. If you have not already looked at the guides for Stendhal NPC Coding and Stendhal Quest Coding, these could be helpful.

If during testing you find that the NPC is not responding as you expect, you should first check that the flow of conversation states is correct. If you are using standard Producer, Buyer or Seller code, this is already likely correct. Otherwise, the quest tutorial covers the theory and how to test it.

After the conversation states are confirmed correct, you can check is that the NPC is correctly interpreting (parsing) what the player says. To support you in this process there is the NPC Conversation Parser Test Environment (PTE):

You can launch the dialog with the script "runpte.sh" on Unix/MacOS and with "runbte.bat" on windows. This will compile the server and tools part, then launch the Java dialog. It may be even easier or you to run it directly from Eclipse by launching the class games.stendhal.tools.npcparsertestenv.TestEnvDlg .

The dialog displays how the conversation parser interprets user input and gives a hint about not yet known words. You can choose one of the predefined example sentences or write your own text into the input field. This way you can design the NPC conversations and test how the parser reacts on user input. You can see how the parser interprets the text, recognizes the words and merges them to longer expressions. Each expression is assigned an expression type like OBJect, SUBject, VERb or ADJective. If the parser discovers any unknown words, the surrounding expression is displayed in red color. You should add these new words to the word list "words.txt", located in the package "games.stendhal.common.parser" .

In the right window section there are visible the fields Subject, Object, Verb, ... . If the expression type is unique in the sentence, you can immediately see the respective expressions. Otherwise you see the number of expression types.

Currently the most important output for developers may be the "trigger" field in the right bottom of the upper "Sentence" section of the window. Looking at this you can see which trigger expression is evaluated from user input, word list and grammar rules. This is used for matching in the finite state machine.

---

In the "Matching" section located at the bottom of the window you can select an expression type and enter a matching expression. After activating the button "test match" you see if the user input in the upper section matches the expression in the lower section or not. Matching depends on the selected matching type. It says that buy 3,000 cookie matches buy 3 cookies yes this matches when using the standard mathcing method the expressions match, the number is just an attribute. if you use exact matching, it does not match:

• Joker matching allows to use "*" wildcards as placeholder for arbitrary expressions.
• Exact matching only matches sentences if all of the expressions in the sentence exactly match them in the match string.
• Case insensitive matching behaves like exact matching, but does not look on upper/lower case.
• Similarity matching allows the user some spelling errors. It matches if there are not too many character differences in each of the constituting words of the user input string.
• Controlled matching allows to specify the matching type by leading type flags like "|JOKER|", "|SIMILAR|" or "|EXACT|ICASE|".
• Merged expression matching compares the normalized expressions, not looking at e.g. concrete item numbers.

If you use any of this extended matching types in your code, it may be helpful to use the matching string, e.g. "|JOKER|buy * bananas" in the display field.

---

You may also have a look into the documentation of the NPC Conversation Parser to read about internals of the conversation parsing process.