Jump to content

Suggestions of mine ( LSL related )


Krade DimondAK
 Share

You are about to reply to a thread that has been inactive for 4070 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

OK now that ive already posted this in the wrong area once before, but thisplace looks more suited, the other froo froo sub-forums under Creation Forum scared me away.  

What I want to start a thread about inner script data sharing via notecard-like data. 

I know notecards cannot be edited internally by script because every edit to the card is a UUID change. I don't suggest changing notecards at all, I want to see some way to read and wright variables on a transferable, copyable, script friendly inventory item. Much like a memory card. ill just call it an mcard for now.

These are just a few functions I can think of.

llUseStoredVariable(string mcard, string entryName) uses the entryName out of the mcard specified as a variable in script. All changes made to the variable in script is also changed in its respective mcard and any other script also using the same entryName value.

         llUseStoredVariable(string my_mcard, string copiesmade); is the same as. integer copiesmade; 

llColectStoredVariablestring mcard, string entryName ) Similar to the above, but only gets entryName at its current state. 

llWrightStoredVariable(string mcard, string entryName,  integer newInt, vector newvec, rotation newrot string newstr id newkey) Replaces said entryName value. 

 

I would love to hear your input on my idea, and other suggestions about how to get this idea seen.

Link to comment
Share on other sites

In the past, I have offloaded and/or shared data by using several different methods (depending on my needs):

  1. an external HTTP server that is called by the LSL scripts to load/save information
  2. a "helper script" that really just stores name,value pairs in a list data type and communicates via link message
  3. a prim "server" that stores data the same as #2 but communicates via HTTP and email. HTTP is used for get/store while email is used to find the HTTP server url (which changes whenever the lindens feel the need to restart the region that my "mainframe" sits on.

I've found that a mono script can store approximately 200 items in a list without running into memory issues. Of course, I use small amounts of storage. With a maximum of 64K, taking into account pass-by-value and overhead for the logic, I figure I've got around 20K of storage per LSL script in my "mainframe".

Link to comment
Share on other sites


I want to see some way to read and wright variables on a transferable, copyable, script friendly inventory item.

Interesting combination of attributes. It's more viable, I think, for not including the abiity to change the asset except by script... and that makes the suggestion of in-world (or external) data services seem a reasonable substitute for what you're asking--except that you want it to be a transferable, copyable inventory item. Is that intended to leverage familiar SL permissions as a means of authorizing access to specific data elements? (I can see some value in that.)


All changes made to the variable in script is also changed in its respective mcard and any other script also using the same entryName value.

This part, if I understand it, sounds almost like distributed shared memory, which introduces all kinds of trouble for maintaining consistency. I'm hoping that's not really important because it's "hard" in ways that have nothing to do with difficulty of implementation.

Otherwise, the request seems to be for a common data store, as can be supplied from an in-world or external http server, as already suggested.

It would be an interesting project to define the minimal script -- an existing transferable, copyable inventory item -- to mediate the desired data storage functions, with secure authorization, to a served data store.

Link to comment
Share on other sites

I don't see in which way your mcard differs from a notecard. Seems to me your suggested methods would be just  wrappers for writing to a notecard. Writing to a notecard is entirely implementable, uuid change or not (after all, an object changes it uuid as well on each rez) but I doubt LL would do it in near or not so near future.

Link to comment
Share on other sites

I never got why the uuid change is a problem, there are already objects rezzing a lot of temporary objects each with their own uuid all the time. Bullets from guns for example.

Also, maybe I'm totally missing something but, even if it's a problem, why not adding a limit to how often a notecard can be edited, or making the script sleep for a second or 2 after editing a notecard?

It could be a useful feature if it was implemented.

Link to comment
Share on other sites

One basic problem is spam.  If LSL scripts could create notecards, it would be much easier than it is now for griefers to generate thousands of them at a time and spew them at us.  This would be junk mail at the max.  Spam notecards could be tailored to each recipient, so you'd have personalized junk mail.  Imagine the load on a sim's servers, and the additional lag. LL could throttle the production rate the way that IM production is throttled, but there are always ways to get around throttles.Once the door is opened, we're into the land of unintended consequences.

Link to comment
Share on other sites

I can understand that, but I didn't mean creating new notecards, just editing a notecard that would already be in the object contents, so it wouldn't be any different than it is now in terms of griefing, or would it?

Also I was kinda hoping there are better ways to deal with griefers than just renouncing to add new features...

Link to comment
Share on other sites

Oh, I see.  Yes, that's different, and I can't see a griefer problem there. It would be lovely to be able to do that.  The real problem is that the objects that are in your own inventory or the contents of another object aren't really "there". They don't exist and thus can't be edited until they are rezzed in world.  Until then, they are simply entires in a lookup table in the servers, analogous to a table of contents.  For security reasons, I'm fairly sure that LL doesn't want us messing around and editing things in the servers themselves.

Changes in complex systems often have unintended consequences.  Depending on who you listen to and what day it is, Linden Lab either introduces new features and LSL functions too slowly -- as in "I wanted that feature yesterday!" --- or too fast.  Unfortunately, many people would agree that "too fast" has been the norm for a long time.  It's hard to keep track of all the innovations like V2, Direct Delivery, Pathfinding, and llTeleportAgent that were released before they were ready.

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 4070 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...