llWriteNotecard, llWriteNotecardLine

I want to see a way for a script to do these things....

1) Create a new notecard in objects inventory,
2) Save data to the notecard

If this is done, it should allow storage of more data, without taxing memory.

Also, for private communication, an object could write something in a notecard, and send it to another item, which would read it, and do whatever it needs too. Not as easy to hack as standard listeners, and not so dependent on XML-RPC/Email

Should also be a way to add lines to exsisting notecards, as well as clear whipe them clean to start over.

This has been turned down numberous times as a notecard is an asset on the asset server and LL doesn't want scripts to be able to create assets. That and I read somewhere that editing a notecard in truth creates a NEW one instead of overwriting existing data. Hence, giving a script a blank notecard to work on is the same as allowing it to create notecards.

You know what? Somebody suggested it elsewhere, but we should just have databases. Notecards are a horribly clumsy way of reading and storing data anyway; they're only useful for having user-configurable commands for scripts.

Say, every user has a certain amount of space for tables (and perhaps you could buy more - another sink or income source for LL, hint hint) and they were accessible via SQL, or a subset.

I know it's not sexy but it would be bloody useful, rather than having to have your own server somewhere and issue requests to it. That's all very well for projects of your own but you can't sell things like that without also selling server space or having to customise the scripts.

Note cards, IMO, are actually very useful for storing data if you're storing massive amounts of information that you won't need to look up any time soon. Example: Lottery Tickets (the keys of the people who purchased). You list them in order of purchase and read either all of them one by one, or read one line randomly (i.e. llGetNotecardline(Floor(llFrand(llGetNumberOfNotecardLines())) + 1); then extract the UUID in the dataserver event).

Other uses cover large amounts of data (mostly for games) and being able to print out customized notecards as info. For example, in a Lottery I run, it works like PowerBall, you choose 3 numbers and a PowerBall number. If I were able to print out notecards to give them to people that had the numbers they chose on it, I'd have a lot less trouble if something goes wrong, like accidentally causing a heap overflow BEFORE I was emailed the tickets for my records.

Agreed, and this has been mentioned many tiems just on the first few new features pages.

AND

If we gave people the ability to edit objects on the main asset server, someone would get the 'bright idea' to make a script bomb to send a few thousand requests a second via multiple scripts running link message sync to get around any sleep penalty for the purpose of crashing the asset server.

Its bad enough when idiots try to take out a sim, if they could take out the asset server the whole grid would be screwed fast. No we do not want this. If you want persistant storage use scripts in the same object that function as database lookups. Use strided lists in a server scripts set to work as memory modules all using link_message communication to a master controlling script.

Link messages dont have a sleep penalty and resolve very quickly. And if you get low on memory you just add another copy of your memory module script and let some auto negotiation get it linked up to the manager script for use. Each script has a 16kb memory extension and there is no limit to the scripts put into a single object.

And as i mentioned just THIS WEEK in another thread asking this same feature you can also let your object send emails to itself. With subject lines specially formatted with a key to what data is in the email so that you can filter which email to grab based on data desired.

All these options dont open up yet another form of grid attack. They all require some basic level of understanding of scripts thus are above the reach of the ignorant masses who would 'accidentally' break things with the methods. Granting notecard writing or just editing privledges to the masses would be granting too much power to people with no clue what they were doing. We already have to many lame scripts running idiotic sensor or timer frequencies and channel zero listeners. We dont need more methods for people with no sense of effeciency or responsibility to break stuff.

Did I mention how many 16 KB scripts it'd take me to keep track of ALL the lotto tickets I intend to be selling?
No?
Fifty-Two
And that's assuming I don't sell *more* AND that the script contains no data itself.
Which is why I opted to email the tickets to myself, copy the data, and paste it to a notecard that then later gets read one line at a time, laborously until it finishes.

You can still store that in a proper database though. An import function would be simplicity itself if someone wanted to paste records in from somewhere else. There's no advantage to notecards in themselves, they're just inefficient flat files.

