couple suggestions

how about a new event

mouse_over (key user)

this would bring a whole new level of interactivity, no?

(maybe even if the distance of the user could somehow be passed to the event too)

and a new function call

llDoMenu

that allows access to certain user interface menu commands from a script, this would have loads of applications!!! obviously mostly on scripts written for people's own benefit and use.

but hey , its bloody brilliant allready

I'll move this to Scripting Tips for further discussion, in case there's anything appreciably similar which already exists.

Also, feature suggestions can be formalized in:

Feature Voting Tool

Get lots of support and it'll help raise visibility and possible priority of getting it done, at our discretion--but I have seen great things come true many a time!

Have a nice day, Goapinoa.

http://secondlife.com/vote/vote.php?get_id=1699

This was my feature proposal. Basically just something that, when a mouselooking avatar sees ground/object/avatar, the function would return a vector or a distance from the avatar.
Not exactly what you're looking for though.

Presumably if such a new event were implemented, it could be done like the other events (rather than a key as you suggested, an integer number of detected mouse-overs). Scripters could then use the llDetected* functions, such as llDetectedPos, to get information about those triggering the event.

I don't really see how this would be THAT useful, perhaps you'd like to elaborate?

As for llDoMenu, just why would a script need to mess with the user's settings through menu commands? I would think it would need to be a very small subset of the commands accessible to not become annoying or dangerous.

If you could explain some of the things you have in mind, it might help your suggestions sounds more useful.

~Az

Mine gets a vector that the avatar in mouselook is looking at. Useful for completing triangles in some cases and may be for HUDs using distance formulas or anything.

Not exactly the same as you said, but in the same vein. Ill be voting for both.

"Presumably if such a new event were implemented, it could be done like the other events (rather than a key as you suggested, an integer number of detected mouse-overs). Scripters could then use the llDetected* functions, such as llDetectedPos, to get information about those triggering the event."

Of course it would, why didnt i think of that!


The uses of a mouse-over event would be plentiful, far too many to list,

shopping, - targeted advertising in a more friendly fashion than sending notecards based on sensors, whilst still not having to rely on the user requesting the product info

displays - imagine the freebies bizzarre without all the SetTexts, now each of the setTexts only appear on mouse over - much nicer!

collecting statistics - imagine the benfit of knowing which of your products are recieveing more mouse-over events than which others, experiment...do they register more mouse-overs with this grahic or this graphic, collecting consumer data !

gaming - the application to gaming of this event would be HUGE!!, but ill just take Tringo as an example, if we had a mouse over event then the chap that made Tringo (raises hat), would have surely used it instead of having the dot that requires an extra piece of mental calculation. "Ohh quick think, will it fit, um two along one up, no not herem, umm, yeah, oh shit, timeout"

The mouse-over event would have enabled the prospective position of the piece youre about to drop on the board, have its target destination outline highlighted.

(Maybe thats half the fun, but you see what i mean)

As i write this the application to gaming of this event are floodin my brain! Snooker, Chess, RC stuff, any game with defined movement boundarys...

Sensor Replacements in some cases. - probably alot of people have scripts on their property that they want to do x,y,z but only when theyre around. E.G I have room generator thats uses the temp on rez hack to keep a 1 prim, fully furnished office in place. Even though now, i have it set up on a sensor so it only actually exists when im near it. A mouseover event would enable me to save lag and sensor calls and then i can keep my office intact when im near it by have a large mouse-over sensitive prim located well nearby that generates it instead.

Realism in Nature - You can sneak up on a deer sometimes, a mouse over event that makes it bolt, is probably the only way youll be able to get a kind of behaviour similar to that of the real world for the bolting of startled deer. -
Many fish swim around in SL, in RL when you wave your hand over a river the shadow causes the fish to swim away.

and loads more

---

llDoMenu uses too would be pretty handy, I guess its uses would be limited unless you have a GetPermissions - Do menus, of some sort.

however even without permissions, just for your own benefit you could have...

'Scripting mode' - Have you Draw Distance, Particles Visibility, Beacons visibility, Sound Levels all jump to your preffered setting for Scripting,
then when youre done touch of a button, they all bounce back to your
'Exploring mode' - Higher draw distance, sound back on, beacons off etc

Photography - Camera /Video could automaticaly snapshot when certain conditions are met.

Uploads could be performed without user interacation.

This would almost enable MIRRORS where in the camera snapshots the image in repsonse to a command frmo a sensor event (or preferably a mouseover event) uploads it and the new snapshot is displayed as a picture on the face of the mirror straight away.

Anti Doppler - A little attachment that listens to the sound levels and adjusts your own volume according to your distance from the source to compensate for the doppler effect would be possible, this has applications for dealing with noisy neighbours. without shutting out all your sound.

This is just the tip again, plenty more scope here...

And if we could use llDoMenu with some permissions stuff then we could have...

Masses more effects,
If you can control the end users visual settings for a spell in response to permission being granted, you can turn of and on their particles and beacons and adjust their sound levels you have just multiplied the possiblities for visual/auditory effects tenfold.

Sound effects in your shop become on/offable for anyone who visits, individually! without taking the user away from the shop and into his preferences at all.
Particle Effects as above for sound

Draw Distance - Setting the draw distance of the people that visit your establishment, is a handy Lag control device, you can just tell the clients of all your customers not too pay attention to the neighbour three doors down whos just maxed out there 15000 prims each one with its own unique texture.

-

I'm still pretty new to all this and chances are theres ways to do alot of this stuff already i just dont know about.....yet... Please lemme know if you do...Or if I'm getting confused about how SL works in regards Draw Distance /Sounds, lol reckon i probably am else why would i get moved to the Scripting Tips forum?

i dunno where this thread was originally but it should have been in the feature suggestion forum ... most scripted solutions to mouseover are clunky at best

Lol, It was!