Jump to content

My HUDs wont apply the textures anymore once they are sold

Studcrusher

By Studcrusher,
in LSL Scripting

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

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

Recommended Posts

Studcrusher

Studcrusher

Posted
Posted

Almost 2 years ago I made some simple HUDs that would apply one of any 8 textures to the Mesh item (a beach towel, or shirt, or pants or whatever) its made for.  I was selling them on world and in MP. They worked great for everybody. Until recently. Now they don't except for me. Once one changes ownership thru a sale or gift to an alt of mine (to test whats going on) they break. All that happens is the mouse cursor changes to a finger over the HUD but that's it.. This also includes the HUDS that were sold before they stopped working, Ive asked customers who bought one and they reported that the HUD worked before but not anymore..

So who did what to break my HUDS?

🤔

Link to comment
Share on other sites
Rolig Loon

Rolig Loon

Posted
Posted

I can't be sure at all without seeing the script, but the usual reason for that behavior is that the script is not written properly to recognize the new owner.  I suspect that you have a security check in the touch_start event that looks something like this: 

touch_start(integer num)
{
    if ( llGetOwner() == llDetectedKey(0) )
    {
        // Do something
    }
}

If you pass the script to a second person but do not reset the script, it will remember that you are the owner and will refuse to let the new person use the device.  The usual way to beat that is to force the script to reset in an on_rez event or in a changed event where you check for CHANGED_OWNER. If you don;t want to reset the script for some reason, you can still get around the problem by defining a global key variable, kOwner, and then giving it a value of 

kOwner = llGetOwner();

in the state_entry event and then using the changed event to update the value when necessary: 

changed (integer change)
{
    if ( change & CHANGED_OWNER )
    {
        kOwner = llGetOwner();
    }
}

Then you just have to remember that the filter in the touch_start event has to look like this: 

touch_start(integer num)
{
    if ( kOwner == llDetectedKey(0) )
    {
        // Do something
    }
}
Link to comment
Share on other sites
Studcrusher

Studcrusher

Posted
  • Author
Posted

Wow very nice but the HUDS were working at one time. I check these things and they functioned perfectly after I set them up and were sold, but NOW those and any newer ones do nto function after transfer of ownership.

Mesh Texture Changer - HUD Setup Script (Place in HUD)
Mesh Texture Changer - Sender Script (Place in HUD)
Mesh Texture Changer - Receiver Script (Place in Mesh Item)
 

The setup entailed me editing a file named MTC - Config Notecard.cfg, also placed in the HUD and it looked like this;

~These Things Will Break the Device If Done:~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~Do Not Remove "*" Symbols
~Do Not Remove "~" Symbols
~Do Not Rename Button 1, Button 2, etc
~Do Not Reset The Script in the Hud After You Finalize
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


~~~~~~~~~~Configuration~~~~~~~~~~~~~~~~~~~~~~~~

~Enter in a Unique, Negative, Number Below.
~You Should Never Reuse this Number in Any Other HUD
~Think of this Number as a Security Key to Your HUD.

~This Number Can be Any Negative Number Between -1 and -5243212~

Unique ID: -555


~Enter in the UUID of Each Texture Next to the Face # That it Should Appear On.
~Do Not Delete Face UUID Lines - Instead Just Leave Them Blank
~All Textures Should be Full Perm That You Enter Here Otherwise
~You Run the Risk of Permission Problems.

*Button 1
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Face 0 UUID: <uuid number went here >
Face 1 UUID:
Face 2 UUID:
Face 3 UUID:
Face 4 UUID:
Face 5 UUID:
Face 6 UUID:
Face 7 UUID:

*Button 2
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Face 0 UUID: <ditto>
Face 1 UUID:
Face 2 UUID:
Face 3 UUID:
Face 4 UUID:
Face 5 UUID:
Face 6 UUID:
Face 7 UUID:

ect.

When done I hit finalize on a menu that pops up every time I saved the cfg file. then a small save in inventory-then-rerez-hud-to-ground procedure happens that sets the perms proper.
Done it many many times.
I'm hoping this rings a bell for somebody out there...

They worked after I sold them, people liked them. Then they stopped working. ALL OF them that been sold. Any HUDS I made recently work for me until I sell them. 

Now I do have more complex and rather confusing texture application systems that work fine. They use a different way of doing things. 

But since a rather sizable amount of HUDs that were sold to people stopped working long after they bought them with out warning tells me somebody changed the rules which in turn broke them.

