Re: [opensource-dev] Tutorial needed on TPV viewer-side AOs
On 14/04/2012 11:09 AM, glen wrote: > >> I don't really have any insights into the client vs. server vs. >> scripted AO debate. I think adding asynchronous events would be a very >> good short-to-medium-term solution, and any scripted AO that used them >> would probably cause low enough sim load that the whole question could >> be punted for a long time. Assuming script load is the reason this is >> being considered. >> > I think we've all gone a bit OT to be honest. All he wanted in the first > place was a quick tut on how the existing in-client AOs worked. I'd > assume he's considering adding one to the LL client. I agree with Anne > that he should probably start with the inworld scripted AOs and then > work from there as there are a lot of possibilities. That's because the AOs in TPVs are necessarily incomplete - because they cannot integrate with the server-side. If Linden Lab *were* considering just dropping similar functionality into the viewer without additional server-side integration, I'd consider that to only be half a job. ie: If Linden Lab basically copied what the TPVs do for the official viewer then creators would once again likely wind up in the position of telling customers "No, you can't use the builtin thingy. You have to use the scripted thingy instead, or it won't work properly. Why? Well, it's kind of complicated to explain..." That's a point of friction that users don't need. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Tutorial needed on TPV viewer-side AOs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/13/2012 6:09 PM, glen wrote: > The funny thing is that the only reason why I even bothered writing > one in the first place is because yours didn't have "sit now"! > > See Oz? Features! What is "sit now"? Your average user isn't going to be adding their on code to their AO, that's how you and I would fix it :P -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPiPVAAAoJEIdLfPRu7qE2zYUIALDOi7HzBgfZRTMrDlxqVR4F TOMVbZKkHqjiBDuia9DRLgNcMShsdJlutDV1v2FiT/LAj89/vBviDmOwrkr07H48 tZNS/U6ixDXPIE2D+6YeaOU7Wqazmrm0PBPaZvYx8J7DtHhF0449d/0gA/QZnESB pdSUhDfGRaA7Nf61lTeR6uk5YmY3017yQSt5tNLfAcp47v/Z1ffc9/CM48lxHkjq af+YvqTQ8S6h46hdVMOMVpJ6Exu2MqbiogryXb3NPHCc5rmVTV9Wxvm0RLpmDBL5 0bn1i0NPREbtkicBcU2TPbiSh8fn/GQFg4qIzF5N1SVxnGbv6C5ANIcVlCeyMeg= =oybM -END PGP SIGNATURE- ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Tutorial needed on TPV viewer-side AOs
Since we're already OT... On 4/13/2012 6:09 PM, glen wrote: > I agree with Anne that he should probably start with the inworld > scripted AOs and then work from there as there are a lot of > possibilities. Agreed, for purely selfish reasons. I hope LL adds new LSL functions that enable AO features / performance / scalability that is impossible today. Then someone else will write the next ubiquitous AO, and I will eventually stop getting the "Your walk sucks, I want my money back or I'm reporting you to the Lindens" IMs. My only piece of advice to whoever might pick up that baton - don't distribute it in a form that allows someone to sell an object with your name as creator. And the ironic thing is, the ZHAO isn't even all that well-written of a script. I'm sure any of you who've looked at it have come to that conclusion a long time ago. Ziggy ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Tutorial needed on TPV viewer-side AOs
On Fri, 2012-04-13 at 16:23 -0700, Ziggy Puff wrote: > On 4/13/2012 3:08 PM, glen wrote: > > My timer is ony 0.25, not 0.02. I get very, very little stutter and > > then only on sims that are too loaded for me to be in anyway. > > I think I set the timer to 0.2s or 0.25s for ZHAO-II. Been a while > since I tested it, but AFAIK, my results matched yours - some stutter > on sims that were heavily loaded, where it wasn't clear that a faster > timer would help or would make things worse. No perceptible lag on > unloaded sims. > > Kadah wrote: > I believe FS's was designed to mimic the ZHAO II hud, it even uses > its config notecards. "Franimation Overrider" is a new one to me. > ZHAO-II was born from ZHAO-I, which was born from Franimation, which > was created by Francis Chung. Franimation is a direct ancestor of > ZHAO-II, and is much older. There would have been no ZHAO without > Franimation. > The funny thing is that the only reason why I even bothered writing one in the first place is because yours didn't have "sit now"! See Oz? Features! > I don't really have any insights into the client vs. server vs. > scripted AO debate. I think adding asynchronous events would be a very > good short-to-medium-term solution, and any scripted AO that used them > would probably cause low enough sim load that the whole question could > be punted for a long time. Assuming script load is the reason this is > being considered. > I think we've all gone a bit OT to be honest. All he wanted in the first place was a quick tut on how the existing in-client AOs worked. I'd assume he's considering adding one to the LL client. I agree with Anne that he should probably start with the inworld scripted AOs and then work from there as there are a lot of possibilities. --GC ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Tutorial needed on TPV viewer-side AOs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/13/2012 4:23 PM, Ziggy Puff wrote: > Kadah wrote: > > /I believe FS's was designed to mimic the ZHAO II hud, it even uses > its config notecards. "Franimation Overrider" is a new one to me./ > > ZHAO-II was born from ZHAO-I, which was born from Franimation, > which was created by Francis Chung. Franimation is a direct > ancestor of ZHAO-II, and is much older. There would have been no > ZHAO without Franimation. Ah ok. That was all before my time :P -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPiLWpAAoJEIdLfPRu7qE2g4UIAK4NHSBZ8OLt+DE7x0otXR3L mY+Sg9o6Yyi+MZxph9T/00sVWkpaK3YraAPPg1+J5D/hLyWtFJbVF7IvN537W4i8 aqgbXyKuNsisKDsRvs23kInL/3krSbWPjRq0n/Fx1qvlkVnGhKPcilu0+AzDBcly ZqRO7vehbKwKEZoEShRsPJnGYIBABZeV33Nb3gelwBd9q4KXq5kkSdlQHQEb63sR A1zDxKQgCUvmPx9jr2P1j3Qf/cFjgkcg4rSONyk73a6GMos+Ghe5tGS0OYVfD5T+ ycrojbcczZGo4/o5MvvzQzGytQwidrQP+caGF42eAgTl3wv2SHlIBrknuVYGvzM= =48xA -END PGP SIGNATURE- ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Tutorial needed on TPV viewer-side AOs
On 4/13/2012 3:08 PM, glen wrote: My timer is ony 0.25, not 0.02. I get very, very little stutter and then only on sims that are too loaded for me to be in anyway. I think I set the timer to 0.2s or 0.25s for ZHAO-II. Been a while since I tested it, but AFAIK, my results matched yours - some stutter on sims that were heavily loaded, where it wasn't clear that a faster timer would help or would make things worse. No perceptible lag on unloaded sims. Kadah wrote: /I believe FS's was designed to mimic the ZHAO II hud, it even uses its config notecards. "Franimation Overrider" is a new one to me./ ZHAO-II was born from ZHAO-I, which was born from Franimation, which was created by Francis Chung. Franimation is a direct ancestor of ZHAO-II, and is much older. There would have been no ZHAO without Franimation. I don't really have any insights into the client vs. server vs. scripted AO debate. I think adding asynchronous events would be a very good short-to-medium-term solution, and any scripted AO that used them would probably cause low enough sim load that the whole question could be punted for a long time. Assuming script load is the reason this is being considered. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Tutorial needed on TPV viewer-side AOs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 4/13/2012 1:10 PM, Henri Beauchamp wrote:
> Again, the viewer side AOs are in fact mimicking exactly what
> scripted AOs (and most specifically Francis Chung's "Franimation
> Overrider") do.
I believe FS's was designed to mimic the ZHAO II hud, it even uses its
config notecards. "Franimation Overrider" is a new one to me.
> The scripted AOs got two main flaws (which are in fact the result
> of the same lack in the scripted event support): they are often too
> slow to change the overriding animation in time to avoid seeing
> the overridden animation playing for a second or so before the
> overriding anim is started.
I've only seen that behavior with clientside AOs. I figured it was due
to the latency of the viewer having to respond to a simulator event
then send an override.
> Another, much worst issue with viewer side AOs, is that, like I
> explained in my previous message in this thread, they lack a way
> to be disabled automatically by scripts. Let me explain this issue
> more in details: while AOs are great, they can be a nuisance when
> interacting with certain scripted objects which want to play their
> own animation on your avatar. This is especially the case for
> "seats" (in the largest extent of the term: i.e. any object you
> "sit" your avatar onto) that usually provide their own sit anim;
> these objects stop the default sit anim (llStopAnimation("sit"))
> then start their own anim. If your AO is configured to override
> the default sit anim, then the overriding anim will also override
> the scripted seat object's anim. In order to solve this problem,
> the Lockmeister protocol
> (https://wiki.secondlife.com/wiki/LSL_Protocol/LockMeister_System#Special_Commands)
>
>
was extended with "bootoff" and "booton" commands ("boot", because
> the first AOs were in fact used in scripted shoes/boots) allowing
> to (respectively) turn off and turn back on the compatible AOs
> automatically. The seat then just has to send a "bootoff" commmand
> when your avatar sits down on it, then a "booton" command when the
> avatar stands up, and your AO gets automatically turned off and
> back on so that the seat's anim is not overridden.
>
> Note that there are other cases than just seats (for example when
> wearing two AOs or, for BDSM folks, when scripted cuffs are used
> and must be able to override an AO in some cases and especially
> when the avatar is fully chained/bound).
Unlike LSL, the viewer would be able to tell when something else is
trying to animate the avatar. I don't know if the FS AO handles this
(I don't actually use the viewer, and I prefer the use flow of an
attachable AO), but it is a possibility where it is not for a scripted
one.
> Also, not all seats/scripted-devices-with-built-in-anims use
> Lockmeister and this results in having to manually disable the AO
> in some cases.
Most don't.
> There is however a caveat to this apparently ideal solution: anim
> states are currently hard-coded with the default anim UUIDs in the
> viewers and a few code paths in the viewers check these to decide
> whether to take some actions (this is true for AGENT_ANIM_WALK,
> for example: see in llvoavatar.cpp): this could cause a few
> glitches and would have to be checked/tested. A solution for these
> few hard-coded code paths/anim states would perhaps be for the
> server to send (play) both the default anim and the overriding anim
> in a row (and also to stop both in reaction to a
> llStopAnimation("walk")): as long as the overriding anim is played
> last and got the same or a higher anim priority, this would still
> work.
What about having the option to just not sending those play messages
for the default anims in the first place?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJPiLEhAAoJEIdLfPRu7qE2eCAIANIsQvZKRkBJV5yEnrXfHdcw
CZJ7qiTiaMaCe9Njn1K6ecyKaWhvRpkvQhCiaL+gb4V6qCoUmDATNTEclF5asIR7
LAg2sKkDaSMGlUwUAaKp9YsMUAaAp+D031nmu0mTVqOY9OPE27UmDgdnz08YW70a
ZxwnYMcExKFenFa6OQWZoNdetVsmPxwbGH5817dyVS1SPf5YXKLVXyji3zND1yJq
yrcxaWOSWvbVAiSsaq3+gXYQdtfd6iASRnhJln2XzMzeQyocHs7xNfT5jwE85URm
T2AkIlwRVdi7xKQV0tyiXivs1eWY0V2Ybs1ElY3m9tkdKo/+FvToUZxTQqrcFjE=
=JLaH
-END PGP SIGNATURE-
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Tutorial needed on TPV viewer-side AOs
On Fri, 2012-04-13 at 22:10 +0200, Henri Beauchamp wrote: > As a result of trying to mitigate this issue, AOs all too often tax the > sim servers by using a very high rate timer that checks the currently > playing anim every frame (llSetTimerEvent(0.02); or less) so to detect > the start of the default animation to be overridden and to start the > corresponding overiding animation as fast as possible. > My timer is ony 0.25, not 0.02. I get very, very little stutter and then only on sims that are too loaded for me to be in anyway. > While it is possible to script relatively "low lag" AOs, especially by > using the control() event and detecting key presses that cause the > walk/turn/run/fly anim changes and then using a lower frequency timer > to catch the rest of the animation changes (e.g. when "falling"), they > are still more laggy (seen from the server side) than a viewer-side AO. > > These flaws are due to the lack of a change() event for animation > changes (time to implement CHANGED_ANIMATION, perhaps ?...) in LSL: if > such an event existed, then the scripted AOs could become just as fast > as viewer-side AOs if not faster (see below about the "ping" problem) > and would not cause any measurable lag (since the high frequency > timer() would then become useless and would be removed). > While CHANGED_ANIMATION would be cool, I would MUCH prefer that key release events could be properly reported. My first version used no timer, but as I couldn't get key releases to trigger the control() event reliably I had to abandon that approach. For some odd reason, when I asked about it on the scripter's list, no one knew what I was talking about. CHANGED_ANIMATION would be usable in more than one case, so perhaps that indeed would be the better way. Downside, of course, is that in order to be used in no-script areas you have to both take controls and have animation permissions in order to keep running. In this case, properly reported key releases would indeed solve the timer problem too. > Viewer side AOs simply watch the animation changes as sent by the > sim server and, when a default animation (ANIM_AGENT_*) is triggered, > the viewer watches its AO table to see if a custom animation should > replace the default one, and in the affirmative, sends stop default > anim/start overriding anim orders to the server. Note that while there > is no lag involved doing so from the server side, the user may still > experience a delay (assimilated to "lag" from their point of view) > if their ping with the sim server is high (a 250ms ping will then > typically result in a half second delay before the default anim gets > overridden as seen by the user in their viewer, thus not providing a > better experience than a scripted AO). > > As mentionned in other messages in this thread, there is also the > problem that the viewer side AOs are currently poorly implemented and > lack region change/TP checks, etc, causing the animation overriding > to fail in some cases, when scripted AOs are not affected (not hard > to fix however... Just a matter or re-coding them properly). > This is true. But still, adding the myriad features used by any group is not going to be simple. from Zi: > *when I'm underwater, apply a vertical impulse of strength X to simulate > > partial buoyancy. > > *when I'm less than half my body height from the surface, attract me to > > the surface and play the treading water animation. > > *add a flight aid boost when I fly up or down so I go a little faster. > > These need external scripting support. That's why I was making the case for scripted AO rather than client-side. Client-side is NOT a bad idea, but it has quite a ways to go before it'll really be capable of taking the place of the scripted versions. The original poster has LOTS of studying and work to do if he's gonna undertake this project ;) > the flexibility of the interface and functionality, there will always be > > holes, sometimes large, that will make it less fit for entire classes of > > people. > > Depends. I am sure most of these gaps can be filled by small supporting > scripts as soon as a standard interface for the AO is in place. LSL interface to the existing (rather, updated) Firestorm LSL bridge? Most of what I mentioned would indeed be doable if the bridge could talk to the AO, and if there were LSL access to the bridge. I'm sure there's a security breach in there somewhere, though, so maybe that wouldn't be a good idea. I'm not too familiar with the bridge, I just wear it.. haha. > *every 6 seconds, play this fidgeting animation. > > *every 30 seconds (the standard) switch stands. > > So two timers instead on just one? Our Viewer side AO supports at least the > animation switch on a defined cycle time. > One timer using several tick counters. In an effort to reduce the timer load as much as I could, I used a 0.25 timer interval, which was about the largest I could get that wouldn't screw up the switching. I wa
Re: [opensource-dev] Tutorial needed on TPV viewer-side AOs
On Fri, 13 Apr 2012 12:16:03 -0400, Oz Linden (Scott Lawrence) wrote:
> Ok... so those are nice opinions to have, but you're not succeeding in
> educating me... what is it that makes these better or worse?
>
> What do they do or not do that differentiates one from another?
Again, the viewer side AOs are in fact mimicking exactly what scripted
AOs (and most specifically Francis Chung's "Franimation Overrider") do.
The scripted AOs got two main flaws (which are in fact the result of
the same lack in the scripted event support): they are often too slow
to change the overriding animation in time to avoid seeing the
overridden animation playing for a second or so before the overriding
anim is started.
As a result of trying to mitigate this issue, AOs all too often tax the
sim servers by using a very high rate timer that checks the currently
playing anim every frame (llSetTimerEvent(0.02); or less) so to detect
the start of the default animation to be overridden and to start the
corresponding overiding animation as fast as possible.
While it is possible to script relatively "low lag" AOs, especially by
using the control() event and detecting key presses that cause the
walk/turn/run/fly anim changes and then using a lower frequency timer
to catch the rest of the animation changes (e.g. when "falling"), they
are still more laggy (seen from the server side) than a viewer-side AO.
These flaws are due to the lack of a change() event for animation
changes (time to implement CHANGED_ANIMATION, perhaps ?...) in LSL: if
such an event existed, then the scripted AOs could become just as fast
as viewer-side AOs if not faster (see below about the "ping" problem)
and would not cause any measurable lag (since the high frequency
timer() would then become useless and would be removed).
Viewer side AOs simply watch the animation changes as sent by the
sim server and, when a default animation (ANIM_AGENT_*) is triggered,
the viewer watches its AO table to see if a custom animation should
replace the default one, and in the affirmative, sends stop default
anim/start overriding anim orders to the server. Note that while there
is no lag involved doing so from the server side, the user may still
experience a delay (assimilated to "lag" from their point of view)
if their ping with the sim server is high (a 250ms ping will then
typically result in a half second delay before the default anim gets
overridden as seen by the user in their viewer, thus not providing a
better experience than a scripted AO).
As mentionned in other messages in this thread, there is also the
problem that the viewer side AOs are currently poorly implemented and
lack region change/TP checks, etc, causing the animation overriding
to fail in some cases, when scripted AOs are not affected (not hard
to fix however... Just a matter or re-coding them properly).
Another, much worst issue with viewer side AOs, is that, like I
explained in my previous message in this thread, they lack a way to
be disabled automatically by scripts.
Let me explain this issue more in details: while AOs are great, they
can be a nuisance when interacting with certain scripted objects which
want to play their own animation on your avatar. This is especially
the case for "seats" (in the largest extent of the term: i.e. any
object you "sit" your avatar onto) that usually provide their own sit
anim; these objects stop the default sit anim (llStopAnimation("sit"))
then start their own anim. If your AO is configured to override the
default sit anim, then the overriding anim will also override the
scripted seat object's anim.
In order to solve this problem, the Lockmeister protocol
(https://wiki.secondlife.com/wiki/LSL_Protocol/LockMeister_System#Special_Commands)
was extended with "bootoff" and "booton" commands ("boot", because
the first AOs were in fact used in scripted shoes/boots) allowing to
(respectively) turn off and turn back on the compatible AOs
automatically.
The seat then just has to send a "bootoff" commmand when your avatar
sits down on it, then a "booton" command when the avatar stands up,
and your AO gets automatically turned off and back on so that the
seat's anim is not overridden.
Note that there are other cases than just seats (for example when
wearing two AOs or, for BDSM folks, when scripted cuffs are used
and must be able to override an AO in some cases and especially
when the avatar is fully chained/bound).
The problem with viewer-side AOs is that since a viewer can't listen
to a private channel, it can't intercept the "booton"/"bootoff"
commands sent by Lockmeister-compatible devices. Of course, you could
use a "bridge" (an object with a script that listens to the
Lockmeister channel and relays the boot* commands to the viewer via
a special llOwnerSay(), à la Restrained Love), but it's IMHO quite
dirty.
Also, not all seats/scripted-devices-with-built-in-anims use Lockmeister
and this results in having to manually disable the AO in some cases.
I think the above
Re: [opensource-dev] Tutorial needed on TPV viewer-side AOs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/13/2012 9:16 AM, Oz Linden (Scott Lawrence) wrote: > Ok... so those are nice opinions to have, but you're not succeeding > in educating me... what is it that makes these better or worse? > > What do they do or not do that differentiates one from another? Gonna try to list pro/cons-ish things about both that I'm aware of. Scripted AO pros: * Work on any viewer * Can natively affect avatar's movements (eg. move faster, fly, swim) * Included as part of an outfit without needed further required actions * "Buy & wear" work flow * Latency-poof for the most part * Unique behaviors through additional scripting Scripted AO cons: * Memory foot print of some AO huds are ridiculously high * Memory and notecard limitations restrict animation lists * Unable to detect when animations are being overridden by another source (eg. pose balls) * Issues related to no-script parcels and script-disabled regions * Unable to react to user actions not exposed in LSL (I don't have an examples of this offhand that client AOs have implemented) * Subject to simulator performance issues (eg. High TD or script time will highly affect them, but movement in general is usually an issue during these events anyway) * Some complicated AOs eat up a none trivial amount of script time/CPU, even compact AOs add up to a lot when a region is near capacity * Updating AO core less than ideal (typically requires repacking all animations and notecards in to new copy of the HUD. Given the normal volume of items involved with these, just viewing the objects inventory is non trivial let alone transferring. This process is not "noob friendly". Could be offset with AO hud that supports and "updater", but these also have their caveats and further add to script load.) Clientside AO pros: * Can detect when animations are being overridden by another source (eg. pose balls) * No script memory impact (unless being fictionally expanded by a worn scripted object) * Ditto for script time impact * Nearly unlimited animation list lengths * Not subject to no-script land and script-disabled regions * Updating AO system considerably easier, only requires updating the viewer Clientside AO cons: * Not supported by every viewer and different viewers' AOs might not function identically (Though most of them use FS one, but not always the same version of it) * Currently cannot be part of an outfit for easy switching (AFAIK. Could be added with some cleverness.) * Subject to simulator-viewer latency * Less than ideal setup flow (minimally requires unpacking to folder in inventory) * Requires viewer update to add features or fix bugs (not sure if that's necessarily a bad thing) Disclaimer: I'm not too familiar with FS's clientside AO. [One thing that was brought up a few times by others is object-to-AO communication support by scripted AOs, and that it could be added to clientside AOs with a relay. But there is a problem with this, not many AOs actually have this feature, nor do many in-world objects make use of it, and the ones that do, use different or unique standards. I wouldn't count this as a major feature of any AO, but might have the possibility to be one if there was a one widely adopted standard.] I had planned for this to be a short list, I guess that didn't happen. The major pros and cons of both are just essentially the technical limitations of doing something in either LSL or on the viewer's end. Ideally I think getting SCR-10 implemented would help scripted AOs be more robust, and adding some sort of minimal support for serverside animation override to help mitigate the latency would make clientside AOs better suited for the average User McResident. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPiIJMAAoJEIdLfPRu7qE2U40H/jcOCNttE0Vj6anUBe8qU3hy 1KMckgM471YMU9WNoCyE8LWoAeA3Exsr1ln0lHzx7Dr4xbGBzLIr6zqYl/qt3RNq tYYnOjb5osl5KAo6kJn3iIyKNi+FYW9MOBrsnCObYyLYpWVy9KvxtUSHYFsw8IGL B41f6QlRBmAhU4Zv6G4LohPyiGvC3T5sPUrpt2cWqIsOeLUW/WFReKCQEboz/EEW uFgi5bFr6BkkZUjlBrOBt59uhg84wh55mOFb3+B6qA/G4zVfBzuVoUYJ/j1DFfnC l7+h1xdpPu1ve7u+DZo3ZRT8PkANxGTYigRC4kPCi2Rm9W4U2Wbj7plwIFFDylk= =tbGR -END PGP SIGNATURE- ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Tutorial needed on TPV viewer-side AOs
Are the non-AO default animations actually transmitted by the viewer? Or does each client already know which animation state the avie is in, and animate them with the correct default animation appropriately? If the entire AO set was something broadcasted to everyone in advance, it would cut down on all the start/stop animation traffic and be truely clientside for everyone. The downside is the newer viewer would be necessary to see official AO's. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Tutorial needed on TPV viewer-side AOs
Am Freitag, 13. April 2012, 19:19:45 schrieb glen: > *listen for this input on this/these channel(s), then turn off/on or > perform another action in response. That's something that needs an external script to forward channel talk to llOwnerSay talk. > *every 6 seconds, play this fidgeting animation. > *every 30 seconds (the standard) switch stands. So two timers instead on just one? Our Viewer side AO supports at least the animation switch on a defined cycle time. > *allow random/sequential animation switches. > *cycles these animations, but not this one. > *know when I'm under water and play my swim anims when I move rather > than my walks & runs & flies. Yep, we do that. > *when I'm underwater, apply a vertical impulse of strength X to simulate > partial buoyancy. > *when I'm less than half my body height from the surface, attract me to > the surface and play the treading water animation. > *add a flight aid boost when I fly up or down so I go a little faster. These need external scripting support. > *disable sit override when being animated by another object that I'm > sitting on. Yep, we have that. > *disallow certain animations to play, or cancel animations started while > sitting on one object but not another. That would need a list of objects and animations ... could get quite large, but entirely possible. > the flexibility of the interface and functionality, there will always be > holes, sometimes large, that will make it less fit for entire classes of > people. Depends. I am sure most of these gaps can be filled by small supporting scripts as soon as a standard interface for the AO is in place. > Server-side, this would only be made worse owing to the need to keep > this kind of load off the sim, which would mean an even further reduced > feature set. Ideally, the AO would be "loaded" only once. After that the viewer does all the work, as it does now. Only the setup should be saved in inventory as a wearable AO inventory item, for example. > Scripted AOs can be made to be *exact* fits for whatever the user wants > or needs, and if well-written, can present a minimum of load to the > server. More load than a client-side AO, to be sure, but good scripting > is good scripting. I agree completely with this. Zi ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Tutorial needed on TPV viewer-side AOs
Client-side AOs don't offer the flexibility that scripted AOs do. Scripted AOs can be made specific to any given use-case. Client-side *COULD* be, but that would imply offering an extremely configurable interface to rival the gamut of options available to scripters. For example: *listen for this input on this/these channel(s), then turn off/on or perform another action in response. *every 6 seconds, play this fidgeting animation. *every 30 seconds (the standard) switch stands. *allow random/sequential animation switches. *cycles these animations, but not this one. *know when I'm under water and play my swim anims when I move rather than my walks & runs & flies. *when I'm underwater, apply a vertical impulse of strength X to simulate partial buoyancy. *when I'm less than half my body height from the surface, attract me to the surface and play the treading water animation. *add a flight aid boost when I fly up or down so I go a little faster. *disable sit override when being animated by another object that I'm sitting on. *disallow certain animations to play, or cancel animations started while sitting on one object but not another. .. ad infinitum. Different communities will needs different sets of options that client-side AOs don't currently offer. No matter the effort put into the flexibility of the interface and functionality, there will always be holes, sometimes large, that will make it less fit for entire classes of people. Server-side, this would only be made worse owing to the need to keep this kind of load off the sim, which would mean an even further reduced feature set. Scripted AOs can be made to be *exact* fits for whatever the user wants or needs, and if well-written, can present a minimum of load to the server. More load than a client-side AO, to be sure, but good scripting is good scripting. Hope that answers. --GC On Fri, 2012-04-13 at 12:16 -0400, Oz Linden (Scott Lawrence) wrote: > On 2012-04-12 17:50 , glen wrote: > > On Thu, 2012-04-12 at 14:09 -0700, Ann Otoole wrote: > >> Thankfully the previously bad aos are not so bad now. If a client side > >> AO cannot perform what Oracul and/or Vista AOs do then it is a total > >> waste of time to bother with the client side code. In order to do > >> client side AOs requires AO expertise. Period. Don't even bother if > >> you don't have it. Because it will be a waste and people will still > >> use AOs. > > Agree. I'm one of the ones who's written a scripted AO. I tried the > > client-side AO in Firestorm and went back to my own because of the > > feature set. A server-side AO would like be even worse. > > > > Ok... so those are nice opinions to have, but you're not succeeding in > educating me... what is it that makes these better or worse? > > What do they do or not do that differentiates one from another? > > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Tutorial needed on TPV viewer-side AOs
On 14/04/2012 3:09 AM, Jamey Fletcher wrote: > Cinder Roxley wrote: > >> An advantage to scripted AO's as has already been stated is that >> bundling the config, AO, and animations into one object that can be worn >> and added to specific Outfits is simpiler and conserves Inventory count. >> AFAIK, any client-side AO relies on animations being unpacked and in the >> user's inventory, sometimes creating additional object links. AFAIK, the >> only client-side AO implientation that doesn't do that relied on an >> external xml config saved to hard disk and was abused by users plugging >> UUID's of animations in which they did not own. It was subsequently >> replaced with another implementation. > One of my friends has different AOs for different outfits - she goes to great > trouble to select animations so that while sitting in a skirt, the hands > don't > go through the skirt during the animation, and similar issues. I'm not > certain > just how many AO sets she has, but it's significant. A dozen sets certainly isn't an unusual number, in my experience - and many people might have quite a few more than that. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Tutorial needed on TPV viewer-side AOs
Am Freitag, 13. April 2012, 18:35:00 schrieb Adeon Writer: > Alright, here's some features that, if missing, *someone* would complain: All of your requirements are present in the Firestorm viewer side AO. > -Adeon Zi ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Tutorial needed on TPV viewer-side AOs
Cinder Roxley wrote: > An advantage to scripted AO's as has already been stated is that > bundling the config, AO, and animations into one object that can be worn > and added to specific Outfits is simpiler and conserves Inventory count. > AFAIK, any client-side AO relies on animations being unpacked and in the > user's inventory, sometimes creating additional object links. AFAIK, the > only client-side AO implientation that doesn't do that relied on an > external xml config saved to hard disk and was abused by users plugging > UUID's of animations in which they did not own. It was subsequently > replaced with another implementation. One of my friends has different AOs for different outfits - she goes to great trouble to select animations so that while sitting in a skirt, the hands don't go through the skirt during the animation, and similar issues. I'm not certain just how many AO sets she has, but it's significant. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Tutorial needed on TPV viewer-side AOs
On 4/13/2012 10:16 AM, Oz Linden (Scott Lawrence) wrote: > On 2012-04-12 17:50 , glen wrote: >> On Thu, 2012-04-12 at 14:09 -0700, Ann Otoole wrote: >>> Thankfully the previously bad aos are not so bad now. If a client side >>> AO cannot perform what Oracul and/or Vista AOs do then it is a total >>> waste of time to bother with the client side code. In order to do >>> client side AOs requires AO expertise. Period. Don't even bother if >>> you don't have it. Because it will be a waste and people will still >>> use AOs. >> Agree. I'm one of the ones who's written a scripted AO. I tried the >> client-side AO in Firestorm and went back to my own because of the >> feature set. A server-side AO would like be even worse. >> > Ok... so those are nice opinions to have, but you're not succeeding in > educating me... what is it that makes these better or worse? > > What do they do or not do that differentiates one from another? For the most part, the only advantages of client-side ao are those that bypass lsl limitations such as working in areas where Run Scripts is disabled and being able to create very large animation sets with almost zero load time to switch (after their initial creation of course.) For example, I have an AO set with 115 stands which cycle, 15 walks, 48 sits, 22 ground sits. This configuration is far greater than what can be configured in a scripted AO because of the lsl's memory limitation. This is probably not a typical use case, but it is an advantage. An advantage to scripted AO's as has already been stated is that bundling the config, AO, and animations into one object that can be worn and added to specific Outfits is simpiler and conserves Inventory count. AFAIK, any client-side AO relies on animations being unpacked and in the user's inventory, sometimes creating additional object links. AFAIK, the only client-side AO implientation that doesn't do that relied on an external xml config saved to hard disk and was abused by users plugging UUID's of animations in which they did not own. It was subsequently replaced with another implementation. To my knowledge all client-side ao's also suffer from region crossing bugs which, for whatever reason, cause them to misinterpret the avatar's state or don't release the animation they were currently in while crossing sims (being stuck in a falling flight state being the most common that I've encountered.) Scripted ao's, of course, don't suffer this. Scripted AO's can listen for commands from other objects in the region more easily and interact better when they've been scripted to do so. There are patches floating around that add compatibility with lockmeister and whatnot, but there is no standard viewer api for such cases. kind regards, -Cinder ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Tutorial needed on TPV viewer-side AOs
Alright, here's some features that, if missing, *someone* would complain: -Any given AO needs to be able to have multiple stand, sit, and groundsit animations. Stands needs a choice of either playing them sequentially, randomly, or on a set timer. For sits, people want choices of which sit of many to use so they can switch between them while sitting. In both cases, the amount of animations you can put on one slot shouldn't be capped. It would actually be going the extra mile to let ANY slot have multiple on a choice/sequential/random/timer, if it can be done without over complicating the UI. (by the way, the "slots" I am referring to are all of the possible return values from llGetAnimation, plus some extras like typing animation) -Secondly, an easy way to turn the whole thing on or off (without taking it off) is needed, AND a way to just turn the sit override on it off but keep the rest on The most common AO is the ZHAO-II AO HUD, it's open-source and is usually the standard as far as features go. As far as new features go, I would look into all of the system animations an avatar can do, and consider allowing them to be replaced too. (Example, the shout, chat, away, and voice animations are not always included features of AO's, but they make great candidates.) -Adeon On Apr 13, 2012, at 12:16 PM, "Oz Linden (Scott Lawrence)" wrote: > On 2012-04-12 17:50 , glen wrote: >> On Thu, 2012-04-12 at 14:09 -0700, Ann Otoole wrote: >>> Thankfully the previously bad aos are not so bad now. If a client side >>> AO cannot perform what Oracul and/or Vista AOs do then it is a total >>> waste of time to bother with the client side code. In order to do >>> client side AOs requires AO expertise. Period. Don't even bother if >>> you don't have it. Because it will be a waste and people will still >>> use AOs. >> Agree. I'm one of the ones who's written a scripted AO. I tried the >> client-side AO in Firestorm and went back to my own because of the >> feature set. A server-side AO would like be even worse. >> > > Ok... so those are nice opinions to have, but you're not succeeding in > educating me... what is it that makes these better or worse? > > What do they do or not do that differentiates one from another? > > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Tutorial needed on TPV viewer-side AOs
Alright, here's some features that, if missing, *someone* would complain: -Any given AO needs to be able to have multiple stand, sit, and groundsit animations. Stands needs a choice of either playing them sequentially, randomly, or on a set timer. For sits, people want choices of which sit of many to use so they can switch between them while sitting. In both cases, the amount of animations you can put on one slot shouldn't be capped. It would actually be going the extra mile to let ANY slot have multiple on a choice/sequential/random/timer, if it can be done without over complicating the UI. (by the way, the "slots" I am referring to are all of the possible return values from llGetAnimation, plus some extras like typing animation) -Secondly, an easy way to turn the whole thing on or off (without taking it off) is needed, AND a way to just turn the sit override on it off but keep the rest on The most common AO is the ZHAO-II AO HUD, it's open-source and is usually the standard as far as features go. As far as new features go, I would look into all of the system animations an avatar can do, and consider allowing them to be replaced too. (Example, the shout, chat, away, and voice animations are not always included features of AO's, but they make great candidates.) -Adeon - On Apr 13, 2012, at 12:16 PM, "Oz Linden (Scott Lawrence)" wrote: > On 2012-04-12 17:50 , glen wrote: >> On Thu, 2012-04-12 at 14:09 -0700, Ann Otoole wrote: >>> Thankfully the previously bad aos are not so bad now. If a client side >>> AO cannot perform what Oracul and/or Vista AOs do then it is a total >>> waste of time to bother with the client side code. In order to do >>> client side AOs requires AO expertise. Period. Don't even bother if >>> you don't have it. Because it will be a waste and people will still >>> use AOs. >> Agree. I'm one of the ones who's written a scripted AO. I tried the >> client-side AO in Firestorm and went back to my own because of the >> feature set. A server-side AO would like be even worse. >> > > Ok... so those are nice opinions to have, but you're not succeeding in > educating me... what is it that makes these better or worse? > > What do they do or not do that differentiates one from another? > > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Tutorial needed on TPV viewer-side AOs
On 2012-04-12 17:50 , glen wrote: > On Thu, 2012-04-12 at 14:09 -0700, Ann Otoole wrote: >> Thankfully the previously bad aos are not so bad now. If a client side >> AO cannot perform what Oracul and/or Vista AOs do then it is a total >> waste of time to bother with the client side code. In order to do >> client side AOs requires AO expertise. Period. Don't even bother if >> you don't have it. Because it will be a waste and people will still >> use AOs. > Agree. I'm one of the ones who's written a scripted AO. I tried the > client-side AO in Firestorm and went back to my own because of the > feature set. A server-side AO would like be even worse. > Ok... so those are nice opinions to have, but you're not succeeding in educating me... what is it that makes these better or worse? What do they do or not do that differentiates one from another? ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Tutorial needed on TPV viewer-side AOs
On Fri, 2012-04-13 at 11:00 +0100, Nexii Malthus wrote: > Would be best to have the AO server-based, to cut on roundtrip latency > especially being from europe, and using script-based language to > define how and when the animations should kick in. > > > Oh right, we got LSL. Why not improve LSL to make it more efficient? > As an AO creator I'd like to have the "agent change" > event: https://jira.secondlife.com/browse/SCR-10 > > > And more than 64KB memory per script to cut on the significant amount > of unnecessary overhead across multiple > scripts: https://jira.secondlife.com/browse/SVC-3581 > > > It's these more simple server-side fixes and improvements that would > make client-side AOs unnecessary. > > > - Nexii I think that client-side AOs are fairly unnecessary now, without those jiras. I do agree that anyone adding one to a TPV needs to study more than just their own use-case if adding one anyway. Different people in different communities will have different needs - Henri's Lockmeister mention is a good case in point. --GC ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Tutorial needed on TPV viewer-side AOs
Adding entirely new "slots" to AO's (running against a wall, standing on a ledge, running at various inclines, swimming in system water) is one of the things you can only do do programmatically. But a base "animation replacer" client AO to get rid of the official animations is still handy. A script can just handle all the extra, where it's actually necessary. On Apr 13, 2012, at 10:14 AM, Stickman wrote: >> Agree. I'm one of the ones who's written a scripted AO. I tried the >> client-side AO in Firestorm and went back to my own because of the >> feature set. A server-side AO would like be even worse. > > I've written scripted AOs, and while I'm not familiar with the > clientside AOs, I know that a scripted AO is significantly more > powerful than a clientside AO on one very important point: > > A scripted AO can be quickly and easy be changed. Features can be > added or removed. Say someone has the bright idea to add extra > "one-shot" animations, such as a stumble to break up a repetitive > running cycle, it can be added without much fuss. While a clientside > AO built into the viewer, unless built in a way to support it, > couldn't do such a thing. > > More support for a clientside AO wouldn't be a bad thing. But it > couldn't, and probably shouldn't completely replace scripted AO. > > Stickman > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Tutorial needed on TPV viewer-side AOs
> Agree. I'm one of the ones who's written a scripted AO. I tried the > client-side AO in Firestorm and went back to my own because of the > feature set. A server-side AO would like be even worse. I've written scripted AOs, and while I'm not familiar with the clientside AOs, I know that a scripted AO is significantly more powerful than a clientside AO on one very important point: A scripted AO can be quickly and easy be changed. Features can be added or removed. Say someone has the bright idea to add extra "one-shot" animations, such as a stumble to break up a repetitive running cycle, it can be added without much fuss. While a clientside AO built into the viewer, unless built in a way to support it, couldn't do such a thing. More support for a clientside AO wouldn't be a bad thing. But it couldn't, and probably shouldn't completely replace scripted AO. Stickman ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Tutorial needed on TPV viewer-side AOs
On 13/04/2012 11:29 PM, Robert Martin wrote: > The only real thing that HUD AOs have that a client side AO can do is > the various "buttons" for different things. I normally (back when i > was inworld) used a Dire Wolf > this has a bunch of different functions (different animations and > recoloring things) also will we ever get a way to do a true Quad frame > (with Mesh Avatars would be good)? since that i think would drop a > couple scripts from the AO. > > My opinion is that looking at what all is done in AOs and then seeing > if it can be done server side/or in viewer would be a good idea. Certainly. The current viewer-side AOs are actually incomplete because of the lack of access to modify grid and protocol code. Studying the use of actual in-world AOs would yield more and better information than studying the current viewer-side AOs. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Tutorial needed on TPV viewer-side AOs
The only real thing that HUD AOs have that a client side AO can do is the various "buttons" for different things. I normally (back when i was inworld) used a Dire Wolf this has a bunch of different functions (different animations and recoloring things) also will we ever get a way to do a true Quad frame (with Mesh Avatars would be good)? since that i think would drop a couple scripts from the AO. My opinion is that looking at what all is done in AOs and then seeing if it can be done server side/or in viewer would be a good idea. -- Robert L Martin ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Tutorial needed on TPV viewer-side AOs
On 2012-04-13, at 00:09, Adeon Writer wrote: > Wouldn't a new inventory item type make most sense? That way it could be put > in with any outfit folder or packaged with sold avatars. For a LL-provided feature, yes. I was still disappointed when TPVs didn't implement something like an "AO attachment point" that accepted a box containing a notecard and animations ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Tutorial needed on TPV viewer-side AOs
Would be best to have the AO server-based, to cut on roundtrip latency especially being from europe, and using script-based language to define how and when the animations should kick in. Oh right, we got LSL. Why not improve LSL to make it more efficient? As an AO creator I'd like to have the "agent change" event: https://jira.secondlife.com/browse/SCR-10 And more than 64KB memory per script to cut on the significant amount of unnecessary overhead across multiple scripts: https://jira.secondlife.com/browse/SVC-3581 It's these more simple server-side fixes and improvements that would make client-side AOs unnecessary. - Nexii On Fri, Apr 13, 2012 at 6:49 AM, Tateru Nino wrote: > I think it would make more sense than overloading an existing item type > - but that's a server-side mechanics issue. > > The important thing would seem to be how to keep the current existant AO > user-experience at the viewer. But that would (yes) have to be kept in > lockstep with the grid side of the equation. So, there's undoubtedly > some protocol work involved too, perhaps an additional message type. > > On 13/04/2012 3:09 PM, Adeon Writer wrote: > > Wouldn't a new inventory item type make most sense? That way it could be > put in with any outfit folder or packaged with sold avatars. > > > > On Apr 12, 2012, at 10:42 PM, Tateru Nino wrote: > > > >> > >> On 13/04/2012 11:30 AM, Argent Stonecutter wrote: > >>> The overhead of a conservative scripted AO is pretty low, and the > ability to switch AOs by wearing an asset (attaching the AO HUD) means that > I can have appropriate AOs for each of my avatars and outfits without > having to tweak my client settings each time I jump from kangaroo to > grasshopper to dolphin to ferret... > >> Absolutely - if we were talking client or server-side AOs, they'd have > >> to be linked to outfits or wearables somehow to maintain parity with > >> common use-cases. > >> ___ > >> Policies and (un)subscribe information available here: > >> http://wiki.secondlife.com/wiki/OpenSource-Dev > >> Please read the policies before posting to keep unmoderated posting > privileges > >> > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
