reading child prim descriptions

[clarashymonkey]

I am trying to decide if I am attempting the impossible or missing something stupidly obvious, so I thought I would ask.

Basically, I am trying to read the description of a child-prim contained in an attachment worn by avatars detected by the object containing my script.

The detection side is all taken care of and, from that, I am able to read the description of the attachment's root-prim, no problem.

I just can't work out how get into the rest of the attachment's link-set, where I have the attachment using child-prim descriptions for data storage.

I suppose what I am hoping for is a cross between llGetObjectDetails and llGetLinkPrimitiveParams. Does such a function exist?

Still learning LSL so any help would be greatly appreciated.

[Mollymews]

from a script in the root prim then:

key link = llGetLinkKey(2);  // where 2 is the linkset number of prim 2
  
string desc = llList2String(llGetObjectDetails(link, [OBJECT_DESC]), 0);

 

[Nova Convair]

If you want to read that info with llGetObjectDetails you need the uuid of the child prim. Only a script in the object can tell you the uuids of the child prims though.

[Fenix Eldritch]

2 hours ago, clarashymonkey said:

I suppose what I am hoping for is a cross between llGetObjectDetails and llGetLinkPrimitiveParams. Does such a function exist?

Unfortunately no such function exists. If you want to read the description of a child prim from another linkset, you're going to need to get creative.

Mollymews's suggestion to use the root prim to temporarily hold a copy of the child prim's description data is one option - though if you are using multiple child prims worth of data you'll need to create a system to shuffle them around.