I'm far too lazy to C&P data from emails on a regular basis, myself. If I was doing what you're doing now I'd use an external server, but if you can keep things to SL, having a database would be much easier.

If we had any kind of in-World script storage, I'm all for it. As long as I don't need to figure out complicated scrits and/or fuctions to be able to access one piece of data (I know SQL is hell like that, I had to write a database look up function and it was a final project, I and my partner were one of three groups that turned in ANYTHING and ours didn't work).
As for off-world stuff, the existing RPC whatever it is requires that I code MY OWN server cgi scritp (no way in hell I'm doing that) and the HTTP Request is looking the same way. I want a one like function that grabs a piece of data. There can be more elaborate things to grab more data of different kinds, but I want SIMPLE as well. cout (C++ keyword to print to the screen, C OUT as in C++ OUTput) worked very well. You could even--in about 4 lines--code for fout (File OUT). I'd like something similar with my LSL scripts.

Draco:

How about if your memory manager (perma rez in world) when it was running out of 16kb memory scripts it could send a request to a server that would just GIVE it another copy as needed. Again if the scripts for the memory management were well written you could ACCESS any data with just a few lines of code. And if the new script on arriving did some automatic integration so that it was effectively the next page of data you would be good. Then you wouldnt need to worry about the number of scripts cause it would be automated and all YOU would have to worry about is the interface for it.

Im out of town visiting family but will return wednesday if you want to find me in-world and we could talk about it then. Id like to discuss in person what data you are currently storing and if there are any methods of reducing that requirement. Im fairly good with script effeciency.

Btw Jess. Hope you dont take any of the various critiques here negatively. The problem you're trying to solve is very real and does need dealt with. Just theres many reasons that it should not be specifically solved using notecards. Thats all.

Then someone please suggest to the Lindens an alternative way TO store info. The reason people mention notecards is because it seems like the easiest method to modify to achieve the needed function. If not notecards, then Lindens need to do something else to fix the problem. As I posted in another thread, "So far, the artificial methods of storing data (such as storing it in an object that emails the owner and resets its data every so many hours) is poor and inefficient."

A propostion: generalized file objects, like in a filesystem:
four new functions and four constants:

FILE_TRUNC, FILE_APPEND, FILE_BIN, FILE_ASCII
llFileReadLine(filename) // infers FILE_ASCII
llFileWriteLine(filename) // infers FILE_ASCII | FILE_APPEND
llFileRead(filename, mode)
llFileWrite(filename, mode)

Changing prim properties doesn't create a new object, doesn't cause a new key to be issued, doesn't bother the asset server, isn't even time-restricted at all...

I don't see why notecards are so different, except that they obviously can't contain scripts and therefore can't function the same way as prims when it comes to delivering data...


But even if something like this is a long time in coming (or never shows up) in SL, there's always HTTP requests. If you know Perl, or Python, or any other CGI-able language, it's pretty painless to find a free host... and if your scripts are so data-hungry and popular that a free host can't handle it, well I should hope that business is granting you enough to afford the overhead of a cheap paid host. ^~

--

>>> import this_

sl wasn't designed to use large scale database made of prims scripts or whatever, so i suggest too to use an external database, itsnot that expensive to rent a php host these days, but please don't clutter SL with this kind of things

I've tried a similar thing - I don't think you can do that. The problem is, the server can't rename the script, and if an object gives another object a clone of an item that already exists in that object's inventory, then it's overwritten, not uniquified.

Is this a repeat thread?

Draco: why don't you offer some money for someone to implement a server like this for you?

You'd need to offer RL money, of course... and contract programming rates are a good deal more than you're going to want to convert to Linden Dollars.

I could have, but at the time I didn't have the cash and 2, everything works hunky dory right now so I don't care.

Oh, nice. I'll keep that in mind for if I ever feel like revamping my unused lotto service (come on people, L$2 for a ticket! Buy them!)