|
|
|
WarKirby: Well, for starters, the problem in the status quo isn't bad or uninformed animation makers. It actually doesn't work, whether your animator is smart or not. Priority 3 walks don't work. Priority 4 walks do. They make their walks Pri4 - that's smart, but leaves other anims without an opportunity to continue undisturbed at a higher priority = broken.
Your ideas have merit, though it would somewhat increase the complexity of the SL universe for your average joe who has no idea what an animation priority is and is just double clicking them out of his inventory. The addition of support for priority 5 and 6 is a very low work solution - there are already functioning priority 5 and 6 animations in world as we speak. All that needs to be done for anyone to be able to create them is to update the uploader to offer it as an option to all. In the long run I'd like to see a better AO solution, and from what I understand Lindens have talked about it, are in favor of it, but have no intention of devoting resources to making it happen any time soon. Your number 2 item has some drawbacks, though. With embedded priorities you can set the animation priority for each individual joint. As it is, you make this decision with crude tools of whether to set each joint's priority to 0 or X (X being between 1 and 4). If you change the joint's position between frame 0 and frame 1, it will be set to X, otherwise it will be set to 0. The actual animation engine You can gain access to this functionality just by editing anim.ini (at least, on the current RC)
I've already uploaded anims with priority 5 and 6 on the normal client, and I even uploaded an animation with per-joint priority. Not going to describe the finer detail right here, because presumably LL deliberately only exposed priority up to 4 to us... If a Linden comments here saying this is fine, I'll happily describe exactly how to do it. But yeah, the comment saying saying giving us access to 5 and 6 is a 'low work solution' is right on the nail. Two lines of code in an ini file did it for me. Well, this has been here 2½ months now. LL has had plenty of time to post any complaints about the issue so in the interest of moving forward I'm going to go ahead and post the information needed to test priority 5 and 6 animations in SL.
____________________________________________________________________ Method 1: close Second Life open Second Life/skins/default/xui/en-us/floater_animation_preview.xml in a text editor modify this section: <spinner decimal_digits="0" follows="left|top" height="18" increment="1" initial_val="0" change max_val="4" to desired maximum animation priority level Method 2: [GLOBALS] upload your animation normally, choose desired priority level Method 3: For methods 1 and 2, you may run into a windows permissions error preventing you from modifying the file in question. You can get around this by running your notepad as an administrator (right click > run as administrator), or by copying the contents of the file in question into a new one, then delete/swap the old one out. What needs testing is whether the server can handle all animation priorities on all joints, whether the various viewer mods posted above have any pitfalls or shortcomings, etc. It would be nice to hear from a Linden whether the server has any issues with higher priority animations. To help new animators, it might also be wise to add some guidelines in the uploader in the form of tooltips for what would be an appropriate priority level choice for certain types of animations. I urge content creators to use this information responsibly, making user experience the first priority when determining the appropriate priority for new animations.
There are hundreds of thousands of existing products which make heavy use of the fundamental assumption that starting a priority 4 animation will override whatever existing animation is playing for the affected joints. We do need more priorities. It is a real shame that Linden did not have the foresight to set a standard with more than one priority above the system animations at the beginning of time. Before uploading a new animation at a priority higher than 4, please consider whether your user will honestly expect your animation to continue playing when they sit on a chair or join a dance ball or get into a car or any of the thousands of other possible actions they might take. Similarly, please consider whether your animation is going to break all those existing shoes and accessories that currently use priority 4 scripts to lock ankles and arms. There are certainly situations where a priority 5 animation which overrides just a few joints opens fantastic new possibilities. However, the person who creates an AO full of priority 5 animations has doomed their customers to a life of confusion and simply elevated the problem we have today with priority 4 animations to priority 5. Should we foresee that inevitability and upload our cool new animations, which are by far the best and most definitely the only ones which should be playing, at priority 999? Or 99999? Obviously this is absurd. In the absence of guidance from Linden and enforcement of limits at the server level, it is up to those of us with the skill to circumvent the limitations to be responsible. I recommend that we establish guidelines for the use of higher priorities. To this end, I have taken the first step and created a Wiki article at https://wiki.secondlife.com/wiki/Animation_Priority It could use some additional examples of good uses for lower priorities, if there is anyone out there that is having success with those. AD |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Major
Add higher animation priorities
in SL supports any priority combination for all joints, though, and would happily play a single animation with some joints at 0, others at 3, others at 4, and still others at 6. The uses for this may be obscure, but that power and flexibility is indeed useful! If only the uploader didn't dumb it down so much!
A better way:
1. Make it possible to DISABLE, not just override, the linden default animations.
2. Discard the horrible concept of priority embedded in the animation asset. Make a new animation function which takes a priority as an argument.
3. Community agreed standards on what each type of animation should have as a priority. eg, walks, 1 or 2, etc.