object_name list var (client)

ID:134271
 
Dec 12 2006, 5:30 pm
 
mob
  var/class = "Fighter"

mob/proc/SpecialName()
  if(key)
    return "[src.key] the [src.class]"
  else
    return "[src.name] the [src.class]"

mob/Move()
  ..()
  if(client)
    for(var/mob/M in view())
      src.client.object_name[M] = M.SpecialName()


(Ignoring the fact that it would be much better to only update for newly-spotted mobs.)

Essentially, the object_name variable would be an associative list associated by references on the client's screen. When the client mouses over or attempts to use a verb, the object's name will be first checked from the object_name list. If no entry in that list is present, the client will take the object's name directly from its instance instead.

This would make it possible, for instance, to have generic people on your map called "person" and have people you actually know called "[Personname]".
Dec 12 2006, 6:22 pm
Jtgibson wrote:
This would make it possible, for instance, to have generic people on your map called "person" and have people you actually know called "[Personname]".

Seconded. I've wanted to do this several times.
Dec 12 2006, 6:40 pm
I like the idea, though I'm not so sure about implimentation. The way I always wanted to do this was to give images a name var, which would override the name of the atom just as it the image.text var overrides the text of the atom.
Dec 12 2006, 6:44 pm
In response to Shadowdarke
Shadowdarke wrote:
I like the idea, though I'm not so sure about implimentation. The way I always wanted to do this was to give images a name var, which would override the name of the atom just as it the image.text var overrides the text of the atom.

This would be a pretty useful feature. In my game, I have a black shroud that I represent using image objects, and I don't want to let the player mouse-over the image object to take a peek at what terrain is under it. My workaround is making the terrain named blank, and players will eventually need to know what terrain name for actual viewable objects are.
Dec 13 2006, 3:16 am
In response to Shadowdarke
Shadowdarke wrote:
I like the idea, though I'm not so sure about implimentation. The way I always wanted to do this was to give images a name var, which would override the name of the atom just as it the image.text var overrides the text of the atom.

Nice idea. Not so sure about the associative list one though.
Dec 13 2006, 12:36 pm
In response to Kaioken
How would it be done any way apart from with an associative list? The best way I can see for this is to have a default_name, if this is set then this is shown, otherwise the real name of the object is shown. If a client knows the name of an object (or gives the object a name) it is added to the associative list in the format [object]:[name] or [word]:[substitution].
Dec 14 2006, 3:52 am (Edited on Dec 14 2006, 4:05 am)
In response to Hazman
Hazman wrote:
How would it be done any way apart from with an associative list?

It could also be done with an image like SD suggested; if the image's 'name' var is set, then that string is displayed - otherwise, the object's own name is. Though actually if you only add an image to change the shown name, it's kinda a waste.
Thinking about it, an associative list would work fine, but I'm not sure how efficient it's going to have a list that updates every time an object steps into/out-of view - also, that would be much less useful. It would probably be better to have the list not update and you just modify it manually; if an entry for an object exists in the list, that entry's associated value will be displayed as the name (if valid). Otherwise, the default 'name' var will be displayed.
You could then even use the same list for your own purposes; like this suggestion with mouseover shown text, have a different name show for different people in Say verbs etc.

The best way I can see for this is to have a default_name, if this is set then this is shown, otherwise the real name of the object is shown. If a client knows the name of an object (or gives the object a name) it is added to the associative list in the format [object]:[name] or [word]:[substitution].

Your first and second sentences kinda contradict eachother... Also, the first sentence makes no sense; just set the existing 'name' var instead, the second one is my above suggestion pretty much.
Dec 14 2006, 11:41 am
In response to Shadowdarke
Images changing names seems very, very strange unless the /image type was renamed to "virtualdata" or something like that, to represent any kind of override for how the client perceives the object on his end of the connection.

Plus, unlike the associative list which always works, there are situations where the default assumed behaviour with a /image would prevent certain functionality. When I attach an image to an object, for example, and the image has a null name, how would I go about also setting the mob's name to null without specifically setting the mob.name variable? Do we really want BYOND to distinguish between null and "" for that variable?
Dec 15 2006, 6:20 am
In response to Jtgibson
Jtgibson wrote:
Plus, unlike the associative list which always works, there are situations where the default assumed behaviour with a /image would prevent certain functionality. When I attach an image to an object, for example, and the image has a null name, how would I go about also setting the mob's name to null without specifically setting the mob.name variable? Do we really want BYOND to distinguish between null and "" for that variable?

Bad example, no need to set the image.name var to null neither "", just using " " etc would do the trick. :P

Though yeah, this could be added as another, extra, way to accomplish it, but the associative list idea (specifically mine :P, you haven't commented on it Gibson) is better because if you just add an image for changing the name, it's a waste of an object, adding it to client.images etc.
Dec 15 2006, 8:46 pm
In response to Kaioken
Kaioken wrote:
Jtgibson wrote:
Plus, unlike the associative list which always works, there are situations where the default assumed behaviour with a /image would prevent certain functionality. When I attach an image to an object, for example, and the image has a null name, how would I go about also setting the mob's name to null without specifically setting the mob.name variable? Do we really want BYOND to distinguish between null and "" for that variable?

Bad example, no need to set the image.name var to null neither "", just using " " etc would do the trick. :P

Actually, no, it wouldn't. BYOND has special behaviour for an object with no name versus an object with a name of a " ".

As for the comment, my code was an example of how a developer would use the integral BYOND feature. You don't honestly think I would've suggested that code for the feature itself...? Your post explicitly stated the exact same thing as mine did. =P
Dec 16 2006, 1:22 am
In response to Jtgibson
Jtgibson wrote:
Actually, no, it wouldn't. BYOND has special behaviour for an object with no name versus an object with a name of a " ".

Yes it does, but it won't screw things up in this example, you will still see no name in mouseovers/input windows.
As for the comment, my code was an example of how a developer would use the integral BYOND feature. You don't honestly think I would've suggested that code for the feature itself...?

Where'd you get that from? The fact I replied with "Bad example" should be more than enough to gather from that I knew that was an example. :O

Your post explicitly stated the exact same thing as mine
did. =P

Eh? Hell no. My post stated your post included a bad example. =P
Dec 16 2006, 1:27 pm
In response to Kaioken
Kaioken wrote:
Jtgibson wrote:
Actually, no, it wouldn't. BYOND has special behaviour for an object with no name versus an object with a name of a " ".

Yes it does, but it won't screw things up in this example, you will still see no name in mouseovers/input windows.

*smacks his forehead* The whole bloody point was that you wouldn't be able to duplicate the "no clickability" feature with a /image system.


As for the comment, my code was an example of how a developer would use the integral BYOND feature. You don't honestly think I would've suggested that code for the feature itself...?

Where'd you get that from? The fact I replied with "Bad example" should be more than enough to gather from that I knew that was an example. :O

Your post explicitly stated the exact same thing as mine
did. =P

Eh? Hell no. My post stated your post included a bad example. =P

You're talking about the wrong post. =P