llList2Notecard

I know at the last script related meeting, there are issues with the way notecards are stored for us to be able to randomly write to a notecard.

But, it seems totally possible with the current architecture to create a new notecard with some lines of text, rather than "edit" a card.

I'd like to see a llList2Notecard method added to LSL. It would do a one-time dump of a list to a notecard. We can then read the notecard the standard way.

e.g.

list myList = [apple, orange, banana];
llList2Notecard(myList, "New Note #1";

Seconded!!!!!!

I know RPC-XML is coming and all BUT an alternative way to store information onto the notecard when you do not want the hoodickey to set up a server for XML-RPC would be cool.

All my free money is being drained into LL now anyways. NO money to afford any decent servers to host anything.

Give us some kinda notecard writing!!

This would allow for writing randomly actually.

Read, manipulate, delete old, write new.

-Adam

Third-ed.

XML-RPC is not going to be the answer for everyone, especially for people like... say... me, who doesn't have the money or the resources to run server space or my own email account.

I highly endorse this feature/idea.

I would definitly use this one.

*Edited, silly idea addition. Just read notecards in the standard way *

Yep, this would be highly appreciated

Lindens: any timeframe on adding llList2Notecard? It would really help with some of the inter-object communications where we want to pass data around. I could reduce the numbers of emails sent if I could just simply write a list to a notecard, and pass the UUID of the notecard, rather than sending multiple messages.

I endorse this feature / idea / and/or suggestion.

There has also been some requests for llWrite2Notecard, where you would pass a single string and then create a notecard. llList2Notecard would do the same thing, but would allow us to store list data.

Lindens?

I support this concept, but to generalize a bit, I'd like to see:

llString2Notecard(string name, string text);

or maybe a better name would be llCreateNotecard

Maybe all of this is just barking up the wrong tree.

I understand this suggestion is in response to the comment during the last town hall meeting where it was explained that a "llWriteNotecardLine()" would not be practical to implement given the way the notecard data is represented currently.

We have come to read that as assuming that modifying an existing notecard is where this problem lies, but creating a brand new notecard may not be as problematic to implement.

We need local persistent storage. If notecards are not the answer, please find some way to make it possible.

This is a critical issue. We can't develop a stable environment without the ability to have persistent storage.

Even with RPC in place, we need something to use for short-term storage for instances when the RPC call fails, for example. The internet is not reliable, so we need reliable local storage for critical information systems (sales, debts owed, auction data, etc). Such storage would be very useful for a temporary 'buffer' until the network connection for RPC can be restored.

Please, LL -- if you can't hack it with notecards, give us *something* we can use.

Thanks for reading...

-- Kex

Write to notecard is pretty crucial for a lot of stuff.

Eg, you write a script that non-scripters can teach to do something. You want the script to automatically save what its learned to a local notecard.

You dont want to have to get the non-scripter to copy and paste from console/email into a notecard and drag that notecard into your object...

It's not impossible to get people to copy and paste into notecards but its untidy, takes a lot of time and it's just not user-friendly!

Azelda

P.S. See also this new thread for an alternative / complementary paradigm for WriteToNotecard:

/13/5b/12809/1.html

"Be Able to Send Objects into SL via Email"

bump!

I'm seriously considering doing

llEmail( (string) llGetKey()+"@lsl.secondlife.com","Config",gConfig);

Please spare me from this awful hack! =D

[
Edit: I forgot to cast, thanks Adam =)
]

/me kicks dead horse

/me kicks dead horse

This horse IS dead. If thre is to be in-world persistant data, it won't be via writing to notecards. From what the Lindens, including Philip, have said, making notecards modifyable isn't feasable due to the way they are stored and retrieved.

They would have to completely re-write the way notecards are handled to make this work, so it would be easier to make some completely new system for storage that isn't such a hack.

I mean, storing data for script usage in notecards is great, but I'd prefer to keep the data in typecast list form instead of converting it all to text and back again whenever I want to change it.

I'd like to see a Data object type (like those of sounds, textures, or animations in 1.4) that you can move from object to object, copy, protect, refer to by key, and read/write VERY quickly. As Notecards are like text files, these would be like binary files. Random access is a must.

*punt*

I agree in general. Writable/editable notecards would be excellent.

- Zeke Murdock

Philip Linden himself said this will not be implemented. So drop it. Viva games, casinos, and dance clubs!

If permanent storage on Linden servers is something you want, ask for that. Don't ask for anything to do with writing to notecards, since that would actually be more work to implement properly.

Several people have asked for...
1. Notecard writing
2. MySQL access
3. Simplified database access
4. Any database access in-world

All have been met with a bit NO from Linden Labs.

This is indeed disappointing as persistent storage is what's holding back many objects from becoming less "props" and more independent pieces of software, if their only purpose is to just exist inside SL

They may argue that they dont want persistant storage but how is this any different from somebody keeping a blog in the form of notecards, a different notecard every day in their inventory. Or say outputting pieces of a 'game state' at intervals and copying it from history into my own notecard.
Its a black hole in the scripting API that must have slipped through I understand but if not notecards then I whole heartedly endorse another alternative besides XML-RPC if only for a form of caching that somebody here mentioned.

anyone have a log of what exactly the lindens said that made it unfeasible?

No, I don't have an idea. And now that this dead horse has been kicked up again I have realized that the function is already there, it has to be.

When, in my client, I do Inventory->New Note, edit note and press save, this exact function is requested of the server by my client. Why not expose this function to LSL?

As Donovan had noted we have to play "politburo watching" to get answers. My speculation is that they know that the asset server is a single-point bottleneck for the entire SL system, don't know how to farm its services out and fear that no matter how much manual creation of notecards happens, that script access to such could hit the asset server many times harder.

Just speculation folks, nothing to see here, move along.

Edit: for proper attribution of "politburo".

I agree. Some sort of method to create notecards on the fly would be excellent.