Jump to content

changed owner dilemma


Ruthven Ravenhurst
 Share

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

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

Recommended Posts

 

I'm having trouble using the changed owner event in a script that is intended to die when the event is triggered.

I have a bowl of jelly beans. a use touches the bowl. It rezzes out a bean. communicates to the bean a random flavor and color. user touches to buy a copy of the bean. the user gets a copy in their inventory, the changed owner event is triggered in the still rezzed copy. The still rezzed copy dies, and the bowl of beans waits for another touch to rez a new one

the problem I'm having is, if I send the bowl of beans to someone. and it rezzes out a bean, the changed owner event is automatically triggered

I could set a default state to listen for the flavor/color, changed to a buyable state, and put the change event there. but then how would I prevent it from triggering again when the end user eats (attaches) it?

Link to comment
Share on other sites

It's not really clear to me what the added value of such an approach is. It sounds very complicated for what added value exactly. Why do you not give out simple attachable beans (and skip the whole step with an "interim vendor" that first rezzes and then delets itself). Just give the user the attachable bean directly from the bowl. Then put a script in the bean that choses the random flavor and color and renames it on first attachment. Then you can also get rid of the whole "the bowl communicates something". Or do all these complicated additional steps that you have in mind bring any additional value?

Link to comment
Share on other sites

I had thought about that approach, but while this example would be a small scale use. I also have another project that would need the function to work this way.
I haven't tested it yet, but I have an idea that might work for it.
In the state entry, I would store a global owner key. In the changed event I would check the stored key against the current LlGetOwner. If it is the same, then I'll know it was the above scenario that triggered it,and not the new owner rezzing it. If it is the new owner rezzing it, I would update the stored key, and still allow the changed event to trigger again when the user buys the object

ETA:

Yep. Tried that idea, and it worked as I'd hoped. Now I wonder if the changed owner event triggering the way mentioned above is supposed to happen that way, or just a happy accident?

Link to comment
Share on other sites

Your stored key comparison should work.

Here is another way to do it:

Name one object e.g. "vendor bean" and the other e.g. "attachable bean".

In the "changed" event you check the name of the object. If it is "vendor bean" then delete it. If it is "attachable bean" then don't delete it AND change into another state that does not contain the changed event.

(the state change is a safety measure: Just imagine someon renames the object to "vendor bean", gives it to someone else and then it would delete itself...).

EDIT: My proposed name solution has the security problem that someone might reset the script and then brings it back to the state default... So better stick with your owner key comparison

Link to comment
Share on other sites


Ruthven Willenov wrote:

I had thought about that approach, but while this example would be a small scale use. I also have another project that would need the function to work this way.

I haven't tested it yet, but I have an idea that might work for it.

In the state entry, I would store a global owner key. In the changed event I would check the stored key against the current LlGetOwner. If it is the same, then I'll know it was the above scenario that triggered it,and not the new owner rezzing it. If it is the new owner rezzing it, I would update the stored key, and still allow the changed event to trigger again when the user buys the object

ETA:

Yep. Tried that idea, and it worked as I'd hoped. Now I wonder if the changed owner event triggering the way mentioned above is supposed to happen that way, or just a happy accident?

You can also use llGetCreator in the same way, as in if (llGetCreator() != llGetOwner()) {// something happens here}.

Link to comment
Share on other sites

Sure, but the changed owner event was the only way I could find to detect when someone buys an object (at least for L$0)

I didn't try it with L$1 to see if it would trigger a money event, but as far as I know that changes buy to pay, at least it did when I had the click action set to buy for L$0

 

ETA: Unless you're talking about in the changed event I already established. I want the initial changed event in rez to not make the beam die. But still want it to die on the second time it's triggered, which is why I save and update the owner

Link to comment
Share on other sites

Try this:

on_rez(integer startup){    list temp = llGetObjectDetails(llGetKey(),[OBJECT_REZZER_KEY]);    key WhoseRezzer = llGetOwnerKey(llList2Key(temp,0));    if (llGetCreator() != WhoseRezzer)    {        // This bean was rezzed by the new owner's rezzer    }}

 I haven't tried it myself, but it looks logical.

Link to comment
Share on other sites

I still need the changed event to trigger when someone buys it. it will trigger regardless of what I do in the on_rez event

To get around it I did this:

 

key gOwner:

default

{

state_entry()

{

gOwner = llGetOwner();

}

changed(integer change)

{

if(change & CHANGED_OWNER)

{

if(gOwner != llGetOwner())//it was triggered by the new owner rezzing it(or via their rezzer)

{

gOwner = llGetOwner();

}

else//it was triggered by someone buying it

{

//do something else

}

}

}

}

Link to comment
Share on other sites

I don't see why you need a changed event to do what you are describing.  Unless I am misunderstanding, this will do it:

 

integer gBeanChannel = -38810339;list gAllColors = ["Red",<1,0,0>,"White",<1,1,1>,"Black",<0,0,0>,"Green",<0,1,0>,"Yellow",<1,1,0>];key gAv;integer gRezzedBean;	// TRUE = bean was created by the rezzerdefault{	state_entry()	{		llListen(gBeanChannel,"","","");	}	on_rez(integer startup)	{	    list temp = llGetObjectDetails(llGetKey(),[OBJECT_REZZER_KEY]);	    key WhoseRezzer = llGetOwnerKey(llList2Key(temp,0));	    if (llGetOwner() == WhoseRezzer)	    {	        gRezzedBean = TRUE;// This bean was rezzed by the owner's rezzer	    }	    else	    {	    	state KillTheBean;	//This bean was copied from a rezzed bean	    }	}	touch_start(integer num)	{		gAv = llDetectedKey(0);		llDialog(gAv,"\nWhat color bean do you want?",["Red","White","Black","Green","Yellow"],gBeanChannel);	}	listen(integer channel, string name,key id, string message)	{		integer idx = llListFindList(gAllColors,[message]);		if (~idx)		{			llSetColor(llList2Vector(gAllColors,idx + 1), ALL_SIDES);		}		state KillTheBean;	}}state KillTheBean{	state_entry()	{		if(gRezzedBean)		// This bean was rezzed		{			llRegionSayTo(gAv,0,"You must take a copy of this bean within 30 seconds.");			llSetTimerEvent(30.0);		}		else  	// This bean was copied from a rezzed bean		{			llRemoveInventory(llGetScriptName());		}	}	timer()	{		llDie();	}}

 EDIT:  Ah... small design difference.....  Your design has the color choice mad by the rezzer and sen to the newly rezzed bean, but my script has the potential "buyer" touch the rezzed bean to select a color.  That's a minor difference, though, irrelevant to the "owner change" question.

Link to comment
Share on other sites

The changed event gets triggered in the original copy when someone buys a copy. I'm using that to llDie. I also have a timer start on rez for it to die if someone doesn't buy it within a certain amount of time

 

ETA:

I've already got it figured out with the snippet I posted above

I wish there was a CHANGED_BUY or an object_buy(key id, integer ant)

Link to comment
Share on other sites

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

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

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...