There’s been some buzz about the extra attachment points that are now included in Emerald by default, particularly in how they relate to “force stripping”.
Personally I don’t think they’ll ever get all that much use since they’ll look wrong/silly to everyone who isn’t using Emerald and as soon as people figure that out the appeal of them drops significantly.
Whether or not people will end up using them doesn’t really matter though: at some point or another LL might officially add more attachment points (or clothing layers for that matter) and all the same problems will crop up then anyway so it would be better to try and figure out a way in which scripts can make themselves more “future-proof” now.
After peeking at several “force strip” dialogs most seem to fall into three categories:
- A list of all worn attachment point names spread across different dialogs
- A list of all worn attachment point names divided into categories
- A list of custom grouped attachment points (i.e. clicking “shoes” will force-detach l/r upper leg, l/r lower leg and l/r foot)
So a hypothetical @getattachnames[:<option>] would return a comma-separated list of attachment point names:
- Without an option it would return all worn attachment point names
- <option> could specify one of the pre-defined body areas (head, torso, arms, legs and HUD) and return all worn attachment point names on that area
- <option> could specify the joint name and return all worn attachment point names on that joint
(the “body areas” weren’t really chosen arbitrarily; they’re the same ones you see in the “Attach To” pie menu when you right-click on a rezzed linkset)
(<joint name> wouldn’t be particularly accurate in some cases – “r upper leg” is attached to the “mHipRight” joint along with “right hip” for instance – so it may or may not be a good idea to add that)
Practical example:
- @getattachnames=1
Skull,Left Foot,Right Foot,Spine,Left Ear,Right Ear,R Forearm,L Forearm,R Lower Leg,L Lower Leg,Top,Top Left,Center,Bottom Left,Bottom,Bottom Right
- @getattachnames:head=1
Skull,Left Ear,Right Ear
- @getattachnames:torso=1
Spine
- @getattachnames:arms=1
R Forearm,L Forearm
- @getattachnames:legs=1
Left Foot,Right Foot,R Lower Leg,L Lower Leg
- @getattachnames:hud=1
Top,Top Left,Center,Bottom Left,Bottom,Bottom Right
—
Additionally @getattachnameswearable and @getattachnamesremovable could be added:
- @getattachnames returns the list of attachment point names that are worn
- @getattachnameswearable returns the list of attachment point names that can be attached to (which is any attachment point that doesn’t have a @remattach=n locked attachment *and* isn’t @addattach=n locked)
- @getattachnamesremovable returns the list of attachment point names that can be removed by the issuing prim (which is any worn attachment point that isn’t @remattach=n locked)
The reasoning for @getattachnamesremovable: it’s more intuitive for a “force strip” dialog to only show attachment points that can actually be force-detached by the script.
Practical examples (same as above – l/r forearm and l/r lower leg are @detach=n locked; Top and Bottom Right are “nostrip”):
- @getattachnamesremovable=1
Skull,Left Foot,Right Foot,Spine,Left Ear,Right Ear,Top Left,Center,Bottom Left,Bottom
- @getattachnamesremovable:head=1
Skull,Left Ear,Right Ear
—
Finally: there’s the question of whether the script should be responsible for clearing its attachment locks or whether the viewer should just ignore them (the latter is how “Hide Locked Attachments” works).
Example:
- Collar executes: @detach=n,remattach=n
- Collar executes: @getattachnamesremovable=1
<empty response> since there isn’t a single attachment point that can be @detach[:<attachpt>]=force’d and actually end up detached
- What the collar should have done was:
@remattach=y, getattachnamesremovable=1,remattach=n
- And then later on:
@remattach=y, remattach:pelvis=force,remattach=n
It would be easy for the viewer to ignore any @detach[:<attachpt>] and @add/remattach[:<attachpt>] locks though which means it could just go:
- Collar executes: @detach=n,remattach=n
- Collar executes: @getattachnamesremovable=1
<full list of attachment points that be force-detached by the collar>
- Collar executes: @remattach=y, remattach:pelvis=force,remattach=n
The collar script still needs to know that it should release its @remattach restriction when actually force-detaching but it’s a step in the right direction.
(Personally I think it would make the most sense for @remattach[:<attachpt>]=force to just only check *other* prims’ attachment locks which would mean that @remattach=n,remattach:pelvis=force would “just work” – on the condition that no other prim has “pelvis” locked obviously. It would certainly save scripts a whole lot of hassle)
—
In closing: this is a *proposal* rather than an announcement. Yes the code has already been written, but simply because it’s a lot easier for me to propose something when I know it’ll actually work 
.
Even if LL decides to block non-standard attachment points with the next rolling restart there will still come a time when we either get new attachment points and/or get multiple attachments per attachment point index so it’s probably best to figure out a solution everyone is – relatively – happy with.
Even if we never get new attachment points it would relieve scripts from having to translate @getattach into a list of attachment point names (less code and no hard coded look-up list should free up some script memory)
Additionally the entire post can be done over for clothing layers: LL supposedly was/is working on extra tattoo layers so when/if we get those all existing scripts that rely on @getoutfit and their hard-coded list of layer names won’t be able to deal with those new layers without an update.
—
Additional thoughts:
- I personally prefer @getattachnames[:[<option>;][wearable|removable]=<channel> over three separate commands (basically making the suffix an additional and optional parameter)
- It might be preferable to fold attachment points together (i.e. Chest and Chest (2) and Chest 2 would all simply report as “Chest” one single time)
)