Jump to content
EnCore Mayne

Drop texture into prim to read and write UUID to notecard

Recommended Posts

just thought i'd ask whether what i may attempt to write is doable before i devote countless hours to achieve stellar revolutionary results:

is there a way of writing a texture's UUID into a notecard when i drop the texture into the prim that has the script?

in other words; 1. can i have a script in a prim that will capture the texture's UUID when it's dropped into it? 2. then, can the script write that UUID into an exact position within the prim's existing notecard?

since it's a super secret project i can't tell you what's already written in the notecard. suffice it to say it's like place1=UUID, place2=UUID, place3=UUID, etc..

yay or nay as to whether the existing tools allow one to do this.

Share this post


Link to post
Share on other sites
Posted (edited)

Scripts cannot write to notecards: they may only read from them.

Additionally, the act of saving a notecard actually creates a whole new asset, with a new UUID.

Edit: Depending on the needs of your project, it might be possible to store the UUIDs in a list within the script's memory. But you still have the issues of discovering the UUID of the texture, which is only possible if the texture is full perm as per llGetInventoryKey.

Edited by Fenix Eldritch
  • Like 1

Share this post


Link to post
Share on other sites
Posted (edited)

leaving Experiences KVP database out of this, then we can read/write data into some prim properties. The two most used common properties are PRIM_DESC  and PRIM_TEXT. With PRIM_TEXT we typically set the text to transparent to hide it

there are other prim properties we can read/write data into also. PRIM_OMEGA for example. We can get/set the properties: Axis and Spinrate - leaving Gain as 0 so that the object doesn't actually omega

if we don't mind adding to the LI then we can link tiny transparent prims to our object to gain more get/set property space

Edited by Mollymews
took out the stuff Fenix mentions

Share this post


Link to post
Share on other sites
6 hours ago, EnCore Mayne said:

just thought i'd ask whether what i may attempt to write is doable before i devote countless hours to achieve stellar revolutionary results:

is there a way of writing a texture's UUID into a notecard when i drop the texture into the prim that has the script?

in other words; 1. can i have a script in a prim that will capture the texture's UUID when it's dropped into it? 2. then, can the script write that UUID into an exact position within the prim's existing notecard?

since it's a super secret project i can't tell you what's already written in the notecard. suffice it to say it's like place1=UUID, place2=UUID, place3=UUID, etc..

yay or nay as to whether the existing tools allow one to do this.

I'm not sure I understand exactly what you're asking here.

Yes, if the texture is full perms to the owner of the object into which you're dropping the texture, you can read the texture's UUID.

No, you can't write anything to a notecard by script.

However, there are several other ways of storing that key more or less robustly, one or more of which may provide a sufficient method of storing the data in a more or less robust manner so you can later retrieve it, but without knowing a bit more about the super super secret project, it's difficult to comment on which might do what you want.

Does that help?   Do you want to know how to read the UUID and assign it to variable?    If that's the case, how does the script know whether to assign a particular texture's UUID to a particular variable?   Is this particular UUID to be held as place1, place2 or place3?

Or do you want some suggestions about different ways to store the data?  In that case, how do you need to access it, how securely do you need to keep it (does it matter if others can read it too?) and for how long do you need to store it? 

Share this post


Link to post
Share on other sites

well, without giving away all the beans, i'm wanting to refine an existing process. as it is now, i have to manually copy the UUID of the textures i upload and manually paste the UUID into a notecard. given that there are numerous uploads, the manual process gets tiresome. if i can't write to a notecard then the only other way i can think of to refine the process would be to have the script write out the text of the notecard, with the UUID in the right places, into chat.

all the textures and objects are 100% mine. as it stands now, it's only for personal use.

  • Like 1

Share this post


Link to post
Share on other sites

EnCore, that is a reasonable approach

AVSitter does something similar in how it handles data to go in notecards. Set up all the animations with the helpers (in your case you are setting up textures). When all done then dump the data into open chat, formatted for a copy paste into a notecard

 

  • Like 1

Share this post


Link to post
Share on other sites
4 hours ago, EnCore Mayne said:

well, without giving away all the beans, i'm wanting to refine an existing process. as it is now, i have to manually copy the UUID of the textures i upload and manually paste the UUID into a notecard. given that there are numerous uploads, the manual process gets tiresome. if i can't write to a notecard then the only other way i can think of to refine the process would be to have the script write out the text of the notecard, with the UUID in the right places, into chat.

all the textures and objects are 100% mine. as it stands now, it's only for personal use.

Thanks.  So what do you need to know?      What you describe sounds pretty straightforward, but it's not clear which part of the process you need help with.

You need to put all the textures in a box together and then drop in a script that reads the texture names and uuids, and assigns them to a series of variables, and chats out the results.  You copy-paste this into a notecard.    

However, the bit that's not clear is what logic the script will use to assign a particular uuid to a particular variable.    Does the variable "place1" hold the value of the first UUID the script checks, "place2" that of the second and so on, or is there a different logic at work there?

It's difficult to help without knowing which part of the process is causing you problems.

Share this post


Link to post
Share on other sites

ideally the script would present a dialog of choices for where the dropped texture should go.  the process is: upload texture, drop it from inventory into the scripted prim which would bring up a dialog of 8 possible places, choose the place's button and have the script chat out the 8 places with the UUID of the dropped texture written out to the proper places.

