[#VWR-8834] Pay option is grayed out in pie menu for paying a child prim in a link set.

1. Second Life Viewer - VWR

Pay option is grayed out in pie menu for paying a child prim in a link set.

Created: 29/Aug/08 10:16 AM Updated: 29/Sep/08 05:21 PM

Component/s:

Linden Dollars (L$), Scripting, User Interface

Affects Version/s:

1.21 Release Candidate

Fix Version/s:

None

Time Tracking:

Not Specified

Environment:

« Hide

CPU: Intel Core Series Processor (1595 MHz)
Memory: 1015 MB
OS Version: Microsoft Windows XP Service Pack 3 (Build 2600)
Graphics Card Vendor: Intel
Graphics Card: Intel 945GM
OpenGL Version: 1.4.0 - Build 7.14.10.4926

Issue Links:

Duplicate

This issue duplicates:

~~VWR-8997~~ Pay.. pie-menu option doesn't correctly track presence of money() event

This issue is original of duplicate:

~~VWR-8832~~ Pay dialog missing from pie menu in some sims

~~VWR-8927~~ can only pay the main prim of an object

Relates

This issue Relates to:

~~VWR-8744~~ llSetPayPrice causes "When Left Clicked: Pay Object" to break

~~VWR-8997~~ Pay.. pie-menu option doesn't correctly track presence of money() event

Linden Lab Issue ID:

DEV-19886

Description

« Hide

There is a bug in the 1.21 release candidate client where you can no longer pay a child object in a linkset.

To reproduce this bug you will need to create three or more prims, in one make a script with a money(key id,integer amount) event. Does not matter if it is LSL2 or MONO. Then link the three prims so that the prim with the money script is a child. Now try and pay that child prim. The option for that in the pie menu is greyed out in the 1.21 RC client where as in the 1.20 release client it is not.

I have noticed that if you just use 2 prims and the money script is in the child prim then you are able to pay the whole object so if you pay the parent prim then the money script will not trigger. You should not be able to pay a prim that does not have a money script inside it.

Expected: Pay option is not greyed out and you are able to pay the child prim.

Actual: Pay option is greyed out.

A good example of this problem is in Munkie Island at 128,136,30. We use a rental table system for renting out the plots on that region and the table is a mini model of the region and each plot has a prim on he table that you use to pay your rent. if people use the 1.20 release client they can pay their rent with no problems but if they use the 1.21 RC client then they are not able to pay rent.

This is a pretty nasty bug.

Here is an SLURL to our rental table which you can use to see this bug. http://slurl.com/secondlife/Munkie%20Island/128/131/30

All

Comments

Work Log

Change History

Sort Order:

[ Permlink | « Hide ]

RaithSphere whybrow added a comment - 29/Aug/08 10:25 AM - edited

As the OP Said, this is a nasty bug and also a serious issue for people who use the same kind of system for rentals or more to the point also some Vendors

[ Permlink | « Hide ]

eltee Statosky added a comment - 29/Aug/08 11:54 AM

I can verify its already starting to hit our customers. I've gotten three complaints in the last couple of hours from people who could not use our vendor, showing the pay option greyed out.

-eltee

[ Permlink | « Hide ]

Ramzi Linden added a comment - 29/Aug/08 01:04 PM

Thanks for reporting this! We are investigating.

[ Permlink | « Hide ]

Hypatia Callisto added a comment - 29/Aug/08 07:32 PM

Same thing is affecting the rental meters in Caledon. Older issues from beta I have linked to this issue, and are probably the same bug.

[ Permlink | « Hide ]

Paddy Wright added a comment - 30/Aug/08 04:39 AM

I confirm all the above, I am unable to pay rent with the RC......yay!

[ Permlink | « Hide ]

Thomas Shikami added a comment - 02/Sep/08 03:16 PM

This issue doesn't seem to be only about Pay..., it also effects Touch

simple test script to test in a linkset:
default
{
state_entry()

{ llSetText((string)llGetLinkNumber(), <1.0, 1.0, 1.0>, 1.0); }

on_rez(integer param)

{ llResetScript(); }

changed(integer change)
{
if(change & CHANGED_LINK) { llResetScript(); }
}

touch_start(integer total_number)

{ llSetColor(<0.0, 0.0, 0.0>, ALL_SIDES); llSetTimerEvent(1.0); }

timer()

{ llSetColor(<1.0, 1.0, 1.0>, ALL_SIDES); }

}

put script into a box, then shift drag copy and link together

Normal touching with left mouse button works, the correct box turns black. But when using the right click and choosing Touch from the pie menu, the event is always sent to the first child prim (prim number 2)

For the money event, it's also sent to first child prim only and then propagated to root prim correctly, if no script has a money in the first child prim.

I have seen similar side effects with Sit, too. But cannot reproduce now.

[ Permlink | « Hide ]

Wolfie Waves added a comment - 09/Sep/08 06:57 AM

I have updated the "how to reproduce" part of this issue after more testing. I found that if there are only 2 prims in the linkset with a money script inside the child prim then you will be able to pay the entire object which isn't' good as the money script will only trigger if you pay the prim that the script is in.

If there are 3 or more prims in the linkset and there is a money script inside one if the child prims then the pay option is greyed out no matter what prim you right click on.

[ Permlink | « Hide ]

Bryon Ruxton added a comment - 11/Sep/08 01:33 PM

I just lost a client, in part because of this problem, she wasn't able to pay the rent and then decided to move...

With such money issue the release candidate should not even be released at all, period.
You are damaging your customers businesses by having anyone potentially using it.

For the sake of everybody in the future, could LL please have a pre-determined list of critical tests to be conducted periodically by a couple internal part time testers on LL's payroll before you release the client.

Is that so hard to do? I cannot understand this.

[ Permlink | « Hide ]

Rob Linden added a comment - 29/Sep/08 05:20 PM

Doing my best to untangle the JIRA trail here. It appears as though there's a fix for this one checked in. This exact issue is marked as a duplicate of ~~VWR-8997~~ in our internal tracker, so I'm going to further update the other task since that's where the internal tracking is.