llWrite2Notecard()

Here's why I think we need a function for writing to notecards, in fact here's a list:

1. Games. I think users would be able to create a lot more in-depth games if a script could permanently write to a notecard. You could have continuous games in world, recording stats, quests, etc. to a notecard that might not be as reliable just storing them in a variable.

2. Databases. I, personally, would be a lot happier working on creating an in-world SQL variant if I could write to notecards. I wouldn't have to update tables by hand. I wouldn't have to manually delete records. It would make it a lot easier to write inventory programs, mapping programs, etc.

3a. AI. It would be a lot wasier to develop in-world AI if they could write to files. You wouldn't have to reteach the (hypothetical) AI everytime you reset it or the sim crashed.

3b. It would allow people people, in-world, to contour some SL Basic classes to the needs of newbies. Imagine if a newbie could talk to a parrot, ask it basic question, and the parrot would record that. The owner could check the messages, and answer those at a class. (For the record, I am vehemently against bots replacing real people as teachers, but I like the idea of a clearly non-av bot being able to collect useful data for a teacher.)

4. Blogs and forums. I would love to have an in-world blog or an in-world forum, the latter would be especially great when the new games take off. Imagine being able to leave hints and clues to the people who follow you.

5. Friendster. This may be re-iterating the database thing, but having a Friendster-like system in-world, one tied to some kind of landmark database would be great. Say you're in-world, working on something, but need help; you could check the list, see how many degrees you were from an expert, and then see if they were on.

6. Reducing the use of Lindens' emailer. I have seen a couple of people say that they use llEmail() to save information, but their system could be replaced if they had an llWrite2Notecard() function. (This may not be a particularly persuasive reason, but it's a reason.)

Those are my ideas as to why I'd like llWrite2Notecard. Anyone else is free to add their own. I'm just of the opinion, that with Linden Lab trying to create some in-world games, that being able to have a "hardcopy" of data will be very, very important to the in-coming developers.

If I can benefit from something developers can benefit from, while trying to help the Lindens benefit from new games, I'm all for getting what i want out of the deal.

Although llSetNotecardLine was talked about as far back as the middle of last year, it's my understanding that the feature is on hold indefinitely.

This thread talks about an I/O system to allow LSL scripts to communicate with computers outside SL. There obviously is a lot more you could do with I/O than with llSetNotecardLine, which is why I'm more interested in seeing I/O worked on first.

Besides, I would imagine that if anything, XML-RPC or SOAP I/O would be easier to implement because of how (I think) SL handles assets. I could, of course, be completely wrong, though I still feel the cost:benefit ratio would be worth it for the Lindens.

One thing's for certain: for all the reasons you've mentioned, we need some kind of permanent data storage, either using notecards or a proper database off-server.

While I agree that I/O provides a workaround to persistent storage, I don't think we should have to rely on it.

The extra dependencies required to set up an entire storage system on a remote computer accessed by XML-RPC is far less elegant than just providing a simple local storage system.

For example, what will the less technically-inclined scripters do?

Take perhaps someone who may be becoming proficient in LSL, but does not have the time or resources to learn how to set up a website + database + middle layer system just so he can persistently save his "top 10 scores" list for a simple game he wrote.

I think the hardcore among us will be able to tackle the dependencies involved in creating external persistent storage, but we will most likely be a minority among those who dabble in scripting. Perhaps some of us may even be generous enough to lend external storage to others once we've set up a system, but it is still a very inelegant solution to a simple problem.

Not only will notecard writing be more elegant for simple storage problems, but it will be more reliable and probably faster. Keep in mind that servers on the internet are always going down, rebooting, under maintenance, getting disconnected, being attacked, etc.

If you are completely dependent upon external storage for your system to work correctly, you'll have to have contingencies for when the XML-RPC gateway can't make a connection to your host. Will your system be blocked until it can make that connection, or will you just drop the data and continue to serve resident requests? Where will you store your data until the connection can be made? Wouldn't it be nice to be able to queue it up inside a notecard before it's sent out, as a contingency for network problems?

