Jump to content

My HUDs wont apply the textures anymore once they are sold


Studcrusher
 Share

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

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

Recommended Posts

I agree with the general consensus that a replacement for the failing script is very likely to end up being the way forward. Still, one can't help wondering if there might be some tiny hope of finding a workaround that salvages all those items in the wild. We'll only be able to confirm such a workaround or completely rule it out if we can figure out what caused the failure in the first place (unless we somehow won the lottery of trying random things).

Other benefits of knowing the cause of failure is to know its scope -- how many other untold items may be affected -- and knowing how to never script ourselves into a similar trap in future.

ETA: I meant to suggest, if the scripts can't be made available and the original scripter can't be contacted, we do still have the ability to monitor at least any link-messaging that goes on between the setup and server scripts in the HUD, and maybe the listen messaging between HUD and wearable (if that negative number happens to be a channel). We might also snoop any http_response() events, just in case there's any to watch. It's not promising, but it's not yet quite resorting to entropy and prayer.

Edited by Qie Niangao
  • Like 1
Link to comment
Share on other sites

1 hour ago, Rolig Loon said:

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

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

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.

To clarify, for the benefit of anyone who is still feeling confused, 

	touch_start(integer total_number)
	{
		if(llDetectedKey(0)==llGetOwner()){
			//do stuff
		}
	}

will always work, since each time someone touches the object, the script checks to see who the current owner is.

However, 

	touch_start(integer total_number)
	{
		if(llDetectedKey(0)== kOwner){
			//do stuff
		}
	}

is going to cause problems when the object's owner changes, since the value of kOwner will still be the original owner unless the script is set somehow to re-read and store the new value for llGetOwner() in the event of a change of ownership.    

One simple way to do this is

key kOwner;
default
{
	state_entry()
	{
		kOwner = llGetOwner();
	}
	changed(integer change)
	{
		if(change & CHANGED_OWNER){//if the owner of the script changes
			llResetScript();//reset the script, thus causing the state entry event to fire and update the value of kOwner
		}
	}
	touch_start(integer total_number)
	{
		if(llDetectedKey(0)== kOwner){
			//do stuff
		}
	}
}

Sorry to tell people stuff that we most of us already know, but I remember getting completely confused by this when I was a beginning scripter.

  • Thanks 2
Link to comment
Share on other sites

3 hours ago, Fionalein said:

Of course only if the script's TOS allow you to....

Well legally there is nothing LL could do about it. They try to claim they own everything but in reality they can not own code writen  that was made public using LSL. Even if a third party claimed plagiarism it could not be proven because no matter how many write a script to do something they will all be almost identical. LSL is a set of library code blocks  called functions and events. The only reason i make some scripts no mod is because i will not make it easy for another when it took me weeks or months to parasite off of my hard work. There are people making even simple scripts no mod, what is the point other than vanity. A script to open and close a door eg is not is not going be anything different than what hundreds of others have written. The whole point of leaving many scripts mod is in the vain hope someone wants to learn LSL and then create their own projects.

As for this thread script, it is a couple of hours work to write a new script or scripts and be done with it. After all the OP states ' Almost 2 years ago ' so even if the first ones were flaky they must have advanced beyond the level the originals were written to. This is why i suspect that  they never wrote the scripts and have no idea how the scripts function. Also i always scan over my scripts yearly and either see areas that need cleaning up or replaced with new more efficiant functions. Those scripts are at a level that any mods i do is so minor as to be nothing more than being bored. 

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 1944 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

×
×
  • Create New...