Unique Channel Maker?

Hey All.

i have an idea for a Unique Channel Maker (best i could come up with).
i just want to know if it's possible first before i even try.

Use the first 5 characters of the OWNER Key on an item and convert it to ASCII code to get the numbers.

Example
Tabris = 84 97 98 114 105 115
first 5 of my key = 57 55 99 51 51

is it possible to do that in LSL (text -> ASCII DEC) or (text -> HEX)

Using a random chat channel works just as well in most cases.
http://wiki.secondlife.com/wiki/LlDialog#Tips

possible, yes, but there are no character code to to value type functions so you'd have to roll your own... the portion of av key to hex is an easier and more reliable method though (but commonly used, so maybe subject to collisions if not fully filtered)

if you still want to go with this method I suggest masking the first name against the last though... much more unique

While on the subject of channels. I've seen recommendations for both "... a large negative integer..." AND "... a small negative integer..." as being the least laggy.

So which is it, or does it really not matter?


My take on channel management would be for the region to handle channel allocation. I know, like the regions don't have enough to do already.

Perhaps...
A script could request a channel using a user defined key.
The first time a request is made using a specific key the region allocates a free channel and adds it to the channel table.
Subsequent requests using the same channel would simply return the allocated channel.

The region could do periodic sweeps and remove key-channel allocations if not used within a specific time period.

This would avoid the situation where residents rez the same product and fail to change the default channel.

It would also remove the need for user channel management which can be a real pain to keep track of for multiple devices.

Rime

Both of those are examples of poor design by the scripter.

I would suggest instead using a hashed combination of the owner's key and a product ID or something. Scripts you want to talk together can use the same product ID. For example:

// Returns a channel that is "private" to this product and owner.
// channelID - A string identifying the use of the channel.  Different scripts
//             using the channel for communicating a particular kind of
//             information should use the same value (e.g. "myVendor/choice"
//             could be used to communicate the choice of an item for sale,
//             and "myVendor/dialog" could be used as a separate channel for
//             dialogs from the same product).
integer getUserProductChannel(string channelID)
{
    string hashInput = llList2CSV([ llGetOwner(), channelID ]);
    string hash = llSHA1String(hashInput);
    integer channel = (integer)("0x"+llGetSubString(hash, 0, 7));

    return channel;
}

TY all,
i have most of the script done now from merging some together,

the only thing I'm stuck on is Hashing the name and the key.
is it as simple as

Hash(String_var_here);

or something different.

also @ Hewee Zetkin
that won't work for my application as I'm communicating between two attachments on the same avatar.

Sure it will. Use the same argument in each attachment. You'll get the same channel. Then if you wanted to do the same thing between two DIFFERENT attachments, or a different attachment and an in-world object, or whatever, use a different argument for the new system.

TY all.
This is the code. it could probably be tidied up a bit in places.

// www.lsleditor.org  by Alphons van der Heijden (SL: Alphons Jano)
integer dialog_channel1; // top of script in variables
integer dialog_channel2;
integer dialog_channel3; 
key Key_ID;
string name;
//key id;
default
{
	
	integer channel() { // top of script in functions
		//Gets Owner Key as integer
		return (integer)("0x"+llGetSubString((string)llGetOwnerKey(Key_ID),-16,-1)) ; 
		
	}
	integer channel2() { // top of script in functions
		//Gets HASH of Owner Key and Owner Name as integer
		return (integer)("0x"+llGetSubString((string)llSHA1String ( Key_ID + name),-16,-1)) ; 
		
}


	state_entry()
	{
	Key_ID = llGetOwnerKey(Key_ID);  //Owner Key Nuff said
	name = llKey2Name(Key_ID);		//Owner Key to Name Nuff said	
	dialog_channel1 = channel();
	//llSHA1String( Key_ID + name);
	dialog_channel2 = channel2();
	// adds the integer outputs of the channel Numbers and Multiplies by -1. in most cases gets a negative value.
	dialog_channel3 = (dialog_channel2 * dialog_channel1) * -1; 
// Here Down is Self explanatory.
	llSay(0, "Hello, " + name);
	}
	touch_start(integer total_number)
	{
		llSay(0,name + " Touched: "+(string)dialog_channel1);
		llSay(0,name + " Touched: "+(string)dialog_channel2);
		llSay(0,name + " This is Final Channel "+(string)dialog_channel3);
	}
}

 

Lets all do a Happy Dance

(^'-')^ (^'-')> (>'-')> <'-'^) ^('-'^) (^'-')^ (^'-')> (>'-')> <'-'^) ^('-'^)

Not helpful at all.

Why thank you Luke! Feel free to pop in and give examples or help in any way.

That was not meant as an example, just an assessment. If you setup your product so that the customer has to go in and edit the channels, then you have set it up wrong.

See, back to my reasoning for making this a server task.

