Motivation

By now, a script can access to invenory or set pin of the prim the script is installed into. As consequence you have either to keep all inventory in one prim of your build, or when you want organize the inventory by prims keeping it, you need to have a script in each prims of the build. This increases the number of needed scripts.

Furthermore, when your build has multiple prims with installed scripts and you want to update them, every of that prims has to have a script that sets the negotiated pin in order the updater can replace running scripts in that prims. This means all that scripts have to implement the same piece of code (setting the pin by link or chat command.)

Feature in Request

Since we have already a few functions that change external propperties of other prims in linkset, like llLinkParticleSystem or llSetLinkPrimitiveParams, I'd suggest to extend this list by functions accessing the prim inventory and the script pin too.

Inventory access

For external access to the prim inventory we'd need these functions:

• string llGetLinkInventoryName( integer link, integer type, integer number );

• integer llGetLinkInventoryType( integer link, string name );

• integer llGetLinkInventoryNumber( integer link, integer type );

• integer llGetLinkInventoryPermMask( integer link, string item, integer category );

• key llGetLinkInventoryKey( integer link, string name );

• key llGetLinkInventoryCreator( integer link, string item );

  The functions behave like their counterparts without "Link" in name but access the prim specified in the link parameter. Because we access the prims of the same linkset, there are no security concerns. The functions just save up installing a script in that prim and requesting the data via linked message.

  The question is, if link should specify a single prim like by positive number or LINK_ROOT, or it is allowed to specify multiple prims like via LINK_SET. Giving a linkset here could have the benefit of having access to the inventory of all prims at once as if it was the inventory of a single prim.

  However, it could produce non-deterministical results, when for example multiple prims have inventory with the same name. In this case, when multiple prims are meant, only the prim with lower link number could be used.

  Additional inventory access

  Additionally for installers, inventory givers and other applications we would need these functions

• llAllowLinkInventoryDrop( integer link, integer add );

• llGiveLinkInventory( integer link, key destination, string inventory );

• llGiveLinkInventoryList( integer link, key target, string folder, list inventory );

• llRemoveLinkInventory( integer link, string item );

• llSetLinkScriptState( integer link, string name, integer running );

• integer llGetLinkScriptState( integer link, string script );

• llResetLinkOtherScript( integer link, string name );

• llRequestLinkInventoryData( integer link, string name );

• key llGetNumberOfNotecardLines( integer link, string name );

• key llGetNotecardLine( integer link, string name, integer line );

  The functions also work on the prim specified by the link parameter, instead of the prim itself, i.e. the call of llGiveLinkInventory with LINK_THIS behaves like the call of llGiveInventory.

  The reason to give such a comprehensive list of functions is that we can only avoid installing of help scripts in other prims, when every script function dealing with the content of the same prim has a counterpart dealing with the content of another prim in linkset.

  Script installation

  To install a running script into a prim we have the function llRemoteLoadScriptPin which requires the target prim to have a pin set. However we can by now only set the pin by a script installed into the prim, for example by a script being replaced due installation.

  As stated above, this leads to have dublicated code setting the pin in case of updating a linkset. Also it is not possible to upgrade the build by installing runing scripts into prims that have no script yet and that were not prepared by a script having set the pin prevously. This function would help here:

• llSetLinkRemoteScriptAccessPin( integer link, integer pin );

  It works the same as llSetRemoteScriptAccessPin does but sets the pin to a different prim in linkset or to all prims when called with LINK_SET.

  However, security concerns could trigger here, stating that this way we could produce a back door because we can override the pin by a trojan script. To avoid this we could follow the idea widelly used for password change: To change the password, we have to enter the old password. In this case the function would be this:

• llSetLinkRemoteScriptAccessPin( integer link, integer pin, integer curr_pin );

  The pin is only changed, when curr_pin provides the pin set to the prim currently and fails sillently when it doesn't.

  Applications

  The feature allows a range of applications. I can give three of them i had in mind as i posted the issue.

1. Reduction of the number of scripts: When all actions that a script can do inside the same prim, the script can do inside the other prims, than you can have a single script working on the entire linkset.
2. Comfortable update / upgrade. Today you have to prepare your build when you plan to update it later. Especially updating your build by running scripts will fail when you not had set the pin to the prims prevously. After this feature you can release your build first and much later an update, which will stil work even if you not have prepared the build (properly).
3. Inventory organizer. Since you can not have folders in the prim inventory, you stil can organize it by sharing upon prims and you stil can have a single prim working with the shared inventory.
4. Tagging of prims via prim inventory. Sometimes you need to tag your prims so a script can find the prim. For example by giving it a special name or description. This will fail, when the build rins a script system that expects different name or description of the prims. With this feature you can put e.g. a specially named notecard into the prims and your script will find the prims just by checking their content.

Links

Related

• [BUG-230784] [Feature Request] - Link/remote script memory checking functions. #8379

{
  'Business Unit': ['Platform'],
  'Date of First Response': '2014-03-19T13:20:23.068-0500',
  'How would you like the feature to work?': 'Requested feature',
  'Target Viewer Version': 'viewer-development',
  'Why is this feature important to you? How would it benefit the community?': 'Motivation',
}