ID:2042446
 
Not a bug
BYOND Version:510.1327
Operating System:Windows 7 Home Premium 64-bit
Web Browser:Chrome 48.0.2564.116
Applies to:Dream Seeker
Status: Not a bug

This is not a bug. It may be an incorrect use of syntax or a limitation in the software. For further discussion on the matter, please consult the BYOND forums.
Descriptive Problem Summary:
Things that could be right-clicked to access their verbs in the 509 client no longer can if their mouse_opacity is set to 0.
Numbered Steps to Reproduce Problem:
Have an obj with a verb
set src in world in the verb
set mouse_opacity = 0 on the obj
Try to right-click it to access the verb
Try it with mouse_opacity set to 1 and see that it works otherwise
Code Snippet (if applicable) to Reproduce Problem:
world
fps = 25 // 25 frames per second
icon_size = 32 // 32x32 icon size by default

view = 6 // show up to 6 tiles outward from center (13x13 view)


// Make objects move 8 pixels per tick when walking

mob
step_size = 8
obj
step_size = 8

testObj
mouse_opacity = 0
icon = 'ayy.dmi'
verb
test()
set src in world
world << "We're right-clickable!!"


I do hope this is an actual bug, though. I could see how this would be WAD, but I also know that we have code currently where we'd like something to be able to right-click use a verb on something even where mouse_opacity is 0.
mouse_opacity = 0 means transparent to the mouse, it's not supposed to interact with the mouse at all, right-clicks included.
Alright. Thought I'd make this report anyway, since in 509 this didn't occur, which made it seem like it might have been a bug.
I think there were some changes in the 510 series that resolved some standing mouse_opacity issues. I'd imagine this was one of them.
Such a change wouldn't have been intentional, but if an atom with mouse_opacity=0 was showing up for right clicks before, that was a bug for sure. Correct behavior for an atom with mouse_opacity=0 is that it shouldn't respond to right clicks at all.
Lummox JR resolved issue (Not a bug)
uhg... we do kinda rely on this at /tg/.

admins should be able to view vars anything, even mouse_opacity=0 things.

mouse_opacity=0 is more about pixel/click collisions, and less about what should show up in the right click context menus.

shunt that behavior to mouse_opacity=-1
Urgh, you're kidding.

I hate the idea of mouse_opacity=0 being used for right-clickable stuff, but if you're relying on this then I guess I'm okay with modifying the behavior. However I think for PLANE_MASTER it should simply shut off everything in the plane to right-clicks if its mouse_opacity is 0.
I always figured invisible to the mouse meant invisible to the mouse, I've never seen anything that relies on this behavior outside of SS13 (that's news to me)
Good solution might be an override setting on the verb itself like set popup_menu = -1 means "always display in popup menu even if this verb normally wouldn't because of mouse_opacity".

Honestly though, changing this isn't a big deal. I would rather focus is spent on important things like reducing var access and proc overhead rather than wasting time on reimplementing legacy quirks like this. At /tg/station, almost nothing is going to be impacted and even for the stuff that is, there's already a very good workaround in place anyway. If we really care, we can implement a system that does away with the verb outright.
Thanks for the feedback on that. I think I'll stick with leaving this alone, then. It really should never have been possible to see an atom with mouse_opacity 0 in the right-click menu, as that flies directly in the face of the reference.
One, we need more control over the right click menu, not less.

Two, it seems like this is doing two separate things.

Reference
A click or mouse movement over an object's icon normally applies to that object only if it is the top-most object that is not transparent at the position of the mouse. Setting mouse_opacity to 0 would cause the object to be ignored completely


The right click menu is per tile, everything in the tile you clicked shows up, not per-pixel like mouse movements and mouse clicks.

So it doesn't make sense to apply mouse opacity to it.

Mouse opacity is about click collisions, its about allowing you to control rather the icon's 0 alpha pixels can be clicked, or rather none of the icon's pixels can be clicked.

Because the context menu is for the whole tile, it makes no fucking sense to apply mouse opacity to it.


I don't think it was a bug, I think you are miss reading that.

Why the fuck would you apply something that is about pixel collisions of alpha pixels with a mouse to a feature that is per tile just because they both involve a click.
The fact that right-clicks are (or at least originally were) per-tile is itself a legacy thing, though. These days it actually goes by bounds.

The main problem I have with not letting mouse_opacity impact this is that it casts doubt on what to do with PLANE_MASTER. It seems like any solution there would tend to be hacky.

[edit]
I suppose in a way that right-click menus treat mouse_opacity as if it's set to 2, so I do see your point about the two things being different. But what would you recommend be done for PLANE_MASTER and the icons on the plane?
I honestly don't yet understand planes and plane master well enough to even know where those two conflict.