Mouse Hover Highlighting

[EnCore Mayne]

has anyone come up with a tried and true method to highlight an area of a HUD when you mouseover it?

i recently came up against a newly designed HUD that had a few event links based on where you clicked on the texture/face. there wasn't any way of indicating the separate areas were individually discerned links. is there some LSL trick or genius method to have the individual areas indicated or highlighted so the user knows their mouse is in the right area? kinda like a browser's hyperlink. when you mouse over a link it underlines it and changes the text colour.

i haven't given it much thought (not come up with any practical solution as of yet) so i thought i'd throw it out to the community to see if there's an existing direction i might go. it should be easy. the script obviously is able to pick up the individual areas, one could add a prim movement to act as an underline or maybe an asterisk that pops up.... anyone?

[Quistess Alpha]

There's no method other than using Media on a Prim to make the HUd into a webpage you can do CSS/Javascript magic with.

[arton Rotaru]

3 hours ago, EnCore Mayne said:

the script obviously is able to pick up the individual areas,

Yes, but the coordinates will be returned when it's too late already. When touched. What can be done is to "mask out" some areas between the buttons, so that at least the cursor indicates that it's on a clickable/non-clickable area. This can be done with mesh quite easily. The touch event script in the child (buttons) while the root and masking mesh doesn't have a touch event script.

Edited June 7, 2022 by arton Rotaru

[Mollymews]

best we can do in LSL with mouse is mouse_pressed (touch event)

when we drag the mouse while mouse_pressed then we can change the displayed object/surface focus. Is counter-intuitive to do this tho, as people expect the focus to remain with the object/surface captured in mouse_down (touch_start event) when dragging the mouse while the mouse button is pressed (the behaviour of drag drop)

we can use the keyboard to change object/surface focus, by simulating TabOrder. Managed in control event. Substituting the right and left arrow keys for TAB and Shift TAB keys. Also substituting C key for RETURN/ENTER key. Am not sure tho how many people would know to use their keyboard to navigate a HUD in these mouse/touch centric days. So while simulated TabOrder might result a nice visual effect, it may be that nobody much will ever use it

Edited June 7, 2022 by Mollymews
/enter

[EnCore Mayne]

Just now, Mollymews said:

best we can do in LSL with mouse is mouse_pressed (touch event)

when we drag the mouse while mouse_pressed ...

[Mollymews]

explanation

mouse_down = touch_start event
mouse_pressed = touch event
mouse_up = touch_end event

in the control event

mouse_down = level & edge
mouse_pressed = level & ~edge
mouse_up = ~level & edge

 

 

[EnCore Mayne]

i do understand the intricacies of the various events Molly. i was viewing more from the point of view of the user.

• see links.
• see multiple links!
• choose link.
• click mouse.
• get results.

i can appreciate the herculian efforts required to make things seem simple to the consumer but if you have to have written instructions as to how something's supposed to work, it's failed. arogant posture aside, there should be a user friendly way of illuminating or indicating hovering. if there isn't, there isn't. i'm resolved that SL has limitations.

 

[Mollymews]

a mouse_over event is something that has been asked of Linden quite often. We haven't got as I think it would be quite difficult to get it to work smoothly when LSL is server side driven. To do it well then I think it would need some kind of client side scripting interface, and I am not sure that Linden want to open that box

 

[Quistess Alpha]

1 hour ago, Mollymews said:

To do it well then I think it would need some kind of client side scripting interface

The viewer knows when you mouse over something with a touch event, (it changes your mouse type) so I can imagine it could send a message to the server when you mouse over something that has a script containing a hypothetical mouse_over() event, but IMO seems like a lot of developer time for a niche use-case.

 

[Gabriele Graves]

51 minutes ago, Quistess Alpha said:

The viewer knows when you mouse over something with a touch event, (it changes your mouse type) so I can imagine it could send a message to the server when you mouse over something that has a script containing a hypothetical mouse_over() event, but IMO seems like a lot of developer time for a niche use-case.

 

I thought that was because the object has had it's default action object property set to touch?  The mouse changes differently depending on what default action is chosen, like with Sit, the cursor becomes chair, etc.  I am pretty sure it isn't because there is a script with a touch event because I don't think there is a way to know.

