Up to Main Index Up to Journal for November, 2012 JOURNAL FOR THURSDAY 8TH NOVEMBER, 2012 ______________________________________________________________________________ SUBJECT: Inventories: The answer's not in the box, it's in the band! DATE: Thu Nov 8 21:03:50 GMT 2012 Wow! - busy week working but I've had some time to work on WolfMUD. At the moment I'm writing tests for the item package. Actually I've been having problems writing the tests due to a mental block. Something doesn't feel quite right and I've had trouble putting my finger on it. The problem is with the get and drop methods. The way they fumble around trying to get the inventory for the issuer of the command feels like a kludge. Finally I think I have an answer: Inventories are going to be pivotal rather than just quite fundamental. Everything can revolve around inventories. Some examples: Moving something from one location to another: Locations have inventories and we simple remove the something from one location's inventory and put it in the other. Someone drops something: We remove the thing from the dropper's inventory and add it to the location's inventory. Picking something up is the reverse. You give something to someone: You remove the something from the giver's inventory and put it into the receivers. Containers have their own inventories. To put something into a container you remove it from the inventory it is in and add it to the containers. Inventories can also be nested. You could have some gems in a leather pouch. The pouch is in a small wooden box. The box is in a sack. The sack is in a chest which is at a specific location. Now I already have inventories which are working well. I can put things into inventories, remove them and check their content. What I need now is a reverse mapping. Things need to know which inventory they are in. One way of doing this would be to add an inventory pointer to the thing struct. Everything is a thing and when a thing is put into an inventory the inventory sets the thing's inventory reference. Another way would be to add an inventoried interface instead of the inventory pointer. Is there a common name for an element in an inventory? On a side note I think I might have modify the command Interface so that process returns handled as well as a success boolean. That way we know if a command was handled and if so was it successful or not - this is going to be needed for chaining commands together, you probably don't want to process a 2nd command if the first failed. Although as success will not be needed most of the time maybe setting an internal flag which can be checked with a method call would be better than returning two results and assigning one to the blank identifier '_' most of the time. -- Diddymus Up to Main Index Up to Journal for November, 2012