Maestro Linden
tracked
Maestro Linden
needs info
Hi Fred Allandale, can you please include basic root & child prim scripts which demonstrate a funky pay price result (i.e. not matching what root prim has set) on an object?
Fred Allandale
Maestro Linden.
- Create a linkset with 2 prims.
- Drop this money script in both prims so you can see what was paid to each prim.
default
{
money(key giver, integer amount)
{
llOwnerSay(llGetObjectName() + " was paid " + (string)amount + " by " + (string)giver);
}
}
- Drop this script in the child prim:
// Drop in child prim
list pay_buttons = [10,20,30,40];
default
{
state_entry()
{
llSetPayPrice(PAY_HIDE,pay_buttons);
llOwnerSay(llGetScriptName() + " set pay buttons to " + llList2CSV(pay_buttons) + " in " + llGetObjectName());
llRemoveInventory(llGetScriptName());
}
}
- Drop this script in root prim:
// Drop in root prim
list pay_buttons = [30,40,50,60];
default
{
state_entry()
{
llSetPayPrice(PAY_HIDE,pay_buttons);
llOwnerSay(llGetScriptName() + " set pay buttons to " + llList2CSV(pay_buttons) + " in " + llGetObjectName());
llRemoveInventory(llGetScriptName());
}
}
- Try to pay the child prim by selecting the 50 or 60 button from the pay window. You will get the "Payment Stopped" message (or no message and no payment) even though those buttons were set from the root prim which, per the wiki, is supposed to set the pay price for all prim.
6 Pay the child prim by selecting the 30 or 40 button from the pay window. The payments will be accepted because they are common the payments set in both prims.
- Workaround: Drop the following script in the child prim to remove the prior pay price setting and allow the pay prices set from the root prim to be accepted when paying the child prim.
// Drop in child prim to clear pay price
default
{
state_entry()
{
llSetPayPrice(0,[PAY_HIDE,PAY_HIDE,PAY_HIDE,PAY_HIDE]);
llRemoveInventory(llGetScriptName());
}
}
If this is the intended behaviour, the wiki description is misleading at best and wrong at worst.
Maestro Linden
Fred Allandale: Thanks, I can reproduce the issue. I agree that this is a bug, especially with the "Payment stopped: the price paid does not match any of the pay buttons set for this object" failure that triggers when trying a legitimate quickpay button.
I think the wiki is not 100% accurate when it says that "Calling it from a child prim has no effect.", as llSetPayPrice _does_ affect the pay price values in the child prim object. Child prim pay prices are supposed to be ignored when paying an object, though they could become active if a given child prim is later on relinked to become a root prim.
Fred Allandale
Maestro Linden Thanks for confirming. Yes, the previous pay price set via a child prim script seems to take precedence over any subsequent pay prices set via the root prim, even though the only available pay buttons are those set via the root prim. What's worse is if you link in a prim as a new child, and that prim has a previously set pay price, it can also stop payment to the child prim from price buttons set via the root prim, unless the prices are coincidentally the same. The workaround script I sent does seem to "clear" the previously set pay price from the child prim.
Pazako Karu
Maestro Linden I had an object with different pay prices per link, and the one you paid was the one that got the money() response. So if you clicked to pay link #25 even though link #1-24 had pay prices, and money events, it would only go thru link #25.
I
might
have the same llSetPayPrice for the whole object, but the money event at least, should be handled by the object paid, if it has one, or handled by root, if it doesnt and root does.Lucia Nightfire
As per the caveats of https://wiki.secondlife.com/wiki/LlSetPayPrice
"This function only works when called from the root prim of an object. Its effect applies to all the prims in the object. Calling it from a child prim has no effect."
The only weirdness is the fallback to default values.