Phooey..

(Thank You for showing me the script tho..)

Link to comment
Share on other sites
Chic Aeon

Chic Aeon

Posted
Posted
3 minutes ago, Studcrusher said:

Wow very nice but the HUDS were working at one time. I check these things and they functioned perfectly after I set them up and were sold, but NOW those and any newer ones do nto function after transfer of ownership.

Mesh Texture Changer - HUD Setup Script (Place in HUD)
Mesh Texture Changer - Sender Script (Place in HUD)
Mesh Texture Changer - Receiver Script (Place in Mesh Item)
 

The setup entailed me editing a file named MTC - Config Notecard.cfg, also placed in the HUD and it looked like this;

~These Things Will Break the Device If Done:~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~Do Not Remove "*" Symbols
~Do Not Remove "~" Symbols
~Do Not Rename Button 1, Button 2, etc
~Do Not Reset The Script in the Hud After You Finalize
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


~~~~~~~~~~Configuration~~~~~~~~~~~~~~~~~~~~~~~~

~Enter in a Unique, Negative, Number Below.
~You Should Never Reuse this Number in Any Other HUD
~Think of this Number as a Security Key to Your HUD.

~This Number Can be Any Negative Number Between -1 and -5243212~

Unique ID: -555


~Enter in the UUID of Each Texture Next to the Face # That it Should Appear On.
~Do Not Delete Face UUID Lines - Instead Just Leave Them Blank
~All Textures Should be Full Perm That You Enter Here Otherwise
~You Run the Risk of Permission Problems.

*Button 1
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Face 0 UUID: <uuid number went here >
Face 1 UUID:
Face 2 UUID:
Face 3 UUID:
Face 4 UUID:
Face 5 UUID:
Face 6 UUID:
Face 7 UUID:

*Button 2
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Face 0 UUID: <ditto>
Face 1 UUID:
Face 2 UUID:
Face 3 UUID:
Face 4 UUID:
Face 5 UUID:
Face 6 UUID:
Face 7 UUID:

ect.

When done I hit finalize on a menu that pops up every time I saved the cfg file. then a small save in inventory-then-rerez-hud-to-ground procedure happens that sets the perms proper.
Done it many many times.
I'm hoping this rings a bell for somebody out there...

They worked after I sold them, people liked them. Then they stopped working. ALL OF them that been sold. Any HUDS I made recently work for me until I sell them. 

Now I do have more complex and rather confusing texture application systems that work fine. They use a different way of doing things. 

But since a rather sizable amount of HUDs that were sold to people stopped working long after they bought them with out warning tells me somebody changed the rules which in turn broke them.

Phooey..

(Thank You for showing me the script tho..)

Not much of a script person but it was announced more than a year ago (a guess but a long while) that people writing scripts needed to adjust because of the new LAST NAME CHANGE coming in the future.  So just logically it seems like your issue may have something to do with that.  Perhaps someone in the know can comment. The last names are available yet, but it is reasonable to assume that The Lab may be changing the code so that they can text more before that new Premium Perk gets rolled out.

Good luck. I guess I better check my texture change items and see if they still work for others. Don't have many so that's a plus :D.

Link to comment
Share on other sites
Qie Niangao

Qie Niangao

Posted
Posted

You wrote these scripts yourself, or at least have the source code, right? Is there any chance they do some http communications to a server somewhere if they're used by somebody other than you, the creator? (Like for a bogus copy protection scheme or something.)

I'm grasping at straws here for something that actually has changed in LSL in the last year or so.

Just in passing, this part is pretty scary:

2 hours ago, Studcrusher said:

~Do Not Reset The Script in the Hud After You Finalize

but I can't think of a way the scripts would reset themselves now if they didn't before.

If you did not write the scripts yourself, have you contacted the author?

  • Like 2
Link to comment
Share on other sites
steph Arnott

steph Arnott

Posted
Posted (edited)
4 minutes ago, Qie Niangao said:

~Do Not Reset The Script in the Hud After You Finalize

This may be due to a compiled state which does not change and would cause the script to fail if reset. I thought it was only in LSO though.

Edited by steph Arnott
Link to comment
Share on other sites
Qie Niangao

Qie Niangao

Posted
Posted (edited)

Well, regarding the "Do Not Reset" thing, I suspect "Finalize" ships some values to the "Sender Script" from the "HUD Setup Script" that it read from the configuration notecard, and then (just guessing here) the notecard and setup script get removed from the HUD. If that's correct, then resetting the script would wipe the values from the Sender script's state variables. But I don't even know the scripts actually work this way.