Another options is to setup a communication relay between the attachment and the scanner. Basically, when your scanner object detects an avatar, it will direct a chat message to that avatar's attachment (since you already have the uuid) with something like llRegionSayTo. Meanwhile, the attachment's script will have a listener setup to listen for the scanner's message and when heard, it will grab the contents of the child prim's description (Mollymew's code could also be used here) and then llRegionSayTo that right back to the scanner object (which would also need a corresponding listen setup).

[clarashymonkey]

Thank you everyone for at least confirming that I haven't gone bonkers.

For the record, I had already considered all of the work-arounds suggested (and a few others) but had hoped to avoid having to use them in the end product.. 

On balance, however, I think using the root-prim as a temporary 'session-only' data-store seems the least worst option available and I already have a working prototype.

I suppose I just have to pray that end-users are too busy having fun to edit the root-prim's exposed description and thus modifying the data on which the rest of the script suite's concept depends. *wimper*

[Mollymews]

11 hours ago, clarashymonkey said:

I suppose I just have to pray that end-users are too busy having fun to edit the root-prim's exposed description and thus modifying the data on which the rest of the script suite's concept depends. *wimper*

i whimper a little as well, at things that people do sometimes when they obtain stuff

a thing tho is that when the root prim is modifiable then probably the child prims are also. When so then the risk that a user may modify the description field of any prim in the linkset is also present.  I think that sometimes we are best to trust the user to not go out of their way to do out-of-the-ordinary things

 

[clarashymonkey]

On 6/28/2019 at 5:51 AM, Mollymews said:

i whimper a little as well, at things that people do sometimes when they obtain stuff

a thing tho is that when the root prim is modifiable then probably the child prims are also. When so then the risk that a user may modify the description field of any prim in the linkset is also present.  I think that sometimes we are best to trust the user to not go out of their way to do out-of-the-ordinary things

 

I take your point but, actually, I have all the child-prims physically encased in the root-object so, while I agree their descriptions could be tampered with, the end user would (a) have to know they exist and (b) I think physically dismantle the attachment to get at them. Moreover, tampering with the most critical values results in a mismatch between the user-modified settings and those stored in a SHA1 hash during (authorised) first-use initialisation, causing a doctored attachment to die as soon as it is rezzed.

In short, having accepted that total data protection is impossible, I was rather trusting to people's lack of tech-savvy to reduce the risk of tampering to a minimum; hence my reluctance to have the data exposed in a description any fool can see if they know how to click 'edit'. 

Just had the need for defensive programming drummed into me, I suppose — Murphy's Law and all that.

I should perhaps just add that I am not overly OCD about it. It's just that parts of the mathematical engine that drives the attachment are non-linear so I have no idea what tampering would do to the output and would prefer to be nowhere near the attachment's wearer to find out. 

It's a bit 'biological' you see, so it could get horribly messy! LOL

 

 

[Mollymews]

37 minutes ago, clarashymonkey said:

defensive programming

in this case then I probably go with another place where we can read/write data which can't be changed by the users. PRIM_TEXT.  Where we set the alpha to 0.0 so it can't be seen by the eye

integer link = 2;

string text = llList2String(llGetLinkPrimitiveParams(link, [PRIM_TEXT]), 0);

When we use PRIM_TEXT then can also use the color vector to store 3 floats/numbers if needed/wanted in addition to the text

 

edit: not changed that is unless they can drop a script into your object to do this

Edited June 29, 2019 by Mollymews

[clarashymonkey]

1 hour ago, Mollymews said:

in this case then I probably go with another place where we can read/write data which can't be changed by the users. PRIM_TEXT.  Where we set the alpha to 0.0 so it can't be seen by the eye

Hadn't thought of using the child-prims' text. Thank you so much for that!  More bytes too I see, so smacked bottom for me at bedtime! LOL

It's just so obvious now that you mention it, I can't think why I didn't think of it before. DUH!!!

I am already using colour vectors to store a few floats however, so I am getting there I think.

With so much yet to learn, though, I am almost tempted to give another whimper, but learning new ways to achieve the 'impossible' is such fun!  

Again, thank you so much, Molly!

[clarashymonkey]

Well I have done it and I must say it works brilliantly! Setting the child-prims' text alpha temporarily to 1.0 (visible) has also made debugging the rest of the suite so much easier, I am still kicking myself for not thinking to use PRIM_TEXT before.

I have left the bits that will be queried by the on_rez checks in end-user accessible descriptions though on the grounds that (to quote my RL mentor) "a good castle should always have what appears to be a weak point to tempt attackers into foolishness".

However, not all good news I am afraid because,, as he also rightly pointed out, the caveats SL has attached to the use of text for data storage (http://wiki.secondlife.com/wiki/LlSetText) do mean this method is far from perfect and therefore perhaps not suitable for everyone trying to solve the problem I had.

Fortunately, I don't see anything in the caveats to trouble my little project so my gratitude for the suggestion remains undiminished. The integrity of the data I am storing is critical only at run-time you see and, if it is corrupt, that will be picked up by the aforesaid on_rez verification routines long before it can do any harm.

Just thought I should point out the caveats though for the sake of my bottom and for the benefit of others who might be tempted by my enthusiasm to use the method for the long-term storage of critical data that cannot be easily replaced/reconstructed.

Edited June 30, 2019 by clarashymonkey

[clarashymonkey]

Oh dear! Umm … okay so now that I have my data safely stored in the invisible text of my attachment's child prims, returning to my original difficulty, how do I get other objects (not part of the attachment) to access it? 

I had, perhaps foolishly, assumed that llGetObjectDetails would do the trick but, on closer inspection, while it appears to have a parameter for just about everything one could possibly wish to know about an object, almost down to the colour of its creator's undies, surprisingly OBJECT_TEXT or the equivalent seems not to be among them.

So, am I back to square one? Back to exposing the data in the root prim's description where other objects (and end-users) can get at it?

Now up against a bit of a  deadline, I think i am just going to have to just go with that, but I am still open to alternatives if anyone has any. Sorry Molly  

[Mollymews]

lets recap this

1) we want to read data from a persistent store in linked prims >> description field
2) we want an external script to read/write data to the persistent store in response to a user or object intervention (? user touch, user/object collision, rez attach ? )
3) we can only read the root prim description with an external script, we can't read the linked prims
4) we treat the root prim description field as a buffer
5) we worry that users will edit the description fields of the object linkset breaking the app
6) we decide to store the linked prim data in their text property to make it more difficult for the users to break it
7) we can't read the root prim PRIM_TEXT with llGetObjectDetails
8 ) so we still use the root prim description field as the buffer
9) filling the buffer from the PRIM_TEXT of the linked prims as required

 

edit add: i should have posted above about not being able to read PRIM_TEXT using llGetObjectDetails.  I just assumed that was clear from the 2nd code snippet I posted when I wrote llGetLinkPrimitiveParams to get the PRIM_TEXT into the root prim. My bad

Edited June 30, 2019 by Mollymews
not clear