Can llSensor be restricted to avatars on one parcel only?

[Emma Krokus]

I am using Aley's Auto Defence Cannon Tower which is huge fun for me... but possibly not my neighbours...

So my question is, how do I restrict the cannon to react only to avatars on one parcel and ideally also not to fire over the "border" when an avatar is too near the parcel line... it's a small parcel and placing it so the parcel line is out of reach would make the whole thing rather... pointless.

Emma

 

[Wulfie Reanimator]

Not unless you manually check each avatar in the sensor event and make sure they are on the same parcel.

[Ruthven Ravenhurst]

Take a look at the examples on llOverMyLand

[Emma Krokus]

Thank you for the superfast responses, Wulfie and Ruthven!

Very helpful link, thank you Ruthven  

Am I right in assuming that this would not address the issue of cannonballs "flying" onto the neighbours' land?

I would be very pleased about some help with that too.

 

Emma  

Edited April 27, 2020 by Emma Krokus

[Ruthven Ravenhurst]

33 minutes ago, Emma Krokus said:

Am I right in assuming that this would not address the issue of cannonballs "flying" onto the neighbours' land?

Unfortunately yes. And there's not really an easy way to find the edge of a parcel. As long as the parcel is a rectangle/square shape. Starting at the lowest numbers of the parcel coordinates, and checking for the same parcel id every 4m up and to the side you can find the edges. But parcels don't necessarily need to be a square shape, they can have cut outs, being and diagonal having many borders on different x or y coordinates, there can be holes. They can have another parcel run across it cutting it into what appears to be 2 parcels.

I'm on my phone right now, otherwise I'd try to come up with a couple snippets of a script for finding the edges (under the assumption that the parcel is one square shape) and also figure out if the avatar is at least some determined amount of meters from those edges

 

Edited April 27, 2020 by Ruthven Ravenhurst
Changed my first sentence to say yes, instead of no, indicating, yes you are correct in your assumption. lol

[Rolig Loon]

It might be a bit clunky, but try some experiments with 

key kParcel = (key)llList2String( llGetParcelDetails( llGetPos(), [ PARCEL_DETAILS_ID ]), 0);
if ( kParcel != kMy_Parcel)
{
   llDie();
}

where kMy_Parcel is captured and saved as a global key when the cannonball is rezzed.  You'd have to do that test with a fast timer so that the cannonball can only stray outside your parcel a very small distance before it dies.  If that really is too clunky, then you can always fall back on the usual trick of simple forcing the cannonball to die after a really short time, no matter how far it has traveled. 

Incidentally, instead of using a sensor, it's cleaner to use llGetAgentList with the parameter AGENT_LIST_PARCEL to capture the UUIDs of anyone inside your parcel.  Refresh that list with a fast timer.

[Kyrah Abattoir]

Alternatively llGetAgentList can be configured to detect avatars only on the current parcel, however, unlike sensors it doesn't have a range limit.

[Rolig Loon]

6 minutes ago, Kyrah Abattoir said:

Alternatively llGetAgentList can be configured to detect avatars only on the current parcel, however, unlike sensors it doesn't have a range limit.

But then you can use llVecDist( llGetPos(), AvPos) to find out how far away the avatar is from your "sensor" at the moment, where you get AvPos by using llGetObjectDetails with the parameter OBJECT_POS.  Like the method I suggested above for determining whether the cannonball is still inside your parcel, this sort of test is potentially clunky but it can work.

Edited April 27, 2020 by Rolig Loon
Clarity

[Kyrah Abattoir]

1 minute ago, Rolig Loon said:

But then you can use llVecDist( llGetPos(), AvPos) to find out how far away the avatar is from your "sensor" at the moment, where you get AvPos by using llGetObjectDetails with the parameter OBJECT_POS.  Like the method I suggested above for determining whether the cannonball is still inside your parcel, this sort of test is potentially clunky but it can work.

Indeed and it is potentially easier on the region, I have no idea.

[Emma Krokus]

Thank you, Rolig! A great suggestion  

I'll be taking yours, Ruthven's and Kyrah's suggestions into account also. Thank you.

The parcel is a perfectly square 32 x 32, but the cannon is situated around 4 m from the neighbours' parcel border...  with a range of 9 metres - oopsie.

Emma  

[Rolig Loon]

1 minute ago, Kyrah Abattoir said:

Indeed and it is potentially easier on the region, I have no idea.

I don't either. You'd have to experiment. llGetAgentList is certainly more efficient than using a sensor and it has the additional advantage that  its "detection" limit is 100 instead of 16.  On the other hand, a fast timer and all the list checking adds some script time to the region.  If you only have a few avatars in the parcel, I suspect that neither method is going to make a big difference to the region.

[Kyrah Abattoir]

