Hiding a channel?

[GinkoStardust]

how can a channel be hidden?

 

object A speaks to object B on channel 505. user can edit object B.

 

is it possible to prevent the user from seeing the channel?

[Rolig Loon]

You don't have to make the script mod.  Make the object mod and leave the script no mod.

[GinkoStardust]

Appreciate the response -  but that is not what I was asking

Can the channel be hidden?

 

[Rolig Loon]

That's how you do it.  If the user can't open your script, he can't see which channels you are using.

If you don't want someone to guess which channels you are using, use a high negative randomly selected number, and change it for each use.

[Sassy Romano]

In addition to what Rolig has said, one slight change, if the user has to provide something on a chat channel, it needs to be a positive number.

If the user is providing input via chat then it makes sense that the channel will be fairly simple and thus a low number.  In this instance, it's trivial to run a script that creates tens of thousands of listeners to pick up low channels and they're readily available.

If that's the case, then it's not the channel that needs to be hidden but the content within the channel.  Look to encrypt the data, then knowledge of the channel itself becomes somewhat useless.

In all cases, the scripts themselves would need to be no mod otherwise it's just a free for all and no, you cannot hide a channel.

[arton Rotaru]

---

Sassy Romano wrote:

In addition to what Rolig has said, one slight change, if the user has to provide something on a chat channel,

it needs to be a positive number

.

---

Not that it matters much.... this restriction has just been lifted with the release of Second Life Viewer 4.1.2.321518.

 

[GinkoStardust]

I apprciate the suggestions. but it is not what i am trying to do. the user MUST be able to edit script B(my original example). appliers do this very thing.

i'm pretty sure i can do it using llSetLinkPrimitiveParamsFast and LINK_THIS. i just have to fugure out how to put it all together.

I have script A in object A, script B in object B, now all i need is script C in object B.  A(no mod) talks to B(no mod), B passes the trigger to C(mod). that way no one can see the channel A and B are using.

 

 

sorry if i didn't word my OP clearly enough.

[Ruthven Ravenhurst]

I think I see what you're saying.

Object A is the mesh that you are applying the textures to.

Object B is the HUD or other object that communicates the textures to Object A

Script A is in Object A to receive the textures

Script B is in Object B to communicate the textures to Script A

You want the channel hidden in both scripts, so you need to pass the textures to Script B from a third Script C which the next user will edit to plug in the textures.

 

You can have Script C send an email to itself, and Script B can receive it to get the textures

After Script C send the email, you can send a link message to Script B to tell it to look for an email, or when saving Script C, the changed inventory event will trigger in Script B, so it knows that way to look for an email as well

[GinkoStardust]

thanks Ruthven. you understand. i looked up your suggestion but found this

"This function causes the script to sleep for 20.0 seconds."

i imagine that might cause the script to appear not work should the user change textures quickly, like using the wrong texture by mistake and then trying to apply the correct one within 20 seconds.

 

 

[Ruthven Ravenhurst]

You could pass it through link messages, but depending on how many textures, it could take just as long. A notecard could work, but if Script B gets reset, and the notecard isn't present, it wouldn't be able to load them.

[Sassy Romano]

Which is the way that appliers tend to work.  They have a notecard which is read by the script, the script will then read in the UUID's and delete the notecard.  Don't reset the script.

If the script does get reset then the customer just rezzes another applier, it's not a problem.

If this really needs to go via link messages or other comms channels, no reason to not pass any or all of them in one call, just delimit them and parse them back out at the receiving end.

[Sassy Romano]

---

GinkoStardust wrote:

I apprciate the suggestions. but it is not what i am trying to do. the user MUST be able to edit script B(my original example). appliers do this very thing.

---

Why can you not just pass the values into the script via a notecard?

[Sassy Romano]

---

arton Rotaru wrote:

---

Sassy Romano wrote:

In addition to what Rolig has said, one slight change, if the user has to provide something on a chat channel,

it needs to be a positive number

.

---

Not that it matters much.... this restriction has just been lifted with the release of

Second Life Viewer 4.1.2.321518

.

 

---

Makes sense since TPV's have offered it for a long long time.

[GinkoStardust]

---

Sassy Romano wrote:

---

GinkoStardust wrote:

I apprciate the suggestions. but it is not what i am trying to do. the user MUST be able to edit script B(my original example). appliers do this very thing.

---

Why can you not just pass the values into the script via a notecard?

---

I guess I could but I don't know how to do that either, I'm at the edge of my abilities. from what i read notecards aren't as secure.

omega doesn't use notecards. it uses code like this

output = "Upper" + ":" + upper_texture;llMessageLinked(LINK_THIS,-1,(string)output,"");"

i was all proud of myself because i manage to cobble together my own applier script using examples from lslwiki.

you add the  UUIDs, drop it in the avatar, then click on it and the textures get applied. so then feeling all proud I thought maybe i could make it more professional by making so instead of the user editing the script and clicking on the avatar, they could edit a script in a prim and click on that(just like a standard omega applier).

