All Things Notecard

Hi guys,

I was playing around earlier trying to make my notecards more colorful by embedding various inventory items, when I noticed a couple of things, and wondered about a couple of others.

1. It is possible to embed all the following, providing they are full perm:
Landmarks
Prims Objects
Animations and Gestures
Items of Clothing
Body Parts
Sounds
Photos and Textures
Notecards
Scripts

all the above embed, showing their standard icons and description.

2. The only inventory item that would not embed is a Calling Card.


I wondered what would happen if you tried to read a notecard line, and the line simply had an embedded inventory item there. I guessed that it would return the UUID of the embedded item, but being at work, and unable to test, I consulted the wiki, which says:

"Requests from notecards that contain embedded inventory items will always result in EOF, regardless of the line being requested."

This seems to state that if the notecard has an embedded inventory item anywhere in it, such as a landmark, then NO line at all can be read. Do others agree with this interpretation?

I also wondered if it was possible to access any of these embedded items in a notecard (once it is placed in the Contents of a prim, for example) through LSL, e.g, to set an embedded script to running or not running.

Would a running script continue to run once the script is embedded in a notecard in a rezzed prim?

What would happen if you had two notecards, ExampleA and ExampleB, and you embed A into B, then embed B into A?

Is anyone aware of any icons in use that are NOT in the standard Inventory?

(you can see how busy I am at work!) )

Rock

LSL cannot read from notecards that have inventory items in them. You can only read notecards that are plain text.

Hehe try to do that. You'll end up with 2 different versions of A ... one with B embedded in it, one without.

nope, it'd be treated as if it were in avatar inventory, in fact it is, as are all the embedded items.... the embeds are just links to these object, and not actual objects. in fact non-rezzing resources in a prims inventory are just references to the item on the asset server, and not the actual item, including the notecard (which is why it requires a dataserver event to read, or in the case of landmarks a specialized function, etc )

That is the way I envisaged it Void, which is why I was surprised to read in the wiki that any embedded object in a notecard causes llGetNotecardLine to fail with EOF, rather than simply return the link.

Interestingly, if you put one of every type of object on a separate line, then select and copy all in the notecard (Control-A, Control-C), and paste into a Hex viewer, every line has the same Hex values 3F 3F OD OA OD OA (? ? . . . .)

Rock

not TOO surprising, but that string you get in the hex editor is interesting... might explain some of the issue...

"??

"

minus the quotes... 2 question marks and 2 crlf's... probably a marker / instruction for the viewer to check a reference table for the lookup values of the embedded resources...(similar to 'C' style variable insertion) and because of the special processing, (and multiple inlined crlf's) the dataserver doesn't process it... or it could just be that the lookup table interferes with how the dataserver retrieves lines, especially if that table size or data is inserted before the text size / data.

the reason that 3 crlf's mark the end of a notecard file would be upt to the vaugeries of what character encoding they use (UTF8?) and how crlf is normally handled in that encoding (I thought it the was same, but to be honest, never really looked.) as well as ll's chosen file end marker..... presumably you don't get that string or 3 like that normally in the encoding they use.

More data for notecards:

In my notecard I have an example of every type of embedded object (see below). I then went to my inventory where I obtained the original object, and right-clicked each one in turn, and selected Copy Asset UUID. I then pasted the UUID beneath each object (I was looking for UUID constructions). What I noticed was that some of the Objects had all zeroes for their UUID (objects in the Object folder; Scripts; and Textures).

Animation: UUID
Prim Object: zeroes
Body Parts (Male Shape): UUID
Gesture: UUID
Landmark: UUID
Notecard: UUID
Script: zeroes
Texture: zeroes
Sound: UUID
Photo: UUID
Clothing: UUID

Anyone any views on these results? How are Photos and Textures different?


The next test was to click on each embedded object. I got for most the same dialog, 'Copy this item to your inventory?', with Copy and Cancel buttons. The ones that produced something different were:

Landmark: the regular Preview Landmark dialog appeared
Notecard: the actual notecard opened
Texture and Photo: both displayed, with a single Copy to Inventory button


Rock

Textures are uploaded from people's local hard drive, photos are taken with the snapshot feature and are directly uploaded. That's really the only difference, besides the different icon. Well, and they end up in different inventory directories. Just an attempt to sort photos from textures I think.

But the texture has all zeroes in its UUID, while the Photo has a regular UUID. So the difference seems to be a little deeper.

Rock

A texture with full permissions should definitely NOT have an all-zero UUID. Textures are things used all the time from script, by UUID, and you need to be able to retrieve the key. I'm thinking that might have been an asset server problem or something.

specifically anything you don't have permissions for, you shouldn't be able to get a valid uuid for either... exceptions seem to include:
animations (because you can no longer trigger them or give by uuid)
body parts / clothes (because they can't be given by uuid)
gestures (same as above)
landmarks (because there are no permissions settable for these)
but should apply to:
textures
snapshots
sounds
scripts
notecards (maybe, can't remember)


in the case of textures it must be full permissions... I'd assume the same for scripts...

objects in inventory do not have uuid's, at least in the common sense. they are assigned one by the sim, on rez.

I have found notecards notoriously unreliable at keeping photos and landmarks correctly embedded in the notecard. They often disappear leaving a ? in thier place, I have also had photo switch places within the notecard. i.e. photo D which was at the bottom of the page switched places with photo A which was at the top of the page.

It is not just my notecards doing this but those from other creators.

I have had so many problems with this that I have started writing in text the slurl for locations as well as including the landmark.