Communication reliability, timing etc

Just wondering about the feasibility of a project before I get stuck into trying to get it to work...

I'm going to have a long line of largeish objects strung out across a sim that all need to be in one state or another. I want to be able to tell all of them, pretty much at once, to be in state A or in state B. The distances are too great for any link messaging, so it has to be via shouts on some channel, probably with repeaters to cover the distances.

How reliable are llListens? Do messages ever get missed (in my case it would be very bad if one of the objects didn't get the message to change state)? What kind of time does it take a message to get from one end of a sim to another using shouts and repeaters?

Cheers,

SL is coming out with an improved object-to-object communications system.

It shouldn't be too long now.

listens are pretty reliable in my experience, but then, I refuse to use them unless necessary.

Im' not sure how many objects you are planning to usse for this system and what the cahnnel traffic will be, but I hope you use a higher unused cahnnel and that you own your own sim or else your neighbors may be quite unpleased

I may wait and see what communication systems we get then.

It's a large scale transport system for a new island sim, I'm building it for the owner of the sim, and I would of course use some random 5 figure channel for communications.

I'm pretty sure listens are reliable. I've never had a case where it seemed like something wasn't getting the message... the event always fires, and usually immediately. The object-object communication we've been promised for 1.7 is, as far as I understand, the ability to directly send a message to a specific object in the same sim by referencing its key. From the sound of it, you have a lot of objects, and it may be pretty inefficient to message all of them using this method, but maybe you could use it to message the repeaters, and have them shout.

...and given that an object gets a new key on rez, this is likely not to eliminate the need for listens for *most* if not all applications...

...consider objects that are sold.

/esc

actually, none of my object-object communications are done through listens.

I use emails for everything. and that requires registering keys. Most ppl that I know of iwth networked objects use eamils to and from a central server. This onject-to-object cmomunications has been thoroughly tested already and said to look as though it woul dbe at least as fast as llSay. Besides, in this case he wouldn't be taking the item into inventory and rerezzing each time, they would be static objects.

It turns out that I have a way to do what I need with no listens at all (well, no communication at all), at the cost of double the prims. Since the double prims version is technically much simpler, I'm going to go with that and think about refitting after 1.7.

Which is worse for a sim? N prims with listens or 2N prims without?

Thanks for all the advice,

It depends on what the 2N prims are doing.

2N prims with physics is almost certainly worse than N listens on an unusual channel...

That said I think, if my math's is up to scratch n=16 works for listens and shouts for your relay system at least. That's not a huge hit in most sims.

I made a system for kart racing once that uses volumedetect checkpoints and collision events to communicate.

This may be an option for you to consider.

I am thinking your two prims for each spot would be sensed by your vehicle letting it no when to change it's target. if this is the case you can actually use only one prim and have the vehicle's sensor sweep in only one direction and direct it so that the checkpoints will be on that side of the vehicle.

There are ways to get the key of an object back to a main "server" object. For one thing, if an object rezzes another, it can get the key of the rezzed object through the object_rez event. Also, in the case of sold objects, they can "call home" first, registering their key with the server object, allowing it to contact them. Perhaps not ideal, but I can't see a cleaner way of doing it... can you?