Jump to content
Sylvia Wasp

HUD coding w/two sets of buttons

You are about to reply to a thread that has been inactive for 147 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

6 hours ago, Wulfie Reanimator said:

This does not limit the listener to objects owned by the owner. In that line of code you've created a listener that will never hear anything, because it's listening for a specific object name and a specific avatar key. By definition that's impossible to satisfy, you have to leave out the llGetOwner part and check for llGetOwnerKey separately.

 

yes, my bad

  • Like 1

Share this post


Link to post
Share on other sites

Sylvia, is not a biggie to add the extra level of protection against cross-device pollution as Wulfie is recommending

the Key2Chan() function is less secure than is picking a large number ourselves at random.  Why ?  Key2Chan is used by a lot of applier HUDs these days, because the HUD makers read about it on these forums and stuck it in their scripts

. I have a lot of applier HUDs from lots of people using the same Key2Chan() channel, with all kinds of hud names which are not always unique

about a lot of HUDs.  I have an outfit which has 27 different applier HUDs from different creators, to texture change the wearables for the outfit.  I know! but is what I do. The more stuff I can decorate my avatar with at the same time the happier I am

i have neko ears. Which I have to take off when I want to change the textures on a pair of sneakers made by some else that I am also wearing.  When I don't my ears get re-textured. Is annoying to have to take off my ears to do this

as the first lines in the listen object/garment script then remove the opportunity (however remote this might be mathematically) for me, your customer, to get annoyed with you

listen (..., key id, ...)
{
    list own = llGetObjectDetails(id, [OBJECT_OWNER, OBJECT_CREATOR]);
    if (
       (llList2Key(own, 0) != llGetOwner())  // is same owner ?
       && (llList2Key(own, 1) != llGetCreator()) // is Sylvia the creator ?
    ) return;  // is not, so ignore the message
    
   ..
}

 

  • Like 1

Share this post


Link to post
Share on other sites
17 hours ago, Wulfie Reanimator said:

I forgot you're already using RegionSayTo, so the "duplicate channel" issue isn't really a problem after all.

The effort it takes to totally prevent any kind of exploit is literally one line of code that I already included in this thread. If you think it's not worth it, that's your choice. A choice I can't understand, but it's not my product so whatever.

Well, I might add it anyway since you're being so "passively aggressive" about it, lol. :) 

But it's literally adding yet another nesting if-else statement (the very thing I started out to avoid) just to absolutely rule out the minuscule chance that some griefer (who has read this thread BTW) hates me so much they are going to actively try to subvert my code, in order to play havoc with the textures on the 8 or 10 people who actually buy my clothes.  

I mean, I'm a small business and I operate at a loss.  I only make the clothes so as to provide inexpensive, yet quality options for Tonic body users.  

It's more of an Anti-Capitalist action than a business, lol.  

Sylvia, 

Share this post


Link to post
Share on other sites
9 minutes ago, Sylvia Wasp said:

But it's literally adding yet another nesting if-else statement (the very thing I started out to avoid) just to absolutely rule out the minuscule chance that some griefer (who has read this thread BTW) hates me so much they are going to actively try to subvert my code, in order to play havoc with the textures on the 8 or 10 people who actually buy my clothes.  

It's not nesting. It's one line, that's it. Nothing needs to go "inside" of it. There's no Else or Else-If either.

Also the griefing doesn't have to be targeted for you (general you) to be affected, if I did what I explained earlier, I'm almost guaranteed to break products from many creators at the same time. I just like plugging security holes, sue me. 😜

Edited by Wulfie Reanimator

Share this post


Link to post
Share on other sites

adding to the conversation

it isn't greifers so much we worry about, is all the other people who make appliers

the goal is to make our code as efficient as possible. Leaving communications holes in our code, makes our code inefficient

looking at the communications model for your (Sylvia) objects and HUDs so far

key2chan - gives each of our customers the widest possible opportunity  to be on a separate channel

listen for named HUD - as we can uniquely name our products, then no two different products of ours will ever cross talk

