Read Objects's Description In Contents Inventory

[EnCore Mayne]

i have an idea that i'm not sure can be implemented. of course, with my limited personal skillset it is indeed impossible, so i ask our resident genii for their input towards the solution or an acceptable compromise.

i would like to have a pose stand that can accept the Owner's addition of any amount of animations they feel inclined to add to the contents of the multiprimset stand. [subquery: is there a maximum limit for the amount that can be added to any object's Contents?] the script would recognize all available animations so as to cycle (back and forth) through the entire total by clicking buttons from a Dialog and animating the avatar using the stand. right clicking Pay delivers the currently displayed pose/animation.

so far i've been able to do all that, but i'd also like to have EACH pose/animation's price set individually. as it is now the script uses a manually set variable so all animations are the same price. i was hoping, for the simplest Owner's use case the script could read the description field of the animation from the within primset's Contents. seems far easier than adding a user created notecard.

so...can this be done? or, if not, what would be the easiest method (least amount of user effort) for associating the animation to an individually variable set price?

[Wulfie Reanimator]

Interestingly, yes, it is possible. (I didn't expect it but I figured it should be possible.)

http://wiki.secondlife.com/wiki/LlRequestInventoryData

Edited December 20, 2018 by Wulfie Reanimator

[Qie Niangao]

But @Wulfie Reanimator, isn't that only for landmarks? (If it works for other things, too, I'd be very pleased.)

[Fenix Eldritch]

Yeah, I think Qie is correct. I just tried a handful of inventory types and so far the function only outputs anything for landmarks.

default
{
    state_entry()
    {
        llRequestInventoryData(llGetInventoryName(INVENTORY_ANIMATION,0));
    }
    
    dataserver( key vKeyNull, string vStrData )
    {
        llOwnerSay(vStrData);	//only seems to speak for landmarks
    }
}

 

[Wulfie Reanimator]

20 minutes ago, Qie Niangao said:

But @Wulfie Reanimator, isn't that only for landmarks? (If it works for other things, too, I'd be very pleased.)

Oh... You might be tight, I'm posting from mobile and didn't see the type table. In that case I'd fall back to the old and boring notecard reader with name/price matching. 

Also can somebody write a JIRA for a suggestion to expand the inventory request function? It should at LEAST be able to get the description and creator of the item. 

Edited December 20, 2018 by Wulfie Reanimator

[Rolig Loon]

Internally, maintain either a strided list with pairs of animation names and prices or a pair of lists -- one with names and the other with prices.  With a person selects an animation by name, match it to its price in the list(s) and adjust the llSetPayPrice accordingly. If you are managing the device yourself, you can always monkey with the script directly or update a notecard to read in names and prices of new animations.  If you're creating this thing for someone else to use, you can use the notecard approach or gather user input through dialogs and text boxes.  The challenge is keeping any updates in non-volatile storage so that they don't get wiped out when someone resets the script or it jams up.  There are strategies for solving that problem, including off-line servers or KVP, but they take a bit of work if you are not familiar with them.

[Fenix Eldritch]

Another thought is that you could possibly put the price right into the animation name, since you can easily retrieve that from an object's inventory. At lest that way, you could conceivably bundle the price with the animation and avoid needing to maintain a price lookup list in memory or notecard.

But that has a host of problems too. You would need to establish a naming convention and adhere to it very strictly. You'd probably also want to add logic to the name parsing code for cases when an animation gets incorrectly named and fails to follow the convention.

Edit: Also, in regards to your subquery, there doesn't appear to be a hard limit on how many inventory items an object can have - though more will affect loading times when opening said prims. And there is a warning that a limit may eventually be enforced, but I see no additional information about that. See the wiki's Limits page.

Edited December 20, 2018 by Fenix Eldritch

[Rolig Loon]

2 minutes ago, Fenix Eldritch said:

Another thought is that you could possibly put the price right into the animation name

Oh, that opens a whole class of creative solutions that are only superficially about scripting. 

• Names that have one asterisk after them are L$50 each; two asterisks, L$100; three asterisks, L$150 ...
• Names that begin with A - L are L$100 each; those with M _ Z are L$200
• Names with COPY/TRANSFER perms are $L200; those with TRANSFER only are L$175; those with COPY only are L$150
• .....

Presorting your inventory items reduces the amount of list-making and lookup activity you have to build into a script. As Fenix says, you just need to make it clear how the user is supposed to presort things and then include some failsafe coding to dummy proof the vendor against the inevitable user who can't read instructions.

[steph Arnott]

Larger the contents count the higher object  lag

Edited December 23, 2018 by steph Arnott

[Lucia Nightfire]

On 12/20/2018 at 10:47 AM, Wulfie Reanimator said:

Oh... You might be tight, I'm posting from mobile and didn't see the type table. In that case I'd fall back to the old and boring notecard reader with name/price matching. 

Also can somebody write a JIRA for a suggestion to expand the inventory request function? It should at LEAST be able to get the description and creator of the item.  

A request to get an inventory item's description was requested here. Probably needs to be requested again.

llGetInventoryCreator() can get an inventory item's creator.

[steph Arnott]

On 12/20/2018 at 4:47 PM, Wulfie Reanimator said:

Also can somebody write a JIRA for a suggestion to expand the inventory request function? It should at LEAST be able to get the description and creator of the item. 

What is the point? LL does not do anything in regards to what you want. LL are using SL as a cash cow and nothing more. They will add a few features here and there but that is all.

[Fenix Eldritch]

On 12/20/2018 at 11:47 AM, Wulfie Reanimator said:

Also can somebody write a JIRA for a suggestion to expand the inventory request function? It should at LEAST be able to get the description and creator of the item.

The thing about llReuestInventoryData() is that the "data" probably has to be something other than name, description, creator, etc. I'm guessing the original intent was to pull information about the actual asset that a script could use (like the landmark coordinates) rather than metadata about the inventory item wrapper. And considering we can only specify the target item's name, we have no way to tailor what is requested outside of differences between inventory item types. This becomes an issue if we try to enhance it to return names and descriptions because landmarks already return a coordinate vector (in a string) - yet they also have a description. We can't change the existing functionality and thus have a conflict.

So I think the best route is as Lucia suggests, with an additional function to complement the existing llGetInventoryCreator().

As an aside, I could see llRequestInventoryData() being expanded to return the contents of a saved EEP asset.