Time to update 'Things you can't do in LSL' ?

Hi Guys,

Is it time that the sticky entitled 'Things you can't do in LSL' was revised? One or two just need clarifying a little, but one or two maybe just wrong.

The ones I noticed were these:


Place a script into anything other than a prim object (such as a piece of non-prim clothing).
(You can embed a script into a Notecard)

Create, or write to, notecards.
(Notecard givers create notecards, each one having its own unique UUID)

Find out the name of a group.
(of course, we all know that this NOW can be done via the new Search facility)

Store an unlimited amount of anything.
(Of course, nothing in this world is 'unlimited', but with LSL I can store data up to the capacity of my harddrives)


Rock

1.. technicality. The script is dormant in a notecard. Dropping a script into a notecard does not "script" the notecard. (note, this also can not be done with LSL)

2. Incorrect. As much as you are looking for technicalities, you really need to thik about what "create" means. In fact what is happening at BEST, is that the script is "copyiing" a notecard. It can not actually generate a NEW notecard, with new data. "creating a new notecard, or writing to, or otherwise editing data in an existing notecard" is what was implied.

3. This is still technically correct, as LSL ALONE can not get the name of the group, and the abilities of search are still very beta at LL's own acknowledgement. I would be willing to support the amending of this statement in the list, PROVIDED you (or someone) posted instructions HOW to do it, to the script library or wiki.

4. again, read the words: STORE an UNLIMITED amount USING LSL. a script can not store an unlimited amount of strings, numbers, or even the value iof an integer! (it taps out at, what, 2billion?) STORING in LSL is the action being stated here, not the ability to store an unlimited number of files on your HD, or on a webserver. The statement specifically refers to what CAN BE DONE WITH LSL.

The sticky does not mention anything about whether the script is dormant or not, only the bald statement that a script CANNOT be put into anything other than a prim object. This is precisely what I mean about clarity.



No, I think you are incorrect. The creation of a blank new Notecard is always a case of copy, from a blank template. You speak of new data, but that refers to the writing to a notecard part, which I agree cannot be done. But create can. You can put a blank notecard into a prim and a notecard giver script and create as many new, blank notecards as you wish, each with its own unique UUID (surely the very definition of something being created, which was not there before).



Instructions have already been posted in this forum and elsewhere on how to do this, using LSL.



I disagree, the statement makes no reference to WHERE the data can or cannot be stored at all. You believe it implies that the data is stored within variables within a script, but this is not clear at all. By using LSL I can store huge amounts of data, without storing it within a script, or a prim's description field, or many of the other workarounds that people have come up with. To store these huge amounts of data I simply use the llSay, llOwnerSay, and llInstantmessage commands (all LSL commands) to accomplish the storage. That, I would argue, IS USING LSL to store an 'UNLIMITED' amount of data (and I do it).



Rock

technically true, but it doesn't change the only prims may have ACTIVE scripts... I could paste my code on a tshirt and then it'd be in my clothes by the same logic.... but it isn't going to do anything.


I'm with winter on that one, it's just a copy.


