Pay in the Pie menu

Hi gang.
I found it simple to add a "Pay" element to a prim so the Pie Menu shows "Pay".
Not so simple to remove it without resetting the script.
Tried changing states, as if!
I ended up looking at this:
llRequestPermissions(llGetOwner(), PERMISSION_CHANGE_PERMISSIONS .....
but can find very little on it's use. Probably barking up the wrong tree anyway.

What should I be looking at to turn "Pay" OFF in the Pie Menu?
Thanks.

That is what you must do. The Pay option shows up as long as a money() event handler is present. Change to a state that has no money() handler.

(This is probably one of the very few situations I would endorse using states)

additionally you can look at llSetClickAction

I know it's heading off the original thread track, Darien, but could you expand a bit on your comment, please? I'm a beginner scripter with a big messy vehicle script I'm trying to refine and simplify, and was seriously considering trying to use states to set up the off/on engine/controls functions. Your passing remark makes me wonder if there's something wrong with using this approach.

A lot of the time, you can as easily get something by checking a simple control flag as with changing states. Using states often tend to force you to duplicate parts of the code.
Also, state changes are fairly expensive, so don't flip quickly back and forth between them.

But if you do have two markedly different "states" the object can be in, functionality-wise (my typical example is an admin setup mode vs "normal" running of the object), states are perfectly valid, and can certainly clear up a lot of clutter.

ETA: I just noticed this thread: /54/d8/329463/1.html which shows code duplication between several states, including an error in not having the needed on_rez event in every state. While the functionality is arguable different enough to conceptually be states, there is enough shared to cause a lot of code duplication, and it did trip up the coder and introduced an error (by not duplicating *enough*).

states MAY become very popular here shortly, partly related to the WHY state changes are expensive. while I can't say for certain, it APPEARS mono only builds the current state, and then rebuilds on state changes...

why is that important? because the upcomming script limitations may very well only count the current state for memory limits, so changing to a smaller coded idle state may reduce the memory profile of that script and allow it to run when other scripts may not because of restrictions....

none of this is for certain, for instance they may count total script size, or some other method, (and it may be in chunks)... unfortunately there really isn't alot of testing that can be done ATM

in my coding I generally only use state changes for 2 reasons.... controlling what input the script will recieve (sometimes you don't want touch or pay handlers or even the icon changes that go with them on mousover) or abusing the fact that it kills certain continous calls (like listens and sensor repeats)... past that states don't really help you any more than a well placed switch variable, and often require a lot of code duplication as Darien pointed out (creating user functions allievates this some)

Thanks for the help there team.

I just thought it was possible to "Gray Out" the Pay menu by revoking debit permissions or something but by the sound of it, I'd have to have everything duplicated in another state. I don't like that idea.

I'll put up with the "Pay" being visible and to revoke debit perms, I gave an option to reset the script. No great loss there, only a temp list and a few customisations. It will have to suffice.

I'll await any news on what void mentioned above and implement then. (If I'm keen enough)
Thanks again

The "Pay" pie menu has nothing to do with the debit permissions.

Pay signals that other users can pay your object, and your script will react to it, i.e. that you have an active money event.

Debit permissions allows the script to access the owner's lindens and give them away to others, using the llGiveMoney function.

Finally, PERMISSION_CHANGE_PERMISSIONS is something 3rd entirely. It doesn't change what permissions the script holds. -Simply request a new permission set for that.
The intention with that one is to allow a script to request permission to change *asset permission*, i.e. the mod/copy/trans permissions (just like a script can, say, request permission to change the link set), but there are no functions to actually do that. The PERMISSION_CHANGE_PERMISSIONS flag is simply reserved for potential future use. (It would likely work in tandem with something much like the God-mode llSetInventoryPermMask).

That's what subroutines are for.

States are a natural way to express a simple real-time program where there's a fairly simple set of external behaviors being modeled by the script. It soon becomes easy to understand where states are an appropriate control structure, and where flags are a better mechanism.

**** me with the Eiffel Tower and NO LUBRICANTS! You're kidding. That makes no sense at all, most of the state (and memory use) of most scripts is in global variables anyway, since local variables aren't preserved between events.

Though *state-local* variables would be nifty.

Nah. Leaving the pay option on would cause confusion. It seems an avatar can still pay the object whether debit permissions are on or not. But without debit perms granted you can't pay back the amount. Or can you?

This is the first time I've toyed with the money event.
Heres how it looks:

run_time_permissions(integer perm)
    {   
       
            if(perm & PERMISSION_DEBIT)
                llSetPayPrice(PAY_DOOR, [PAY_DOOR ]);
     
    }
     money(key id, integer amount)
    {
        if (pay_switch == 1)
        {
            if(amount != PAY_DOOR)
            {   llSay(0,"nope21");
                llGiveMoney(id, amount);
                llInstantMessage(id, "You paid "+(string)amount+", which is the incorrect amount, the price is: "+(string)PAY_DOOR);
            }
            else
            {
                llInstantMessage(id, "You paid the correct amount"); 
                string person = llKey2Name(id);
                llOwnerSay( person +", paid and has now a terrific person.");
            }
            if (pay_switch == 0)
           {
                llGiveMoney(id, amount); //doesnt work. Might even be crashing the alts viewer
            }
        }
    }

...but you still need at least all the event handlers, as per the missed on_rez-event in that thread I referred to.

*nods* It's much a matter of "feel". It usually works if you think of "state" as *the object's* state, as seen from "outside" when the script is running. Would you say that the *object* is in a different state; doing something (and in particularly reacting) visibly different? Then there's a fair chance it would make sense to model it with states in the script.

I don't think I can add much at this point, as you see it's something of a debate. There's nothing inherently *wrong* about using them, but they can over-complicate the code if used unnecessarily. You should probably think of States like a goto statement, don't use unless you really have to. In the end it comes down to style and preference. (Although if what Void says comes to pass, it will certainly turn things on their ear.)

I dunno if it rebuilds all the globals (or even rebuilds user functions, that I still have to test) and can't say for certain, but when mono first hit we all saw the horror that was state changes, and it MAY be because the current state runs on some sort of JIT basis (that was strife's guess) hard to tell, but I'm thinking about different tests to at least get a clue. and yeah, state variables WOULD be nice

Thanks guys.
I understand the explanations...... sort of!
I'll duck out of any debate and go wrestle with my script attempts some more.

The original state slowness problem affected LSO and Mono equally, and the remnamts in Mono still look suspiciously like a scheduler problem (the timing is pretty much the length of a sim frame).