|
Jotheph Nemeth
Registered User
Join date: 9 Aug 2007
Posts: 142
|
08-11-2007 18:44
is there a good solution to the drain bamaged sensor function?
It can only return up to 16 items, but you can get around it by doing consecutive scans each with a smaller arc. But the gotcha here is that the sensor call has no way to tell it where to start the scan arc.
You have to rotate the scanner.
For example, you want to do 4 scans, one each North, East, South, and West. Do the first scan, rotate the scanner by 90 degrees, do the second, rotate, etc.
But this doesn't work if it's a hud, does it?
Why couldn't the llSensor call include a start position for the arc?
Honest...I'm resisting the urge to call certain people bad names here.
|
|
Malachi Petunia
Gentle Miscreant
Join date: 21 Sep 2003
Posts: 3,414
|
08-11-2007 19:22
From: Jotheph Nemeth But this doesn't work if it's a hud, does it? If the HUD is linked to an invisible prim which is rotated and contains the scanner and exchanges messages with the HUD, it works. You only need to learn about 6 major LSL functions to do this. As to the wisdom of LSL API calls, I think the developer once admitted to hacking all LSL together in a weekend; beyond that I have no comment.
|
|
Jotheph Nemeth
Registered User
Join date: 9 Aug 2007
Posts: 142
|
08-12-2007 00:58
From: Malachi Petunia If the HUD is linked to an invisible prim which is rotated and contains the scanner and exchanges messages with the HUD, it works. You only need to learn about 6 major LSL functions to do this. As to the wisdom of LSL API calls, I think the developer once admitted to hacking all LSL together in a weekend; beyond that I have no comment. Yeah I considered having it rez an object and opening a listen, but that just adds to the sim lag. The point of this particular object is to detect and trace griefer objects. If the invisible prim is directly linked to the hud, then spinning it won't help much.
|