approach for chat channel negotiation (i.e. between objects 0-100m apart)

Hi,

Any comments on best approach for determination of chat channels to use between objects (e.g. in a game), where there are multiple objects (not linked), from 0-100m apart say, assuming the concept was to have a separate chat channel for each object (i.e. cut down on listen event being picked up). The main two I'm toying with:

a) Automated sensing for objects (using the objects name - so a list of agreed object names would be required) and detected the object uuid to obtain the chat channel to use - each object would listen on their uuid (as suggested to me by one of the SL scripters)

b) Pre-allocate various chat channels for each object - I'm thinking if you have to agree on object names for option a) above, you may as well keep it simple and just agree on the chat channels themselves (i.e. avoid having to sense over up to 100m to pick up the uuid's)

Comments? other ideas?



Regards
Greg

I don't know if this is in your projects direction... But use a launcher to prep items, then send them out to the various distances. However @ 100m it's not gonna do you any good. I suggest you use the prep method. IE rez the child, make it llShout it's key to the main 'holder' script and use email. [email]objectuuid@lsl.secondlife.com[/email]

Nexus - I'd love to understand more about what you meant by this?



If you assume my objects will have to be < 100m apart, then is there any advantage of this over my approach (b)? Also if the objects were in shouting distance, why were you suggesting to use email?


Tks

Using email requires that a timer event be coded. Depending on what you are actually trying to do this may or may not reduce lag a bit. If for isntance you want 2 doors to open together, a listen is probably the best way to go if you cannot link the objects because you will want them responding at pretty much the same time.

If if you are trying to setup a server based vendor update system instead (for instance) the object doesn't have to respond immediatly. It could poll say once every 10 minutes to see if any merchandise updates were made available. This would create less lag than a constant listen, and it works across sims. The problem is in the setup, especially across sim boundraies. You generally have to provide the UUID of the object it will be talking to manually. Wether this is via reading a notecard or direct editing of the script is a user choice. Reading it from a notecard is usually better because that way if you give it out to other people they dont need to be able to see or edit your script.

I generate unique comm channel #s based off of the prims UUID for anything I do now, even for just a dialog script. This eliminates the problem that arises when multiple copies of the same object are ressed in close proximity to eachother. If I need more than one channel (say one for the dialog and one to communicate with other prims) I generate my unigue ID for one then add one to it for the other.

In the case where my objects are too far apart to be linked I then 'shout' that ID to the other prims that need to know it on a preset channel. Once recieving that, I turn off the listen on that preset channel and start listening on the newly identified channel.

This method does not sense any other objects UUID, just the UUID of the object the script is in. No use of sensors is required.

Hope this helps, not sure exactly what you are looking to do.

Sounds like a good alternative to my option b. Saves having to type in pre-defined channel IDs in both the client and target objects, but still no need for sensing. I guess any objects which expect to "receive" data from another object would need the knowledge of the objects "names" and keep "listening" until all the objects they were expecting to have interactions with had communicated the detail required on the intial common chat channel.