Strange failure reading from PRIM_NAME or PRIM_DESC

[Badena Atheria]

To put a longer story short: Having an attached hud as a link set, two scripts in the root prim. Communication between the two scripts are usually done with llMessageLinked(....) and link_message(...). For some reasons which do not matter here, I found as a reliable alternative solution that one script writes the data in the name or description field of a child prim. So that the other script can read the data at any other time. So far so good. Imagine a simple TRUE/FALSE example, here in abbreviated form.

The script wrote the state TRUE or FALSE into the PRIM_NAME field as a string 1 or 0. This switch caused the same and/or the other script doing or not doing something by reading 1 or 0 from the PRIM_NAME field. Worked fine. With growing complexity of the scripts, however, it did not work anymore. 0 or 1 were not read properly. I checked with llOwnerSay("Tell me if 0 or 1 is in the PRIM_NAME field"). It proved that the field had always the correct entry. Now comes the strange thing: Obviously only because the content of the field was used with a function, the data was read corerrectly, when I removed llOwnerSay(...) the script went back again not recognizing a change in the name field. I think the same happened with other text entries as well, only that I had not been fully aware what was going on until I found out about it today with checking a simple switch.

A similar thing happened btw with a 1024x1024 texture, a chart divided into 10x10 fields with a letter in each field. Moving from one letter to the other by changing the offset of the texture moved the texture, but despite texture refresh it did not show in the viewer (Firestorm). This was proved by reading the current offset of the texture by a script, which gave the correct new offset, while the viewer still showed the texture with the previous offset.

Just want to share this because knowing it may safe a lot of time.

[Naskiff]

In theory I think complexity should not make something not work anymore, so for the name description issue, I suspect that maybe there was a small mistake in the code, like

if (x = 1) instead of ==

Or maybe "+=" instead of ">"

Or maybe the script checks for 0 or 1 (integer), instead of "0" or "1" (string).

[Mollymews]

we sometimes need to have our scripts wait for the property change to take effect before we continue. For example with writing to object description:

// in our writer script

string data = "something";

llSetObjectDesc(data);

// wait until object description has been updated
while (llGetObjectDesc() != data);

... when object description has been updated then continue ...


// with our reader script that is expecting a change then

string data = "whatever was read previously";

// wait until object description changes
do
{
  string read = llGetObjectDesc();
} while (read == data);

// when object description has been updated then continue
data = read;

/*
   to avoid the scripts going catatonic then we wait for a time
   at times end we break out of the wait loop
   and deal with the fallout

   example:
*/

string data = "something";
llResetTime();
llSetObjectDesc(data);
while ((llGetObjectDesc() != data) && (llGetTime() < 10.0));  // wait for upto 10 seconds

// check for expected change
if (llGetObjectDesc() != data)
   .. expected change hasn't happened ...
else
   ... it has ...

 

a caveat is that doing this kind of thing can get messy

Edited October 5, 2021 by Mollymews
typso

[Profaitchikenz Haiku]

9 hours ago, Badena Atheria said:

A similar thing happened btw with a 1024x1024 texture, a chart divided into 10x10 fields with a letter in each field. Moving from one letter to the other by changing the offset of the texture moved the texture, but despite texture refresh it did not show in the viewer (Firestorm). This was proved by reading the current offset of the texture by a script, which gave the correct new offset, while the viewer still showed the texture with the previous offset.

This sounds like a viewer update issue, as you have found by script the offsets have changed. The texture update can sometimes be forced by a right-click and finding your way to "refresh textures", but there are times when I've only seen the change appear by relogging. It's annoying, and it's also rare enough that I can't produce a test case to take it further.

[Rolig Loon]

For some reason, that sort of thing seems to happen more often in attachments than in free-standing objects. I've never understood why, but sometimes things that you change while an object is attached don't persist after you detach them.  And occasionally, as Molly says, changes are sluggish.  

[Profaitchikenz Haiku]

10 hours ago, Rolig Loon said:

but sometimes things that you change while an object is attached don't persist after you detach them.

It's a caveat in the wiki that changes to PRIM_NAME and PRIM_DESC for the root prim definitely do not get saved on detach, which has bitten me a couple of times, but I have yet to see the problem the OP mentioned, however, the most complex linkset I have worked on using these methods is only about 48 prims, so I'd be interested to know what level of complexity they reached to see the problem?

[bobsknief Orsini]

On 10/6/2021 at 1:18 PM, Profaitchikenz Haiku said:

It's a caveat in the wiki that changes to PRIM_NAME and PRIM_DESC for the root prim definitely do not get saved on detach, which has bitten me a couple of times, but I have yet to see the problem the OP mentioned, however, the most complex linkset I have worked on using these methods is only about 48 prims, so I'd be interested to know what level of complexity they reached to see the problem?

Haven't seen this problem. Have a HUD where i am using 128 prims to store and read data from the name and description. You only need to keep in mind that there is a delay between the command and the prim actually having the description.