llRegionSayTo, yum

[Void Singer]

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)

[Innula Zenovka]

 

---

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?

 

[Imnotgoing Sideways]

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. =^-^=

 

 

[Rolig Loon]

That is one cool function. :smileyvery-happy:  I've been having fun playing with it for a half hour now. Lovely possibilities.

[Jenni Darkwatch]

Damn that's one useful function! I'll have to mess with it, but it seems like this will make secure inter-prim communication much, MUCH easier. Goodbye HTTP, welcome llRegionSayTo.

Thanks for the heads-up.

[arton Rotaru]

Well, as it is limited to the Region, it's truly not a real alternative for HTTP.

[Void Singer]

 

---

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 !

[Innula Zenovka]

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.

[Void Singer]

---

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

[Dora Gustafson]

Correct me if I'm wrong.
On the receiver side you still need to set up a listen channel with llListen including filters and all?

 

[Jenni Darkwatch]

For many things it actually is. For me anyway. Inter-region, sure, it won't do any good, but for inter-region I use an offworld server anyway.

[Innula Zenovka]

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.

[Rolig Loon]

 

---

Dora Gustafson wrote:

Correct me if I'm wrong.

On the receiver side you still need to set up a listen channel with

llListen

including filters and all?

 

---

Correct, Dora.

 

[Pavcules Superior]

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.

[Dora Gustafson]

Amazing!
We get new functions all the time,
but who fill the cavities we had for years like the missing slice functions for BOX, CYLINDER and PRISM prim types?:smileymad:

[Void Singer]

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

[Qwalyphi Korpov]

The resident who provided the previous content, if any, has replaced it with this generic statement.

[Void Singer]

well bugger, I thought it was going to at least stay in there =/

[Dora Gustafson]

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);

[Nika Talaj]

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

 

[Void Singer]

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

[Innula Zenovka]

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?

[Void Singer]

only a little in the case of a dynamic channel like that, but if you recode to use a static channel (less work to parse) then quite a bit... and with a static channel you can kill them all at once if needed

[Void Singer]

UPDATE:

warning, the pass through to attachments is currently broken when the targeted avatar is sitting SCR-66

wouldn't be a new function without a bug right? =P

[Jenni Darkwatch]

Thanks for the heads-up