ZHAO-II Update

That was the reaction I had when Siggy refused to divulge what to chat to talk to his swimmer... so I could make my prim water and underwater house compatible... on similar grounds. Griefing people by turning their anim off is SO a non-issue.

Right, and that's a virtually zero effort thing to do.

Seamless sit doesn't use a listener at all, yet it works with vastly more objects.


Just because you write THE SIT PRIM in all caps doesn't mean that it is such a thing. The sender is the sender. It takes close to zero effort to get a nearby avatar's key, "try hard enough" does not apply.



And that is exactly the point, you can turn off autozhao and do things manually, so why bother to implement it in the first place? Seamless sit is far closer to universal and doesn't have this issue.

We removed AutoZHAO from our own AO scripts precisely because there absolutely WERE complaints about its shortcomings. I suppose that we could have written these people back, and tried to explain to them how silly they were, by insisting that only a SIT PRIM IN ALL CAPS could possibly do that, that the issue was entirely in their imaginations, and that they should just suck it up and not use the feature. Instead, we decided to admit we made a big mistake by adopting that protocol, and removed it.


There were additional autozhao failure modes behind that decision.

1, autozhao failed to work at all if the llSitTarget offset was more than three meters from the chatting SIT PRIM IN ALL CAPS, limiting the variety of objects that could successfully employ it. Seamless sit has no such limitation since it looks directly at the avatar's state and animations.

2. autozhao sometimes failed to turn the AO back on, _even with the provided reference pose stand_. It was unable to cope with the occasional bouncy unsit of the sort that seems to be more common at at high altitudes. We were able to alleviate this protocol flaw by remembering the sit and autozhao states, then re-enabling internally at stand time.

3. autozhao failed to handle the case of an avatar that sat directly on another object without standing first. Avatars very commonly do this, it is good old "poseball hopping". If the first SIT PRIM IN ALL CAPS sent autozhao commands and the second object did not, and the two objects were nearby, the first SIT PRIM IN ALL CAPS would inappropriately turn the AO back on. Our workaround for flaw 2 was expanded to address this failure as well. If the two objects were not so close to each other, the failure mode was essentially the same as flaw 2.

4. autozhao failed when the avatar teleported away before standing. The workaround for 2 pretty much took care of that.

5. The final flaw was the one I mentioned upthread, that the autozhao protocol didn't check if the avatar was sitting. At this point we already had to track the sitting and bypass states, so what purpose did that chat even serve? ZHAO-II was already calling llGetAnimationList to handle some other exceptions, so it was easier and more reliable to look for a running "sit" and omit the listener altogether. We saw that Moeka's approach worked well with the handful of extant "autozhao enhanced" devices as well as most other vanilla sit scripts.

The original seamless sit AO did have some minor bugs of its own, but conceptually it was quite sound and it lent itself well to streamlining.

We did learn of a single legitimate device that was slightly reduced in functionality by this change. It was a chimera-type script so there was no SIT PRIM IN ALL CAPS. Of course, that feature would work only sporadically depending on the avatar distances, so it wasn't a big deal.

That is bullshit. Some people become very much attached to their avatars and become rather upset when failures like that break their immersion. To them it's as upsetting as any other deformation, even though those are also easily fixed. Surely you must be aware that the AO is often integral to the avatar's basic appearance, with folding and such!

Gee Viktoria. so nice you bothered to tell me/us about that, it's been out for over.. oh, 14 months.. and you found these issues when? (checks inventory) Nope, nothing from you to tell us about the problem, we would have (and will) fix it. But I think a timely notecard would have been better than waiting to say something here.

One of us did in fact try to send a notecard in early 2008 and it was never acknowledged. Nonetheless, my logs show that on 24 July 2008 you went down to Hanson and picked up a copy of our scripts. The vendor text spelled out that there were autozhao fixes, the description and credits file also mentioned this, and the comments at the top of the core script (edit to add: those comments are at the top of the interface, that was to keep them in the same neighborhood as the original patch), spelled out exactly what workarounds we had added.

You're assuming that it would ever happen. That's assuming a hell of a lot.

Why would a griefer bother to turn off an AO (once, since you'd disable that option after the first time) when they can toss you a couple of sims over, orbit you, surround you with tubgirl particles, and so on? It's a non-issue not because nobody would be bothered by it, but because so few people would be bothered by it and even with them it has no repeat play opportunity so griefers would have no incentive to use it as an attack.

I'm not assuming anything, it was actually being done and it was shown to me.

Hrmmm, we know how reliable SL is in that regards don't we? And as far as picking up a copy of your scripts.. don't remember, so can't say one way or another. Oh well, just another project for me to add to the stack

Oh.. and one tiny point... you're absolutely right, the AutoZHAO protocol doesn't keep track of sit/stand status.. THAT'S YOUR (sit script's) JOB! the AutoZHAO just tells it ON/OFF, nothing more.

-end of line-