i kind of got there, but then i realized the channel would be visible making it vulnerable to being messed with. so i went looking around for a solution, came here and scoured lslwiki, much was over my head but I kind of understand that LINK_THIS is how two scripts in the same prim can talk to each other without needing a script and so it occured to me one could be nomod and pass the info to the mod one. then when i looked at the omega script i found that code and so i thought i must be on the right track.

 

 

[Qie Niangao]

---

I have script A in object A, script B in object B, now all i need is script C in object B.  A(no mod) talks to B(no mod), B passes the trigger to C(mod). that way no one can see the channel A and B are using.

---

Okay, Scripts A & B talk over a secret chat channel, and then B uses link messages to relate the information to script C which the user can modify. Sounds good to me -- what am I missing?

(The object that contains scripts B and C must be modifiable, too, or the user won't be able to modify any script inside it, but that shouldn't be a problem, right?)

[EDIT: Well, I guess in the intended application C sends more information to B than the other way 'round, but either way or both, it's just link messages.]

[And... maybe it's not clear? Scripts within the same object almost always use link messages to communicate (and link messages only work within an object). In contrast, scripts use chat to communicate between objects very near each other or within the same sim.(Communication between scripts in remote sims requires choosing one of several inelegant and inefficent alternatives, which fortunately is outside the scope here.)]

[Innula Zenovka]

If you're worried about people intercepting/spoofing messages because they know the channel number, and the message is being sent from an object belonging to the avatar to an object the avatar is wearing, when there's a reasonably simple solution.

In the sender script, have the sender use llRegionSayTo(owner, common channel, message).   If you use llRegionSayTo, then the message is heard only by the avatar whose uuid is specified and by objects the avatar is wearing or sitting on.  

So llRegionSayTo should prevent the message being intercepted.

In the receiver object, have the listen event filter messages using the test 

if(llGetOwnerKey(id) == llGetOwner()){   //then process the message, because it's either from an object belonging to my owner or from my owner direct.}else {  //ignore it, since it's from an object belonging to someone else.}

That way people can't spoof messages.

I'm still a bit confused about why you want to let the user mod the scripts at all -- sounds to me like a customer service nightmare, as people try to edit them and then break stuff  and ask you to fix it.    No one else who makes devices to apply textures to mesh bodies seems to find the need to distribute full-perms scripts, after all.

I'm with Sassy on this -- have the script read the data from a notecard.  That's the usual way to allow the user to give the script persistent data without actually editing the script.

If you need help with having scripts read notecards, then you need only ask here -- this forum exists so we can help each other with scripting projects, at whatever level.   Having scripts configure scripts from  notecards looks complicated until someone shows you how to do it, i know, but it's really not that difficult, and plenty of people here will be glad to help. 

[Codex Alpha]

He he, at one time there was a free titler going around in Second Life, that had it's channel name exposed.

Must I say I had great fun changing the titles of friends who wore it, they couldn't figure out that it could be accessed by anyone nearby in chat

[Streak Wildung]

Well there's a couple of different ways to do this.  As many have said, use the llMessageLinked() to pass the date to script C.  If you realy want to be secure you can use a Key2Chan function like I have here...

 

integer Key2Chan(key ID) {    return -0x80000000 | (integer)("0x"+(string)ID);}

 

using the owners UUID to create a private channel.  As long as the user doens't know your logic behind teh Key2Chan function they won't likely deciper your channel.  Then you if  you REALLY want t get secure, even if the channel is some how hacked.  Encrypt your data going between scripts.  I always encapsulate my data in something similar to a digital signature, so the script knows it's mine.

So in the end, even if your channel is figured out...the person attempting to spoof something on your channel will have to know your encryption key...AND your digital signature before anything can happen...and there's way to even further secure it fi you're really super concerned.

Keep in mind the Key2Chan will only work if the same person owns both object A and B.

[Sassy Romano]

---

Streak Wildung wrote:

So in the end, even if your channel is figured out...the person attempting to spoof something on your channel will have to know your encryption key...AND your digital signature before anything can happen...and there's way to even further secure it fi you're really super concerned.

 

---

Yes, except that in this case it's texture UUID's which are the data and are very kindly yielded trivially by finding stuff in the texture cache so all this effort inworld is completely defeated by the viewer.

[Streak Wildung]

LoL  This is true, no getting around stealing that texture if someone REALLY wants it that baddly!

[GinkoStardust]

thanks everyone for the replies and suggestions, i didn't expect so many:)

ok Innula you've convinced me going with a notecard like Sassy suggests is the more practical way to go for what i want to do.

so basically I have to start again, if you or anyone else have some links or suggestions how i can get started with that please post them. in the mean time i'm going to look around myself to see what info i can find to get started.

 

 

[Innula Zenovka]

This might be a good start.   It's very basic, but should show you the essentials:  http://wiki.secondlife.com/wiki/Read_Note_Card_Configuration

 

ETA:   I take issue, though, with one aspect of the example.    Instead of 

if(data != "")

I would use the test

if(llStringTrim(data,STRING_TRIM) != "")

 That's to strip out lines that contain only non-printing characters, such as line-breaks, as well as ones that contain no visible text.