how to create notecard with scripts

I cant find any example how to create a new notecard in my prim inventory.

hope someone can help me..

cheers....

You cannot. Notecards are read only, LSL has no methods for creating or adding/changing them.

The reason, as I understand it, is this:

A new notecard asset would have to be created each time a script added a line, which could, if abused (and it would be), cause problems for the asset server.

As Jopsy said this would be such an easy griefing tool it just isnt safe to ever allow.
Personally I hate the fact that each edit/save cycle changes the UUID. Personally I would love to be able to create one notecard in my inventory and have scripts link to it via its UUID, so much quicker for updating vendors and the like.

I do understand why it isnt that way, but I'm not convinced that its any safer/better for the dataserver than the constant UUID until explicitly copied idea.

Hmm, it just struck me, using the same reasoning, it would also be unsafe to allow scripts to rez prims. Oh, I forgot, that is allowed :}

I had one script go beserk on me (okay, it was 4 am in the morning and I might have been bleary-eyed and so possibly my fault :}) and rez an object a zillion times, like 5400 prim worth altogether, and it was other a sudden message saying "parcel full" that made me go, what's going on here?

Yes. But since lots of script functions could be abused, we should just eliminate scripting entirely.

Would that stop griefers? Nope. You can still break sims even without scripts.

This could easily be done now, it's just a matter of needing to remember to update the notecard UUID in the vendor(s) after each edit.


It's not so much a matter of "safety" as of storage space conservation. If I create a notecard, and give a "copy" to 10 others, there's still only one notecard file saved on the asset servers, with 11 inventory pointers to it. If I edit my "copy", a new asset is created, my inventory now points to the new version, but the 10 "distributed" earlier are unaffected.


Rezzing objects doesn't create new asset entries, only new object instances in the sim.

I don't believe so. Copies of objects are NEW objects with new UUIDs and not linked to the original in any way. Rezzing a copyable object does, indeed, create a brand new object - again with a new UUID. Only if an object is NOT copyable does the original get rezzed in the world with the original UUID.

Correct, but it doesn't create a new asset entry.


Incorrect. Every time an object is rezzed, copyable or not, it is assigned a new instance UUID.

You may be confusing asset UUID's, which is what you would get by right-clicking an item in your inventory on which you have full permissions and choosing "Copy Asset UUID", with instance UUID's, which is, for example, what a sensor would detect for in-world objects. Objects have no asset UUID. If you attempt to copy the asset UUID of an object in your inventory, all you'll get is NULL_KEY.

gosh, how could anyone confuse that? :}

Yes - I was confused. The explanation of the distinction is helpful. Thanks.

Someone needs to put the whole "no notecard creation through scripts" issue in a sticky. New scripters are always asking the question (for good reason because it seems like it should work some how). And how much wasted time has there been looking for the llFunction that does it. I know I spent days looking for it.

Read the stickied FAQ thread at the top of this forum. The 3rd post from Eloise Pasteur answers the question succinctly.

Most people don't bother looking for the answer; it's easier to just post the question and get it over with.

Usually, my answer to these questions is a link to the answer, or how to find it.

So what happens if you then take that object into inventory? Does that create a new asset entry?

Just to clarify, maybe....

is this a fair re-interpretation? accurate? did i forget anything?

________

Copy Asset UUID in inventory works only for notecards, textures, animations, gestures, non-prim body parts, landmarks, clothing and sounds for which you have full permissions. It does not work on them if you don't have full permissions, and it never works for objects that are prim objects, or for scripts.

When rezzed, prim objects may appear to have an Asset UUID, but what they actually have is an instance UUID. If you make note of a rezzed item's UUID, then take it back into inventory, then rez it again, you will find that the UUID has changed. For those of you who have a network of a hundred vendors dependent upon a server's UUID, that's why you *never* take the server back into inventory to move it -- you *wear* it instead to the new location in order to preserve its *instance UUID*.

________________

corrections / additions welcome. Bashed out as lunch hour is coming to an end.

Sounds about right to me Chaz.

You might be able to simplify it, however, by just stating that all inventory types that are not made or comprised of prims - thereby not being rezzable - Have Asset UUID's. You may pull these UUID's directly from your inventory using a right-click as long as you have full permissions. Asset UUID's are persistant (not sure if all types of asset uuid's retain their ID throughout all their copies in all inventories....but I would assume so)

Any inventory item that is made of prims and thereby is rezzable in world, does Not have an Asset UUID, but instead will be assigned a new Instance UUID everytime it is rezzed in-world. Instance UUID's are not persistant and will change each time the object is rezzed.

Apparently not, since an attempt to retrieve an asset key from an object in inventory results in NULL_KEY. Objects in inventory are apparently stored differently.

Objects also have asset UUIDs; you just can't obtain them with Copy Asset UUID like you can all other non-rezzable assets.

They may indeed be stored differently in the asset server, but they do also indeed have asset UUIDs, because there is a Linden god mode function which takes an object UUID asset key to rez: llGodLikeRezObject(), and there is a Rez Asset ID request in the God Tools on the Server menu.

I think the disabling of obtaining object asset IDs is a security precaution more than some weirdness in how objects are represented/stored in inv.