AllowInventoryDrop and SetPayPrice in a child prim

When I set llAllowInventoryDrop(TRUE) in a child prim, I can drop in textures but not notecards (using First Look Viewer on test). Bug or feature?

When I use llSetPayPrice in a child prim, the fast pay buttons are default rather than what was set. Tried resetting script (SetPayPrice was in state entry) but this made no difference. Bug or feature?

Thanks for any information on these, as I searched and could not find anything readily on these issues. It makes a difference on whether I use link messages or listens to communicate. I would prefer link messages, but need to consider whether it is worth the workaround on these issues.

I'm reasonably sure inability to drop notecards in the FirstLook viewer is a bug...the same bug that makes it difficult/impossible to read notecards from an object's inventory in FL.

The second one...I'm GUESSING...is a feature. Here is my HYPOTHESIS (ie, untested idea):
--llSetPayPrice set's the prim default pricing
--When an avatar decides to "Pay" an object...they pay the entire object, and therefore receive the llSetPayPrice settings for the root prim.

That would help me soooo much if the notecard issue is a bug (if they fix it soon).

On paying, if I pay the correct amount by selecting the child prim, the child acts appropropriately (i.e. executes the rest of the script without any other child prims executing their scripts). So it would seem to me that I am able to pay a child prim in a link set. Just get default pay box rather than a single button with correct amount. I'm already double checking amount, so the scripting around that isn't nearly as bad as scripting around the notercard issue.

This was fixed. But now it appears to be broken again.

https://jira.secondlife.com/browse/VWR-3048

IIRC Pay Price is an OBJECT property rather than a PRIM property, like many object properties, setting them from child prims can be flaky, some will set the whole object, some won't set anything, some will do all sorts of wierdness.. I think this is why most wall vendors do a two step dance, touch your item, then click somewhere else to pay...


has conflicting information, near the top is says it's a prim attribute, in the questions at the bottom it says it cannot set the root object....

some combination of the two may be true, where it may be set per prim, but overriden by root, part of the confusion seems to be caused by the fact that the money event IS handled per prim

EDIT: Just read the Jira Article, that should probably be a SVC issue, any way to convert those?

For vendors with more than a couple of options (Buy/More Info) it's practical to have visible buttons which clearly label whats going on. My vendor will have two Buy buttons for example (same price, same product, different objects) along with More Info option.

I know there are a few clunky workarounds. Eg left-click one of the Buy buttons, remember which was clicked, prompt the customer to right-click anywhere to Buy. ...Or, Right-click to Buy, then pop-up a dialog asking which version they want. Both would work but they're clunky non-intuitive work arounds which need extra steps and a small leap of faith by the customer that it'll actually work. Or (which is what I'll probably end up doing) is just to use three objects instead of one.

It's frustrating because this worked up until a couple of days ago and it worked fine with no side-effects. Having the ability to left-click for more Info, and left-click on the same object (different prim) to Pay seems like really basic functionality to me.

I wonder if scripting it to delink the Buy button, set the pay price, relink would work around this bug. As you said, the money event works for child prims, so I think this was all meant to be prim-based by design.