Sensors internally "most likely" do a region wide check.

for llGetAgentList() restricted to a parcel it depends what is the most likely scenario between having people outside or inside the parcel.

Edited April 27, 2020 by Kyrah Abattoir

[Mollymews]

with small parcels then another way is to use smart bullets that know where the target is

in the gun we get the vector position of the target, pack it in a integer, and pass this to the bullet in the rez param. Then in bullet on_rez unpack the target to a vector

example code to pack and unpack a vector to/from integer

// in gun

   vector pos = llDetectedPos(0);
   
   // pack vector in an integer with 1 meter accuracy
   // 9 bits for X : 9 bits for Y : 14 bits for Z
   integer target =
     ((integer)pos.x) << 23 |
     ((integer)pos.y) << 14 |
     ((integer)pos.z);
   
   llRez..., target

// in bullet

on_rez integer param

   // unpack integer to vector
   vector target;
   target.x = (float)(param >> 23 & 0x1FF);
   target.y = (float)(param >> 14 & 0x1FF);
   target.z = (float)(param & 03FFF);

 

now that the bullet knows where its target is then we can 'smart' move it depending on effect. To avoid going off a small parcel then llMoveToTarget is the safest way to move the bullet. Having it llDie after doing its at target effect

edit add: i typed the code off the top of my head and never accounted for potential input overflow. When packing bits is best to mask the input range. So again

integer param =
          ((integer)pos.x & 0x1FF) << 23 |
          ((integer)pos.y & 0x1FF) << 14 |
          ((integer)pos.z & 0x3FFF);
 
vector target;
          target.x = (float)(param >> 23 & 0x1FF);
          target.y = (float)(param >> 14 & 0x1FF);
          target.z = (float)(param & 0x3FFF);

 

Edited April 28, 2020 by Mollymews

[Rolig Loon]

On 4/27/2020 at 9:05 PM, Mollymews said:

integer param =
          ((integer)pos.x & 0x1FF) << 23 |
          ((integer)pos.y & 0x1FF) << 14 |
          ((integer)pos.z & 0x3FFF);
 
vector target;
          target.x = (float)(param >> 23 & 0x1FF);
          target.y = (float)(param >> 14 & 0x1FF);
          target.z = (float)(param & 0x3FFF);

Thanks, Molly! That's a nice, quick pair of routines, easy to write as a pair of utility functions:

integer FromVector (vector v)
{
         return  ((integer)v.x & 0x1FF) << 23 |
          ((integer)v.y & 0x1FF) << 14 |
          ((integer)v.z & 0x3FFF); 
}

vector FromInteger (integer I )
{
    vector v;
          v.x = (float)(I >> 23 & 0x1FF);
          v.y = (float)(I >> 14 & 0x1FF);
          v.z = (float)(I & 0x3FFF);
    return v;
}  

Note, however, that they will only work within the range [ <0.0,0.0,0.0>, <511.0, 511.0, 16383.0> ] .  That's fine for the application you described, since regional positions are always vectors with  positive components and bullets are generally only useful within a single region, but is limiting for vectors in general, particularly any with negative components. 

[Mollymews]

13 hours ago, Rolig Loon said:

Note, however, that they will only work within the range [ <0.0,0.0,0.0>, <511.0, 511.0, 16383.0> ] .  That's fine for the application you described, since regional positions are always vectors with  positive components and bullets are generally only useful within a single region, but is limiting for vectors in general, particularly any with negative components. 

i did a packer/unpacker for positive and negative values here

 

[Rolig Loon]

That's lovely.  I must admit that despite many years of scripting in LSL and decades of programming in other languages before, I have never been comfortable with bit-shifting. It's a conceptual weakness on my part.  Thank you for doing the heavy lifting on this one, Molly.  

[Mollymews]

i have always been interested in artificial intelligence. Compression algorithms put AI into quantifiable hard numbers. Is there a program which can reduce the space needed to store information ? Smarter (more intelligent) programs reduce the space more than less smart programs do

when get way down into these kinds of programs then we end up at the bit level, fractional bit level the deeper we get, with lots of bit manipulation and logical operations to code up

the Hutter Prize encourages this kind of AI research

http://prize.hutter1.net/index.htm

when collect the prize money from Hutter then a further grail of this kind of research is the Clay Mathematics Institute Millennium Prize for a proof of the P vs NP Problem

https://www.claymath.org/millennium-problems/p-vs-np-problem

not that I am anywhere in this league, I just find it interesting

and sometimes when I am in conversations on this forum then I realise that some of the things I have learned from following AI research can be applied to similar SL problems and can sometimes be coded up in LSL. Altho I do tend to use a lot of logic constructs in what little LSL code I do write, sometimes unnecessarily, which is more a product of my learnings than anything else