Up to Main Index Up to Journal for September, 2017 JOURNAL FOR TUESDAY 19TH SEPTEMBER, 2017 ______________________________________________________________________________ SUBJECT: Command handling and Inventory clean up DATE: Tue 19 Sep 22:34:34 BST 2017 It has been a week since the WolfMUD v0.0.7 release and I have not heard any screaming or received any angry emails. I take it people are happy. I’m now looking at cleaning up a few things that either became complicated or messy during the work for the v0.0.7 release. First of all I am looking at how command handlers are currently implemented. The motivation for this being the ugly helper functions I added for the JUNK command: junkLockAll, junkCheckVetoes and junkDispose. The helpers should have been methods, however the JUNK command itself is implemented as a function — as are all commands: func Junk(s *state) { … }. This means there is no type to put the methods on[1]. While working on the JUNK command I also discovered that junking, resetting and respawning items are still not working quite as I would like and while working from a player’s point of view there are a few oddities going on internally that I need to address. For example, extra events being triggered only to be immediately cancelled several times over. This seems to be mainly due to too much magic in the Inventory type, specifically in the Move method. As I said a while ago[2]: “All of this is now working, but the Inventory type could do with being cleaned up somewhat — my priority was to get things fixed first. Ultimately the goal is to only allow items to be added or removed from the world via the disabled lists. When items are in the world and enabled they can only be moved from Inventory to Inventory, not added or removed as can happen now. This would make the interface for Inventory types cleaner and simpler and also simplify the code in places — such as the Inventory Move method.” Next, after sorting out command handlers, will be to work on the Inventory type. The Inventory.Move method knows too much about other attributes such as Cleanup and Reset. Each Attribute should be self contained and the commands then act as the glue to make things happen. The Move method adds a Cleanup event to a Thing when it is added to an Inventory. When the Thing is removed from an Inventory any Cleanup events are cancelled and the Thing is also checked to see if a respawn event should be added. All of this should be handled by the GET/TAKE and DROP/PUT commands as only they can actually add or remove a Thing that is an item from an Inventory. It should be noted that the MOVE command can also add and remove Thing from an Inventory — to move players between locations. However, that shouldn’t trigger a Cleanup or Respawn and is currently handled as a special case in the Inventory.Move method. Slowly the WolfMUD code is growing, evolving and maturing. As a consequence issues become more apparent as different areas of the code interact, sometimes in unexpected ways. Some interactions which started off simple become more complex with more side effects. Some interactions need to change in order to accommodate new features. Once in a while you have to step back, look at the overall design, look at the pain points and rewrite some code. The previous paragraph can be summarised as the “What the hell? Oh crap…” moment when you realise things just aren’t going to work the way they are. -- Diddymus [1] I could create a function type — receivers for methods have to be named types. Then I could add methods to the function type. But if I am defining a (function) type anyway why not just define a Junk type on a struct and turn the function into a method on that type — instead of trying to be clever? [2] Journal for Thursday 7th September: 7.html Up to Main Index Up to Journal for September, 2017