llRegionSay and llSay and channels and lights (oh my)

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

llRegionSay and llSay and channels and lights (oh my)

Argent Stonecutter
Based on previous discussions with Lindens: when chat happens on a  
channel, every listening object in the sim is visited. First a check  
is done to see if they're listening on the same channel, then they  
are examined to see if they are in range and other filters are executed.

This means:

* Every listener gets examined on every chat.
* The most efficient filter is by channel.
* Filtering by range is unnecessary overhead that is eliminated by  
llRegionSay.

Using llRegionSay is the absolutely most efficient way to implement  
any sim-wide communication system.
_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
Reply | Threaded
Open this post in threaded view
|

Re: llRegionSay and llSay and channels and lights (oh my)

Kelly Linden
Argent Stonecutter wrote:

> Based on previous discussions with Lindens: when chat happens on a
> channel, every listening object in the sim is visited. First a check
> is done to see if they're listening on the same channel, then they are
> examined to see if they are in range and other filters are executed.
>
> This means:
>
> * Every listener gets examined on every chat.
> * The most efficient filter is by channel.
> * Filtering by range is unnecessary overhead that is eliminated by
> llRegionSay.
>
> Using llRegionSay is the absolutely most efficient way to implement
> any sim-wide communication system.
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
You are pretty close.  The actual order of events is:
1. Chat that is said gets added to a history.
2. A script that is running and has a listen event will ask the history
for a chat message during its slice of run time.
3. When the script asks the history for a chat message the checks are
done in this order:
 - channel
 - self chat (objects can't hear themselves)
 - distance/RegionSay
 - key
 - name
 - message
4. If a message is found then a listen event is added to the event queue.

The key/name/message checks only happen at all if those are specified of
course.

So, the most efficient way is llRegionSay on a rarely used channel.

_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
Reply | Threaded
Open this post in threaded view
|

Re: llRegionSay and llSay and channels and lights (oh my)

Harleen Gretzky
A prim cannot hear itself, an object consisting of more than one prim can
chat among prims (though it is probably better to use link messages in most
cases).

----- Original Message -----
From: "Kelly Linden" <[hidden email]>
To: "Scripters" <[hidden email]>
Sent: Tuesday, November 13, 2007 3:04 PM
Subject: Re: llRegionSay and llSay and channels and lights (oh my)


> Argent Stonecutter wrote:
>> Based on previous discussions with Lindens: when chat happens on a
>> channel, every listening object in the sim is visited. First a check
>> is done to see if they're listening on the same channel, then they are
>> examined to see if they are in range and other filters are executed.
>>
>> This means:
>>
>> * Every listener gets examined on every chat.
>> * The most efficient filter is by channel.
>> * Filtering by range is unnecessary overhead that is eliminated by
>> llRegionSay.
>>
>> Using llRegionSay is the absolutely most efficient way to implement
>> any sim-wide communication system.
>> _______________________________________________
>> Click here to unsubscribe or manage your list subscription:
>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
> You are pretty close.  The actual order of events is:
> 1. Chat that is said gets added to a history.
> 2. A script that is running and has a listen event will ask the history
> for a chat message during its slice of run time.
> 3. When the script asks the history for a chat message the checks are
> done in this order:
> - channel
> - self chat (objects can't hear themselves)
> - distance/RegionSay
> - key
> - name
> - message
> 4. If a message is found then a listen event is added to the event queue.
>
> The key/name/message checks only happen at all if those are specified of
> course.
>
> So, the most efficient way is llRegionSay on a rarely used channel.
>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
>


_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
Reply | Threaded
Open this post in threaded view
|

Re: llRegionSay and llSay and channels and lights (oh my)

Murrough McConachie
Update

Thanks to all who responded.  We have evaluated all the input.  First, we have updated the requirements

Requirements Summary

a)  Originally we started out with this mechanism for just controlling lights.  However, it has transpired that we will be using it for two other features (albiet linked),

b)   The system will also be used to hide/unhide pose balls.  We have hundreds of these as well, and they all seem to have listen events.  We will be re-commissioning most of these to work on linked messages only and remove their listen events.  The protocol will just pass a boolean value (integer of course)

c)   We will also be using the same schema to set textures of objects so we can change schemas from a command as well.  In this instance, the UUID of the texture will be passed.

Functional Specification

