Animesh seat scripting

[VirtualKitten]

Hi all I have something to stump you all. I have a seat working in my static model that allows me to pose sits on a ball  that is part of the armature of the model and moves with the model. I thought that as I was linked and placed as offset from this when the model moved in animesh i would move relative to the ball that is controlled my animesh . This doesn't happen instead I am placed at the location the seat was at before animesh is switched on  .

 

in my seat ball I have groups mNeck, mCollarLeft, mCollarRight and mChest asisgned to link and vectors.

Here with stationary seat

 

Here with Animated Mesh turned on 

 

This is were seat ends up presumably showing armature is not working ?

 

 

I presume I am missing some scripting that repositions my seat when movement occurs or the armature is not working on the seat  which is linked in blender to bones vertex in spine.  Is this linked thing a problem in animesh ? What do I need to achieve this not the resit but the detection we have moved by animesh and how this works in principle. is there a trigger to check movement and to do this or an event ?

 

The fire ball also does the same thing as a separate link  in blender with bone vector groups assigned mHead.

Why dont these item move with mesh model as they appear to be offset to original position of stationary object when the animation is switched on how do we get round this please is it a scripting issue or a mesh issue with armature?

 

 

 

kisses 

Denise

Edited June 12, 2021 by VirtualKitten
Added image

[Quistess Alpha]

As far as I'm aware animesh can't have 'attachments'.

Now, if you were just using prim animation, I believe you could llSLPPF the position of the link that corresponds to the seated avatar, which is generally the highest link number.

[Bloodsong Termagant]

it doesn't work like that.

 

your avatar sits on the sit target (stationary relative to the object center).  if you want it to move with the animesh it is sitting on, you need to create an animation for the sitting avatar that matches it.

 

[Patchouli Woollahra]

Your workaround is to place the avatar on a static part of the animesh and confine its movements to other bits of it. Until LL comes up with a way to script sittargets into the animesh armature itself, this is as good as it gets.

[Lucia Nightfire]

As I mentioned in the Animesh Developers group earlier:

Animesh and user avatars have to be animated separately with synchronoized animations. There is no sitting-on & following effect capability on its own.
There is a feature request accepted for the capability, but I doubt we will be blessed with it any year soon.
https://jira.secondlife.com/browse/BUG-100864 fwiw
Also, fwiw, attach points would work similarly where you "assign" the attach points to a unrigged link and it will then "bind" to the attach point the skeleton uses and follow on an offset pos/rot.

[animats]

As Lucia points out,  the "sit" system does not work for animesh.

Worse, animesh can't access the animations inside seats. It's an IP policy thing. You can sit on things you don't own, which results in the unusual case of a linkset where not all the links have the same ownership.  But you can't lend an animation to a different user unless it's copy and transfer. So "sittter" scripts can't interact usefully with animesh, even if both sides are programmed for that.

[VirtualKitten]

5 hours ago, Quistessa said:

llSLPPF

What is this llSetLinkPrimitiveParamsFast? . i guess am using it it works in static model . I am thinking its the links that dont work when you import that carry the animesh vector parts its very strange that the balls remain as in static model . What is it doing wrong please. Quintessa i gave up with Jira ages ago and ditched my account what does the Jira say or is written please. I dont think it follow it has armature bone vector settings in it so why does it not stay with bone. Please explain what you mean as am learnier L plates

Seat.
As you can see the balls are in blender with model and the weight painting has been done. It doesn't matter if i am seated or not if i turn on animated mesh they dont remain in correct position. However they do in blender animation . They are exactly correct!  Its only LSL which seems to get this wrong any ideas please as we are struggling to know if its script related or mesh related.?

 

Fire ball.

Same is true of the fire ball

 

4 hours ago, animats said:

As Lucia points out,  the "sit" system does not work for animesh.

Worse, animesh can't access the animations inside seats. It's an IP policy thing. You can sit on things you don't own, which results in the unusual case of a linkset where not all the links have the same ownership.  But you can't lend an animation to a different user unless it's copy and transfer. So "sittter" scripts can't interact usefully with animesh, even if both sides are programmed for that.

 

It was all imported from Blender in one go Lucia The animation for seat only  in the seat .The seat animations are all full perm from a friend.

thanks for lookin

D

 

Edited June 12, 2021 by VirtualKitten
Added image

[VirtualKitten]