(oh, I agree with Argent, you're making a monolith out of a flea-speck on the 'griefing' issue)

Proof of concept doesn't make it a real threat in use in the wild.

Symantec came up with a proof of concept for a PalmOS virus to scare people to getting Norton Antivirus for the Palm. There was NEVER an actual virus in the wild for PalmOS, but a number of people got their palms *and* backups trashed by Norton.

Perhaps, but your arguments in defense of the protoco's robustness aren't valid.

Victoria is correct that with AutoZhao, it's trivial for someone to write a spoof script to turn someone else's AO on or off (if they're within 3M of your spoofer). However, it's not trivial to figure out whether someone's AO supports AutoZhao (other than by trying it and watching).

Whether anyone would bother is another issue. I tend to agree with Argent that it's a non-issue. If AutoZhao was very popular and implemented in most everyone's AO, then it's likely that a few idiots would find fun spoofing it. Furthermore, if someone does spoof your AutoZhao AO, you can easily turn off the feature and you're no longer bothered.

So, hardly an issue, but let's face the facts and not deny that it's easily spoofed (from within 3M).

That's nice but irrelevant, because I changed things in response to a support request, not some theoretical clean room proof of concept. The person was actually, for real, being harassed by that and a variety of other annoyances in a certain location. When the usual IM troubleshooting stuff bore no fruit, I asked to be shown the area and was allowed to visit, but was unable to reproduce it on my own avatar. We tried punching more settings on his AO to isolate the cause. The problem followed autozhao, so I set up a listener to see what was up. There were little objects following this avatar around. I don't know the entirety of tricks those object were performing because I was concentrating on the AO issue. I did IM the owner of the followers to ask what the deal was, and the explanation, in its entirety, was, and I quote, "lol". And that was that, I wasn't going to continue distributing something that allowed crap like that.

And did you AR the piss-poor griefers involved?

I submitted what I saw, I don't know if the person I was helping out sent anything in. As is usual with AR stuff, I've no idea if anything became of it.

Well, anyway, I apologize. There is no griefing technique so wimpy some griefer isn't lame enough to actually try it.

.... and I never denied it. But then how else can you use it on something you don't own? Oh yes, could ask permission every time you sat down, sorta defeats the purpose. It works for for all our customers but I never said it was perfect... but it works for what it does, and it's working quite well if you tell your .. er.. sit agent (script?, prim?) to turn it on/off.. and that's all it was ever designed to do... turn it off, turn it on.

Seems to me that you did:

Let's just let this go, OK? AutoZhao is not evil. It can be griefed, though there's an easy workaround (turn the feature off until the idiot who's griefing you gets bored).

Hey, I'm not the one that waited over a year to bring the issue up Oh and er...



and now I scurry back to the workshop.

Really, you don't remember going out of the way to a mainland sim that really had nothing interesting in it, and picking up a copy of one of the very few AOs that ever tried to implement this protocol that you now seem to care so deeply about? And you had no interest at all in even peeking at what those changes to your code might be?

You simply didn't care, did you? Why are you pretending to care now?



The broken AutoZHAO code I used originally came from YOUR AO SCRIPTS which today continue to fail to do any job like that. YOU did not do YOUR JOB. We did ours.

You don't get to blame others for your broken code. You can stick to the story that you never got any notecards about these bugs (you did acknowledge one her earlier reports, a naming bug that prevented the load button from ever working). However, you belatedly acknowledged your awareness of the patched AO by personally visiting a backwater sim with no real places of interest, and personally picking up at least one copy of the changes.

No one but you can shoulder the responsibility for ignoring them again for over 15 months after you had that in your hands.

And DON'T YOU DARE accuse ME of making a "monolith out of a flea-speck". YOU are the one who entered this thread and engaged me, spouting misinformation and blaming others for your mistakes.

Jeeze, you really need to try some decaf

LOL, can't take what you dish out.

...then along comes Emerald with a client side AO built into the viewer...

test

Sorry I'm late to the party. The ZHAO is long overdue for an update, I
think, and since I have a 2-year old running around now, I really
haven't been on SL much. So I'm glad someone else is thinking about it
Haven't read through the whole thread, but here are some ideas I've
had for a while:

* Pull out the notecard parser into a separate script, and extend the
link message API to allow it to feed animations to the main AO script.
This will save a little bit of memory which means a few more animations
(you'll be surprised how many people come to me with stack-heap
collision crashes). More importantly, it will let custom av builders and
others use a different scheme for specifying animations. Different
notecard format, or hard-coded in the script, or whatever. Just remember
to hook it up to the 'reset' functionality, so the animation list gets
sent out again to the AO.

* Add a typing override to the notecard. Support for this has been
spotty, I think some of the modified ZHAO versions have this, and plenty
of people have asked me for it.

Sorry I'm late to the party. The ZHAO is long overdue for an update, I think, and since I have a 2-year old running around now, I really haven't been on SL much. So I'm glad someone else is thinking about it Haven't read through the whole thread, but here are some ideas I've had for a while:

* Pull out the notecard parser into a separate script, and extend the link message API to allow it to feed animations to the main AO script. This will save a little bit of memory which means a few more animations (you'll be surprised how many people come to me with stack-heap collision crashes). More importantly, it will let custom av builders and others use a different scheme for specifying animations. Different notecard format, or hard-coded in the script, or whatever. Just remember to hook it up to the 'reset' functionality, so the animation list gets sent out again to the AO.

* Add a typing override to the notecard. Support for this has been spotty, I think some of the modified ZHAO versions have this, and plenty of people have asked me for it.

test