Images currently are forced to assume the mouse_opacity of the object they are connected to.
For example, I was hoping to have part of an object be visible but click-throughable by showing the associated click-through portion as an image on top of the object (with mouse_opacity = 0). Unfortunately, this does not currently work.
An alternative, somewhat related suggestion is to extend mouse_opacity to also accept values from 0-255. Only parts of the image >= that value are clickable. (-1 or 256 could be used as a special value to indicate the entire image is click-through able regardless of opacity.)
ID:1126740
 Jan 16 2013, 7:27 am
|
|||||||
| |||||||
Presently mouse opacity is intimately tied to the object itself; the routine that looks up mouse hits looks up the object. That's why images tie in as well. However I do think it makes some sense to allow images to use a separate opacity. This might be simple enough to squeeze in, but I'll see. It also makes sense when image.override is in place to override the mouse opacity. However I also think this should be limited to newer worlds only as old compilations might rely on the old behavior.
| |
This should be a thing. Right now, adding an image to an atom directly affects that atom's clickability. Most of the time, I wouldn't even want that to happen. Since we have support for large icons, we usually don't even need clickable images. If images had their own mouse_opacity, then we could really use them as purely visual effects, like the reference claims that they are.
Things like health bars, selection boxes, and particle effects shouldn't be clickable. Without this feature, we are often forced to use objs for things that would work far better as images. The point is, images are not ideal as visual effects as long as they get in the way of the real atoms that we actually want to click on. | |
This bothers me. There are many cases where I don't want a /image to have the same mouse_opacity as its loc. This may force me to do something really laggy, like use a whole other obj where an image would actually be ideal.
Normally, mouse_opacity would default to 1, but for /image objects, an exception can be made, to support backwards compatibility. So instead, their mouse_opacity would default to their loc's mouse_opacity. You would then be able to override this mouse_opacity to another value, as expected. This means you could have an image with a mouse_opacity that's separate from the loc.
It's strange really. I can successfully modify the mouse_opacity of a /image object, but it appears to have absolutely no effect. I'm not even talking about overlays either. I'm talking about images that are actually sent to a particular client. I see this as pretty buggy behavior, so I don't really know what's going on. Since /images are supposedly "atomic" objects, I think it makes sense to support mouse_opacity for them.