Ok I removed my ball links and the animesh seemed to work correct with animation so it seems you cant link items to animesh  to seats or fire emitters pretty useless really go figure? Even if it has same armature how silly is this ?

Edited June 12, 2021 by VirtualKitten

[Quistess Alpha]

1 minute ago, VirtualKitten said:

Ok I removed my ball links and the animesh seemed to work correct with animation so it seems you cant link items to animesh  to seats or fire emitters pretty useless really go figure?

Yes, this is why you do basic test builds to understand the technology limitations before you make your animesh dragons or whatever.

[VirtualKitten]

Quistessa this is awful what is LSL thinking  you cant have linked items in animesh  what on earth is the point of it then! as its seems if a horse cant have a saddle  or a dragon cannot have fire or a saddle This is supposed to be a virtual world creation platform am very frustrated and feels like a waste of time to build in it seems to me like this has  not been thought out at all!

Is very fed up now blender has exceeded my expectations now its far superior to SecondLife they really need to catch up  I have done basic builds but to be honest I am shocked by this and you dont seem surprised at all!

 

Ok i rephrase that I can sit on it but the fire emitter is not possible and the sit animation dont work Its seems Blender is far more advanced than LSL 

https://i.gyazo.com/900bf9600ddbdc0baeccda2ac4773da4.mp4

D

 

Edited June 12, 2021 by VirtualKitten

[Quistess Alpha]

A couple points:

1: You can't magically expect everything that works in blender to magically transfer to Secondlife. SL has limited capabilities.

2: Just because a tool doesn't do exactly what you need/want it to do doesn't make it useless. That's like saying a car is useless because it can't travel off-road, or indoors.

3: For me at least, product creation generally has 3 parts; 1) having an idea 2) exploring the techniques involved 3) actually implementing the thing. If you jump straight from 1 to 3, you're going to run into a mess if you try to use something without understanding the limitations. Nobody's saying you can't have a saddle, it just needs to be a major design consideration, and you need to know what method you're going to use to circumvent the limitations (for example, keeping the seat position steady and moving the rest of the dragon around it) as a first step, not while you're in the weeds of actually building and animating the thing.

[OptimoMaximo]

There's a separation between the transform node and the mesh shape that also is in Blender. When you animate your things, their origin points stay put where they were at the beginning, and only the mesh moves. That's the separation.

Anyway, to get your desired results, you need to make the avatar animations by attaching an avatar to the seat via constraint and export that specific animation for your avatar to play back in synch with the dragon movement.

[VirtualKitten]

Quistessa there is a great skillset of people using Blender to produce fabulous works that can produce wonderful video imagery . You say LSL is limited but is that not the whole problem a dream is only a dream if its in finite . Do you think I would have got this this far without some wonderful peoples help in blender on this forum .

 

7 hours ago, OptimoMaximo said:

There's a separation between the transform node and the mesh shape that also is in Blender. When you animate your things, their origin points stay put where they were at the beginning, and only the mesh moves. That's the separation.

Anyway, to get your desired results, you need to make the avatar animations by attaching an avatar to the seat via constraint and export that specific animation for your avatar to play back in synch with the dragon movement.

OptimoMaximo this is ridiculous complication of the problem . Why do you have animation priority numbers if its not to do just separate animation priority .  If the linked seat and fire  balls have the same armature  and work in blender why being rigged to they not follow the animesh armature  in LSL? this is absurd. Does this mean if I made a coat as a link that would not work either on the model ? 

Quite frankly the only problem i have seen in blender is the pose which is surmountable by having two models one to animate  and upload animations to LSL and other one to upload from  blender to LSL which is the correct x orientation. I understand this is caused by a problem with the armatures being built in Maya with the wrong orientation This problem with alignment and the origins disappears with two models  . I would have expected LSL to strive to do the best, do you not think that is what i am trying to do with it?  I have spent several months with a great team that had made a new model and is great in blender doing everything it should . why would i now want to import a rider as a link and animate that this makes no sense at all to me as there are  already super animations in world with some amazing animators who should also deserve a mention  . You seem to be then offering a limited option not one that is expansive and set LSL on a route that is one of awe and possibilities. If your suggesting these animations need to be done in blender why cant full perm ones be exported to bvh then if you need to take an animation in to blender and animate the rider with the model?

Edited June 13, 2021 by VirtualKitten

[OptimoMaximo]

3 hours ago, VirtualKitten said:

I understand this is caused by a problem with the armatures being built in Maya with the wrong orientation

No, you don't understand. First, Blender has the wrong orientation, not Maya. It's been built the way it is to conform to the general purpose concept of a forward vector that, in SL, is the X axis forward for everything. Also in both 3d packages, when things are skinned to joints, the object stays put while the mesh shape follows the animation, concept that apparently isn't quite clear to you yet. Want fire particles being emitted from the fireball? Blender allows emission from the surface of the mesh, SL only from the center of the object. And NO, these two aren't the same thing, sorry.

Another concept that blatantly is not clear to you yet is that joints have no physical presence anywhere in both server and viewer side code, meaning that server doesn't know that joints exists at all, while the viewer has only the notion of transform points that transfer rotations over to the skincluster for deformation. At no point in time there is any object anywhere within and or in between the two components, server and viewer, that could be capable of setting or inheriting transformation values inworld. Animations are just cosmetic things that need a specific purpose, and the whole concept of something being "universal" within the scope of SL animation is pretty much ridiculous, let alone unachievable. So yes, that is the only method, as of the time of this writing, to obtain the result you're after. The only way to make that happen is having LL add the attachment points to animesh, which is inherently exactly what I was saying above: transforms that should be capable of setting and inheriting transform values inworld from the skeletal animation data. This is different from skinning the mesh to a joint as it is a parent-child type of hierarchical relationship and therefore tying two transform nodes directly.

Edited June 13, 2021 by OptimoMaximo

[VirtualKitten]

Hmm OptimoMaximo you make good points  but have been informed in community forum that the Bento Armatures was all developed in Maya  not in blender ( as a Maya Diva you should be aware of this :laughs) as such the variation for animations occurred requiring two models. in the appropriate axis one to work in LSL the other to work with the different orientation of the armature   I understand the skin of the model is being manipulated by the armature but why then not the other linked balls children's skins? It makes no sense that these carry the armature but the ball skins do not stay in place  all mesh in blender that move in blender with the armature they do not  do this in LSL in browser idk why.

How did the brilliant AKK horses managed to do this without Animesh I am unsure as they used to have saddles and other link trappings on their horses which all predate animesh this has I think gone and the resultant animesh has been left unworthy of the replacement to this technology it was replacing. It saddens me as these was great fun.

I am aware that particles in LSL have to come from the center of an object it is why I am trying to get linked balls with armatures joints and vector assignments working in LSL Se above the balls are joined to the armature at certain positions . My test models proved this and work great  but I want it in the animesh or otherwise i will have to dump it as unusable . and find out how AKK horses did it and use outdated scripting tools   *sighs*

I just dont see why anything you have said would prevent this working as if a ball or skin if you like is moving with the bone group then it should suffix to have a sit position on place and run a separate animation from that center . What is occurring is the parts of the mesh in links even with control rigging in them do not move with the animesh  and are left at an offset from the stationary position . This doesn't make any sense as I can understand why they move here if not acted upon by the armature . But then when you move whole modal the children links move at equidistant to the model as was initiated by the movement start position of the animesh. i hope you understand how silly this is that it does not follow what blender does and makes the animesh hopeless and only usefully working in a childless link model.

What is happening is the links balls and skin  are left in the position they was in in the stationary model if Jira has an issue with this which has been undisclosed why are they doing their usual thing sticking there head in the sand? 

Hugs D

[OptimoMaximo]

17 minutes ago, VirtualKitten said:

Hmm OptimoMaximo you make good points  but have been informed in community forum that the Bento Armatures was all developed in Maya  not in blender ( as a Maya Diva you should be aware of this :laughs) as such the variation for animations occurred requiring two models. in the appropriate axis one to work in LSL the other to work with the different orientation of the armature   I understand the skin of the model is being manipulated by the armature but why then not the other linked balls children's skins? It makes no sense that these carry the armature but the ball skins do not stay in place  all mesh in blender that move in blender with the armature they do not  do this in LSL in browser idk why.

How did the brilliant AKK horses managed to do this without Animesh I am unsure as they used to have saddles and other link trappings on their horses which all predate animesh this has I think gone and the resultant animesh has been left unworthy of the replacement to this technology it was replacing. It saddens me as these was great fun.

