Give more control over parsing to the world implementation rather than hard-coding it in the server

[doughsay]

No description provided.

[Omikhleia]

Sharing additional considerations regarding the current command parsing / matching --

Currently a list of matched object is built using findNearby, i.e. inside target and in target's location (contents and extra matches) -- where target is (usually) a player. Let's call this (inside + location) the 'environment'. Determiners (if any) will apply on this list.

While this is certainly quite ok for 'this' targets, it turns out to be confusing for 'any' targets, especially for get-like and put-like commands.

• "get item from container", for instance, will try to resolve item from the environment, at no actual use.
• "get item" will look inside first, then in location -- it's probably even worse here, since we quite certainly don't want to get something we already have, and determiners however will apply to the whole list (so item.1 may be in player inventory, while we would have wanted the 1st item in room).

I have toyed with the idea of keeping the lists separate, and adding new verb qualifiers more precise than 'any', resolved after a verb is potentially matched (by pattern only): get {any-in-location}, get {any-in-this} from {this}, put {any-in-inventory} into {this}, etc. to ensure objects to be looked for at the appropriate place.

That could perhaps be interesting for 'this' targets too: drink {this-in-inventory} requires target to be 'handled' by player, drink {this} would match any drinkable target in location too (e.g. pool of water, etc.).

I haven't been further than giving it a thought (since it's a breaking change for the client's verb editor too) so I am unsure there are no edge-case, and that the added complexity would be that beneficial.

Perhaps something easier may be considered. But you can at least see the idea here -- it reverses the current logic (first matching objects, then attempting to apply verbs) by first collecting applicable verbs and then try to match objects more precisely.

[doughsay]

These are some very interesting ideas. I've really been wanting to do something a little more sophisticated with the verb and object matching. I will think about it a little more deeply; since 4.0 isn't out yet, now the time to consider breaking changes.

…

On Tue, Jun 13, 2017, 12:21 PM Omikhleia ***@***.***> wrote: Sharing additional considerations regarding the current command parsing / matching -- Currently a list of matched object is built using findNearby, i.e. inside target *and* in target's location (contents and extra matches) -- where target is (usually) a player. Let's call this (inside + location) the 'environment'. Determiners (if any) will apply on this list. While this is certainly quite ok for 'this' targets, it turns out to be confusing for 'any' targets, especially for get-like and put-like commands. - "get item from container", for instance, will try to resolve item from the environment, at no actual use. - "get item" will look inside first, then in location -- it's probably even worse here, since we quite certainly don't want to get something we already have, and determiners however will apply to the whole list (so item.1 may be in player inventory, while we would have wanted the 1st item in room). I have toyed with the idea of keeping the lists separate, and adding new verb qualifiers more precise than 'any', resolved *after* a verb is potentially matched: get {any-in-location}, get {any-in-this} from {this}, put {any-in-inventory} into {this}, etc. to ensure objects to be looked for at the appropriate place. That could perhaps be interesting for 'this' targets too: drink requires target to be 'handled' by player, drink would match any drinkable target in location. I haven't been further than giving it a thought (since it's a breaking change for the client's verb editor too) so I am unsure there are no edge-case, and that the added complexity would be that beneficial. Perhaps something easier may be considered. But you can at least see the idea here -- it reverses the current logic (first matching objects, then attempting to apply verbs) by first collecting applicable verbs and then try to match objects more precisely. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#144 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AANh_d6dI_DDAhbWQwqVf0VMGO69m6bqks5sDuFFgaJpZM4Nsh3r> .