Phlox: a "simple" solution to pass values between scripts

[Yichard]

When we have complex objects with multiple scripts, often a script needs a value calculated in another script. The standard way to do is to use linked messages. However this is cumbersome, in more of disrupting the flow of the calculus. We need a simpler way to do so. This has been discussed in Inworldz, without a clear solution emerging.
I am now having one:
Adding dedicated slots in the prim properties. A prim is stored in the database as a set of values: size, taper, colors, texture names, etc. If we add some new dedicated fields to that, the trick is done. What we need is simply adding some script functions:
iwReadPrimMemory(Prim Number, name)
iwWritePrimMemory(Prim Number, name)
The code already exists, it is the same as writing or reading any other prim property:
LlSetObjectDesc("text");
LlGetObjectDesc("text");
The only difficulty I see is that we already have many prims without those fields. So that attempts by a script to read them should start some error, but in any case return a null value without interrupting the script.
But the object saving routine must detect the presence of these new fields, when they have appeared. This may be the most complicated. In a first step, just don't do that. The values would not be saved in inventory, but this is still better than no values at all.

Workaround: We can use existing prim properties, which are unused in our application. For instance use the 7th texture name to store a text. However this has inconveniences, mostly another user may start to use this prim property for its primary purpose, it will create errors in the script, very hard to figure out where they come from.

Special cases. The root prim may have more fields, dedicated to the whole object.
A mesh body may have additional fields like "gender" "species" etc.

[Misterblue]

There was a module added to OpenSimulator that does something similar. JSONStore module. The stored objects are not associated with a prim but has a separate namespace that is kept in the simulator and cleared when the simulator is restarted.

[Yichard]

Thanks for the suggestion @Misterblue , but this stops working if the object is a vehicle and it leaves the region. This is why I suggest the system to be borne by the prim, or by the object.
.
At a pinch, my workaround is much better than I though, if for instance we have a foo prim with 8 triangles only, each of a different material: we can store 8 strings (texture names), llSEt/GetColor can store 8 vectors, and so on. Although each of these params has its own caveats. I still leave this issue open, if ever somebody has some energy or idea to work on it.

[Misterblue]

That's a good point about keeping the information when region crossing. The solution that JSONStore provides is read/write to a notecard which uses an existing storage system for the prims.

[mdickson]

I traditionally provided this kind of thing via a web service accessible from the grid but seperate from it. There really is no need for the grid or the grid software to provide this capability. Its more a function of the application yout building. For me the key is used to lookup a dictionary of key/values and the keys are named. There was a simple mechanism to do a lookup and the data comes back in the http_response event.

[Yichard]

Thanks for your contributions, but both use events. The idea was not to use events, so that not to disturb the calculus flow. http is even worse from this point of view, since we add random Internet delays and packet losses. (the dataserver event is very fast actually, we can have several in only one time slot)
What I do already is using the description to store config data, in a way that the user can set. I read it using llGetLinkPrimitiveParams. This works well, save that we need to decode a key=values list. We can write too the same way.

Doing that way still have several issues:
-if the user modifies the description (or other prim param) he messes up the script, creating mysterious errors.
-Lack of "privacy" for some of the params
-Limited numbers of params and types (full list here https://wiki.secondlife.com/wiki/LlGetPrimitiveParams)

[mdickson]

You really can’t get away from the dataserver event for something that is a data lookup against some source (the data is persisted somewhere). Adding a synchronous access requirement to something that is potentially unbounded in time isn’t going to work. I can appreciate that it might seem easier for the scripter but the blocking needs to be addressed somewhere and you can’t realistically push it into the script engine. Storing the data as prim properties means it needs to be stored in the prim table and as asset data when the prim is picked up. And copied across region boundaries on a region crossing. Again not really feasible for an open ended list of key/value pairs. I can say that I would never implement a keystore this way. I think providing access to key/value data is an application problem. You’ve actually added a “realtime” component to it since one of your objections is that the web access is potentially too slow. If you really need to do real time access to a keystore then I think you might want to rethink your use cases and carry the data in variables in your script. From: Yichard Muni ***@***.***> Sent: Friday, October 7, 2022 3:53 AM To: HalcyonGrid/halcyon ***@***.***> Cc: Mike Dickson ***@***.***>; Comment ***@***.***> Subject: Re: [HalcyonGrid/halcyon] Phlox: a "simple" solution to pass values between scripts (Issue #140) Thanks for your contributions, but both use events. The idea was not to use events, so that not to disturb the calculus flow. http is even worse from this point of view, since we add random Internet delays and packet losses. (the dataserver event is very fast actually, we can have several in only one time slot) What I do already is using the description to store config data, in a way that the user can set. I read it using llGetLinkPrimitiveParams. This works well, save that we need to decode a key=values list. We can write too the same way. Doing that way still have several issues: -if the user modifies the description (or other prim param) he messes up the script, creating mysterious errors. -Lack of "privacy" for some of the params -Limited numbers of params and types (full list here https://wiki.secondlife.com/wiki/LlGetPrimitiveParams) — Reply to this email directly, view it on GitHub <#140 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAI3NMZZDUITBOH3UJLCR4TWB7JHRANCNFSM6AAAAAAQU7PXEY> . You are receiving this because you commented. <https://github.com/notifications/beacon/AAI3NMZXBPB2NHJACO74ARLWB7JHRA5CNFSM6AAAAAAQU7PXE2WGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSLYWRRQ.gif> Message ID: ***@***.*** ***@***.***> >

[Yichard]

Ok it always is interesting to discuss on something, as problems and workarounds may appear from the discussion, that we did not foresaw while opening an issue.
I would draw two conclusions:

1. we have a workaround, prim properties. Each property has its caveat, but the method is still workable, to store a few variables but important ones. For instance the color param allow to store and recover 8 vectors, even on inexistant faces (tested). But, as texture names are changed to UUID, the only way to store texts is with description and floating text, with some restrictions. We can see here which prim properties can be used: https://wiki.secondlife.com/wiki/LlGetPrimitiveParams

2. OK for not changing the prim storage structure just for that. But let us remember this possibility when we have a compelling reason to add new prim params in the asset storage (this may even come soon, for instance for animesh). We can take profit of such an occasion to add several prim params, for this purpose or for others (the "gender" field for instance)

For this reason, I recommend to leave this issue open, even if likely there is nothing more do discuss.

[Yichard]

For info, this functionality was just added in SL, with a series of functions, see https://wiki.secondlife.com/wiki/LlLinksetDataRead
Basically it runs for a linkset (an object). We can write, read, count, etc. name:values pairs, some protected, up to 64kilobytes.
There even is an event linkset_data( integer action, string name, string value ){ ; } if we need to know that a value was changed.
.
I think this replies to this issue, with the details that it is for linksets, not for prims, but we can do with that.
64k is even much more than I requested, we can even store key lists for interpolators.

[Yichard]

I finally close this issue, since SL implemented a better solution. So that whatever we do, we are compelled to do as SL, for compatibility.
I send to issue #141 which is a better solution.