Notecard editing in an object

[Bavid Dailey]

I have a configuration notecard in an object; if I edit the object and edit a notecard from the obects' contents, saving when done - it appears to me that the changes are not noticed unless I take the object an rez it agin.

I assume this because the server is caching notecards and it doesn't  notice the save - perhaps the UUID isn't changing?.

Does anybody know if this is true, and is it the iontended behaviour?

[Love Zhaoying]

Scripts only work on an object's inventory items when the object is rezzed..could be a short way of explaining it?

I'm sure someone will correct me if wrong.

[Fluffy Sharkfin]

23 minutes ago, Bavid Dailey said:

I have a configuration notecard in an object; if I edit the object and edit a notecard from the obects' contents, saving when done - it appears to me that the changes are not noticed unless I take the object an rez it agin.

I assume this because the server is caching notecards and it doesn't  notice the save - perhaps the UUID isn't changing?.

Does anybody know if this is true, and is it the iontended behaviour?

It's more likely that the script only loads the contents of the notecard when it first runs, so the changes you make to the notecard won't be read until the script is reset which is most likely occurring each time you rez the object.

[Love Zhaoying]

2 minutes ago, Fluffy Sharkfin said:

It's more likely that the script only loads the contents of the notecard when it first runs, so the changes you make to the notecard won't be read until the script is reset which is most likely occurring each time you rez the object.

Yep! I assumed the object wasn't rezzed at all from the OP's phrasing. 🙂

[Qie Niangao]

9 hours ago, Love Zhaoying said:

Yep! I assumed the object wasn't rezzed at all from the OP's phrasing. 🙂

I don't how to edit a notecard inside an object that's not rezzed.

9 hours ago, Fluffy Sharkfin said:

It's more likely that the script only loads the contents of the notecard when it first runs, so the changes you make to the notecard won't be read until the script is reset which is most likely occurring each time you rez the object.

Seems likely, and this is why the CHANGED_INVENTORY event is very common in scripts that use notecards because users are forever editing those notecards and expecting stuff to update as a result. Maybe that's why the event is handled in the sample script for llGetNotecardLine().

9 hours ago, Bavid Dailey said:

I assume this because the server is caching notecards and it doesn't  notice the save - perhaps the UUID isn't changing?.

This never happens; to save a revised notecard is to create a whole new asset with a new UUID. This fact is often used in scripts that care about only one (say) of a bunch of notecards in the object: By keeping track of the UUID of the notecard it read, the script can avoid re-reading it every time some other notecard is updated.

[Wulfie Reanimator]

12 hours ago, Bavid Dailey said:

I have a configuration notecard in an object; if I edit the object and edit a notecard from the obects' contents, saving when done - it appears to me that the changes are not noticed unless I take the object an rez it agin.

Show your script, there's very likely a super simple explanation for what you're seeing.

Like Qie said, saving a notecard always (always) replaces the old UUID, but the old UUID still exists and is readable.

[Love Zhaoying]

3 hours ago, Qie Niangao said:

13 hours ago, Love Zhaoying said:

Yep! I assumed the object wasn't rezzed at all from the OP's phrasing. 🙂

I don't how to edit a notecard inside an object that's not rezzed.

Being a vegetarian, I can't blame a turkey coma.. 

[Profaitchikenz Haiku]

4 hours ago, Qie Niangao said:

By keeping track of the UUID of the notecard it read, the script can avoid re-reading it every time some other notecard is updated.

I wonder how many previous versions of it can be accessed this way? Thanks greatly for this detail, I am off to fliddle about with this.

Colour me over-eager, I re-read what you wrote and see the error of my ways.

Edited November 29 by Profaitchikenz Haiku
Owning up to wishful thinking

[Qie Niangao]

21 minutes ago, Profaitchikenz Haiku said:

I wonder how many previous versions of it can be accessed this way? Thanks greatly for this detail, I am off to fliddle about with this.