Edited by Qie Niangao
Link to comment
Share on other sites
steph Arnott

steph Arnott

Posted
Posted
2 minutes ago, Qie Niangao said:

Well, regarding the "Do Not Reset" thing, I suspect "Finalize" ships some values to the "Sender Script" from the "HUD Setup Script" that it read from the configuration notecard, and then (just guessing here) the notecard and setup script get removed from the HUD. If that's correct, then resetting the script would wipe the values from the Sender script's state variables. But I don't even know the scripts actually work this way.

It is a guessing game. I do not know either. I do suspect that the script was written by another.

Link to comment
Share on other sites
Alyona Su

Alyona Su

Posted
Posted
On 1/9/2019 at 6:12 AM, Studcrusher said:

Almost 2 years ago I made some simple HUDs that would apply one of any 8 textures to the Mesh item (a beach towel, or shirt, or pants or whatever) its made for.  I was selling them on world and in MP. They worked great for everybody. Until recently. Now they don't except for me. Once one changes ownership thru a sale or gift to an alt of mine (to test whats going on) they break. All that happens is the mouse cursor changes to a finger over the HUD but that's it.. This also includes the HUDS that were sold before they stopped working, Ive asked customers who bought one and they reported that the HUD worked before but not anymore..

So who did what to break my HUDS?

🤔

I've read the thread... the BEST ANSWER: Create a new HUD for your stuff, then replace the HUD in the stuff you sell. Allow people who have already purchased to Re-deliver (and on Market Place they can redeliver by visiting Order History.

Use this to rebuild your HUD, it's free (not a demo, but the real deal) and AMAZINGLY AWESOME (I have it and use it and it does everything the "big boys" do:

https://marketplace.secondlife.com/p/Tavatar-ColorTexture-HUD-Kit-Free/4299174

Link to comment
Share on other sites
Arduenn Schwartzman

Arduenn Schwartzman

Posted
Posted (edited)
22 hours ago, Rolig Loon said: 

touch_start(integer num)
{
    if ( llGetOwner() == llDetectedKey(0) )
    {
        // Do something
    }
}

If you pass the script to a second person but do not reset the script, it will remember that you are the owner and will refuse to let the new person use the device.

I found that hard to believe.

First, if you pass on a script, as you say above, and the new owner puts that in a box, the script is always reset.

Second, theoretically, each llGetOwner() call should result in an up-to-date owner key, no matter how it was passed on--either by selling the original to another person (so not a copy), or by giving a copy, even without resetting.

I found this very unlikely to be true, but at the same time, I anticipated that it might be, because each platform has its quirks. So I decided to test it. I tested three scenarios using the following script: 

default{
    touch_start(integer Total){
        if(llDetectedKey(0)==llGetOwner()){
            llSay(0,"You are the owner.");
        }else{
            llSay(0,"You are not the owner.");
        }
    }
}

And with this script I did the following:

1. I gave a box with above script to someone else and let the new owner click it.

2. I set an in-world box for sale such that the original box changed ownership upon purchase and let the new owner click it.

3. I gave the above script directly to someone else for them to put in their own box and let the new owner click it.

In all three cases llGetOwner() came up with the up-to-date key, saying: "You are the owner." 

So, no, if you pass the script on to a second person but do not reset the script, it will not remember that you are the owner (nor should it, because each llGetOwner() call should get a fresh result). Consequently, the new person should be able to use the device.

That's not all. To make things worse, your solution...

22 hours ago, Rolig Loon said:

  


changed (integer change)
{
    if ( change & CHANGED_OWNER )
    {
        kOwner = llGetOwner();
    }
}

 

... actually breaks the original, functional code: the CHANGED_OWNER event is only registered when the original object changes ownership while it is rezzed in-world (e.g., by setting it for sale and set to 'Give Original').

Conversely, the CHANGED_OWNER event is never triggered when you take the object back into your inventory and then give a copy to someone else (or, sell it on MP or a copy in-world through a vendor). This means that in all but one method of object transfer, the kOwner variable actually never changes at all and the new owner will not be able to use it.

Edited by Arduenn Schwartzman
Link to comment
Share on other sites
Rolig Loon

Rolig Loon

Posted
Posted

OK, let's be a little more precise here.

12 minutes ago, Arduenn Schwartzman said:

First, if you pass on a script, as you say above, and the new owner puts that in a box, the script is always reset.

Yes, that's true.  Thank you.  As I look back at what I wrote, I should have been clearer.  What I said was, 

22 hours ago, Rolig Loon said:

If you pass the script to a second person but do not reset the script, ....

What I should have said (and meant to say) was, "If you pass the scripted object to a second person but do not reset the script ..."  That is perfectly true.  It's an error that people make all the time, and accounts for a great number of the cases when people receive a scripted object that still remembers its previous owner.  As you say, correctly, a script that is dropped into a new object will have no trouble.  A scripted object that is simply taken to inventory and handed to another person, however, will not reset on rez unless you have specifically scripted it to do that.

If you follow through the rest of what I wrote earlier, you'll see that the advice about using a changed event to redefine kOwner when a scripted object changes hands is also true. That bit of advice has been around for as long as LSL has. You'll find it in scripts all over SL

Again, I apologize for the confusion I caused by writing "script" where I meant "scripted object," and regret any worry that I may have caused you or the OP.

  • Like 2
Link to comment
Share on other sites
Fionalein

Fionalein

Posted
Posted
7 minutes ago, Love Zhaoying said:

I don’t recall seeing where the OP was actually referring to owner in their script..

Not sure if it must, a good mesh body has saveguards to only listen to appliers of it's owner... or a not so well configured applier HUD could apply to all mesh bodies in chat distance... 

Link to comment
Share on other sites
Love Zhaoying

Love Zhaoying

Posted
Posted
1 minute ago, Fionalein said:

Not sure if it must, a good mesh body has saveguards to only listen to appliers of it's owner... or a not so well configured applier HUD could apply to all mesh bodies in chat distance... 

Doesn’t sound like it was for bodies:

On 1/9/2019 at 9:12 AM, Studcrusher said:

I made some simple HUDs that would apply one of any 8 textures to the Mesh item (a beach towel, or shirt, or pants or whatever) its made for. 

Unless mesh clothing and attachments count.

Link to comment
Share on other sites
Fionalein

Fionalein

Posted
Posted (edited)
4 minutes ago, Love Zhaoying said:

Doesn’t sound like it was for bodies:

Unless mesh clothing and attachments count.

Same principle applies, you do not want Troll McTrollface to be able to change your blankets if he happens to have the same HUD as you do, it is bad enough the HUD could actually change all rezzed instances of the item you own...

Edited by Fionalein
Link to comment
Share on other sites
Love Zhaoying

Love Zhaoying

Posted
Posted
2 minutes ago, Fionalein said:

Same principle applies, you do not want Troll McTrollface to be able to change your blankets if he happens to have the same HUD as you do, it is bad enough the HUD could actually change all rezzed instances of the item you own...

Got it. I’ve only made texture change HUDS that changed my own non-mesh objects, didn’t occur to me that I’d care about owner (except permission to use) since I wasn’t selling it. Duh!

Link to comment
Share on other sites
Fionalein

Fionalein

Posted
Posted
3 minutes ago, Love Zhaoying said:

Got it. I’ve only made texture change HUDS that changed my own non-mesh objects, didn’t occur to me that I’d care about owner (except permission to use) since I wasn’t selling it. Duh!

Still the HUD does not have to care - the listener script has to.

Link to comment
Share on other sites
Love Zhaoying

Love Zhaoying

Posted
Posted
9 minutes ago, Fionalein said:

Still the HUD does not have to care - the listener script has to.

True, true. I screwed up there, but if anyone sent the correctly formatted messages to my objects and screwed up my textures, I’d just reset them with my HUD. Those scripts are due for an update, I just don’t want to repack all the rezzers.

Link to comment
Share on other sites
Innula Zenovka

Innula Zenovka

Posted
Posted

If the OP can post the scripts here, then we can maybe help diagnose and fix the problem.    Otherwise, if that's not possible, then the solution would seem to be  to contact whoever did write the scripts and ask him or her to fix it..

As things stand, it's a complete guessing game, as Steph said, and it's a completely pointless guessing game, too, since no matter how many blind guesses we make, there's no way  the OP can test or implement any of them if the original scripts are no mod.

If the scripts are available, please post them.   Otherwise, either take it up with the original scripter or bite the bullet and send out replacements using the new script that the OP has found that does work.   

  • Like 2
Link to comment
Share on other sites
You are about to reply to a thread that has been inactive for 1943 days.

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

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share
Go to topic listing
×
×
  • Create New...