Auto create notecard with LSL

Hi there,

I wonder if a notecard can be created by LSL?

Many thnx

Quick answer, No

And long answer is that the Lindens have stated that this capability will never be added.

...though I had a more manual, LSL-aided proposal a long time ago that a Linden looked at and said something to the effect of, "Hmm. That could be more workable. The message protocol isn't setup for it and we'd have to create a new data channel, but eventually it could happen." The idea was to send the contents (and name) of a new notecard to the viewer, and have the viewer treat it as if the user had created a new notecard and entered the contents without hitting the save button. The notecard would pop up on the user's screen, and it would take manually hitting that "Save" button to actually create the asset.

Not quite the completely autonomous solution that most people are looking for, but it could help a bit in writing configuration notecards and such. A nice simple UI enhancement that could make products easier to use for new residents and such. Of course, now that we have llOwnerSay() and 1k characters per chat, maybe copy/paste isn't too bad of an extra step in the process either. Still, might be worth creating a JIRA with the suggestion (I made it before JIRA was being used, and haven't really revisited since).

What exactly do you want to do? Although you can't create notecards, you can store a fair bit of info in a prim description, and read it back easily. Should also be able to use child prims to store additional info. That is a little bit more persistant than global variables, and will survive an llResetScript, although it isn't anything you would want to use for end-user editable material.

BTW, I have found that storing info in the description doesn't behave for HUD/Worn items... at least it didn't the last time I tried.

name/description fields in worn items revert to the value they were last saved with in inventory when detached, it's a known issue. globals usually survive sim resets but if you're worried about dynamic information being lost, you need to save it offworld (thogh some minor data can be saved in prim properties that aren't being used (mostly floats)

You could also use a dedicated script for data storage. Just be careful not to reset it along with the other scripts involved (e.g. do NOT do Tools -> Reset All Script In Selection).

i wonder if soem of the more experience scripters have ever tried to send he info via http somewhere then send it back to an av(maybe a bot) and have it create a notecard ?
is it possible?
I am no where near that level in scripting but is a thought i had

There WAS talk at one point of a bot that would accept an IM, create a notecard, and send it back. Not sure if anyone actually has one running out there. It is certainly a viable option. (Someone DOES have one running for name-to-key translations though.)

Thank you for your answers.



What I want to do is just insert login (avatar name) and password in a notecard before it will be given to avatar when he/she buys my product.

Hmmm what would be the purpose of that? I certainly wouldn't want my password stored in any in-world object.

Maybe it's a customer password, rather than the login one?

From what I've seen, merchants who are providing avies access to, say, a web site that requires login, simply either a) have a script that sends an IM to the avie with the correct login info or b) display the info in a popup menu. As for notecards, that I'm aware, they're not writeable. If they were, people would not be doing all sorts of acrobatics (i.e., using description fields, remote services, etc) to persist data.

This seems pretty easy. I'm going to do this.

Of course it's easy.

From December 2008 jira:
https://jira.secondlife.com/browse/SVC-3515

Not sure if you're saying it's not easy or what. The existing openmv testclient has this functionality built in. It's just a matter of ripping it out and attaching it to a webpage or something. Should only take a few hours. Hardest part for me is going to be communicating between the web page and the bot which I've never really done before.

Ummm... communicating with a website and having it send the user an IM with the pertinent data? Cake. Though, that is not what the OP asked. Recall, they wanted to *create a notecard* containing the user info. Obviously easy, if writing notecards were actually supported. Which it is not.

No, I'm imagining a form on a website you type a bunch of data into and then click submit and the bot creates a notecard with that text and gives it to you.

It could do IMs too but I think an html form would be more convenient and scripts could use llHTTPRequest

Not sure how to handle spam issues, but I'll cross that bridge when I come to it.

So you're talking about writing an SL bot using libsecond life, wherein said bot creates and writes to a notecard, and then drops said notecard in the target's inventory? Since that is the only way auotmated notecard generation can be done, that is hardly an "Autocreate notecard with LSL." Which is the title of this topic. As for the spam bridge when I come to it bit? erm... okay. lolol

EDITTED. Cool, glad everything is fine.

Well, it (theoretically) totally solves the OPs problem because he can just use llHTTPRequest to call the webpage and submit the data and then the bot sends the notecard.

oooooooooo nice!

In your face absolutely everybody. I went a slightly different route but I think this is more practical than the http thing.

Also, I absolutely guarantee about a 70% uptime with this thing so you can pretty much rely on it to be there some of the time!

LOL. Very good. Okay. So, does the 70% up time have to do with when ur running the bot? Also, did u write ur own bot or r u using a prepackaged one?

Yeah it should be up most of the time really. It's my group invite bot that I modified to do this as well. I wrote the whole thing from scratch using openmv. Of course like everything on SL it can crash from time to time and not come back for a while. Anyway, it should be pretty reliable. More than 70% realistically.

The code is really not that complicated as I mentioned there's a working prototype in the TestClient that comes bundled with it.