Isn't that pretty easily solvable with some type of macro system?

"macro take get"

Or something similar.

I think he just means you could assign an array of keywords per command. The signature of the :get command would be the same, so if you wanted
to "get shirt ground" or "take shirt ground" it would still find be [ :get("shirt ground") ]

Your macro system would work fine this way.

I qualified my suggestion by saying that it depends on where you want to handle errors. I've been saying all along that I would prefer all error handling to be in the command logic, and all type checking to be handled in the dispatcher. If you want some of your basic error checking to be handled in the dispatcher, I'm not saying it's a bad idea or anything. And it obviously wouldn't be logical to use my suggestion if you do. If you'd rather have error checking in the command logic, though, I was showing how you could do so and still produce the same end results. Instead of passing <obj_in_room> as a parameter to your command method, and knowing it was a valid target for the command already, you would pass <obj> and <scope>, knowing that <obj> was a valid object that was in a valid scope, but not whether or not it was a valid target for the command. Really, it doesn't matter how you do it. I was just suggesting a different organization that seemed more logical to me. :grinning:

Well, I would want to ensure it's a valid scope per arg and not valid per command. Like in the example with the object you're getting selecting from something you're wearing because the 3rd arg should allow that as a candidate.

That could probably be done tweaking your example a little bit.

Another thing you should think about is how to handle interdependent arguments. In the "get <obj> <container>" example, you can verify that <container> is an :arg_obj_in_room, :arg_obj_in_inv, or :arg_obj_equipped, but what will you do for <obj>? Its scope is <container>, which isn't a singular scope like inventory, room, equipped, etc.

Yeah, that is something interesting to think about. It's also possible to parse such cases a single argument. "get <obj from container>". In other words, :arg_obj_from_container being a string that represents enough information to filter it to an object in a container in the valid scope.

"get sword from locker"

resulting in

get(obj)

Well, then you're restricting yourself to not being able to constrain the scope of <container> (you'd have to check all scopes). I can't think of any situations where this becomes problematic, given a typical MUD command list, but it's something to consider, anyway.

Also, if you plan on allowing quoted arguments, you'd have to do some mucking about with the argument parser: get "red apple" from "big tree" versus get "eye from a newt".

I was doing some work on NLP that I've discussed here somewhere before, a system called 'CLIP' (too time-pressed to trudge through MB's lousy search at the moment though). Basically it had a grammar where things could be modified by other things (where 'thing' is left intentionally vague). So, "get sword from bag" could parse to "get <sword> <from bag>" or "get <sword from bag>". In this case, the 'from' makes it obvious what is going on, and in general prepositions usually do. But I remember there being cases that got tricky, although unfortunately I don't have those examples in mind at the moment. I'll ping back if I come across them again.

I disagree. I was constructing that within your previous code. The scope could be broadly defined for where the container is.

"get sword locker"

If we constructed it with [:scope_in_room, :scope_in_inventory] and filters of [:arg_obj, :arg_obj_in_container] meaning the command can be typed:

"get sword"
"get sword locker"
and either way produces

get(found)

Ahhh, my mistake. I thought you were using the original notation. :redface:

I guess my system is entirely different to yours but I parse the first arg as a command and let the method or script work out the details by just passing the remaining string to it.

I figured my command would always have a better idea of how to get the scope and so on than any controller.

