Up to Main Index Up to Journal for October, 2019 JOURNAL FOR FRIDAY 18TH OCTOBER, 2019 ______________________________________________________________________________ SUBJECT: Remaining commands now updated with matcher DATE: Fri 18 Oct 19:46:44 BST 2019 Over the past week I’ve been working on updating the remaining commands to use the new matcher code. Changes for OPEN, CLOSE, EXAMINE, JUNK and READ are now on the public dev branch. Tests for those commands are still being worked on. In fact I may have jumped the gun a bit there as I want to write the tests for the old version of the commands and then add the matcher tests. That way I can make sure the new version of the commands work like the old except for the expected changes. Hope I can still manage to do that without screwing up the git repository history. I’m thinking of branching from commit f5fc8eb, writing the old tests, merging in dev to get the new commands, then updating the tests for the matcher changes, finally merging everything back into dev. An arse about face way of doing it, but I really want to get these changes out. The code for all of the commands is still very verbose and needs some cleaning up. A lot of duplicated code needs to be consolidated and simplified. However, all of the current commands now work with the matcher code where appropriate. The commands in general work, some better than others. The OPEN and CLOSE commands still cannot refer to doors using a direction qualifier. The READ command is particularly broken and could use a little TLC. For items written on, like scrolls and papers, READ works okay. For items that are written in, like books, READ doesn’t work so well — it depends a lot on how the item’s description and writing attributes are phrased. For items that have narratives with writing on them, like a chest with a plaque or a package with a label, READ is terrible. Consider these two items: %% Ref: O1 Name: a scroll Aliases: SCROLL Reset: AFTER→1m JITTER→1m Cleanup: AFTER→1m JITTER→1m Writing: It says "Wanted! Brave heroes for dangerous work!". This is a small, dirty, yellow scroll of paper. %% Ref: O2 Name: a book Aliases: BOOK Reset: AFTER→1m JITTER→1m Cleanup: AFTER→1m JITTER→1m Writing: The book is about a brave knight going off to fight dragons in distant lands. This is a small book with a hard cover. The cover is decorated with a knight's helm and the title 'Here be dragons'. %% First the scroll: >exam scroll You examine the scroll. This is a small, dirty, yellow scroll of paper. It has something written on it. >read scroll You read the scroll. It says "Wanted! Brave heroes for dangerous work!". Next the book: >exam book You examine the book. This is a small book with a hard cover. The cover is decorated with a knight's helm and the title 'Here be dragons'. It has something written on it. >read book You read the book. The book is about a brave knight going off to fight dragons in distant lands. The book description, when you examine it, is not referring to what is written on it, but in it. The trailing “It has something written on it.” has been added because the book has a writing attribute for the story in the book. The trailing text does not refer to the book title on the book. At the moment it’s not possible to read something on something. For example if we have a narrative plaque on a chest we can’t say we want to ‘READ PLAQUE ON CHEST’. We can sort of bodge the issue by having a location with a narrative plaque and narrative chest at that location. Then ‘READ PLAQUE’ would work, but the plaque would not be on the chest — if the chest was to move the plaque would not move with it. It could look like the plaque was on the chest by calling it ‘a plaque on the chest’… ugh! messy :( For the chest and plaque example I could tweak the READ command so that if you used the form ‘READ <item> ON <item>’, with ON being optional, it would work. The plaque would then need adding as a narrative to the chest’s inventory. What if you had a plaque on a stone statue? You probably wouldn’t want to add an inventory to the statue just to add the plaque to it — otherwise it would become a container you could PUT items into or take items from. Inventories are quite basic at the moment and have no capacity. If they did we could set capacity to zero. How would we specify capacity? Maybe as a separate attribute? Not sure, but we would need to handle at least two different types of containers: those that contain items and those that contain portions of an item. For the latter I’m thinking of items such as bottles and jars that can contain liquids, powders, granules and other substances that can be gradually emptied as their content is used up. For example a water bottle, when full, could contain four ‘portions’ — allowing a player to drink from it four times before the bottle was empty. For now things are as they are, with plenty of room for improvement :) Only 13 days left till Halloween… /\oo/\ -- Diddymus Up to Main Index Up to Journal for October, 2019