ID:154272
 
Well, it's back to the memorize descriptions and translate to names proc. I figured out how I could memorize descriptions and replace them with names when seen, but I have a little rock, or maybe a big rock, I don't know, that's getting in my way.

You see, when you refer to anything in the game, you refer to it by one or many of the items in it's name_list. So if there is a "long-haired oaf" named "Tummel", he'll have a name_list that looks something like this:

list("long-haired","oaf","Tummel")

Now, if a player comes along and sees the long-haired oaf who introduces himself as "Tum", which is what his friends call him, and that player remembers Tummel as "Tum". How then is that player going to be able to refer to Tummel if all he sees when Tummel does something is, "Tum looks at you." but he doesn't respond to the name "Tum".

I need to figure out some way to get past this, otherwise I'll have to resort to using only descriptions...
I'm not sure I see a problem as much as a usable design decision. Unfortunately, I have not been following all of your MUD threads so it's quite possible I'm missing something.

If you don't allow prefixes, then you have the ability to stop players from accessing things they don't know the name for.

If someone makes a mob that hides its information, that's the fault of the mob maker. Why would a mob be introduced as something that is not in its list of names?
In response to ACWraith
Because the mob is introduced as a description, and the player can "remember" the mob as anything they want. So if they see "a monkey" then can remember the monkey as "some stupid critter" if they want, but that's not the monkeys name. However, if what they used to see is:

You see a monkey playing in the grass here.

Then they will now see:

You see some stupid critter playing in the grass here.

However, they'll still only be able to refer to the creature as "monkey" since that's the name it was given. If the player decides to refer to the monkey as "Alverenzo" from now on, I need some way to allow them to refer to that monkey as Alverenzo from now on. So:

look alverenzo

would be the same as

look monkey

And I haven't the slightest clue how to do that :o)

However, I can't simply add Alverenzo to the monkey's name list, because other players will still see it as "a monkey".
In response to Foomer
Don't give up on the idea completely.

You could try picking a category of names. For instance, if the player was mad, they could see/use "some stupid critter". If the player was bored they could see/use "a monkey". If the player knew the name and was in the mood to see/use it, the player could see/use "Tummel".

I think giving the player the freedom to make whatever names they want for whatever they want might be easy to abuse. However, the truth is I'm just too tired to think of a solution myself at the moment. ;)
In response to Foomer
I think what you need is a per-player name list, along these lines: Each list will be associative, containing things and the name they're associated with:
mob
var/list/localname

proc/LocalNameFor(thing)
var/nm=localname[thing]
return nm

atom
proc/desc2name(mob/describeto)
if(describeto)
var/nm=describeto.LocalNameFor(src)
if(nm) return nm
... // show a normal description

Now as for using these local names in commands, you probably need a second associative list for that. Basically what I'd do is parse the local name (if any) into a list of strings, and have another list within the mob that's set up like this:
mob/local_namelist["red"]=list(/mob/bugbear,/mob/DaveTheRed)
mob/local_namelist["dave"]=list(/mob/DaveTheRed)
mob/local_namelist["bear"]=list(/mob/bugbear)

That's just a shorthand syntax, obviously, showing how things would be set up within the list.

Lummox JR
In response to ACWraith
This is designed for use in a roleplaying game, so while what one player refers to another player/obj/mob by in his commands really has no effect on anyone else, causing trouble that disrupts the game will get you banned (or at least get your character deleted). Since you have to create appropriate information, descriptions, and basically create a detailed new character every time, that can be less than fun.
In response to Lummox JR
I'm not sure I understand all that :oP In fact, I'm sure I don't.
In response to Foomer
Foomer wrote:
I'm not sure I understand all that :oP In fact, I'm sure I don't.

It's just an associated list.

name_list[whateverName] = whateverMobOrObj

The reason I did not mention it before was I was worried about saving all of the mobs/objs when saving the player's name list. One way around that is to give every mob/obj a unique ID. (Perhaps you could use something of the "mob[number]" and "obj[number]" variety.)

name_list[whateverName] = uniqueID

Then, when saving you can get the IDs from the mobs/objs and when loading you could look for the mobs/objs with those IDs.

If you allow multiple mobs/objs to be referenced by the same name, you might want to use the format:

name_list[whateverMobOrObj] = whateverName

name_list[uniqueID] = whateverName
In response to ACWraith
I'm not having any trouble referinging whatever name the player wants to that mob, that's not hard.

mob/verb/Remember(mob/M, T as text)
src.Memory[M.name] = T
src << "You remember [M.name] as [T]."

mob/proc/CheckName(M)
if(Memory[M.name])) return Memory[M.name]
else return M.name

mob/verb/Say(msg as text)
src << "You say, '[msg]'"'
oview() << "[CheckName(src)] says, '[msg]'"


My only problem is making it possible to refer to a mob using the memorized name.

If M.name_list = list("Gray","Haired","Man","Bob"), how can I make them respond to "Zippy" if that's what someone chooses to remember them by, so that "Look Zippy" will return "Bob"?
In response to Foomer
Foomer wrote:
I'm not having any trouble referinging whatever name the player wants to that mob, that's not hard.
[snip]

name to mob?

[snip]
My only problem is making it possible to refer to a mob using the memorized name.
[snip]

name to mob?

As if I wasn't confused enough. :)

Are you asking how to make a trigger?

Within Say, you have a direct reference to the mob. You can make a trigger within say that passes the mob and the phrase to those who can hear. You don't need to worry about what the name is for activating the trigger because the mob itself is passed.

If you do need to know what someone calls you at some point, you were passed the mob that called you and the mob has a CheckName() proc. This might be useful if you want to search the phrase that was passed for the name the mob calls you.
In response to ACWraith
No no no :oP

I need to make it so that you can refer to a mob by whatever you remembered them by! Regardless of what they can be refered to as normally. If you remembered the mob as "some stupid monkey", I need to figure out a way to allow the player to type "look at some stupid monkey" and actually have the parser understand what mob it's talking about based on the player's memory.
In response to Foomer
Yes yes yes.

Use a look trigger too.
In response to ACWraith
Okay, explain how :oP (again)
In response to Foomer
Foomer wrote:
No no no :oP

I need to make it so that you can refer to a mob by whatever you remembered them by! Regardless of what they can be refered to as normally. If you remembered the mob as "some stupid monkey", I need to figure out a way to allow the player to type "look at some stupid monkey" and actually have the parser understand what mob it's talking about based on the player's memory.

What I was getting at was this: You have a list of words that can be used to refer to an object, and this list is used by the parser. What you need is another list of words and the object(s) they may refer to, but this list belongs to each player. The parser should check both the player's list of words and the word lists for the available objects to determine what they mean.

For example: Say you have a red table, and a ladybug that the player calls "spotted red bug". The word "red", like "table", is in the table's name list. Players should have a similar list, different for each player, of names they've chosen to call things. When the parser sees the player talk about something "red", it then checks the player's list to see what they might mean by that, then it checks other objects to see if they too are known as "red". So you have two different lists, together acting as one.

The trick with this is that the player's special name list isn't just a simple list. It's associative, and it should associate with other lists, so localname["spotted"] might return a list with a ladybug, a dalmation, and a leopard, if the player chose names for them like "spotted red bug", "spotted dog", and "big spotted cat". You'll need to parse whatever the player names them so that you can add these things to the list, and then remove words from the list when they're no longer used.

Lummox JR