However, I did have to write a quite complicated regex parser that could figure out what the subject and target using a preposition term.. :( it still boggles my mind when I look at the code even now..

Your way looks intriguing tho, keep us up to date on how you go with it will ya?

Heh, did you write a whole NLP or something? Because just handling prepositions should be quite a simple regex.

I did, at least as a prototype; more details here. (Well, really, the important details there are the links to more details and the demo.)

You can try things like: "give the long elvish sword to the goblin" or "give the long elvish sword from the bag to the goblin"
The second one is interesting because although it knows to separate the units by preposition, it doesn't realize that from/to have source/target semantic meaning. So it proposes two options: (a) you're giving the sword to the bag-modified-by-goblin, and (b) you're giving the sword-modified-by-bag to the goblin. Option (b) is the correct one, and I'd just need to add the semantics of individual prepositions. The current prototype is mostly just a parser that tries to associate parse trees with known logical forms.

"get the sword from the bag" is also interesting in that it proposes two forms, which is also incorrect because of the semantic value of 'from' that it fails to capture.

Way cool DH. I've done things like that but not that approach (or I'm assuming, I don't know Lua). What I did was to sit down and apply logic to 'one_argument' (still from a diku-line).

So the game will take 'get my sword out of my backpack' and it boils it down to 'get sword backpack', unfortunately I haven't gone further to do like 'get my silver sword out of my grey backpack'. Just never got time to sit down and include that sub-check for the keywords still matching.

It's much better than Diku/Merc/Rom, just not quite where I wish it was.

The simplicity of it? It simply does a while statement and steps through the arguments until it doesn't hit a 'this/that/my/the/a/from/inside/'etc type thing.

My code was really just messing around with prototyping this stuff. I'm not sure it's actually necessary to be able to specify things like: "put the sword from my bag into the backpack on the ground". Of course, there are times when it's convenient to differentiate between objects based on where they are. Let's say you are wearing a backpack, and there's a backpack on the ground; this approach lets you differentiate those two cases.

That's one reason why I brought it up here: the parser itself allows players to specify scope by saying things like:
"use the sword on the ground"
"use my sword"
"use the sword in the bag"
"use the sword in my bag"

etc.
and it could, in principle, complain about ambiguity:

> look
There is a bag here.
> inv
You have a bag.
> get sword from bag
Did you mean your bag or the bag on the ground?

Well, no, I started out that way with antlr but I quickly hit major complexity that I decided I didn't want.

You're right, the regex is fairly simple, but I use several:

public static final def OBJECT_NAME_EXP = /^([\w\W\s])+(?=\s[0-9]+)|^[\w\W\s]+$/
    	
    	// matches the index
    	public static final def INDEX_EXP = /\s[0-9]+$/

…
		def void parse(argstr, prepositionExp){
   	    	    def prepositionExpSpaced = /$prepositionExp /
		    def postPrepositionExp = /$prepositionExp [\w\W\s]+(\s[0-9]*)?$/ 
		    def subjectExpression = /^[\w\W]+(?=\s$prepositionExp)|^[\w\W\s]+(\s[0-9]+)?$/
		        	
		   	subjectObject = parseSubject(argstr, subjectExpression);
		   	prepositionObject = parsePrepostionPart(argstr, prepositionExpSpaced, postPrepositionExp)		   
		}
…

.. but you can see index matching in amongst it there which tries to match an index, much like the old lpc muds do.

So this sort of command works:

get red flag 2 from sack

where "red flag" and index 2 are stored in a separate "holding" object and the sack in yet another holding object, without trying to find the actual mudobjects.

The holding object has methods to look up the "red flag" or "sack" or whatever in given a container mudobject, within which the actual mudobject may or may not exist.

So effectively, I can do this:

…
parser = new GenericSyntaxParser()
parser.parse(argstr, "from|(out of)")
…

Which then provides me with two holding objects, subjectObject and prepositionObject, which will hold the object names.

It's not really the regex thats complex, its the holding object logic that tries to figure out which object you mean (all red flags, flag 2, etc) and what index you're talking about that's a bit mindbending. I really should address that somehow, but anyway, it works for me.

edit: I should note that this works equally well if the player does not give a preposition in their command, eg, get sword. The second preposition holding object will be null, and my command can check for that.

What it should do under those circumstances is check to see which, if any, bag actually contains a sword and act accordingly; the command is only ambiguous if bothbags contain a sword.

Similarly, the command "put the key in the hat on the treestump" is often only ambiguous in the absence of information about the state of the room. If you know that there is an empty hat on a treestump and that you have a key in your inventory (or on the ground), then there's no ambiguity; similarly if there is a treestump which doesn't have a hat on it, but elsewhere there is a hat which contains a key, you're fine.

> put key in hat on treestump

There is no sign of either a hat on a treestump or a hat containing a key.

I think this is why the lpc mud style is quite specific about things you are holding being more important than whats on the ground, and generally containers on the ground being inaccessible unless you are holding them.. rules like this are ok but should be tailored to your game IMHO.

Hmm, sorry, my bad; I thought it was obvious that this was the ambiguity I was trying to express. :smile: