Debit Permissions Driving me Batty...

Ok, I've been given a couple of different methods for this, so I'm now totally confused on WHICH person to request debit permissions from.. owner, detectedkey, etc....

Here's the issue, I wrote this script for someone else... THEY need to be the ones to place the teleporters around... be able to change the notecards, etc.

However once I transfer an object with my code in it to them, or they buy the object for $0 from me... the code is busted is "unable to find specified agent to request permissions". However I (being the creator I assume) can place objects around with the script in them all day long and they work without fail for other persons.

here is the pertinent code:

state_entry(){
llRequestPermissions(llGetOwner(),PERMISSION_DEBIT);
desc = llGetNotecardLine("TPInfo",0);
llSitTarget(<0,0,1>,ZERO_ROTATION);
gStartPos = llGetPos();
}

Anything missing? Am I requesting permissions from the wrong person? Is there another way or flow of script I should be using perhaps? The entire script is the Pay2Teleport script I recently posted to share.

Thanks for any help.

-Hap

Yes, you are asking for permissions from the wrong person.

Two key points:
1. A script can only take money from its current owner
2. state_entry is only invoked when the script enters the script. Which is when you explcitly change the state, or when the script is reset (compiling resets).

So what you need to do is capture the owner changing event and either request new PERMISSION_DEBIT there, or just invoke llResetScript.

Ok then, that being the case ... if someone right clicks, and tries to teleport... it is going to detect that as a change of course... however that is also going to effect the flow of things... I will have to try it when I get home I guess. my concern is this...

All of the variable defining (well most of it) is happening in the 'money' routine... comparing whether or not they have paid the right amount, refund or no, etc.

So if I wait to request permissions until the change state, will it even go that far before just dumping out? I fear I've stumblied into yet one last wall and don't want to have to rewrite my entire script yet again.. ugh... I really thought I had it this time.

I will see what I can do tonight.. maybe I can sneak a try at lunch

Thanks,
- Hap

Ok I give... can anyone come in world and help? Or may I post this lengthy script yet again and someone point it out to me? Nothing is working right... I'm back in my original boat, I don't believe it!!


Basically I have two choices.. I can ask for permission from GetOwner or DetectedKey(0)... so .. no matter what I do or where I ask, one or the other is giving me script errors once the teleporter is no longer mine especially.

If I use GetOwner... it's all fine and dandy if I set up the teleporter... anyone can use it.. whether they are a part of a group if it's on group land or not etc. No problems... but as I said... I hand over the object / sell it to someone else... it's all messed up...

Any other ideas? Is it because I created it? Shouldn't it belong to who buys it and work for them?

Thanks in advance, I'm really stumped here.

Make sure you set the script to reset on change of owner. You are requesting debit permission using state entry, the state is retained when you take it back in to inventory and even when you give it to someone else unless you reset the script and do the state entry event again.

So how about I add an on_rez -- resetscript?

That will usually work, but only because you'll probably always just give it to somebody as an inventory transfer, not sell the rez'd original. The suggested alternative, though, is to do the llResetScript() in the changed() handler, specifically when the change is CHANGED_OWNER (as opposed to, say, CHANGED_LINK, which is probably how the script is currently detecting it's got somebody to transport).

Make sure you have an on_rez event in all the states, if you take it in to inventory from testing it and it is not in the default state it will still be in that state when someone else rezes it.