✨ Feature Requests

  • Search existing ideas before submitting- Use support.secondlife.com for customer support issues- Keep posts on-topicThank you for your ideas!
Add Internal Animations for Bento and Attachment Bones
Linden Lab never added an Internal always-running, default/background animation for Bento bones, like the ones that have existed for the classic body since the beginning of Second Life. In practice, this means there is absolutely nothing that resets the rig to its default position when an animation stops. As a result, Bento bones remain frozen in the current frame of the animation that was stopped. The situation is even worse with the system of attachment bones, which never had a simple reset mechanism at all. Creators have been left to first figure out why bones appear in strange positions, and then to fix the problem manually, by creating low-priority neutral pose combined with always-running scripts that continuously replay background pose. This workaround is completely unnecessary and could be easily resolved by Linden Lab. Unfortunately, both the need for such a fix and the workaround itself are not widely known, which is why we still see “stuck” Bento bones all over the grid. Request: Please finally complete the Bento project by adding an always-running, low-priority internal pose/animation for all Bento bones that keeps the rig in place. This task is long overdue, considering Bento was introduced years ago. Also, in the same manner, add one simple, internal, always-running, background, low-priority default pose/animation that resets Attachment bones’ rotation and position. I urge you to dedicate time to this request, which should be relatively quick to implement, as creators need this simple solution and shouldn’t face backlash from users due to the system’s lack of proper support. If you need additional explanations and/or help on how/why to do this, please contact whoever brilliantly set up the internal animations in the first place.
21
·
Animation
·
tracked
Replace Animation Overriders with a built-in solution in the viewer
Currently, all Animation Overriders ever written in the past 20 years (aye, 20) rely on scripts that require accurate information about what exactly the avatar is doing (i.e., moving, walking, idly standing around...), polled several times per second, in order to swiftly override a standard/default animation with a new one. This is a major source of lag, especially considering that current-generation AO HUDs additionally suffer from texture bloat, increasing the wearer's ARC, and so forth. Certain third-party viewers, which shall remain unnamed, have 'fixed' this issue by embedding the AO in the viewer itself — running fully client-side and not relying on any in-world scripts to do so. They don't have a HUD, so they're not sexy and flashy and cool-looking, but they can read from the same notecard format as LSL-based HUD AOs, and, strictly speaking, they're a great way of reducing lag. So long, of course, that people are aware that such an option exists and are familiar enough with how AOs are configured. Please consider overhauling the whole concept on the viewer side only, so that LSL-based HUD AOs become completely irrelevant. Think of an interface like you have for the Gestures — some kind of viewer-side pop-up window which can load the "standard" animation overrider notecard, and, well, do its magic. Exactly like certain TPVs already do. In fact, as you're considering to introduce RLV to the official SL Viewer... why not AOs as well? Note: There is not even the argument of what happens if an animation hasn't loaded — what will other users see? The answer is trivial: everybody already has the standard animations from 2002 pre-loaded. If someone's AO animations are slow in loading for some reason, your viewer will default to displaying that avatar using the default animations instead. In fact, that's exactly what happens today, when someone else's viewer, though that resident's AO, instructs our viewer to load animation X for avatar Y. If X is already in our cache, good, it will be shown. If not, it falls back to the default animation. There is absolutely nothing that you need to change on the overall code logic! And, of course, you don't even need to reinvent the wheel — just grab the code from the TPVs and use it. It's been there for eons — well before smilies! — and for eons we have had to struggle with LSL AOs and spread lag all over the place. Then: Promote it . It's useless to have a wonderful new technology which reduces animation overriding effectively to zero lag if no one knows about it. Grab the main suppliers of AOs in SL and announce the 'new' system, so that they also spread the news among their customers. They will only need to provide the notecard with the configuration and the animations inside. Note that the TPVs even allow multiple sets of AOs to be configured, and people can freely switch across them (it's even easier than locating that specific AO in your inventory... what was it called again?). This issue has just one drawback I can find: some AOs are rather sophisticated and go beyond what is usually offered on the 'standard' AO configuration notecard; their HUDs are especially designed to allow access to those nifty extras, and have great visual impact. So be it — soon (or so we hope) we'll have the Lua-scripted viewer, and such special effects are perfect for content creators to deploy their ultra-laggy HUDs. But to do that, there needs to be an embedded AO in the viewer itself first. And then, of course, the first thing to do is to get rid of those AOs on the 'free' avatars that come as standard when a new user registers... they should be the very first to use the 'new' system. Well, new for the SL Viewer, that is. Some other feedback/suggestions which are vaguely related to this one: * https://feedback.secondlife.com/feature-requests/p/animation-system-overhaul P.S.: The attachment is just a note on the history behind the Animation Overrider. It might be useful, amusing, or totally irrelevant, so feel free to ignore it 😅
1
·
Animation
Load More