Up to Main Index Up to Journal for July, 2015 JOURNAL FOR TUESDAY 21ST JULY, 2015 ______________________________________________________________________________ SUBJECT: You want it all? You can't have it all! DATE: Tue 21 Jul 20:48:18 BST 2015 Back and coding again after getting rid of the dreaded lurgy. Working on the commands and exit changes and while doing so came across an old issue I thought I'd sorted out. There is still an issue where a Narrative attribute can be confused for an Inventory attribute - in fact I still have a BUG tagged in the 'look' command source. I've also been asked if I will be implementing the 'ALL' behaviour for commands as implemented in the Java version. Also will I be implementing multiple items for commands. Some examples: GET ALL GET BELL BOOK CANDLE There is actually a bigger issue here - that of players 'competing' over items. If two players type 'GET ALL' at the same time who gets what? Does the first player picked get everything? What happens when you have a player on a much faster or slower connection? As I see it there should be some fairness and a level playing field for all. So I've given this some thought. One of the first things I think should be implemented is command rate limiting. So you can issue a whole bunch of commands - maybe the client you are using lets you define macros - and they are queued up and executed one at a time but no quicker than, say, one command a second or something. This would level the playing field a bit for slow or fast connections - or clients with macros. This then leads to a solution for the 'GET ALL' and 'GET BELL BOOK CANDLE' examples above. What could happen here is that the ALL examines the location and finds the items 'BELL', 'BOOK' and 'CANDLE'. Then the commands 'GET BELL', 'GET BOOK' and 'GET CANDLE' are queued up and carried out. For the second example the same commands are queued up and carried out for the specific items. In effect the commands are just expanded. Now when two players issue 'GET ALL' they both execute the same commands and they are interleaved by the Go scheduler - or maybe some custom code - and you might get one item but not the others. Even if a player issues 'GET ALL' a little later than the other player they might still get something :) Things will start getting interesting when expanding commands such as 'TAKE CHEESE BREAD APPLE LUNCHBOX' which would expand to: TAKE CHEESE LUNCHBOX TAKE BREAD LUNCHBOX TAKE APPLE LUNCHBOX In this case we would have to assume that the last item on the command is the container to take the other items from. It would also be nice to implement stop words in the parser so we can type commands more naturally: TAKE CHEESE BREAD AND APPLE FROM THE LUNCHBOX Parsing is a huge area where things can get very interesting if you like working on natural language parsing and processing problems :) If anyone has comments on this, or better ideas, I'd be glad to hear from you! As always drop me an email and we'll have a chat: diddymus@wolfmud.org -- Diddymus Up to Main Index Up to Journal for July, 2015