still can't be done yet strictly with lsl... because new search http reseults seem to be blocked from within SL... requiring another server to parse the message... you could add the caveat that it's possible with a server to parse the search info. (just like I added one for hard coding it's own group name, same would apply to compiled lists of group names vs functions that return the key)


nice try, but that requires an outside server, and the intent for that statemnt is 'within lsl'... but if you want to add it as a workaround, I'm not against it.

and while we're at it, lets add some
Get the current audio stream address for a parcel.
Set/Get 'buy' status or price.
create vehicles with more than 32 prims (or is it 31?) (there are workarounds)
get/set the 'glow' prim parameter
prevent scripts from being removed from no-mod objects (there are methods to replace... that don't work on no script land)
change the axis on which particles are emitted (workarounds available)

just to name a few...

EDIT:
if you ever find something unclear, you can always post a clarification... it's not a locked sticky.

Hi Void, Winter,

Just on the issue of notecards, and whether they can be created or not using LSL.

I am not convinced by the 'it's just a copy' argument, as to my mind almost everything created with the creation tools in SL is just a copy of something somewhere on a server in template format, so please bear with me on this one.

I think that you would concede that when you go into your inventory and use the Create, New Note, function, what you do is CREATE a notecard. Correct me if I am wrong.

Now think of it this way:

1. Go into your inventory and create 5 new notecards, all blank.

They all then sit in your inventory, with the name, New Note, and contain nothing, and each has a unique UUID.

2. Now, put a blank notecard named New Note into a prim's content folder, and a notecard giver script, on touch. Click it five times and accept. What you will then see will be 5 new notecards.

They all then sit in your inventory, with the name, New Note, and contain nothing, and each has a unique UUID.


This is EXACTLY the same outcome as step 1.

Isn't it??

Rock

heh, but then by your logic, we don't really create new note cards we make copies of blank ones =)

it comes down to your definitions of 'creation', and 'new'.

after all you can 'create' a 'copy'.

now my position in this instance, is that creation requires making something new, AND unique. and a notecard having a new uuid doesn't qualify it as unique, but rather as being seperated from it's original.... it's just a reference used to differentiate permissions, and the possibility for it to BECOME unique (by one or another being changed), and therefore 'new'. similar to copying a file on your hard drive, all the data is the same, unchanged from the original, just with a differing address, which is what a uuid is in this case. to further illustrate the point the notecard (like a copied file) will have the same creation date.

now when you think about it, the only difference between a new blank file and a copy of a new blank file is the creation date. it takes a change at the time of creation to make it new, as opposed to a copy... no change = copy.

but that's just my opinion.

We know very well what the intent of "creating and writing to notecards" is though. The idea is that someone wants to dynamically write content for users and/or for script data storage. When a new user asks about creating a notecard from LSL, this is what they mean. This is still not possible without some major hacks (custom client) that are not available to the average scripter. So the answer is still a big, clear, resounding, "No. You can't."

Besides, no, it's not true that you create a new distinct notecard every time you hand out a copy. You'll notice those, in fact, all have the SAME UUID. It is when you open the notecard up in the viewer, change its contents and hit save that it generates a new asset in the asset servers with its own UUID. That--NOT when you create a "new notecard" from your inventory context menu--is, in fact, when a new notecard is created.

Exactly. Can scripts create landmarks, or clothes? They can create new instances of them with different UUIDs certainly, but saying that would just confuse anyone who actually needed to ask the question in the first place.

"Create" has a different connotation when it comes to actually _rezzing_ things I would say, though in fact, it would be clearer to say that scripts can't actually create anything at all, they can just copy things from their inventory that they already have. I was just answering a question on this subject, actually, one which comes up quite often - the "can my script give somebody a customised version of something in the object inventory?" to which the answer is "no, you'd have to customise it after the fact, once it was rezzed".

Storage implies the ability to retrieve the data. What's your proposal there? And how many residents do you think want to stand around getting SPAM that is simply written to their harddrive? How many do you think can remain logged in 24/7 to be at the mercy of their scripts' whims? This is not a solution. It is still not a problem for which there is a clear answer.

You're here arguing the literal interpretation of a word or two. This is not a useful discussion.

As for the other points:

Perhaps it would be worth a footnote saying that you can attach a non-functioning script to a notecard, but that it won't affect the notecard.

This is worth adding as a workaround.

Not _within_ LSL, even less so than the group name part, but pointing people towards relevant resources to enable them to work out how to store data off-world would be useful.

I think the thread in question should just point to a wiki page anyway to be quite honest.

Folks,

You're arguing precise technical semantics in that notoriously imprecise, ambiguous language known as English. It doesn't matter who's right or wrong, what matters is wording things so that novices reading the text won't infer the wrong conclusions.

I suggest:

1. Run a script from anything other than a prim object. For example, you cannot put a script into non-prim clothing, let alone run it. (You can put a copy of a script into a notecard, but it cannot be executed from there.)

2. Change the contents of a notecard. In particular, you cannot create a notecard from scratch, generating its contents on the fly. You can, in a limited sense, create an exact copy of an existing notecard by giving the copy away.

(3. Omitted, as I'm not up on using search to find group names.)

4. Store more than a modest amount of data for subsequent retrieval within LSL, without using some mechanism outside of LSL (such as an external server).

Hi folks,

I've updated the top post of the sticky. Thanks for your updates!

name 2 key for groups (may not be reliable 100%)
http://secondlife.com/app/search/search.php?site=Groups&q=allintitle:Exact Group Name

key to name for groups (reliable)
http://world.secondlife.com/group/<uuid>

both need to be parsed as they are xml web page returns and don't seem to be accessible directly from within SL



for residents it would be (not 100%, haven't figured out what stops it on some names)
http://secondlife.com/app/search/search.php?site=People&q=Avatar Name
(note that just the name will return blank profile that allintitle: won't)

key2name that is not subject to the av having been on the sim
http://world.secondlife.com/resident/<uuid>
(good alternate to request agent data, since it doesn't quietly fail on group keys)

Yeah but technically....wait...oops sorry I almost got involved in this stpid conversation. Never mind

ZOMG UR ALL WRONG!
-----
Does it work now?

I have marked these as not reliable on the sticky thread, because there's no clear evidence of such. Linden Labs have not given us permission to access the world server directly, and the specification of llHTTPRequest states that:



Thus, that it works for world.secondlife.com is presumably a bug and this is a bug exploit.

if by 'access directly' you mean from within lsl, then I'm apt to agree... there reason that the world address can be accessed (while search cannot) is because the world address is being hosted separately (by amazon IIRC). it's unlikely they'll go out of their way to block this.

but there's a deeper reliability issue, since without checking all instances, reliability isn't guaranteed (I guess I should have said as far as I know), in the case of Avatar name2Key lookups I can guarantee it's not reliable, as I know at least one user who's profile is not blocked, that cannot be retrieved via search, but does show up in the direct key to name search.

I only mentioned them here because someone asked about them, and because they are workarounds for inworld problems. (key2name for av's being the weakest, but still viable since it a least returns a not found result when fed a group key, unlike agent info, in the case of group owned objects