I am aware that particles in LSL have to come from the center of an object it is why I am trying to get linked balls with armatures joints and vector assignments working in LSL Se above the balls are joined to the armature at certain positions . My test models proved this and work great  but I want it in the animesh or otherwise i will have to dump it as unusable . and find out how AKK horses did it and use outdated scripting tools   *sighs*

I just dont see why anything you have said would prevent this working as if a ball or skin if you like is moving with the bone group then it should suffix to have a sit position on place and run a separate animation from that center . What is occurring is the parts of the mesh in links even with control rigging in them do not move with the animesh  and are left at an offset from the stationary position . This doesn't make any sense as I can understand why they move here if not acted upon by the armature . But then when you move whole modal the children links move at equidistant to the model as was initiated by the movement start position of the animesh. i hope you understand how silly this is that it does not follow what blender does and makes the animesh hopeless and only usefully working in a childless link model.

What is happening is the links balls and skin  are left in the position they was in in the stationary model if Jira has an issue with this which has been undisclosed why are they doing their usual thing sticking there head in the sand? 

Hugs D

Did you try to set tge sitting balls as animesh objects before linking them back to the main model? Might be the balls haven't been turned as animesh and are seen as static links.

As of AKK system. The first AKK horse I have seen was made of sculpts, and when mesh came out, they updated themodel but the system was the same. For every pose in an animation, there was a different model which was turned visible while all the others were turned transparent, creating the illusion of motion. This technique is called alpha flipping, but it's very much resource wasteful. Also, notice that those horses were attachments for the avatar to wear, and that the avatar played an animation to lift it up on the saddle, BUT the actual avatar did not really move as suggested by the name tag which did not move. The name tag follows the position of the avatar controller, the thing that moves it around the world, and not the avatar mesh,reason why when riding those horses the name tag was always sunk in the avatar mesh abdomen or crotch area.

Later on, when bento was introduced, horses were skinned to the avatar extra joints. All animations became avatar animations, like AO, which still required the avatar to be lifted up to saddle position while skeletal animation was also applied to the horse itself. Less resources waste and way better looking animations.

As Quistessa noted above, not all features transfer from 3d apps to engines. You'd say that the 2 topnotch game engines on market, unreal and unity, could do that, but it's not the case. While Unity, at least until last time I worked with it in 2019,actually has a skeleton in scene to parent things to, "sitting" a character on it still requires a ton of synchronized animations, even though  not to the extent that SL does as noted earlier. Unreal engine, on the other hand, requires an even more complicated setup within the actor blueprint to achieve such result, and still have a ton of synchronization code and synchronized animations. The bottom line of all this is, basically, that a 3d app has all the means to take all the time needed to calculate and render any kind of setup the user wants, even 2 weeks per frame if necessary. A game engine can't, as usually the minimum performance standard is to have 1 frame every 3 milliseconds, at the very least. Therefore it can't afford to have millions of relationships to calculate the transformations that a 3d app makes you pay with longer execution time.

[OptimoMaximo]

51 minutes ago, VirtualKitten said:

Hmm OptimoMaximo you make good points  but have been informed in community forum that the Bento Armatures was all developed in Maya  not in blender ( as a Maya Diva you should be aware of this :laughs)

About this part here, I think you wanted to say that bento skeleton was developed in Blender and not in Maya. First off, the original skeleton was made in Maya when Blender did not even exist. So the bento skeleton appendages had to comply to the already laid out standards. Secondly, yes, the main input came from the Avastar team, but they were well aware of what the standards should be, as their addon just do that : it runs a series of procedures to align Blender models and skeletons to the Maya based requirements, as joint orient, joints scale, bind matrix, vectors length, scene orientation, scene scale, object scale and linear units to be written correctly to collada files to comply with a Maya exported item.

See, many years ago I collaborated with the Avastar team for the animation setup and workflows. So I'm well aware of these things.

Then I moved on, and made my own animation plug in for Maya, and now also collaborate with @Cathy Foil
on Mayastar. So again, I'm well aware of how these systems work.

Edited June 13, 2021 by OptimoMaximo

[VirtualKitten]

Wow @OptimoMaximo that is amazing thank you for all your hard work  and patience with us , oh it was only the first one then , i was not aware of that . It does explain the sequence of events for  the two models and standard thereafter .

Am pleased to be talking to the right person

So why does the linked children in an animesh sequence do what they do which is so not helpful  . My  model is part character based and disables this character  to key motion movement while in the air flying .

