Welcome to the Second Life Forums Archive

These forums are CLOSED. Please visit the new forums HERE

Abusive Sensors/Boot Scripts got you down? How about llSensorList and a sensed event?

Jeffrey Gomez
Cubed™
Join date: 11 Jun 2004
Posts: 3,522
04-19-2005 11:08
I've been working on an autopilot script on and off for the past couple of days. Works great. Since I can easily create an autopilot that'll navigate several sims with ease, why aren't we able to create ones that avoid abusive sensor bubbles for ban scripts?

I propose the following two solutions to that problem:

llSensorList(vector offset, float time, integer type)
Lists the last fifteen sensor events at current position plus offset within a maximum 60-second time interval. Returns information as based on the following constants for "type."

SENSOR_POSITION - sim-relative position of sensor object.
SENSOR_ARC - scanning arc of this sensor.
SENSOR_ROTATION - Rotation of sensor, to make the arc relevant.
SENSOR_RADIUS - Scanning radius of the sensor.
SENSOR_TIMER - Returns number of seconds since last event by this sensor. Multiple events are truncated.
SENSOR_KEY - Returns key of object calling the sensor.
SENSOR_SIM - Returns sim of sensor if able to detect cross-sim.
SENSOR_TYPE - Returns constant scanned for: AGENT, ACTIVE, PASSIVE, SCRIPTED, or the combined bits thereof.

As stated, multiple calls from the same object are truncated.


Additionally, how about an event when an object is sensed?

sensed(integer total_number)


Thoughts? Is this abusable? I know if we had this sort of event, pathfinders and autopilot scripts could navigate around many of the encroaching "ban everything that moves" scripts on the grid.

Furthermore, since much of this information is already kept at the sim level, additional sim load would likely be minimal.
_____________________
---
Oz Spade
ReadsNoPostLongerThanHand
Join date: 23 Sep 2003
Posts: 2,708
04-19-2005 16:01
I'd like to add:

SENSOR_OWNER - Returns UUID key of owner of object.
SENSOR_CREATOR - Returns UUID key of creator of the *script*.
(actualy the NAME may be better rather than the KEY)

You could get that by doing the object key, or perhaps a land scan of the owner of the property its own, but eh, would be nicer to have those.

However, while I like this idea very much, what is to prevent someone from making a script that uses this to detect objects within a game to avoid objects in a game that use sensors?

Also, a griefer could use this to detect the scanner and stay out of range and grief you. While this may be fun if they aren't on your land anyway, it could still present a problem, correct?

While anyting can be abused, but usualy isn't, those are the two things that came to mind ^.
_____________________
"Don't anticipate outcome," the man said. "Await the unfolding of events. Remain in the moment." - Konrad
Jeffrey Gomez
Cubed™
Join date: 11 Jun 2004
Posts: 3,522
04-19-2005 16:24
From: Oz Spade
However, while I like this idea very much, what is to prevent someone from making a script that uses this to detect objects within a game to avoid objects in a game that use sensors?

Also, a griefer could use this to detect the scanner and stay out of range and grief you. While this may be fun if they aren't on your land anyway, it could still present a problem, correct?

While anyting can be abused, but usualy isn't, those are the two things that came to mind ^.

Good points. I would say that the first makes a compelling argument for more land tools for scripts. The second could be alleviated fairly easily, so long as the person knows what they're doing - increasing the scan range or triggering it at certain times, for example. ;)

And it would require a fair deal of math to "cheat" with this, again making it more isolated as a "cheat on demand" kind of thing.
_____________________
---