[DGD] Aliases & Stacked commands

[Michael McKiel]

 --- dannic at orpgs.com wrote: 
> When I originally looked into creating an alias function for Karealia, I
> found that 98 percent of users use a client which can handle aliasing on
the
> client side.  Decided that only commands used in some frequency would get
> aliased and if a player wants to alias a set of commands they can use their
client.
> 
> Maybe this isn't exactly a proper way to treat prosepective users but it
> has been a good idea on my part.
> 

Kinda a moot point, it only took a few days to write the code. And it enables
users with clients even to have in-game aliases for game specific syntax
without having an extensive knowledge of their client to enable a given alias
to work one way at mud a/ and a different way at mud b/
(Which I have done in my own TF)
But I also found when playing at muds that do have aliases, like Igor, and
most old LPmuds that utilized the ole 'dictionary' they were warmly accepted
and used. It also provides albeit perhaps a small consideration, to people
that might be not at 'home' where their client resides on their home comp.

And whether or not its overly used, its the learning process and bits of
complex code improves understanding extensively more than writing dup'd easy
chunks of code. What I have garnered from the alias situation is that I will
need a stack-based command resolution, even without in-game aliases.

And that force_me() bit that was posted - isn't exactly what I instituted for
the force command, but perhaps similiar ;)

What I did was one of my few 'adds' to the kernel, in userd.c I added a:
object forced_user;

object forced_user(varargs object who, int unset)
{
    if (previous_program() == S_API_USER) {
    if (typeof(who) == T_NIL) {
        if (!unset) {
            return forced_user;
        } else { 
            return (forced_user = nil);
        }
    }
    return (forced_user = who);
}
}

which is called thru the inherited secure/api/user.c (which is in all my
common auto.c)
in the force command after various security checks, and find_user:

	forced_user(target);
	if (!self)
		target->receive_message(do_cmd);
	else
		target->do_command(do_cmd);
	forced_user(nil, TRUE);
	return 1;

To date, in the lib, the only place this_user() has cropped up with problems
was in the echo() (which sends text to all people in a given location)

so I did this:
	obj = (forced_user() ? forced_user() 
			         : this_user() ? this_user() : this_object());

since everything in the command-bin relays message's back to
previous_object() 

Course this command-stack might cause some serious issues with the way I have
instituted 'possess' - which allows an admin/implementor to possess any
object and all commands he issues, when passed thru receive_message() if the
admin is possessing something - the issued text goes to force possessed()
sent_text.
-- Which down the road when the lib is heftier, will enable things like:
    possess familiar, or mentalists that try and possess each other or fight
over possession of a given mob, et al. 

Anyways, perhaps too much blather, good day :)


______________________________________________________________________ 
Post your free ad now! http://personals.yahoo.ca
_________________________________________________________________
List config page:  http://list.imaginary.com/mailman/listinfo/dgd