Did the AKK Horses just use keyframe animation and lSLPP to move saddle and reigns back in position  back in the day. I presume this is independent of animesh? Does anyone know how this was kept in step with animation? The path finding is not brilliant with character so am happy to ditch it in favor of Key frame motion if that will work?

It seems i am going to have to rediscover this old  route as  this new technology animesh is just rubbish and for silliness and those selling it as developer kit are much mistaken that it can have any serious person as one object . I can't believe you have not discussed this in the past what did you manage to achieve please are Jira sitting with heads in sand or just sitting on their hands in the corner on the naughty chair?

Edited June 13, 2021 by VirtualKitten

[OptimoMaximo]

44 minutes ago, VirtualKitten said:

So why does the linked children in an animesh sequence do what they do which is so not helpful  . My  model is part character based and disables this character  to key motion movement while in the air flying .

I guess you're referring to the need of an object that is the root to move the dragon around, while it animates on the spot as opposed to animating it all and have the movements sorted from animation. It is a limitation that comes from how games handled movement and animation back in the days when SL was created. There is an invisible capsule that moves under the user controls. Parented to that, the avatar plays the animations associated to what is called "character state" : walking, running, turning, etc. So the movement is space around the scene needs to be basically subtracted from the animation and, as result, the animations are "on the spot". Compared to SL age, the "root motion" system that transfers the animation spacial motion to the controller is relatively new and can't even be implemented because of the animation system architecture relationship with the physics controller. We could call it "joints naive system" as the phisics that run the avatar controller on the simulator has no remote knowledge of what a joint is, even if it technically is a transform node and could, technically, be seen and sampled as if it was an object. Doing such kind of update would crack the pandora vase open and require a near infinite chain of dependencies updates that could potentially disrupt the whole platform working order completely, if not break it or, in the best scenario, break older content, which is seen by LL as the coming of hell, with horror and absolute fear (might mean a colossal financial hit the Lab could not survive)

 

44 minutes ago, VirtualKitten said:

Did the AKK Horses just use keyframe animation and lSLPP to move saddle and reigns back in position  back in the day. I presume this is independent of animesh?

Back in those days, animesh was not available, and also key framed motion was. They basically had 1 model for each single pose of the horse, and it's parts, linked together and used a script to sequencially make only one pose be visible at any given time.

 

44 minutes ago, VirtualKitten said:

I can't believe you have not discussed this in the past

OH I did go to the content creators meetings up to the bento project. I contributed to solve issues that the week later someone else claimed as their own solutions, while I was constantly shunned aside as the incompetent moron. But guess what, bento project had a long release delay because the issues I foresaw with the face joints setup had to be taken into account for a fix within the viewer when shape sliders where changed. Ever wondered why there's a useless joint called face root? Because of the offset fixes that Vir had to implement to make the face work with the existing shape sliders. Ever wondered why faces don't show elasticity in the shapes or animation? Because this incompetent moron (myself) claimed that using animation joints to drive shapes was a bad idea from the get go, not only because of the issues mentioned earlier that I foresaw, but also because the shaping results would not be really satisfactory. The blender "pros" knew it better, so I just shut up and let that be to its destiny, don't care. Therefore I quit going to the content creator meetings, what is the point? I am a rigger and pipeline developer in RL in RL studios, I'm more than capable of taking what I'm given and make it work anyway.

Edited June 13, 2021 by OptimoMaximo

[VirtualKitten]

Yes i have the character model doing what you said walking about under character mode . This is then randomly checked for air above and random time to try start flight . Jumping up in air and then flying. we are  working on better animations at present with newer model from my team. It does all this with bells on but does need better animations and its getting there with the newer model  its pretty cool . But is it enough no everyone wants to ride it it to fire and flame all things that should be possible . Yes you have the idea basically its a string of animations but tricks the system into thinking they are fluid in content as the eye is not fast enough to catch up and they are played  . essentially it is on one spot not so much as its moving in air by keyframe or MoveTo  But oddly the 'Animated Mesh' button moves it backward on the X axis leaving the children  in front as you saw from my screen captures its most peculiar that LSL does this and not very joined-up.

As this stuff was all available to developers pre Animesh  can it still be used  today with the 'Animated Mesh' uncrossed  using KeyFrameMotion my own pursue and wander written in 2020 for keyframe in air .its currently reliant on character modeling to wander about on ground .

