here's the repository git://github.com/cmickeyb/opensim.git there is still a lot of debugging to do & i need to re-enable the compatibility. without changes to the login server (and the robust appearance save) you won't see much benefit. those changes are available for simian in a separate patch.
--mic On Wed, Oct 20, 2010 at 1:52 PM, Mic Bowman <[email protected]> wrote: > > > On Wed, Oct 20, 2010 at 1:32 PM, Melanie <[email protected]> wrote: > >> Hi, >> >> >> The avatar appearance (avatar service) is a name-value pair storage >> >> anyway, so it could easily hold the UUIDs of baked textures along >> >> with the components of the avatar appearance. It could also hold the >> >> visual params, the question there is to what degree that is useful. >> >> >> >> >> > the encoding i have right now is one string (OSDMap) for all of the >> > appearance >> > assets. when i looked at the userdata code, i think every field/value >> pair >> > generates >> > a separate database update. and given that the appearance gets re-saved >> for >> > every attachment right now (that is, on login the attachments module >> forces >> > a save of the appearance once for each attachment even for attachments >> that >> > are already in the appearance data) that seemed like a lot of db writes. >> > >> > could you expand the size of the string value that can be stored to >> medium >> > string? >> > that would be enough size to handle the encoding i'm using. >> > >> > >> >> Having one row for each item is highly desirable, as it is easy to, >> for instance, programmatically detach a single attachment, or unwear >> a single wearable, like through a website. Storing the entire >> appearance in one OSD is not what we would want. The overhead of >> rewriting 27 rows is negligible in such a small table. >> >> > The way the code currently works... it uses the single encoding for > agentcircuitdata, clientagentdataupdate, and it uses that encoding in the > copyto/copyfrom methods in scene presence. I kept the IAvatarData code and > the get/setavatar functions so that (in theory) i wouldn't have to change > any of the behavior in the ROBUST AvatarService (so it can still be > key/value pairs passed around). I've modified the simian connectors to use > the full encoding (which greatly simplifies the code there). I have not > looked at how to provide the correct encoding for login from ROBUST. again, > it was a pretty simple three line code change for simian to send it because > thats what is being stored directly in the user data. that is, having one > encoding that spans the services dramatically simplified the login process > as well. using a separate format for the avatarservice can work... but > you'll have to encode it in form the login service needs. > > --mic > >
_______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
