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 <tateru.n...@gmail.com> 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 <tateru.n...@gmail.com> 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