Notecard creation?

Is it possible for an object to create a -new- notecard, or modify an existing one? I'm trying to script several objects that can identify users based on notecards. Basically, each user has a unique notecard that is created upon registration, or whatever. This notecard is given to the user, and to the object. The object sends an email with the notecard's unique identification, which all objects will receive, and update accordingly. How feasible is this, and if it isn't possible, are there any alternatives you can suggest?

It's only possible to read notecards, can't write to them since that would bog down the asset server.

A script can't create notecards. You could hold the data in memory and hope the script never crashes, have a debug command where it spits it out in chat/IM to the owner and then manually save it to notecards, email it to a script running on an off-world server which then saves it as a text file or into a database... those are some alternatives that come to mind.

You could make one script that only holds data and tranfer the data to that script via link messages or llSay

So, it sounds like, you can't create a script that would blank out a notecard, and then write data to it?

(What I'd like to do is have a blank notecard in an object, write some data to it, give it to someone, and then blank it out again).


Scott

No, you can't. A simple, easy search of the forums or the scriprint Wiki would also have come to this conclusion.

It just kind of shocked me, it seemed like a basic function that ought to be there.

Hmmm..... Back to the drawing board.

Hrm, one curiosity. If a script A puts information into another script B, and script B is given to another user, presumably it would retain all of it's data? If the object containing B has copy rights for the script, then it can give it out freely, and then reset it's own copy of script B, allowing it to place more data inside to give to the next user.

In this way it would also be possible to secure the data held inside as the script can be made no-mod, no-copy so the user who it is given to can do nothing to it or see how it works.

Then they can drop it back into the original object (doing so will make the script inactive so there is no exploit here). The object could then (having confirmed the script is genuine using creator id) activate the script, thereby making it's data available for retrieval.

In theory at least, I'm not certain if this would work, but it should as far as I can see.

Well, one problem is that when a script is dropped inside another object via CTRL-drag (ie by someone other than its owner) then scripts inside the object are not informed of this. Hopefully this will be fixed though as it's a bug! You can get around this by checking every so often, or having the user click the object after they've placed their script inside.

Actually for me, I just need the data in a text readable format, so this would work.

Hmm, so a silly beginner question, how does one create and write to a script? Or Alternatively, delete the contents of a script so you can replace it with something else?

Ah, sorry I think I'm misunderstanding then. The script would be unreadable, but it would contain the information. You said it was for identifying users, so do they need to be able to see what information is inside?

Basically you'd have two scripts, a controller script (that handles the giving out of registration scripts), and the registration script itself.
The registration script would have appropriate variables for storing the info it needs, like a string for example.

It would then have a link_message() event from which it can receive commands, so if the integer it is fed is zero then it will reset (just using llResetScript() is usually fine), otherwise it will take the string it is given and store it.

So, your controller script after generating your registration info, sends it to the registration script which stores it. The controller then gives the user a copy of this registration script (containing the info).
It will then reset it's OWN copy of the registration script back to zero, this will not affect the copy it gave out.

Basically rather than creating a script to give, you're changing the variables in an existing one, and giving - in effect - a personalised copy to the user.


If you could give a better idea of what you're trying to achieve though, there might be an easier way to do this. Are you trying to let people register for an event and then automatically greet registered avs when they arrive? How many avatars are you likely to be keeping track of? Things like this will help, as there may be an easier way.

a script cannot change inventory, it can only give inventory and delete it. It cannot modify it or create it.

Not entirely true, a script can give information to another script in it's inventory (via link messages), and then give this 'modified' script to the user.

Ehh... err... um... actually, when a copy of a script is given, it gets its own asset assigned I believe. So any postdata contained therein pretty much disappears into the ether.

Least... that's the way it's been in my experiences... ... .....

I agree with Jeffrey. Every time I've seen a script taken out of one object and put into another object, it essentially runs fresh. All variable data contained therein is cleared. It's about the same effect as hitting the reset button on a script or calling llResetScript();

Ok now your nit picking.

*puts on nit picking boots*

It's not the link message causing the change but the script itself, it's up to the script if it handles link messages or any other type of event. Meaning that it is the script that is modifying it self. If you are brave (and quick since mono is coming) you could make a script that rewrites its own bytecode. Yes thats right, since the entire script is contained in a 16k block you could make a script that writes to its own bytecode section (or your could jump the execution pointer to where the variables are stored, which ever).

Well if the script clears 'fresh' upon being given, could you modify it after it's been given, via talking in another channel? Does this resetting thing apply to rezzing an object as well?

Haravik I believe was responding to my original question of identifying users.

Wow! That sounds like Helmholtz. The Law of Conservation of Inventory; dig it

Hmm, well in that case you could give the user a registration box, perhaps a HUD attachment and then use llSay() to give it some information to store. Then if the user is wearing this HUD attachment (or otherwise places the object) it can respond to queries.

So in this case you'd have an object (HUD attachment or otherwise) which a user is given so that they may receive information. Once the user has rezzed or is wearing the object, they click your controller to register. Your HUD attachment will be listening for information on a channel, the channel on which the controller communicates. The controller then says some info at which point the HUD attachment stores it and stops listening for information (to avoid it being over-written).

Then when you go to the event and need to be identified, you just click on your HUD attachment which will send a message via chat which your object(s) can detect and use to identify the avatar as being valid.

Does that make sense? In this way you can have the information 'readable' by giving the HUD attachment a button which causes it to speak the information. For example using llOwnerSay() to keep it private.

I've actually already begun using an object as identification, but i didn't think of having it store unique 'user info' as well. I guess i'll do some tests and figure out the limitations to storing information in scripts and such. If each user were to have his/her information stored in a reliable/secure manner then the whole need for an external database would disappear.

If you want to store unique user info in an object you might be able to use llSetObjectName and llSetObjectDesc to store the info, if the object is to be used only for storing information you could even encode information with llSetPrimitiveParams.

heh using the parameters of a prim to store variables is pretty creative. But by suggesting that are you saying the variables might not hold in the script?

Well at least if you give the object to another person, you can make sure the variables aren't reset if you make the script read them from the prims decription, name and parameters

Hmm, although it would depend on what you want to store. If you want to store a long string or a list of strings then a script would do best.
Unless you have llResetScript() commands in odd places, or are dealing with large and complicated data sets, the script is perfectly dependable.