llRegionSayTo(llGetOwner().... - our HUD will never send a message to a script owned by another  person

 

adding to this

check for Owner - excludes any message from a scripted object with the same name as our HUD,  on the same Key2Chan channel, owned by someone else

check for Creator - excludes any message from a scripted object with the same name as our HUD, on the same Key2Chan channel, made by some one else, owned by the owner (our customer)

adding these last two checks means that our communications model is 100% efficient

  • Like 1

Share this post


Link to post
Share on other sites
On 2/2/2020 at 11:35 AM, Mollymews said:

adding to the conversation

it isn't greifers so much we worry about, is all the other people who make appliers

the goal is to make our code as efficient as possible. Leaving communications holes in our code, makes our code inefficient

looking at the communications model for your (Sylvia) objects and HUDs so far

key2chan - gives each of our customers the widest possible opportunity  to be on a separate channel

listen for named HUD - as we can uniquely name our products, then no two different products of ours will ever cross talk

llRegionSayTo(llGetOwner().... - our HUD will never send a message to a script owned by another  person

 

adding to this

check for Owner - excludes any message from a scripted object with the same name as our HUD,  on the same Key2Chan channel, owned by someone else

check for Creator - excludes any message from a scripted object with the same name as our HUD, on the same Key2Chan channel, made by some one else, owned by the owner (our customer)

adding these last two checks means that our communications model is 100% efficient

Okay so I added the code because better safe than sorry 🙂 (thanks for the code BTW, awesome, simple and very clear as usual)... but you've only (slightly) convinced me of the necessity of the first check (for owner), and not really convinced me of the need for the second check (for creator) at all.  

Your problem with the ears seems to stem from two things that will never happen with my products, which are: 

- multiple HUDS by different creators for the same product. The only way I could see this happening is with Gacha (and I am opposed to Gacha on moral grounds, lol)

- HUDs that are not uniquely named.  (I would just never, ever do this)

 

It also still seems to me that because I'm using this in the HUDs ...  

llRegionSayTo(llGetOwner(),cmdChannel, (string)index);

... that a HUD can only talk to the owner of the HUD, so if the HUD is owned by someone else, it can't communicate with anyone else.  So it still seems to me that we're talking about griefers.  Someone who's essentially made a hacked (illegal) version of my HUD that can talk to other owners.

The second situation also seems to necessitate someone making a hacked (illegal) version of the HUD and the product, and that someone who normally buys my products has unwittingly instead purchased this shady product (or more likely "found" it in a sandbox).

Both, extreme edge cases IMO, both requiring illegality, and in both cases the intention of the griefer would be to do a lot more damage than just ripping off my few silly products.  More likely there would be some other nefarious code payload that would be the focus. 

Anyway ... adding them anyway!, (and thanks again), but I think we're really dealing with secret agent levels of security here.  

So here is the final, final listen code I got (for anyone following and wanting to reproduce the thing):

    listen(integer channel, string name, key id, string message) 
    {
        list crown = llGetObjectDetails(id, [OBJECT_CREATOR, OBJECT_OWNER]);
            if ((llList2Key(crown, 0) != llGetCreator()) && (llList2Key(crown, 1) != llGetOwner())) return;

        integer index = (integer) message;
        string  texture_key = llList2String(textures, index);
        llSetLinkPrimitiveParamsFast(2,
            [ 
                PRIM_TEXTURE, ALL_SIDES, texture_key, <1.0, 1.0, 1.0>,ZERO_VECTOR, 0.0,
                PRIM_NORMAL, ALL_SIDES, texture_NRM, <2.0, 2.0, 2.0>,ZERO_VECTOR, 0.0,
                PRIM_SPECULAR, ALL_SIDES, texture_SPC, <1.0, 1.0, 1.0>,ZERO_VECTOR, 0.0,<1.0, 1.0, 1.0>, 51,0,

            ]);
    }

I switched creator and owner around so it makes more sense with the variable name. 

thanks for all the help everyone! :) 

Sylvia

Edited by Sylvia Wasp

Share this post


Link to post
Share on other sites
8 hours ago, Sylvia Wasp said:

I think we're really dealing with secret agent levels of security here. 

lets look at this from a different pov. A pov of mathematics that can lead us into a situation that we have no reason to be in

we have a script which listens on a channel, where the possible number of channels is 2 ^ 32 - 1 (not counting the debug channel) = 4,294,967,295

the script listens to a named object. A name which can be length 1 to 63 where there are 94 possible ASCII-7 chars to choose from

length 1 = 94 ^ 1
length 2 = 94 ^ 2
length 3 = 94 ^ 3
...
length 62 = 94 ^ 62
length 63 = 94 ^ 63

add them all up: 2.0497E+124

multiply this by the channels: 2.0497E+124 * 4.29E+09

the result is: 8.80E+133.  A number that is 134 decimal numerals long.  Which is a really big number

and because it is we think that the mathematical probability of our script colliding with another script is so tiny that we are not going to worry about it

not worrying about it, is like betting that we are not going to win the Lotto. A thing about large numbers, is that somebody does eventually win the Lotto. We are gambling that it will never be us

what we should be thinking is that our script is not a lottery ticket. Is a script to change the textures on our object/garment

 

Edited by Mollymews
8.8
  • Like 1

Share this post


Link to post
Share on other sites
19 hours ago, Mollymews said:

lets look at this from a different pov. A pov of mathematics that can lead us into a situation that we have no reason to be in

we have a script which listens on a channel, where the possible number of channels is 2 ^ 32 - 1 (not counting the debug channel) = 4,294,967,295

the script listens to a named object. A name which can be length 1 to 63 where there are 94 possible ASCII-7 chars to choose from

length 1 = 94 ^ 1
length 2 = 94 ^ 2
length 3 = 94 ^ 3
...
length 62 = 94 ^ 62
length 63 = 94 ^ 63

add them all up: 2.0497E+124

multiply this by the channels: 2.0497E+124 * 4.29E+09

the result is: 8.80E+133.  A number that is 134 decimal numerals long.  Which is a really big number

and because it is we think that the mathematical probability of our script colliding with another script is so tiny that we are not going to worry about it

not worrying about it, is like betting that we are not going to win the Lotto. A thing about large numbers, is that somebody does eventually win the Lotto. We are gambling that it will never be us

what we should be thinking is that our script is not a lottery ticket. Is a script to change the textures on our object/garment

 

thanks Molly 🙂

  • Like 1

Share this post


Link to post
Share on other sites
You are about to reply to a thread that has been inactive for 147 days.

Please take a moment to consider if this thread is worth bumping.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...