Parser Ignoring An Object?

[Nilrin]

I'm curious if anyone knows a method to get the command parser to completely ignore an object.

I've worked with verbs plenty before. Generally, you use your direct and indirect functions to tell the verb if you want to allow something to interact with that object.
As an example here, we have a player who is invisible, and another player that suspects the first of being so. Currently, the player could try something like this:

> look nilrin
There is no nilrin here.
> look asdf
You can't look asdf.

Ah hah! So even though we get some coded error for Nilrin "not being there" when know he in fact is, due to the nature of the error message given.

Now, one work-around could be to try and make both error messages read the same. The problem there, is when the parser, or the very least, the verb, matches an argument to an actual object, there isn't any way to query the original argument the player used.

Either way, I think the best method would be to tell the parser to ignore an object all together if that object->GetInvis() returns true. Is this even possible?

[detah]

I'm not entirely sure what your desired outcome would look like. But yes, it is trivial to create a given response for looking at an invisible player. Go to \verbs\items\look.c and in function do_look_at_obj() , add the following right before the last return line:

Code: [Select]

if(ob->GetInvis()) return 1;

This should do absolutely nothing when you look at an invisible player. Not sure how that 'solves' the problem tho. As that too tells the player that that player is present but invis.

-Detah

[quixadhal]

As with any system, the users only have the information they're given by it.

As you mentioned, the simplest way to solve the problem without ripping apart and (probably) breaking the whole parsing system is to do it the simple way... Ensure that the "error" messages you get are identical in form.

> look fjdklsa
You can't look fjdklwa.
> look at fjdklsa
You can't look at fjdksla.

That's what the parser (actually, the look/examine verb) spits back for a non-existent target.

So...   a common practice is to use notify_fail() to spit back custom error messages (or none at all).  You could either add your invis checks in the various places that gather look information and generate an appropriate error there... or perhaps let the object itself do so.

In /lib/events/look.c, SetInvis() takes an argument and simply sets Invisible to be whatever was passed in, using the truth value of it for a few things, but preserving the actual value (which GetInvis returns).

You could probably do something like obj->SetInvis("You can't " + verb_name + " " + obj->GetName() + ".")

Where verb_name would need to be passed in somehow to provide "look, look at, examine, whatever"...
Then when you call GetInvis() it will return that string... which is true (so if checks work), and you could use the message directly.

[Nilrin]

For sure. I figured that was the case. I just hoped there was perhaps a call made to objects from the parser I didn't know about. I'm mostly a MUDlib level guy, so I don't know much about the FluffOS code other than it makes my LPC stuff go.

Thanks for the help.

[Hilapdatus]

You could sow confusion and invite trouble by using set_hide() and writing master()->valid_hide() to allow objects to be hidden under various circumstances. 

[Nilrin]

Another thought I just had is messing with /lib/probs/id.c and changing the GetID() function to return nothing if query_invis(this_object(), this_player()).

[Nilrin]

Err sorry, it is in fact the parse_command_id_list() function. Simply write:

if(query_invis(this_object(),previous_object())){
    return ({});
}

And this will keep the parser from matching anything to the object if they're invisible to that user.

Profit!

This is also extremely useful if you want a nicknaming mechanic in your MUD as you can return extra IDs as well.

[Nilrin]

Actually, I was presumptuous in thinking that would work. Apparently, unless I'm mistaken, a list of IDs for each object is cached by the driver, making the previous code useless. The ultimate goal here is to allow for special circumstances where the list of IDs for an object might be different depending on the observer. I've been messing with this for quite some time, but it seems there is no way to implement this in DS LPC with the current efuns available.

I can think of two good examples of how this would be useful.

1. An identify system where one player can "identify" another player by a certain name, and then use that name when using any coded verb on that player.

2. Subjective key words or adjectives, such as a small character viewing another as "large", while a third character viewing the same character as "moderate".

[quixadhal]

I think you're approaching this from the wrong side.

You shouldn't be trying to "trick" the driver into doing something inconsistent.  Instead, you should modify your game systems to be able to ignore or show alternatives based on what you want to accomplish.

Your original example was based on a player being hidden from view, and thus also not targetable.  The parser itself can still find them, but surely you can code something in-between that validates the target?

IE: You write a valid_target() sefun which does the appropriate checks for visibility, targeting, etc, and ensure that ALL code funnels through it.  If it returns true, all is well.  If it returns false, whatever calls it should generate the appropriate error JUST as it would for the thing not being there, OR try some alternative way to find the target.