Jump to content

Advice Needed - Listening or sensor Scripts


Loki Eliot
 Share

You are about to reply to a thread that has been inactive for 3616 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

Greetings Programmes,

Im researching for an idea i want to do and need some advice.

I want to create Wristbands that when you walk near a person with the same wristband activates a glow to show someone closeby has the same style band.

I had two ideas

1. use listening commands on a certain channel that when hearing a specific word would activate the glow. This would need the oweners wristband to send out the word to be heard by similr wrist bands.

2. A slow Sensor that repeated every couple of minutes to see if anyone nearby is wearing a similar wrist band. I dont know if wearable sensors can sense other poeple wearable attachments though.

Question is wether these ideas are possible  and how much risk of extreme lag is there if over 30 people in a room had these wristbands on. :-p

Any advice or suggestions id be very gretful.

Link to comment
Share on other sites

Because this type of wristband is going to require a sort constant scan of nearby individuals anyway, my personal preference would be to go with a listen().


You could put each type of wristband on a unique channel and have them llSay() every 30 seconds or so ... if they hear another wristband of the same type, they start to glow.  If ~45 seconds go by without hearing anything, they stop glowing.


Going with the listen() route will help multiple bracelets of the same type all light up with the least amount of lag.  Sure, there will be a lot of noise on your channels, but IMHO, it beats a sensor.

  • Like 1
Link to comment
Share on other sites

I think you are stuck with llListen because llSensor doesn't, as far as I know, detect attachments.    

I'm wondering about having the wristbands listen on a channel based on their owner's uuid (using something like the Key2Number routine in the wiki, plus an offset), so you don't have lots of items listening on the same channel.   Then you could have a slow sensor looking for nearby avatars, calculating a channel based on the uuids it detects, and saying "hello" using llRegionSayTo (avatar, channel, ."...."), which the avatar's attachments (and no one else's) will hear too.

 

Link to comment
Share on other sites

I meant something like this.  I am trying to cut down the number of messages getting passed round and which the scripts in each object need to process, since I know from working with RLV relays it can get quite laggy when you have a lot of messages being passed on the same channel, and lots of objects trying to process them. 

This is just part of the script, of course -- not only do you need to decide what to do when you hear from an item with the same name as yours, but you need to decide what to about clearing the list periodically, since it's only going to check people the once.   Maybe reset it when you change sims? 

 

integer myChannel;integer Key2Number(key objKey) {	return ((integer)("0x"+llGetSubString((string)objKey,-8,-1)) & 0x3FFFFFFF) ^ 0x3FFFFFFF;}integer handle;integer offset = 77;list detected;string myName;default{	state_entry()	{		myChannel = offset+ Key2Number(llGetOwner()); //generate an integer based on the owner's uuid		myName = llGetObjectName();		handle = llListen(myChannel,"","",myName);//start listening for someone saying the object's name on this special channel		llSensorRepeat("","",AGENT,5.0,PI,10.0);// start scanning on a slow scanner over a 5 metre radius	}	listen(integer channel, string name, key id, string message)	{		//must have been a message from another object with the same name as mine, so do stuff!	}	sensor(integer total_number)	{		integer i;		do {			key k = llDetectedKey(i); // for each detected avatar in turn, get the uuid			if (!~llListFindList(detected,[k])){ //if it's not someone I've previously tested				llRegionSayTo(k,(offset+ Key2Number(k)),myName);//generate a channel based on the uuid and say the name of the object -- only that avatar's attachments are going to hear it				detected+=[k];//and add them to the list			}		}		while (++i<total_number);	}}

 

Link to comment
Share on other sites

While isolating channels based on an avatars UUID would make for fewer "junk" messages processed by listen(), you're essentially duplicating the effort by then adding a sensor ... and then complicating it by forcing the wristband to figure channels for each avatar it is near. 

 

Remember that this bracelet wants to glow only while others are around and stop glowing when they're not ... so a sensor() repeated every 30 seconds to find unique channels coupled with then llSay() to each of those unique channels results in A LOT more script work when the other option is to simply llSay() on a channel based on your type of wristband every 30 seconds.

  • Like 1
Link to comment
Share on other sites

I'm probably missing it, but I'm not seeing why there should be all that much traffic on the channel anyway. Yeah, one might get unlucky in channel choice and collide with something else that's chatty, but with four billion odd choices, it's not a risk worth worrying about beyond just checking that the message "looks right." The messages within this app seem pretty sparse (compared to RLV, I guess), with a flat background of only maybe two per wristband per minute. At that rate, even if 30 wristband-wearers were crowded within range, each listen() would fire only once a second.

One tiny complication, however, might be how "near" is "near enough". If it happens that 20m is exactly near enough, then llSay() is perfect all by itself.  (Or 10m and llWhisper, or 100m and llShout.) Otherwise it's not a big deal, just a llVecMag() comparison as long as the comms range exceeds "near".

Even if just being in the same sim qualified as "near" it's a simple adaptation to llRegionSayTo() everybody on llGetAgentList() over wristband_type_channel. If the recipient is wearing a listener on that channel, that listening script gets the messages sent to the wearer, as Innula's script illustrates.

It only gets really sticky if "near" range needs to both exceed 100m and span sim borders, which would entail some intermediating comms relay.

  • Like 1
Link to comment
Share on other sites

I don't know why this efforts are suggested to exchange messages by sensor events.

A message and a listen are not devils stuff, especially not when used in that low frequency. :D

Sending out a "ping" by llRegionSay or llShout/llSay/llWhisper to set a lower range will need one message for all other  wristbands. To minimize answers it's possible to cache the uuid's of received "pings" so there is no need to answer over and over again.


Regarding lag: I made a test:
object "sender" fires out 1000 messages by llRegionSay (takes about 1.5 sec)
object receiver receives and counts them (takes about 50 sec, thats 20 messages per second per script)

The sim cashes around 1500 messages btw. if i send out 2000 at once they are capped at 1500. All that does not cause any noticable script load on the sim.

I don't suggest to fire around with messages though. :D Just wanted to mention that the limits are high.

 

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 3616 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...