1)   Our island is divided into the classic 4 by 4 parcel grid (16 in total) with the central four combined into one, making 13 in total.

2)   Having evaluated the use, 70% of instruction will be to a particular parcel, with the other 30% being multi-parcel.

Based on this

a)   Each Parcel (64 by 64) will be allocated its own listen channel as the initial filter.  within each parcel, 9 listen objects will be placed at the tri-grid centres.  These will be 10 by 10 objects.  Hopefully everything in the parcel will be able to be linked to one of these objects

b)   Listen Objects will communicate the message using link all others, to all the prims attached to them

c)   A Comms protocol will be developed, to provide the instruction.  All child scripts therefore will only fire on link_message.  

d)   A hud application will be developed that will listen on a positive channel.  The hud application will then repeat what is said, using RegionSay or Shout.  This allows the avatar to issue commands.  Should the command issued be a global one, the hud app will repeat the message on all 13 parcel channels using RegionSay. Otherwise it will get the pos of the avatar and calculate the correct channel to send and use Shout

d)  Listen objects will only be deployed if 1 or more prims needs to be linked to receive instruction.  Similarly, if more prims need to be linked than can be accommodated, then a second duplicate listen object will be deployed.  The key is the co-ordinates of the listen objects are fixed

e)  Since most of the parcels have false floors, there are small gaps between the land and the floor, where the listen slabs (10x10x0.01) will be placed.  This avoids the need of having to phantom the root and cause all the link objects to go phantom as well

f)   The listen objects will also respond to the hide/show command sequence, so they can be found again.

The only other area we are researching is whether we can send an email to a fake key, and use a mailto event to trigger an http response in a group of unlinked prims.  Depending on whether the 'cheat' as mentioned by Kelly can also be forced to cheat here, but this is a long shot, and will probably be ruled out within a few minutes of starting (if not on here first).

In Closing

I know when I started scripting, I found it hard to research such things on the mainland, especially such enterprise techniques and solutions like this.  If anyone wants to try any such idea, then provided it does not adversely affect the business model of Elation Island, you are welcome to come over and play accordingly.

Our other large project is automatic vehicles.  This is far more complex, getting boats to automatically move along the water channels between the parcels using vehicle mechanics rather than just physical moves.  This has been tacked with a 4 script 3-prim system, being a Navigator, that calculates a route or recieves global instruction to move, a Pilot that moves the vehicle, a Watchman, that detects other vehicles, implements anti-collision, requesting new routes etc and finally a Watchdog, that monitors movement based on timers and resets everything should there be a major problem.  The anti collision and corrective measures is proving to be very difficult.


A big thanks for everyone who has contributed

Kind Regards


Murrough McConachie
Elation Island (www.elationisland.com)


Harleen Gretzky wrote
A prim cannot hear itself, an object consisting of more than one prim can
chat among prims (though it is probably better to use link messages in most
cases).

----- Original Message -----
From: "Kelly Linden" <kelly@lindenlab.com>
To: "Scripters" <secondlifescripters@lists.secondlife.com>
Sent: Tuesday, November 13, 2007 3:04 PM
Subject: Re: llRegionSay and llSay and channels and lights (oh my)


> Argent Stonecutter wrote:
>> Based on previous discussions with Lindens: when chat happens on a
>> channel, every listening object in the sim is visited. First a check
>> is done to see if they're listening on the same channel, then they are
>> examined to see if they are in range and other filters are executed.
>>
>> This means:
>>
>> * Every listener gets examined on every chat.
>> * The most efficient filter is by channel.
>> * Filtering by range is unnecessary overhead that is eliminated by
>> llRegionSay.
>>
>> Using llRegionSay is the absolutely most efficient way to implement
>> any sim-wide communication system.
>> _______________________________________________
>> Click here to unsubscribe or manage your list subscription:
>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
> You are pretty close.  The actual order of events is:
> 1. Chat that is said gets added to a history.
> 2. A script that is running and has a listen event will ask the history
> for a chat message during its slice of run time.
> 3. When the script asks the history for a chat message the checks are
> done in this order:
> - channel
> - self chat (objects can't hear themselves)
> - distance/RegionSay
> - key
> - name
> - message
> 4. If a message is found then a listen event is added to the event queue.
>
> The key/name/message checks only happen at all if those are specified of
> course.
>
> So, the most efficient way is llRegionSay on a rarely used channel.
>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
>


_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters