Hiding atoms' names in BYOND Discussion

ID:133523
 
Jul 13 2008, 6:07 am
I thought it could be nice if we had a var like mouse_opacity, but that only accounts for the atom's name display when the mouse is hovered over it (or have this implemented as flags into the existing var), meaning when it is set to 0, the name is not displayed*, but mouse actions (right-clicking, Click()) still work. Just a quick, not essential suggestion to add to the List if you guys like it.

*: As per mouse_opacity, the name of the object under that atom will be displayed instead, if any.
#1 Jul 13 2008, 8:48 am
So the status bar would display the name of the object under it, but still be able to click it? It seems a little confusing...

I can't imagine where one could actually use this.
#2 Jul 13 2008, 9:23 am
In response to Kaiochao (#1)
The usage would be similar to mouse_opacity, as is the feature (like I said, it'd even be suitable to implement this to the same variable). It'd be a nice feature to be able to control this built-in behavior (which can't really be done otherwise without rather crappy workarounds) on a per-object basis.
#3 Jul 13 2008, 9:40 am
The function could be useful, but I don't see the need for an extra variable. I'd rather add more mouse_opacity values.
#4 Jul 13 2008, 11:04 am
In response to ACWraith (#3)
They could use bit flags similar to how sight works.
#5 Jul 13 2008, 8:51 pm
In response to Naokohiro (#4)
Why not just turn off the status bar. Considering it does nothing but display what you hover the mouse over; its pretty much completely useless now
#6 Jul 13 2008, 8:55 pm
In response to Falacy (#5)
Because not everyone has 4.0. Some people would like to keep backwards compatability with the older versions.
#7 Jul 13 2008, 8:59 pm (Edited on Jul 13 2008, 9:15 pm)
In response to Popisfizzy (#6)
Popisfizzy wrote:
Because not everyone has 4.0. Some people would like to keep backwards compatability with the older versions.

What o.O
you cant play 4.0 games in the older versions of BYOND <.<
And how would the status bar effect backwards compatability anyway? The only possibly way I could see is if they were using some sort of outside script to marquee something across it or somethin, but I doubt that effects many (if any) games on byond
#8 Jul 13 2008, 9:02 pm
In response to Falacy (#7)
I'm pretty sure you can play games compiled in 4.0 on pre-4.0 version of BYOND, as the staff kept a lot of backwards-compatable stuff there (like the default interface, which is set up exactly the same, right down to right-clicks not being sent to the Click() proc), and maintaing that would be useless if it can't be run in previous versions.
#9 Jul 13 2008, 9:18 pm
In response to Falacy (#5)
You've failed to see the point. Completely turning off or disabling the status bar would be completely different from this suggestion.
#10 Jul 13 2008, 9:19 pm
In response to Popisfizzy (#8)
Popisfizzy wrote:
I'm pretty sure you can play games compiled in 4.0 on pre-4.0 version of BYOND,

Newer 4.0 compiled games cant even be run in early versions of 4.0 (starting with 415 I believe)

as the staff kept a lot of backwards-compatable stuff there (like the default interface, which is set up exactly the same,

Not really <.<

right down to right-clicks not being sent to the Click() proc), and maintaing that would be useless if it can't be run in previous versions.

If you disable client.show_popup_menus then right clicks will be sent to Click()
#11 Jul 13 2008, 9:28 pm
In response to Popisfizzy (#8)
Popisfizzy wrote:
I'm pretty sure you can play games compiled in 4.0 on pre-4.0 version of BYOND, as the staff kept a lot of backwards-compatable stuff there (like the default interface, which is set up exactly the same, right down to right-clicks not being sent to the Click() proc), and maintaing that would be useless if it can't be run in previous versions.

Backwards compatibility is for the sake of playing 3.0 games in 4.0. Games compiled for BYOND 4.0 have features that can't work in 3.0 or 3.5.

As of version 415, we have a little finer-grained control available for some features, so if we have a new feature added that a game happens not to use, we can treat the .dmb as compatible with older versions. client.pixel_x/y is used this way. This sort of thing will show up more with future features, but it doesn't impact features that were implemented in the past.

Lummox JR
#12 Jul 13 2008, 9:37 pm
In response to Lummox JR (#11)
Ah, okay, my mistake.
#13 Jul 13 2008, 9:54 pm
In response to Kaioken (#2)
While this will add overhead maybe it would work for whatever idea you're having.

Add a variable to atom with a default value then create a process for MouseEntered that checks to see the variables status and then reacts accordingly. Then just return the parent functions value or return a suitable return with whatever would be sent to the status bar as an empty string??

Ok so yeah it's not the greatest workaround but hopefullay an idea at least.
#14 Jul 13 2008, 9:58 pm
In response to StolenSoul (#13)
That's likely the rather-crappy workaround he was referring to. MouseEntered() and similiar procs are at best avoided unless they must be used, as they add overhead to the executable, and make things a bit slower.
#15 Jul 13 2008, 10:00 pm
In response to StolenSoul (#13)
As I said in a post, I'm aware of the fact you can work around it with soft-code, but there is no current way to actually accomplish this properly. Any workaround would involve clearing the name var, which is inherently quite crappy. Having this built-in would make this easily possible to pull off well, and with no extra lag caused by extra processing (server-side, at that).
#16 Jul 13 2008, 10:11 pm
In response to Kaioken (#15)
My bad on the posting a softcode workaround just got off work and am half asleep. Although I don't see how you'd have to clean the name var if you don't return the default process for atoms you don't want the description shown for and would return a "customized" return value instead. Maybe it's just the sleep talkin xD.

Back to subject though. While I can't think of a ton of things this would be useful for I can think of one or two off the top of my head, ie a hidden treasure, or mission objective that you don't want the name popping up for. So I say the var would be a plus, or possibly an alternate display_name var as well for those that want to give their atoms a different status bar name.
#17 Jul 13 2008, 10:44 pm
In response to StolenSoul (#16)
StolenSoul wrote:
Although I don't see how you'd have to clean the name var if you don't return the default process for atoms you don't want the description shown for and would return a "customized" return value instead. Maybe it's just the sleep talkin xD.

It's just the sleep talking. In short - the name display on mouseover is currently hardcoded, NOT handled by any mouse proc (which all do nothing by default, they're just meant to be overridden as hooks). This is why I request a variable to control this behavior.
#18 Jul 13 2008, 11:43 pm
In response to Kaioken (#17)
Dang it all that's the last time I post this late.

You're right of course.

We should definitely have some way to override it either with a flag or an easily overridable var that we could set to NULL to have it not shown or to another value to override the name display without affecting anything else.