Generally and to the OP, the viewer never gets sight of the scripts, it's all server side.  The client side scripting parts work because the server tells the viewer what it needs to do viewer-side like "rotate this object" because llTargetOmega() was called but the viewer never gets sent the script under any circumstances.  So the server would have some way to say to the viewer that these objects need to be mouse hover enabled because they have an event handler for mouse_over, so call me when you detect that the mouse is over such an object.

HUDs objects are just inworld rezzed objects btw, attachments in fact, that are displayed on a 2D plane that only you can see.  Otherwise the viewer and the server treats them pretty much like any other inworld object that is attached.

Edited June 8, 2022 by Gabriele Graves

[Quistess Alpha]

3 minutes ago, Gabriele Graves said:

I thought that was because the object has had it's default action object property set to touch?  I didn't think that mouse changed otherwise.  I don't think it is because there is a script with a touch event because I don't think there is a way to know.

FWIW, objects are set to click to touch by default, but only objects with touch event scripts do the mouse pointer change. Whether that's implemented as the server changing a flag on the object I dunno. Either way, doesn't change the fact that the viewer COULD be re-written in such a way as to send messages to the server telling it what object it thinks you're pointing at, when it's told before hand that the server might want that information.

[Gabriele Graves]

Just now, Quistess Alpha said:

FWIW, objects are set to click to touch by default, but only objects with touch event scripts do the mouse pointer change. Whether that's implemented as the server changing a flag on the object I dunno. Either way, doesn't change the fact that the viewer COULD be re-written in such a way as to send messages to the server telling it what object it thinks you're pointing at, when it's told before hand that the server might want that information.

I never said it the viewer couldn't be rewritten to do that though, just that I didn't think there was such a mechanism now.  I did feel pretty sure about it but that is why I asked it as a question.  I just misremembered about it being dependent on a script as well.

[Mollymews]

am not sure is practical for the server to be receiving potentially dozens of mouse pointer position updates as we drag our mouse across an object's surface

this could be reduced down to only a mouse_enter event and mouse_exit event.  Which only fire one time each (when pointer enters the surface of the prim and when it exits) For a HUD (2D surface) then is pretty straight forward-ish to implement

with a inworld object being in a 3D setting then is a bit more problematic to know whether a person is interacting with the object, or their mouse pointer just happens to be hovering over the object while they are doing something else

[EnCore Mayne]

i saw that "click action" as having some potential.  i built some objects with the changeable clicks (sit, zoom, buy), but once they were attached as a HUD, they all came up blank.

another question, how are the links in the viewer interface and its tabs activated with a mouseover? any menu item is highlighted with a mouseover. same with dialog box options inworld....

which gave me a eureka moment as to how to solve this problem. instead of not knowing what you're clicking (as with the current HUD's deficiency) i built a HUD that brings up a dialog of choices on any ole generic touch anywhere on the prim. so, instead of having no idea if the HUD is a single link or multiples it's perfectly legible and only one click more.

genius?

the revolution has just begun.

[Wulfie Reanimator]

1 hour ago, EnCore Mayne said:

another question, how are the links in the viewer interface and its tabs activated with a mouseover? any menu item is highlighted with a mouseover. same with dialog box options inworld....

The viewer uses a very different system for its user interface than scripts. Since the viewer runs on your computer and has direct knowledge about everything (like your cursor and its own interface), it can tell that's being moused over.

With scripted objects, the viewer doesn't know which part of the face/texture is scripted to do something, since that info isn't/cannot be transmitted from the sim to the viewer.

When a scripter wants only a specific part of a face/texture to be clickable, they must first find out where an object was clicked, and then needs to write a bunch of "if X is between these values and Y is between these values..." conditions. The catch here is that the script can't "pre-define" the touchable area, it must be checked dynamically and that's why the information can't be told to the viewer beforehand.

The script knows where a face was clicked because in order for the viewer to interact with anything in the 3D world, it needs to use raycasting. This way the viewer knows which object is under the cursor (and thus if it's touchable), as well as the precise location where on the face the click is happening. But because of the previous paragraph, this won't work for scripted hovering without a new LSL feature for pre-defining touchable areas and new network messages to get this info to the viewer.

Edited June 8, 2022 by Wulfie Reanimator