[MUD-Dev] Introductions and

[coder at ibm.net]

On 12/12/97 at 05:02 PM, s001gmu at nova.wright.edu said:
>On Fri, 12 Dec 1997 coder at ibm.net wrote:
>> On 10/12/97 at 01:33 PM, s001gmu at nova.wright.edu said:
>> >On Tue, 9 Dec 1997 coder at ibm.net wrote:
>> >> On 18/11/97 at 07:47 PM, Mike Sellers <mike at online-alchemy.com> said:

>> Given private namespaces and free user programming, one of the first
>> targets to be attacked are characters private namespaces.  Essentially a
>> namespace virus is something which attempts to corrupt, delete, or
>> re-write a character's namespace without the character's knowledge or
>> consent.

>Ahh... quaint.  Sounds very similar to one of the side effects of a spell
> system I was thinking about.  I was toying with storing the 'code' for 
>spells in the game database.  The interesting side effect is that since
>many  spells would be designed to modify the database, what's to stop a
>spell  from modifying another spell?

Precisely -- self modifying code as it were.

One of the things that I expect the users to provide extremely quickly are
introduction card type objects.  These will be small virtual objects that
one character can give to another to have a preferred name assigned for
them.  The main reason I'm not providing such a service object to start
with, or implementing  any inbuilt sercurity wrappers for the namespaces
is to encourage namespace viruses and name wars.

>> >>   Bubba is here.
>> >>   There is a troll here.
>> 
>> >mmm.. but what if they really are both named Bubba?  
>> 
>> Who cares?  Remember: private namespaces.  They have no names until you
>> name them.

>ok, better question, what if I want to name both of them bubba, in 
>defference to their requests to be named as such?

That's where the rub currently lies.  I don't have a solution I like yet. 
The nickname etc type pattern I just suggested to Sellers might be an
acceptable solution.

>> I don't encourage either that convenience or coincidence in my game.  I
>> almost encourage the reverse.

>Is this to 'solve' the problem by making sure it doesn't arise, or do you
> have other, in game reasons?

Purely because I expect to find the resultant confusions, attempted
solutions, and side-effects amusing, both as a player and admin.

>> True, this is a weakness.  <sigh>  I really don't want to have to do a
>> category deliniation every time I have two objects with identical assigned
>> names...(ie find a suitable deliniating difference).  More thought is
>> required.

>I don't see how you can get around it.

Looking for unique names might be an approach.

>> If I do go for a graphical system I can of course ignore it for the
>> general case of the game telling the user what he sees.  Just label each
>> body "Bubba".  The interesting part arrives when the player attempts to
>> reference a specific Bubba.

>Well, technically, you're not ignoring it.  You are letting the graphical
> image provide the more subtle, delineating differences.  A picture is 
>worth a thousand words, neh?

Quite.  I'm relying on the human to do the distinguishing, not the system. 
The problem is that I need to be able to have the human communicate to the
system which one he has distinguished.

>As for referencing a specific Bubba, I'd be tempted to fall back on a 
>diku-ism.  'Say "hi" to 1.bubba.'  Kludgy, but saves a LOT of typing and 
>parsing.  Heck, build the parsing in and allow the #.<name> as an option,
> if you insist.  :)

<shudder>

Blech.  I want a cleaner solution as I happen to find that one of the more
horrible and nasty perversions that DIKU's have foisted on the MUD world.

>> >I'd be tempted to take it a step further and allow the player to override
>> > the later descirption with a surname of sorts... so instead of getting 
>> >Bubba the troll with a large nose, the player could just assign Bubba 
>> >Bignose or somesuch.
>> 
>> Yup, I currently have support for this, but it really is an incompleat
>> answer.

>How so?  

The problem occurs when handling the collision when defining the N+1'th
name assignments.  Given N Bubba's, each with a
surname/nickname/modifier/etc, and a new object I want to name "Bubba", I
now must arrive at a new Bubba-type name which is unique as compared to
all the other N Bubba names.

If you have a system that lets you fist assign the name 'Bubba'  >to the
'Troll with a large nose', and then 'Bubba' to the 'Troll with  >Blue
eyes', giving you 

> >l
> Bubba, the large nosed troll,
> Bubba, the blue eyed troll

>when they are in the same room, and then the ability to further assign 
>'Bignose' as a surname to the first Bubba, resulting in

> >l
> Bubba Bignose,
> Bubba, the blue eyed troll

>what situations doesn't it cover? If we can get a nice and convoluted 
>example of where this fails, maybe we can work something else out to be 
>more generalized.  :)

Another possibility is to use sub-names, or to use the other, non-primary
aliases (essentially all names are aliases for the internal ObjectID), as
sub-names for the primary name assignment.  Thus a particular troll might
have an effective full name assignment of:

  Bubba(bignose, snotface, greenie)

Which maps to a primary name of "Bubba" and secondaries of "bignose",
"snotface", and "greenie".  (Probably the list of names should be ordered) 
The system would then use this to generate a unique name as applicable:

  > l
  Bubba snotface bignose is here.
  Bubba snotface treekill is here.

<sigh>

--
J C Lawrence                               Internet: claw at null.net
----------(*)                              Internet: coder at ibm.net
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...