llMessage2Key

I'm a bit tired of the Listener vs. Link Message debates. Since I realize the debate is in many ways an impasse, it might be wise to add a new communication class.

So I propose:

llMessage2Key(key id, integer num, string str, key data);
... to call link_message in another prim that need not be part of a linked set. The first variable of the link_message return will be -1 or LINK_SET.

Pros:
- No further "Listeners" or timers need apply between non-linked prims.
- Rapid message routing, since the key data is provided upfront.

Cons:
- I realize the Lindens have worked hard to prevent "automated systems" that would function across very large, or polysim, regions of their world that function on the processing power of the sims themselves (see: Global Attack). As such, a distance function (similar to llGiveInventory?) for calculating whether a message should be routed to a prim or not would be a good idea.
- Routing limited to a single prim per message

Security issues.

Considering you can encrypt contact commands or set such a thing to only work between two, self-owned prims or scripts, I'm not truly sure that would be an issue.

But, at face value - yeah.

Jeffrey -

There have been proposals in the past to expand Prim / Script support for IM's.

Currently, they can only be sent to Avatars - but perhaps the ability to receive and process such communications would fit with what you're trying to accomplish?

Take care,

--Noel "HB" Wade
(Tread Whiplash)

I do not support this because it uses a string for it's message type and not a list.

I will not support any new messaging protocalls that doen't use lists.
We waist large amounts of CPU time parsing text back and forth between lists & strings; loosing data in the process. And why? There is no good reason.

Strife: Because its all pass-by-value; wouldn't any "list" implementations have even higher overhead than passing a string? I mean, its true you may not have to do as much parsing on either end... But throwing around all the bloated bits that make up a list seems like it could be a big drain on server resources. Or am I missing something? I don't mean to be so negative - I'd love such an implementation; but I do not want a bad or inefficient implementation.

Thanks, take care,

--Noel "HB" Wade
(Tread Whiplash)

You could get around that with a required PIN, similar to the way llRemoteLoadScript and llRemoteLoadScriptPin function.

How many bytes is a float or an integer? 4. how many characters does it take to express a float? 12. So to pass a list currently i first have to convert my floats to strings, which can take as long as a 1/4 second per float. Not to mention convert the entire list to a string.
So already i've already manualy pulled apart the list to custom parse, float, rotations, and vectors. Then there is the issue of the seperator. If my sperator is in one of the strings it will chew the string -> list parsing. The string -> list parser also is custom building a list. Basicly we end up with something on the order of 6 * n * n just for parsing in both directions not even using the data; and we aren't guarentied are data is what we passed it.

A list would be a little more overhead but it would be faster. And really who uses the key for just a key?

And anyway with a list you can still fall back on a string; just make a list with a single string entry. The extra overhead would only be a few bytes. One big advantage of this it will free up memory; no more memory waisted on code for custom parsers.

So:
List = Accurate
List = Less code
Less code = More memory
Less code = Faster Script
Less code = Happy Sim

But really so what if it's pass by value, so is everything else.

The less code i have to write and debug the happier I am

Strife -

I conceed most of your points... I wasn't disputing the speed improvements of not parsing strings anymore; what I was concerned about was the messaging of large chunks of data, considering that lists can be up to 15kb in size...

I guess I just don't know what % of the SL scripting-population actually does complex list->string conversions for their communications... They way I see it, the vast majority of scripts are for making jewelry "sparkle" with particle effects, or texture-anim things, or other simple stuff. *shrug* I worry about people's coding practices and how "bad" it would be (as far as impact on the Sim, I mean) if they used things improperly.

Ah, well. Take care,

--Noel "HB" Wade
(Tread Whiplash)

I see your point about 15KB lists. I'm at this point really only advocating for this for single sim messaging. This would make copying the data easy from one script to another. Just copy the list from one part of memory to another.

Sorry if I came off a little harsh. Someone has to carry the battle flag.

They should simply limit the number of entries in the list passed to the function, if LL really feels like limiting the amount of data we can send via linked message.
==Chris

Chris -

Problem with that, is strings/keys and integers have vastly different memory requirements! I can suck down most of a script's memory simply by putting around 100 object keys into a list. 100 Integers, on the other hand, take up 30% - 60% less space, for the same number of entries...

Strife -

No hard feelin's! I just try to think of all the angles on these sorts of things... Keep the battle-flag held high!

Take care,

--Noel "HB" Wade
(Tread Whiplash)