Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0006688opensim[REGION] Script Functionspublic2013-06-24 08:432016-12-14 07:23
ReporterStarflower 
Assigned To 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusnewResolutionopen 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0006688: suggestion for improved osAttach* and osForceAttach* functions
DescriptionThe current llAttach* and osForceAttach* functions here listed do not in every circumstance allow you to attach an item from prim inventory on a temporary basis, i.e. a copy will always be made in the avatar's inventory, unlike llAttachToAvatarTemp. I find my avatar inventory filling up with copies, as a result! There are two possible approaches to filling in all the gaps in the use cases, either by creating the suggested functions or, which would seem much less unwieldy, modifying how the functions work and deprecating the current ones:

Current: llAttachToAvatar, llAttachToAvatarTemp, osForceAttachToAvatar, osForceAttachToAvatarFromInventory, osForceAttachToOtherAvatarFromInventory

Suggested: osAttachToAvatarFromInventoryTemp, osForceAttachToAvatarFromInventoryTemp, osAttachToOtherAvatarFromInventoryTemp, osForceAttachToOtherAvatarFromInventoryTemp, osForceAttachToAvatarTemp

Alternatively you could use optional parameters to reduce the required number of functions:

void osAttachToAvatar(integer attachmentPoint, {integer temporary})
void osForceAttachToAvatar(integer attachmentPoint, {integer temporary})
void osAttachToAvatarFromInventory(string itemName, integer attachmentPoint, {integer temporary})
void osForceAttachToAvatarFromInventory(string itemName, integer attachmentPoint, {integer temporary})
void osAttachToOtherAvatarFromInventory(string rawAvatarId, string itemName, integer attachmentPoint, {integer temporary})
void osForceAttachToOtherAvatarFromInventory(string rawAvatarId, string itemName, integer attachmentPoint, {integer temporary})
[temporary = TRUE, FALSE]

Another approach would be to add a second optional parameter and avoid repeating all the osForce* duplicates (this would simply be ignored if the script has not got permission to use high threat level functions, in which case it would ask for permission in the normal way. You could, if you liked, choose for the script to report an error if force == TRUE and threat level exceeds that allowed, but for no error to be reported if force == FALSE or if the second optional parameter is omitted.

void osAttachToAvatar(integer attachmentPoint, {integer temporary}, {integer force})
void osAttachToAvatarFromInventory(string itemName, integer attachmentPoint, {integer temporary}, {integer force})
void osAttachToOtherAvatarFromInventory(string rawAvatarId, string itemName, integer attachmentPoint, {integer temporary}, {integer force})
[temporary = TRUE, FALSE; force = TRUE, FALSE]

I think it's useful, however, to retain these last three as separate without adding further optional parameters for other avatar name if any, or name of asset in inventory if any, as this would massively over-complicate the functions! :-)

Note you might also want to follow the same pattern here, for consistency:

osDropAttachment{{integer force})
osDropAttachmentAt(Vector3 pos, Quaternion rot, {integer force})
Steps To ReproduceN/A
Additional InformationAs outlined above, the second optional parameter would seem to require the first one at least to be specified - otherwise how would the script engine know which was meant? So if only one is specified, you must assume it is temporary and not force. Or, to avoid this, you could insert them in a different sequence to avoid ambiguities arising...(?) This might seem rather messy, so see the following suggestion instead:

Perhaps you could use different integer values with named constants instead? These could be ANDed to combine them, as elsewhere in LSL. (This could be one combined optional parameter.) I can foresee several possibilities but it would seem fairly simple, one way or another, to allow for all possible permutations with a rather smaller and more convenient set of functions and less duplication.
TagsNo tags attached.
Git Revision or version number
Run Mode Grid (1 Region per Sim)
Physics EngineODE
Script Engine
EnvironmentMono / Linux32
Mono Version2.10
Viewer
Attached Files

- Relationships

-  Notes
(0031449)
fu barr (reporter)
2016-12-14 07:06

Would be exceptionally nice if there was indeed a

osForceAttachToAvatarFromInventoryTemp(avatar_uuid, item, attach_point)

which could attach an item from the objects inventory to an avatar without filling up that avatars inventory with many copies of that item.
(0031450)
Total Sorbet (reporter)
2016-12-14 07:23

osForceAttachToAvataFromInventoryTemp()

Yes please!

This could definitely help make inworld experience/games more immersive and seamless by doing away with the need for popups and inventory spam.

- Issue History
Date Modified Username Field Change
2013-06-24 08:43 Starflower New Issue
2013-06-24 08:45 Starflower Physics Engine BasicPhysics => ODE
2013-06-24 08:46 Starflower Description Updated View Revisions
2013-06-24 08:47 Starflower Description Updated View Revisions
2013-06-24 08:48 Starflower Additional Information Updated View Revisions
2013-06-24 08:49 Starflower Additional Information Updated View Revisions
2016-12-14 07:06 fu barr Note Added: 0031449
2016-12-14 07:23 Total Sorbet Note Added: 0031450


Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker