llGetCollision or llDetectedScale

One of the things that I am strongly miss in SecondLife is a way for scripts to find out about the existance of a collision mesh in a place nearby.

Scripted robots today usually have fly blind, or phantomed. They cannot obtain information about the scale of objects nearby. They cannot detect any information that will allow them to tell ahead if they are about to face collision if they move trough a specific set of coordinates or not. And this is quite frustrating.

I'd like to recommend the implementation of atleast one of the following three functions:

- key llGetCollision(vector pos) - Checks if this set of coordinates exists inside a prim or a linked object that is not set to Phantom. If true, the key of the object will be returned. If false, the function will return NULL_KEY.

- vector llGetScaleKey(key id) - Returns the overall scale of an object that is in the same Simulator as the object.

- vector llDetectedScale(integer detected) - The same as llGetScaleKey(), but goes into the sensor() event.

Please concider.

/me wants!

I want a way to specify a unit vector and tell me the coordinates (or even just distance) of the first solid surface it encounters.

In addition, I want llDetectedCollisionPoint or somesuch for collision events that returns the point where the two contact.

In the meantime... Could you use a companion object, positioned at the vector you wish to check? The object could be totallyclear and could report back what it finds using collisions or scans along with llDetectedKey... from that key, you could try llGetBoundingBox() to figure if it's safe for the robot to move, or if a new vector should be tested.

a good idea and I've seen people do it, but it requires another physical object :/, not to mention following objects tend to get lost at sim boarders.

I do not advocate for any of the above recommended functions; except for maybe lDetectedCollisionPoint()

llSensorCollision(vector local, float radius, integer type)
local can be no further then 10 meters in any direction.
radius can be no bigger then 5.
A sensor event is thrown if anything is in that collision radius at the local vector.
type is a bitfield:
TYPE_NORMAL - detects normal prims
TYPE_AVATAR - detects avatars
TYPE_VOLUMEDETECT - detects volumedetect prims
TYPE_PHANTOM - detects phantom prims

llDetectedScale or llGetScaleKey would be totally useless, scale is just one of a few factors that go into making the bounding box of a prim (example i have a <10,10,10> box that has a bounding box <30,30,25.4>, so tell me how knowing it's scale would help me know if it were colliding?). Use llGetBoundingBox(key object);

The getting lost problem could be solved by rezzing a new companion object if no response is heard from the current object. The current object would die if it doesn't hear from the parent after a while.

And why would the companion object need to be physical?

the companion object needs to be able to derez itself it if gets lost.

and it needs to be physical because collision events are only fired if one of the interpenetrating objects is physical. if you were to llSetPos() a volume detect non physical prim over some other non physical object no collision event would fire.

I support Strife's ideas though the llSensorCollision params might need some work.

I think this last function is a bit unnecessesary. One could just use llGetScaleKey(llDetectedKey(...)); to get the scale of a detected object.



See this post.




This is true strife, and is one of the reasons LSL in general is lacking for giving an object any ability to "visualize" the world around it.
Linden Lab needs to retrofit the llDetected* functions to account for linked primitives. This way, an equivelant of llDetectedScale can be called on each prim in the set to create accurate collision detection.

==Chris