Colour me over-eager, I re-read what you wrote and see the error of my ways.

In fact, though, I think you were on to a good idea, one I was debating whether to ramble about when I posted: It should be possible to retain a sequence (a list, say) of previous notecard UUIDs that the script could use for a sort of version management: hit a notecard edit that breaks something and roll back to the last working version. If the human user didn't retain their own historical copy, a utility script can read from the UUID-identified version (possibly into a browser window) so they can copy the text into a new notecard from which to edit from a known working version. Or something like that.

[Profaitchikenz Haiku]

That was exactly what I hoped I could do, then just have a list of  uuids with a date and description. If I get a moment I'll see if it's all all possible.

[Bavid Dailey]

Wulfies request for a 'show the script' was reasonable, but impractical. It's part of big project, so I need to come up with a test caee.

Thing is the project is from 2010 and it used to pick up edited notecards in those dark ages , read them AND note the changes. Hence my OP. Can I prove that ?  Hardly, its a long time ago and my memory has better things to do. But if it didn't work like that I'd have documented it more than likely. 

Given that the fast notecard read newish feature works by using the serverside cache, the opportuity for a change that caused this is high. It's a bug because the cached version of the n/c does not reflect the master database copy as it should.

If you can read prior version of a n/c by exploiting this bug, I assert that's a bug too 🙂

I'm working on the test case, will let y'all know what I find

Edited November 30 by Bavid Dailey

[Wulfie Reanimator]

5 hours ago, Bavid Dailey said:

Given that the fast notecard read newish feature works by using the serverside cache, the opportuity for a change that caused this is high. It's a bug because the cached version of the n/c does not reflect the master database copy as it should.

If you can read prior version of a n/c by exploiting this bug, I assert that's a bug too 🙂

Either I'm not understanding what you're saying, or you're misunderstanding the role of the notecard cache.

If you're reading a notecard using the name of the notecard, the script will be immediately interrupted by the cache when the notecard contents change.
If you're reading a notecard using the uuid of the notecard, you will continue to to read that notecard even after someone edits a notecard with that UUID.

There's no bug or exploit here, everything is working as intended and as it should work. I can go into more detail if this doesn't make sense to somebody.

Edited November 30 by Wulfie Reanimator

[Love Zhaoying]

1 hour ago, Wulfie Reanimator said:

If you're reading a notecard using the uuid of the notecard, you will continue to to read that notecard even after someone edits a notecard with that UUID.

Fascinating! (I read cached notecards in my current projects.)

[Wulfie Reanimator]

2 hours ago, Love Zhaoying said:

Fascinating! (I read cached notecards in my current projects.)

The reason for that is the fact that the old (before save) UUID stays cached. The new UUID gets its own cache entry. (And this is why reading a notecard by name will result in NAK / interrupted reading. The new notecard isn't automatically cached.)

And none of this caching affects the old functionality, because that will always wait for the latest data to be available before returning any data.

Edited December 1 by Wulfie Reanimator

[Qie Niangao]

8 hours ago, Bavid Dailey said:

Thing is the project is from 2010 and it used to pick up edited notecards in those dark ages , read them AND note the changes.

How? Is there a changed() event handler that re-reads the updated notecard from Inventory in every state the script could be in when a notecard might be edited? Because if not, it never correctly got those updates.

If so, and it's somehow not working now, to begin to substantiate such a bug we'd need to know whether those changed() handlers aren't triggered appropriately or whether instead the contents of the re-read notecard aren't appropriately updated.

As Wulfie points out, if the notecards are read by UUID not by name, then there can never have been an update to their contents.

I'm not quite so confident that nothing could have happened to let a script read a stale named notecard. I haven't seen such a bug and I've definitely recently seen normal response to updated notecards in object inventory, but there have been changes in notecard processing so… could there be a buggy edge case somewhere? If so, it could be very difficult to replicate.