Feature Proposal: LSL function : llSelected( integer : selectionindex)

list : llSelection( ) would return a list of keys of objects currently selected inworld by the user

I like this feature suggestion, but Id like to add three events:

select(integer numSelectors)

select_start(integer numSelectors)

select_end(integer numSelectors)

that activate when the object containing the script is selected (either in edit mode, when being right-clicked, or when being drag-moved with the ctrl button). These function much like touch/touch_start/touch_end
==Chris

Yeah that would be neat. I suggested this a year ago
I wonder why LL is always so reluctant to mess with the scripting language...

Added this to SL feature voting system as proposal 112
==Chris

Christopher Omega's l"lSelected" Proposal 112 will greatly increase scripters powers to control objects. Many wonderful things would ensue for the users of scripted objects. Everyone who likes scripted objects to do neat things - like for example, align the left edges or right edges or tops of all selected objects - should support this proposal.

Let's see now, what is that I really want the ability for a script to know what is selected for?

This is just one example of what I am wanting: to be able to write a routine that will position selected objects evenly.

Just put the first object where you want it, the last object where you want it , and select the objects in the order you want them to be positioned in. The routine would calculate the difference in position between the first selected object and the last selected object and determine the average change in postion, then put the objects in evenly spaced positions.

The problem with this that you still have to tell the objects where to go using one of the existing message functins. What I really want is the ability to call one objects routines and variable from within another object.

But perhaps one could work in a more SL style manner with an additional command llSelectedMessage, similar to llLinkMessage?

I think this idea needs more work to flesh out how it would be put into use. I invite further discussion.

Prop 112 has my vote I came to this same conclusion; And is the reason I searched the Proposals and found it! Let's get some steam under this one! Maybe LL don't wanna mess with this one now. Maybe they have it implemented for H2 and Mono

This would be soooooo useful.

There might be some problems, such as the list of selected keys being too long for LSL to deal with.

If so, there would be some way to deal with this problem, such as adding an index number to the function a getting the results one at a time.

Regardless of what changes it might take to make the spirit of the idea implementable, this is an idea that would benefit all of SL tremendously.

Vote for it!

I'm not sure I understand this. I was assuming that the goal was to allow a script to detect another object that you selected, for in-game use (say, to let you target the second object with particles, or to select an avatar by clicking rather than by name, in a hug script).

You can already use touch or voice to communicate to scripts in objects themselves. For that purpose wouldn't an llIsSelected() function that the script could use to tell if the prim it was in was selected? Possibly also llIsLinkSelected(integer link) to allow the root prim to check on its children?

The three events I proposed would work like touch_start/touch/touch_end. If a linked object is selected, then llDetectedLinkNumber will return the linknumber of the selected object. Why deviate from LSL's event-oriented model?
==Chris

Err...

I'm ALSO suggesting basing it on the LSL event model.

But basing it on "sensor()", that is, when I call "llSelected(...)" I'd get a "sensor()" event back telling me the prims the user had selected. Whether they were in my linkset or not.