By all means, I hope they implement I/O first, but I hope that doesn't mean they discard the idea of a local notecard storage. Notecard storage will be much simpler and more reliable. Even with network I/O the ability to write to notecards will still fill an important role.

i agree with kex's point that new and moderate scripters will generally be more capable and comfortable with an inworld solution. i also agree with catherine that external databasing would be dreamy for professional programmers;

but simple notecard storage (appending strings on a new line) would provide a fast, reliable method of storing data inworld;

and backup notecards could be automatically produced and given to a supplemental storage object.

data can be emailed to an external source currently and copy/pasted back into a notecard if the inworld version is lost or corrupted. the only problem is getting the data into the notecard to begin with.

i fail to understand how implementing a notecard write from an object is so terribly difficult to implement. somebody explain it to me please. i have the impression that it's something the lindens just don't want to do for some reason.

i do understand that external, non-client I/O sockets and interfaces will be a real bear to tackle.

I think that every time you save a notecard it gets a new key, evey time you drag it onto an object (into the objects inventory) it gets a new key, every time you give one to someone theirs has a new key.

Notecards are actually I think the least persistant 'object' type in SL. And that may be a problem. It may be easier, and better, to create a new object type called a datastore - an 'inventory only' type object like a script or notecard. One with perhaps more features than we could tack onto a notecard? I'm not entirely sure how it would work. <shrug>. More like a database I would imagine.

Earlier this week i had the idea of creating a guestbook script. I talked to Kex and i found out someone made one that linked to their website, but I find it would be much easier just send a notecard, or two or however many pages there were.

I would like to see this function implemented as well.

I would prefer I/O. Just think, with an I/O system, you could implement your own object-to-object IM by relaying data through your computer.
Screw notecards, I have Oracle 9i and I know how to use it =)
The less technically inclined scripters can just ask their betters for help. Collaboration is (or used to be) the whole point of SL.

The less technically inclined scripters can just ask their betters for help.

If you are completely dependent upon external storage for your system to work correctly, you'll have to have contingencies for when the XML-RPC gateway can't make a connection to your host. Will your system be blocked until it can make that connection, or will you just drop the data and continue to serve resident requests? Where will you store your data until the connection can be made? Wouldn't it be nice to be able to queue it up inside a notecard before it's sent out, as a contingency for network problems?

Are we getting object to object IM or llWriteNotecard in 1.3 or are we just getting the ability to make our land EXTRA flat?

Object-to-object IM and llSetNotecardLine have both been discussed at great length, but so far as I know, neither are being worked on currently, likely because of the problem with the keys. You have to figure out what the key of the object you want to talk to is, etc. The easiest way, of course, would just to have ONE object whose key was hardcoded (or in a notecard.) in all the other objects, and they'd just "dial home" on_rez to get the keys of all the other objects in the list.

As I understand it, though, it's much easier to READ a notecard than it is to reliably write to it. In fact, as Ama said, I think by writing to it, you change its key? It's a Heisenberg thing.

In fact, because of keys, it may actually be easier for the Lindens to implement I/O. I know I keep coming back to that, but it just seems to me that if the problem is with keys, the easy solution would be to get rid of the need for keys.

In the long term, object IM reception and notecard writing are obvious wishlist items for a LOT of people, but for now, I say we focus on asking for the solution that's easier to implement, more powerful, and ultimately, benefits the Lindens more. (Games like Civilization, for example, are simple to design, but run so incredibly slowly that it's not worth it now. The solution: just keep all the calculation done out of world and use LSL as an I/O device.)

if the keys do change every time you write to a card, then i agree with ama that a new data type is needed which will retain it's key when written to.

it can exist only in inventory, but it will need to be passable from one object to another. if data objects can be copied to another inventory set, a new key will have to be assigned to the copy. if the object is transferable only, it can retain it's key throughout a small db system.

what would be really nice is if they'd set up an sql server and let us build small databases per av. they could charge a weekly linden fee for objects to be able to access the tables. oh, but then we'd have to set table permissions and they wouldn't ever work right would they. never mind.