Make the number of HUD position attachments independent
tracked
AmicusMywolf Resident
Currently, we can attach a maximum of 38 attachments, but since objects attached to the "HUD" position are also counted in the total, it's sometimes impossible to wear more.
This phenomenon is particularly noticeable for furry users.
After equipping the necessary furry parts, there are often only 5-6 attachment slots left, along with some commonly used HUD adjustments for body or other parts, leaving almost only 1-2 slots, or even none, for clothing.
I hope there can be a separate limit on the number of objects attached to the HUD position, independent of the attachment count.
Log In
Ember Ember
I disagree. Increasing the amount of scripted attachments users can wear can greatly impact region performance at the detriment of all users in the same region. HUDs are notoriously script heavy items for their various functions and just because you are the only one who can see them client-side doesn't mean they are not affecting everyone else around you.
A tip for furries running into attachment limit issues: Rigged clothing and body parts that have Modify permissions can be rezzed on the ground and linked together so long as their scripts don't interfere with each other (or even better, you can remove their scripts altogether if any). When you take the linked rigged object and attach it, all parts will appear where they belong on your avatar.
AmicusMywolf Resident
Ember EmberHow do you connect clothes when you find they're all uneditable? Many furry objects are not bound, especially body hair; we need them separated into different locations.
When you see people start connecting body parts, their complexity increases dramatically, and at that point, the lag you've been complaining about will only become more severe.
AmicusMywolf Resident
Ember EmberWhen you find that furry users start linking things like I do, do you still complain that people link to so many things that cause your loading to be slow?
Ember Ember
AmicusMywolf Resident yes, there is a difference between region/sim lag and graphics lag and I agree that linking things and wearing more in general causes more lag. But what you're asking for will also cause more lag due to people having the option to wear more huds too.
shrugs
I only suggested linking things because it is a relevant tip/workaround to your asking for more attachment points for HUD items. And to answer your question about unrigged attachments: You can link _rigged_mesh_ objects to a single unrigged attachment so that the unrigged one is the root object and will remain attached to the position it was originally attached to. But yes you're correct, you cannot link multiple unrigged objects that rely on their individual attachment points.
To answer your additional comment: yes I do complain about users linking multiple things because it does cause graphics lag. I merely suggested this to you because it seemed like you could use the tip. XD
AmicusMywolf Resident
Ember EmberOnce you discover that you can link multiple objects to make it a single attachment and add it to your character, you'll find that the so-called limit of 38 attachments is useless; it only adds more links, making it harder to render the avatar.
AmicusMywolf Resident
Ember EmberScripts aren't limited to the HUD; they can be placed anywhere on your character if you find you don't have enough attachments.
Unless it's intentional sabotage, no one would deliberately attach extra scripted HUDs to cause lag. I'd rather see users wearing overly heavy scripted HUDs being reported than having legitimate players restricted.
Ember Ember
AmicusMywolf Resident That is why I also suggested removing scripts from avatar attachments too or did you miss that part? -- "or even better, you can remove their scripts altogether if any". I joined SL in 2006 and have been a creator and scripter in SL since 2013. I know where scripts can go but thank you for explaining that to me as if I didn't know.
Ember Ember
AmicusMywolf Resident Yes, informed users will not self sabotage by wearing more things, but new and uninformed users will wear attachments to the limit unaware of how it is affecting everyone. And that is why the attachment limit exists.
AmicusMywolf Resident
Ember EmberYou can suggest removing scripts from the AV, but you can't control whether users will put scripts in the AV. Some scripts will be added when they find the HUD too obstructive to their wearability.
Just because you started in 2013 doesn't mean you're right.
We're only offering suggestions; using more connected objects on the body to break the 38-point barrier is not a good choice in itself.
Ember Ember
AmicusMywolf Resident I was merely offering a solution to your problem. I never said it was the right one and I only mentioned my account age because you spoke to me like I am an inexperienced user. But I will see myself out of this conversation because you found my tip unhelpful. At least there is a chance someone else will.
AmicusMywolf Resident
Ember EmberI believe your suggestion is based on regional management, which is not the same issue as my desire to improve AV quality. You think more HUDs will lead to more script latency, which requires server restrictions or regional rules, and even the ability to report abuse.
We are simply discussing increasing slots to allow users to freely choose the reduction in complexity.
When you start connecting objects to circumvent 38 slots, your avatar's complexity becomes unadjustable. Since HUDs limit the number of slots, people will naturally try to find ways to circumvent the number of HUDs or even integrate them into the avatar itself.
Qie Niangao
AmicusMywolf Resident I'm unsure what exactly is being proposed here (below), but also: it's a
good
thing if scripts move out of HUDs to the avatar, specifically if those scripts interact with the avatar. HUD-to-non-HUD communications aren't uniquely expensive or anything, but any
inter-object communication incurs overhead, and HUDs tend to do a lot of that, which is one reason HUDs have an especially bad reputation for script lag.What I'm unsure about: Does the proposal limit non-HUD attachments to 38, and impose some (much smaller) limit on HUDs? If so—if HUDs were limited to two or three attachment points, regardless of how many of the 38 non-HUD slots were in use—that could actually be beneficial to performance on avatar-crowded regions. (It would greatly inconvenience folks who use a lot of HUD attachment points, but that might be a good thing on balance, if that's what's being proposed.)
Certainly there must be
some
limit on the number of HUDs if they're to be counted separately from other attachments. Is that limit specified here?AmicusMywolf Resident
Qie NiangaoSince HUDs are computed independently, they definitely need to have quantity limits; for example, only 3-5 HUD layers are allowed to be attached.
I understand that HUDs can cause script latency, so once the HUD position is calculated independently, its number needs to be limited. HUDs that configure avatar parameters are usually not very complex, generally only needing about 2-3 slots. For example, a legacy body HUD, an AUGUEST head HUD, or an expression HUD only need about 3 slots, which is quite good.
If the player still wants to add a HUD, then it needs to be included in the 38 slot positions.
Qie Niangao
AmicusMywolf Resident Ah, I see that would be acceptable even to folks who wear a lot of HUDs. And as long as the incremental number for HUDs-only attachments is in the low single digits, that needn't be a big burden.
It would be a huge win if there were a way to convince people to detach those Legacy (and LeLutka) HUDs, which should only be needed when adjusting those mesh body parts. Viewers have different "Favorite" attachment affordances (the best was Catznip's, back in the day), and those interfaces should be optimized for attaching
and detaching
such items quickly. In addition to reducing script lag, many complaints about viewer performance would go away with those graphics-heavy HUDs.AmicusMywolf Resident
Qie NiangaoYes. I would prefer that legacy systems could transfer some HUD functionality to the body, such as automatic alpha, instead of relying on the HUD for communication. This way, we wouldn't need the HUD at all. The actual purpose of keeping the HUD would be to allow it to communicate with the body so that it can automatically hide when wearing clothes.
Yes. I would prefer that legacy systems offload some HUD functionality to the body, such as automatic alpha, instead of relying on the HUD for communication. This way, we wouldn't need the HUD at all; the actual purpose of retaining the HUD would be for it to communicate with the body so it could automatically hide when dressed.
For example, for my appearance needs, I generally only need one body HUD, head HUD, facial expression HUD, and AO animation HUD.
Just four additional HUD slots would be sufficient to meet my appearance requirements.
I don't think this would cause significant script lag.
Of course, if someone intentionally uses dedicated HUD slots to disrupt the user experience, we should enforce regional rules or report their behavior to LL.
Qie Niangao
AmicusMywolf Resident (A bit off-topic, but not really) The "auto-hide" alpha functions of all the mesh bodies I use (including Legacy M) are in the body itself, not the HUD. Similarly, common facial expression animations for LeLutka heads are all run from inside the head, based on what the HUD sends to it only when the user adjusts settings. So I rarely need either HUD.
Alana Starchild
100% agree with you. It is very annoying and things have advanced since 2003 so surely huds should no longer be counted now.
SL Feedback
marked this post as
tracked
SL Feedback
Hello, and thank you for your feature request regarding making the number of HUD position attachments independent. This is indeed a valuable suggestion, especially for residents who use multiple attachments, such as furry users. We have found that this feature request was previously brought up in Second Life's previous bug tracking system (BUG-227468). We are merging your comments with the existing request to help prioritize it. While we don't have an estimate on when this might be implemented, please keep an eye on future updates. We appreciate your input and hope you continue to share your ideas to help improve Second Life. Thank you!