ID:133523
 
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.
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.
In response to Kaiochao
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.
The function could be useful, but I don't see the need for an extra variable. I'd rather add more mouse_opacity values.
In response to ACWraith
They could use bit flags similar to how sight works.
In response to Naokohiro
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
In response to Falacy
Because not everyone has 4.0. Some people would like to keep backwards compatability with the older versions.
In response to Popisfizzy
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
In response to Falacy
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.
In response to Falacy
You've failed to see the point. Completely turning off or disabling the status bar would be completely different from this suggestion.
In response to Popisfizzy
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()
In response to Popisfizzy
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
In response to Lummox JR
Ah, okay, my mistake.
In response to Kaioken
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.
In response to StolenSoul
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.
In response to StolenSoul
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).
In response to Kaioken
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.
In response to StolenSoul
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.
In response to Kaioken
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.