this would be for one texture at a time. then i'd fiddle with the texture in photoshop and repeat the process till everything for that specific texture place was good.

i've not got any code written yet. just wanting to know if it's possible. sounds like it can be done. the only problem is getting the chat into the format required. the required notecard is of a specific format that doesn't allow for anything outside its fixed format of place = UUID  CR/LF.

i know with AVSitter, the chatted text (with prim name, date) is taken into account by putting in a symbol that is recognized as the being the start of a new line. in this case that won't work since i have no control over the script that reads the notecard. if it's not exactly like the supplied notecard format it'll fail.

hmmm.

so is there a way to have the chat written out without the script's prim name and date written out but preserving a CR/LF format?

text text textCR/LF
text text textCR/LF
place1 = CR/LF
place2 = CR/LF
...
place8 = CR/LF EOF

Share this post


Link to post
Share on other sites
55 minutes ago, EnCore Mayne said:

so is there a way to have the chat written out without the script's prim name and date written out but preserving a CR/LF format?

No, but there are some tricks you can do. The main one is to rename the prim just before the chats to something easy for you to then do a search/replace (null string) in notecard later. Having written it out, then rename the prim at the end of all the chats.

A second trick is to build up a string with all the details in and keep adding the linebreak character ("\r from memory) between each piece of info so that it appears on seperate lines when chatted out,. but watch out for the maximum string length.

When I created the cinema slideshows which were to work using UUIDs in a notecard instead of textures stuffed in a prim, I used this method, filling a prim with the textures I wanted with names ensuring the alphabetic order was the same as the playing order, chatting them out with quotes around the texture name,m then a comma, then quotes around the UUID. (If there are commas in the names you want to use, then substitute something like the pipe character (|) instead.)

 

 

Share this post


Link to post
Share on other sites
Posted (edited)
On 6/6/2019 at 7:49 PM, Mollymews said:

leaving Experiences KVP database out of this, then we can read/write data into some prim properties. The two most used common properties are PRIM_DESC  and PRIM_TEXT. With PRIM_TEXT we typically set the text to transparent to hide it

there are other prim properties we can read/write data into also. PRIM_OMEGA for example. We can get/set the properties: Axis and Spinrate - leaving Gain as 0 so that the object doesn't actually omega

if we don't mind adding to the LI then we can link tiny transparent prims to our object to gain more get/set property space

If data is not sensitive, one can also use llSetLinkMedia(). With a 9 faced legacy prim, you can hold almost 27KB of data using the home, current and whitelist params, each allowing 1023 bytes. That includes the stupid schema enforcement recently added to the home and current url params.

This data is a permanent prim detail and survives taking into inventory, rerezzing and both prim copy methods. Just don't change the number of faces or data will be lost for any faces that don't exist even when changed back.

Another benefit of this method is that data can be read synchronously with llGetLinkMedia(). This means no leaving and/or returning to an event.

Also, if you use the whitelist param, don't use commas as a delimiter as you're limited to 64 "urls".

Edited by Lucia Nightfire
  • Like 1

Share this post


Link to post
Share on other sites
8 hours ago, EnCore Mayne said:

then i'd fiddle with the texture in photoshop and repeat the process till everything for that specific texture place was good.

You know, if you use Local Textures instead of uploading them, you can edit the local texture's file on your computer and save it to have it "automagically" update in-world.

Share this post


Link to post
Share on other sites
21 minutes ago, Wulfie Reanimator said:

You know, if you use Local Textures instead of uploading them, you can edit the local texture's file on your computer and save it to have it "automagically" update in-world.

i know, but i have to put the inworld texture's UUID through the third party's process (in a notecard) to see the texture on their mesh.

Share this post


Link to post
Share on other sites
Posted (edited)
9 hours ago, EnCore Mayne said:

so is there a way to have the chat written out without the script's prim name and date written out but preserving a CR/LF format?

Yeah, don't use chat, have the script act as an http server and output the text to the user's browser (built-in or external).

(AVsitter uses a whole external server to do this, but for what I understand of what you're trying to do the script itself should have enough memory for the necessary HTML.)

[ETA: I'm assuming this is not going to be an interface for end-users. As I recall there are some constraints that make this look a little scary to the uninitiated.]

Edited by Qie Niangao

Share this post


Link to post
Share on other sites
6 hours ago, EnCore Mayne said:

i know, but i have to put the inworld texture's UUID through the third party's process (in a notecard) to see the texture on their mesh.

Local textures have UUIDs even though they haven't been uploaded. You can get the local texture's UUID with just llGetTexture. You can then put that UUID into the third-party applier and apply it exactly like a real texture and still be able to edit it "live" on your computer.

Share this post


Link to post
Share on other sites
On 6/7/2019 at 10:55 AM, EnCore Mayne said:

well, without giving away all the beans, i'm wanting to refine an existing process. as it is now, i have to manually copy the UUID of the textures i upload and manually paste the UUID into a notecard. given that there are numerous uploads, the manual process gets tiresome. if i can't write to a notecard then the only other way i can think of to refine the process would be to have the script write out the text of the notecard, with the UUID in the right places, into chat.

all the textures and objects are 100% mine. as it stands now, it's only for personal use.

That's basically what I do for some of my things, write tools that write the notecard for me to copy paste.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...