Why are sensors so limited?

I was reading this thread in the scripting library...
/15/e4/12070/1.html
So I started wondering, why do we still have the same old crippled sensors we've had since beta?
How do they work behind the scenes, and what's keeping them from being improved?
My guess is that it's a Havok thing. But I don't care about Havok!
Most of what I code both IRL and in SL are business apps that do not require a physics engine and where the concept of distance is anathema.
Why do we even have to have such a weird thing, instead of being able to, say, access a raw list of all users presently in the simulator, or having a pretty wrapper around some predefined database queries?
I would like to have something like an llRequestSimData instead of sensors. I know it's doable, so why not do it?

Also, it would be rather cool if they could become synchronous.

Azelda

I agree, a more detailed key2xyz & list xyz2key (returns all matching keys in a list) would be fantastic.

-Adam

I agree totally, Eggy. But I can probably guess what happened to give us what we have today.

Limited sensing is an important concept for gaming. Essentially, you don't give players full info on the environment, so they battle it out (or whatever) under conditions of restricted data, which makes it more of a challange.

However, plot management is not gaming, and yet somehow developers and administrators have ended up having to use this gaming feature for basic daily management and admin, for lack of any decent data query infrastructure. This is, well, I think the word "nuts" is appropriate.

Gaming is important for the future survival of SL, I agree. But before we're anywhere near to being able to create high quality and highly interactive attractions for players, we need to be able to create and manage our sites! And I mean easily, not as a gaming challange. ))

So, please give us the whole plot + object query infrastructure that's entirely missing at the moment. This is for use by plot and object owners only, not accessible by anybody else. Anything will do. Even a raw SQL string into the database would work, restricted to our own land and items of course, and probably returning CSVs, nothing fancy. Whatever the form, it'll be a massive improvement. It's plain silly at the moment.

Scripts should have at least the same vision on the environment as avatars: and avatars can see out to 100m+, zoom in on any area, and find out the owner, creator, type, size, and so on of any prim in this range.

Sensors should be able to do the same.

Azelda

I'd be a fan of a function that read all avatars on a plot. Yes, through various nasty hackjobs, this can be done with sensors, but if your plot's not round, you're still reading the neighbour's land, or you're missing some of your own. And, frankly, I've yet to see a round plot. I could definitely see this as being an option setting, even, for Eggy's suggested "llRequestSimData"... Some sort of constant that defines the area of application, perhaps, so that you could use something like llRequestSimData(SIM, GETUSERS) or llRequestSimData(PARCEL, MYOBJECTS).

I dunno, just a thought...

I haven't had much time to script in awhile, but can't you specify an angle to scan? Put a scanner in a prim on the corner of your land, point it inwards,and limit the scan to a 90° angle.

Angle isn't really the problem for me... the problem is that sensors can only return up to 16 items and they will only work up to a 96 meter radius. It's also impossible to figure out how many prims are in an object you don't own, through a script.
Actually, it's pretty much impossible to know or control anything in this place. It's all geared towards each script only being able to know about and modify the object it's attached to, which is ridiculous. We can use sensors, but they are a little bit limited when you consider that the world is made up of 400 sims and a lot of people own one of their own.
I shouldn't need a sensor, I should just have to do llGetObjectProperties(key Id); that would return a list containing all the same info llDetected* gives me.
llGetObjectsOnPlot() would give me a list of all object keys on my plot, and then i could run the aforementioned function on each key. Also, llGetAgentsOnPlot(), llGetAgentsOnSim(), among a plethora of other llGetFooOnBar type of functions I could suggest... also llName2Key(string avatar) and all that stuff we'll never get
Oh, and stuff like llReturnObject(s) too.

open the flood gates, we want more and better data

I'd always thought that the way scripts are confined like that was sorta an OOP thing. A "true" object should encapsulate only it's data and not be able to just grab random global data. It should have to communicate with the world by sensing what's around it and requesting data from other objects by using properties, methods or events.

I'm definately with you though that I've yearned for that kind of data on many occasions, but that was always my own reasoning for why it's the way it is.

Yes! We MUST increase sensor effectiveness, if only to provide us barons with better land acquisition tools!

*chortles and spins his leather-easychair back to the massive land map on his main study wall.*

Uh, sensors can't sense any data about the terrain mesh, sorry.

let me try to throw an idea at someone.....

is it possible to have a sensor make one pass, collect 16 agents, dump names into said list, on next scan, check while scanning if agent name is currently on list, go to the next on... if agent not on list... add to it... then call up the list?

I want more detection routines, such as llDetectedMass()...

Generalized raycasting would be nice, though I guess one could simulate this with a very narrow sensor at a particular range. However, it would be useful if we could do this without the sensor being constrained to a prim's location and rotation. (Think: Better pathfinding systems by checking what's to the right/left of us in low-prim items/vehicles...)

Sure. But the problem is, the agents Sensor returns are not... always consistent.

Better just to allow the detection functions in the sensor event to handle more than 16 avs. Let 'em go all the way.

Oh... and...Eggy had crippled sensors....


.... in beta

Well, it's not only the limited number of agents and range. You also have to deal with the weird behavior that happens on sim boundaries. In these cases, you scanner can actually see more than 16 agents if he's on the border of two sims but they will be scanned say 1 time out of 4. It make things a bit more tricky.

As for scanning for ppl on your plot of land, it's quite possible I imagine. You need to have one "server" that collate data from multiple sensors around your terrain. Then you check the x,y position of the players and verify if it's inside your plot of land.

Really avs on sim borders should appear as 256+ or less than 0, ie if there's to the right of your sim (positive x value) then they might be say <266,0,0>, ie <10,0,0> inside their own sim.

This is likely what complicates things, as to take this into account in a quick way for over 16 avatars is not going to be the easiest thing!

In the debug tool the "Main Agents" line reports the correct number of avatars in the sim. So at least in the client there is either a data feed or detection. For "almost" all cases everyone is concerned with avatar detection, this seems to be the what most people want.

I would guess, how ever they are populating the Main Agents line in the debug GUI also has access to the UUIDs of the agents otherwise how could it count uniques? What ever technique they are using to display Main Agents in the debug GUI should be ported to an LSL function which returns the UUIDs of the Main Agents in the current sim. This would both sovle a lot of hack jobs an most likely cut back on laggy scripts using sensors (assuming people adopt the new fuction and discard thier old sensor scripst).

There's a lot of info in the debug GUI that I'd like to see script access to =c) ... even if the data were cached for x seconds before refresh (ie not live) data wold be benificial.

Many features LL is developing for land tools could be dropped if they gave us the tools, we could dev our own features and let LL go on to dev features we couldn't ourselves.

A note on sensors which isn't apparent in the wiki, llSensor() will NOT sense beyond sim boundaries where as llSensorRepeat() will but it may take several iterations (I think four from my fiddling but no guarantees on exactly how many it takes). It also seemed to me that llSensorRepeat() would sense the four sims withing range in a consistant pattern but I never totally verified that.