ID:120731
 Nov 2 2011, 11:29 am
|
|||||||
Redundant
| |||||||
I'd like to request a way for override icons (the ones you can show to select clients to override a thing's current appearance) to also override names for the object they belong to. Making it a separate feature would be perfectly fine too. It's rather annoying how the name being unchanged can open venues for metagaming.
| |||||||
Yeah, that's what I meant. Sorry for the bad wording yesterday, I was rather sleepy.
Thank you. | |
I am not entirely sure as to what circrumstances might make this useful because that would mean when you display an image() to one person an objects name needs to change too but only for that one person?
What is the circrumstance(s) where this might be useful? In general anyways, being able to override a name of an atom replaced with an image isn't a bad idea really, I just don't see the use for it at the moment. | |
Superbike32 wrote:
What is the circrumstance(s) where this might be useful? If you're attaching an image to an object to make it look like it's something else, if the image's name can't be changed that might ruin the illusion. My advice is to not use the name var. There might be some cases where it has to be used (ex: input()) but you can find ways to avoid those situations. | |
Hazordhu replaces the default status bar with a label that updates with MouseEntered(). Since players can give their own names to other players, hovering over someone will display the name you've given them.
It has nothing to do with images, but it's an alternative. | |
Hazordhu's method also increases the overhead of the game dramatically. As any usage of MouseEntered() on this scale will.
| |
Nadrew wrote:
Hazordhu's method also increases the overhead of the game dramatically. As any usage of MouseEntered() on this scale will. It's a bit dramatic to call the amount of overhead "dramatic", especially considering this is only for overriding names of certain objects. The client has to send a message to the server to notify it of each mouse entered event. This is similar to the client having to send a message to the server to notify it that a macro was pressed. The overhead can't be much different than what'd happen when a player mashes keys. | |
It's actually for nearly every thing on the map, buildings, players, I don't think it's done for turfs. In Hazordhu after a while of player development turfs become a bit of the minority on the map =P.
In other games with a limited need for it, it doesn't hurt much. I was talking about Hazordhu specifically, not in general. I can see how what I wrote can come off like that though. | |
Are you sure the problem in Hazordhu is caused by the use of MouseEntered(), and not winset()?
| |
Yeah, probably both actually. I forgot about the winset overhead.
| |
It's still no worse than a macro. When you press the left arrow key the client tells the server that a macro fired, the server processes the event, and sends updates to the client (new/updated object information).
The mouse entered event is equivalent to the macro, the MouseEntered proc is equivalent to the verb called by a macro, and the winset call is equivalent to the updates. If anything the macro is worse because it may require sending updates to other clients, where in this case the winset update is only sent to you. I wouldn't encourage people to override MouseEntered and use winset to merely replicate the functionality of the default status bar, but I wouldn't discourage it just because it requires communication with the server - multiplayer games require communication, it's not something to be scared of. | |
Ter13 resolved issue (Redundant)
atom.override exists for appearance changes, while changing the name of an object already does this. For other purposes, define a true name variable. | |
Awesome key, by the way.