A smidgen of additional back end processing would obviate the need for convoluted scripts to create and test for unique channel numbers. It would also see an end to erroneous use of duplicate channels.

How much of the example solution above (and its processing requirement) could be saved by a simple MyChannel = llRequestChannel() ?

But what do I know?

ps - I'm still waiting for views on the 'small negative' vs 'large negative' is best question.

Cheers
Rime

Why would you need it?

Design your communications protocol to not be dependent on needing different channels.

If it is just two objects, checking to see if it is the same owner should suffice. If you're worried about security, authenticate the messages. If it is more than two objects, use an identifier.

I use random channels in some cases, like for dialogs, but really, even then, it is rarely a necessity.

Hmmm - maybe my ignorance is leading me down the wrong path.

Do all objects that use the same channel, irrespective of owner, see all the traffic on that channel?

In other words, if I rez objects 'A' and 'B' that work together and use a default channel and my neighbour does the same thing does confusion reign or are both sets of communication kept discrete in some way?

I should probably go read the relevant documentation...

Rime

Perhaps you should create a JIRA for this.

I would tend to go for a broad range that encompasses large, medium and small. Having said that, I now realise that the terms I use are potentially ambiguous; when compared in an "if" statement, -1 is the largest negative integer and −2,147,483,648 the smallest, while in conversational use I suspect many people would reverse the meanings.

Only if the listen criteria match.



I think the bigger question is whether you want to keep the information private. It is easy enough to separate the response, based on the owner of the objects.

In other words, if I have a light that I turn on with a separate switch object, and my neighbor has the same light/switch combo, and they are in chat range of one another, it is easy to keep the responses separate to the appropriate owner/switch using this in the listen() event:

listen(integer channel, string name, key id, string message) {
if (llGetOwnerKey(id) == llGetOwner()) {
//toggle state
}
}

If more specificity is needed, the message can include identifiers. i.e., if I have a "red" light switch and a "green" light switch, turning on/off different lights, then the message may be "red on" or "green off" instead of simply "on" or "off".

If you want the messages to be private, or at least make it so that they can't be easily be intercepted, then a random channel approach will work pretty well. If you want to make sure that the messages only come from authentic sources, then you will have to use some kind of authentication to effect it.

Now, some might say it is "inefficient" to code the script such that the same channel is used across a number of different, unrelated, or multiple-owner objects, because the methods above will mean that script events will be queued for all messages "heard" by the objects, even if the messages aren't meant for them. In the majority of cases, this isn't really that much of an issue, and scripting around it is being a bit anal retentive. You will have to decide whether it is necessary depending on how often you would expect objects on the same channel would be within the chat range of each other. If you would expect lots of objects to be chatting constantly on the same channel, then it may be prudent to take the additional step. If there are few of the objects present/in-range, and/or the frequency of messages is low, it may be excessive and unnecessary.

A lot of the script is Debug feedback so i can see what it's doing.

basically everything after the last comment "// Here Down is Self explanatory." will be removed in the final script when it's merged into my others.

as for communicating within the same object i use link message and filter it.

mostly this script is a "Proof of Concept".

the only problem i can see with it is if the User has "Attachment A, B, C" but HUD1 only needs to talk to A & B as the owner Key & Owner Name are the same, Which means that the channel will be the same for all.

chanA = (integer)("0x"+llGetSubString((string)llGetOwnerKey(Key_ID),-16,-1));
chanB = channel1 + 1;
OR:
chanB = (integer)("0x"+llGetSubString((string)llGetOwnerKey(Key_ID),-16,-1)) + 1;
chanC = channel1 + 2;
OR:
chanC = (integer)("0x"+llGetSubString((string)llGetOwnerKey(Key_ID),-16,-1)) + 2;

Communications to/from attachment A on chanA.
Communications to/from attachment B on chanB.
Communications to/from attachment C on chanC.

etc, etc, etc.

Helpful

Go screw yourself Luke. I've been helping here a heck of a lot longer then you have even thought about it.

You two get a room.

(and, no, not OUR room, Jesse)

Using llWhisper/llSay/llShout/llRegionSay all objects within range CAN receive all traffic on the given channel. Each message is checked server-side for every applicable 'listen'. If the listen filter passes the message then a listen event is fired.

In other words, if your neighbour is going to be using stuff on the same channel your objects will hear them and you'd better hope their's an owner-check within the listen handler.

At www.vladwerkz.wikidot.com you can find a function for creating a repeatable key-based dynamic channel...pretty much what you are talking about here.
The example there uses the hour of the day in the channel building equation, so it does change hourly (just happened to be what I was using at the time and I prefer something that changes regularly), but simple modifications can remove date/time entirely and/or other types of data that are able to be detected by both the speaker and the listener can be inserted.
I'm sure someone could think of some ways to make it a bit better, but folks are free to use it if it helps them.