I am really to hear some of your experiences was not good but some people can have big egos and hot air  . But really we all need to get together and get something out of this that works if not try to make linden fix it  would be nice. If we dont the next generation wont have the wonderful  akk horses just ones that run around that they can pat lol

 

 

[Quarrel Kukulcan]

11 hours ago, VirtualKitten said:

I just dont see why anything you have said would prevent this working as if a ball or skin if you like is moving with the bone group then it should suffix to have a sit position on place and run a separate animation from that center .

For two reasons:

Number one: The armature in an animesh object can't affect anything outside that one object. Even if the animesh object is the parent object in a linkset, the other objects in that linkset can't be attached to or weighted to its bones. Not even if they're that way in Blender. Second Life simply doesn't support that. The children will import as if they were attached rigidly to the parent's base position and won't animate with it. (You CAN attach separate objects to avatar bones, yes, but animesh objects lack this feature.)

Number two: Animations only change where an object's mesh is drawn. They don't change where the object actually is or which direction it's really pointing. They also don't change its physics shape -- and the physics shape is what avatars sit on. If your animesh jumps or twists or dances via animation, an avatar sitting on it won't track with it. You have to figure out another method to animate them the same way.

Quote

As this stuff was all available to developers pre Animesh  can it still be used  today with the 'Animated Mesh' uncrossed  using KeyFrameMotion

Probably. I think every technique AKK used is still available. And it should be usable with an animesh mount as well (which is good, because the rider can't be moved in the ways you assumed it could be from your Blender experience).

Edited June 13, 2021 by Quarrel Kukulcan

[VirtualKitten]

Everyone ,

 

This is getting ridiculous the Animesh stuff is really a waste of time. after failures with linked items with armature vectors on them  and them moving away from the bone position  I created a seat on the single mesh running a walk animation  in LSL to see if it was even possible to use a seat and animation where animation was stationary this is the result : https://i.gyazo.com/4c7644a55449496230a082e3b7efd16c.mp4 as you can see I am seated in position but the neck moves beneath as the center of the seat is the Centre of the object as you cant link objects in Animesh and have them operate as if connected to bone . We really need Linden to resolve this 

 

The obvious way for linden to solve this would to be to allow linked animesh children with support for armature placement . I really don't understand why they haven't done this @Quarrel Kukulcan

 

Hugs Denise X

 

Edited June 22, 2021 by VirtualKitten
added

[VirtualKitten]

I sent this thread as a support ticket #1737688 to Linden and am hopeful of some help  Please add anything you feel relevant to this content above.

[Quarrel Kukulcan]

3 hours ago, VirtualKitten said:

I really don't understand why they haven't done this @Quarrel Kukulcan

This is not a scripting question, but...

1. Not even avatars have this feature. Yes, I can attach a box to one bone of my avatar, but other residents can't sit on that box. So letting you attach objects to an animesh object won't let you make a moving, sittable saddle. (And if it did, well, then I could hold a box, and you could sit on it, then you could hold a box and that other woman could sit on it, then she could hold a box and that that guy over there could sit on hers, and and and BOOM, you've broken SL with your crazy-long attachment chain.)

2. Animations only change visual positions, not objects' actual positions or their physics shapes. And the physics shape is what you sit on. (This is the result of how SL's animation handling had to be programmed 18 years ago due to how limited computers and the internet were back then, and now we're stuck with it because changing it now is too much work and would break too many existing scripts and objects to be worth the gains.) Just like playing a constant animation that lifts your AV ten feet off the ground doesn't stop you from bumping into ground-level objects as you walk around, playing an animation that makes your dragon rear up won't move an avatar that's sitting on it (or on anything theoretically attached to it).

 

[Lucia Nightfire]

8 hours ago, Quarrel Kukulcan said:

changing it now is too much work and would break too many existing scripts and objects to be worth the gains

The conversation has been brought up many times in the Content Creator meeting, along with animation reform in general.

There are many applications and use cases that users desire to be satisfied.

Developers are aware of them, but have stated they don't know the best way to update the current protocol and introduce massive change into current infrastructure seamlessly and without users, products or the viewer needing a way to support old and new protocols or a way to switch between protocols with minimal/no user intervention.

Still, it is something of interest with both devs and users.

In regards to https://jira.secondlife.com/browse/BUG-100864 I've noticed its workload/scheduling/priority has been updated 4x since its acceptance, including last month.

This at least shows that it is still on their radar for possible future work. How soon? Who knows.