Jump to content

llRegionSayTo, yum


Void Singer
 Share

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

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

Recommended Posts

originally I was happy, but not thrilled about this function comming to the grid... the original spec I read was kinda limited....

oh but it looks like somewhere along the line it got a great boost....

now, you can target, not only a single avatar or object, but also when targeting an avatar on a non-zero channel, it targets all the attachments on that av...

and the channel is PRIVATE... no more pollution of the region channels... I am seriously loving this function a whole bunch more now.

PS
just in case you didn't realize, this function is live on the grid as of todays server rollout for the main channel (if it's not already on leTigre or BlueSteel, it should be in 1-2 days time)

Link to comment
Share on other sites

 


Void Singer wrote:

now, you can target, not only a single avatar or object, but also when targeting an avatar on a non-zero channel, it targets all the attachments on that av...

and the channel is PRIVATE... no more pollution of the region channels... I am seriously loving this function a whole bunch more now.

Void.. does this mean that llRegionSayTo(avatar's uuid,-1812221819, "some message"); is going to be picked up by that avatar's rlv relay without adding to the congestion on the rlv relay channel?

 

Link to comment
Share on other sites

Correct me if I'm wrong, but, non-0 channels don't get sent to the client, so, RLV has nothing to pull from.  But, now, avatars can get a "To" message to all attachments without the server delivering the message to anything else. (^_^)

This is bloody GOLDEN!  While relays will still be necessary... The API can be re-defined to be far less laggy.  Far far far less laggy. =^-^=

 

 

Link to comment
Share on other sites

 


Innula Zenovka wrote:

Void.. does this mean that llRegionSayTo(avatar's uuid,-1812221819, "some message"); is going to be picked up by that avatar's rlv relay without adding to the congestion on the rlv relay channel?

 

that message will hit all attachments on the specified channel, without a peep on the public side... it can't replace the ownersay portion of the RLV protocol, but the stuff that happen off of the PUBLIC and DEBUG channels? you betcha. all with no need to find out the attachments UUID.

 

and the first thing it's needs to be applied to is making update scripts that don't have to rely on e-mail or http... oh frabjuous day !

Link to comment
Share on other sites

The point for RLV isn't so much that avatars can't listen on negative channels, though you are right to say they can't, but that RLV only listens to commands in the form llOwnerSay("@something-or-other") so you need an object you own, a relay, to pick up requests from objects that don't belong to you, parse them, and pass them on to your viewer in the form of llOwnerSay.

The great thing about this is that now, while there will still have to be a lot of open listeners on the rlv relay channel, you can now apparently direct your commands to your victim's relay without all the other relays in earshot having to pick them up, parse them, determine that they're not meant for them, and silently discard them.    This, I know from doing product demos on RP sims, is a major issue when there's a lot of relays about.   It can easily take 20 or 30 seconds for something to happen that is almost instantaneous on my building platform.

I've got to test it properly, of course, but I've just gone in quickly, and

 

integer rlvrc = -1812221819;integer handle;integer my_channel;default{	state_entry()	{		my_channel = (integer)llFrand(1000000.0)+1000; // has to be positive since the avatar's replying	}	touch_start(integer total_number)	{		llListenRemove(handle);		key av = llDetectedKey(0);		handle = llListen(my_channel,"",av,"");		llSetTimerEvent(20.0);		llRegionSayTo(av,rlvrc,"checking,"+(string)av+",@version="(string)my_channel);	}	listen(integer channel, string name, key id, string message)	{		llListenRemove(handle);		llOwnerSay(message);	}	timer()	{		llListenRemove(handle);		llSetTimerEvent(0.0);	}		}

 

 

 

certainly works.   This should mean I can make my toys work far better simply by changing all the instances of  llSay(rlvrc,"some command") into llRegionSayTo((key)victim,rlvrc, "some command").

This, presumably, has  very positive implications for the performance of many combat systems, too, at least those where your hud and that of your opponent talk to each other.

Link to comment
Share on other sites


Innula Zenovka wrote:

This, presumably, has  very positive implications for the performance of many combat systems, too, at least those where your hud and that of your opponent talk to each other.

not spectacular in most cases, but some at least.... most combat systems already use highly unique to the avatar channels, this will let them clean up the public chatter, which should stop any random communication collisions (right channel, wrong object) (and I've already got one client wanting updates for exactly that reason)

Although it's put me in a mind to revise my old idea for a dog simple combat system, since I no longer have to care about  channel collision, I could simplify processing even more.... of course that'll require me to get interested in combat enough to keep my attention.... ok, maybe not

Link to comment
Share on other sites

I see.   But it certainly seems to be the case that if I use llRegionSayTo(uuid, rlvrc, message); the message is only received by the rlv relay worn by uuid, and that the other relays in range don't have to parse the message, only to discard it when they find it's not for them, even though they're listening on rlvrc.   I've just tested that.

I wonder if there's any way to tell relays to reply using a specified channel other than the main rlv one.   I know you can use @notify to make them use another channel in addition to the rlvrc, but there doesn't seem any way to turn the rlvrc replies off, which presumably spams other people's relays, too.

Still, it's very good news this can cut down traffic by half.

Link to comment
Share on other sites

Just to say, becareful on using the new function in making things.   It is possible that the Server Update with fhis function can be rolled back.

Although gaining this new function, we have now lost the 3 new LSL functions I mentioned the other week.  Not sure when they will return.

Link to comment
Share on other sites

they're still in leTigre, so they'll probably be back in a week or two... the rollbacks were because of bugs in the rez code it would seem.

@Dora: I feel it too, but it's a matter of what's going to break when something is changed... changing prim params has high potential to break stuff, and there's only limited space for additions... new functions generally don't break existing content so they're safe =/ I don't like it either but it's where we are until other options (versioning, C#) come along

Link to comment
Share on other sites

I have followed the Jira SCR-15 and I see it is almost impossible to add slice parameters to the existing list structure in the llSetPrimitiveParams function family without breaking it.
I wouldn't mind new functions though.
Since new functions don't break easily that would be worth considering
May I suggest:

vector llGetLinkSlice( integer linknumber);

llSetLinkSliceFast( integer linknumber, vector slice);

Link to comment
Share on other sites

I could also see this being really handy in making a sim more atmospheric very efficiently ... for example:

> a line of plants where a user can choose simwide seasonal or nite/day transitions using a single controller command for the entire landscape

> a halloween sim where all the lighting changes on command, all the doors snap shut, all the windows blow out

> more coordinated and efficient 'weather' ... e.g. a rainstorm causes the prim waves to kick up

> lower overhead parcel management systems for land barons ... HTTP to a single controller per sim, which acts as a a llRegionSayTo proxy

 

Link to comment
Share on other sites

some of those, but not many if you want them easy to set up (broadcast is still good for some things)

for instance, region lighting? probably not very useful unless you want to grab the keys for each component. (I did one of these for elven forest theme, where ALL the flowers glow at region night, with an override controler,,, turned out nice), but things like holo vendors that tell their objects to die (grab the key on rez)? or that recent game table that the creator was worried about spamming nearby tables (grab player id on sit)? awesome

and that region controller via http? already in the works =D (I'm already monitoring region FPS and agent count that way .

 

also finding it as a useful replacement to llInstantMessage, since there's no delay, so faster spamless vendor notifications, or control interaction messages that don't need to be sent out of region. fast spamless greeters. llOwnerSay replacement for group deeded objects.... I am having way too much fun with this function

Link to comment
Share on other sites

Void, my holovendors calculate a channel based on their uuid, and pass this to the rezzed objects as the start parameter, and the rezzed object listens for its uuid (as a string) to know when to llDie().

In practical terms is there a great advantage to using llRegionSayTo, given that possiblility of there being another listener on the sim using that channel, let alone filtering for a message comprising the uuid of the rezzed object, is utterly remote?

Link to comment
Share on other sites

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

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

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...