[Opensim-dev] MOAP : avatar appearance works fine now
Justin Clark-Casey
jjustincc at googlemail.com
Wed Jul 14 00:27:55 UTC 2010
On 14/07/10 01:16, Enrico Ranucci wrote:
> Hi there, talking with Ai Austin we decided to install a complete demo
> of Justin's moap with a full installation of Simian Frontend so folks
> can see the web on a prim dev.
> Here are the good news :
>
> 1. Avatar appearance now works fine with Snowglobe 2.0.1 !!! This is
> because the Simian ships a default_assets folder pointed by the
> demo installation of tonight ;)
Hi Enrico. Yes, I recently found out that appearance should work okay with version 2 viewers and OpenSim, though one
needs to set up an outfit with all 4 body parts (shape, eyes, etc.) first - this can get rather fiddly. Also, it
appears that one needs an eye texture - otherwise the avatars have disconcertingly blank eyes.
> 2. You can register to the demo-MOAP here :
> http://95.110.224.250/GridFrontEnd/
> 3. Download Snowglobe last release and login with loginuri
> http://95.110.224.250/Grid/login/ (note the trailing slash !!!)
> 4. Current release is R13260. We will follow Justin's job everynight
> and install the newest release.
> 5. Join and test it hardly ;)
> 6. In the next days we will try to install all scalable modules
> (search, voice...etc) any help by devs for installation is
> appreciated;)
> 7. If any of u needs to load iar/oar to the demo server contact me
Testing is welcome, though please remember that this is a work-in-progress so I would hold off from filing any mantises
for now. One thing you might want to try are the LSL methods for manipulating prim media - I've implemented these but
not tested them yet so I wouldn't be surprised if they are broken.
So far, only sqlite persistence is implemented and the format of this might change, so please don't store anything of
value since I won't be doing any migrations. The major thing left to implement is the url whitelist (which annoyingly
doesn't appear to be documented and has no example scripts). There are also some bugs to squash - for instance, drag
and drop doesn't yet work because the viewer doesn't send out object media navigate messages in this circumstance
(unlike the manual media texture setup).
Putting on other modules (search, voice, etc.) shouldn't be necessary unless you are also testing other things.
>
>
> Ty again Justin and ty to all of u devs !!!
Thanks, always good to know the efforts are appreciated :)
>
> Enrico Nirvana
>
> > From: opensim-dev-request at lists.berlios.de
> > Subject: Opensim-dev Digest, Vol 35, Issue 35
> > To: opensim-dev at lists.berlios.de
> > Date: Tue, 13 Jul 2010 19:17:28 +0200
> >
> > Send Opensim-dev mailing list submissions to
> > opensim-dev at lists.berlios.de
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
> > or, via email, send a message with subject or body 'help' to
> > opensim-dev-request at lists.berlios.de
> >
> > You can reach the person managing the list at
> > opensim-dev-owner at lists.berlios.de
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of Opensim-dev digest..."
> >
> >
> > Today's Topics:
> >
> > 1. MOAP : avatar appearance works fine now (Enrico Ranucci)
> >
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Tue, 13 Jul 2010 19:17:24 +0200
> > From: Enrico Ranucci <enrico.ranucci at live.it>
> > To: <opensim-dev at lists.berlios.de>
> > Subject: [Opensim-dev] MOAP : avatar appearance works fine now
> > Message-ID: <BAY155-w38F0F96B17B0BA0028F2C58CB90 at phx.gbl>
> > Content-Type: text/plain; charset="windows-1252"
> >
> >
> >
> > Hi there, ty Justin for you reply. I found out avatar appearance
> working fine with Snowglobe release 2.0.0 and your moap. Also Web on a
> prim works fine ;)With 2.0.1 it does not work ;(
> > Everyone is interested to test Justin's release, i'm running a demo
> stand alone where users can see Web On a Prim working (using Snowglobe
> 2.0.0)You can reach it using loginuri http://95.110.224.250:9020 and
> Test User qwertyuiop as First,Last,Password.If u need your account
> contact me, i will provide a valid user for u.Ty again to Justin and all
> opensim developer for making OS everyday more "cool"
> > Enrico Nirvana
> > > From: opensim-dev-request at lists.berlios.de
> > > Subject: Opensim-dev Digest, Vol 35, Issue 7
> > > To: opensim-dev at lists.berlios.de
> > > Date: Mon, 5 Jul 2010 12:00:05 +0200
> > >
> > > Send Opensim-dev mailing list submissions to
> > > opensim-dev at lists.berlios.de
> > >
> > > To subscribe or unsubscribe via the World Wide Web, visit
> > > https://lists.berlios.de/mailman/listinfo/opensim-dev
> > > or, via email, send a message with subject or body 'help' to
> > > opensim-dev-request at lists.berlios.de
> > >
> > > You can reach the person managing the list at
> > > opensim-dev-owner at lists.berlios.de
> > >
> > > When replying, please edit your Subject line so it is more specific
> > > than "Re: Contents of Opensim-dev digest..."
> > >
> > >
> > > Today's Topics:
> > >
> > > 1. Cloudy avatar on snowglobe 2.0.1 or sl2 (was Re: Opensim-dev
> > > Digest, Vol 35, Issue 3) (Justin Clark-Casey)
> > > 2. Re: [Opensim-users] OpenSim Roadmap (Justin Clark-Casey)
> > > 3. JSON or XML for serialization in the OpenSim database?
> > > (Justin Clark-Casey)
> > > 4. compiling viewer-external with ubuntu 64bit (Marc Adored)
> > > 5. Re: compiling viewer-external with ubuntu 64bit (Marc Adored)
> > > 6. Re: JSON or XML for serialization in the OpenSim database?
> > > (Impalah Shenzhou)
> > >
> > >
> > > ----------------------------------------------------------------------
> > >
> > > Message: 1
> > > Date: Mon, 05 Jul 2010 00:34:46 +0100
> > > From: Justin Clark-Casey <jjustincc at gmail.com>
> > > To: opensim-dev at lists.berlios.de
> > > Subject: [Opensim-dev] Cloudy avatar on snowglobe 2.0.1 or sl2 (was
> > > Re: Opensim-dev Digest, Vol 35, Issue 3)
> > > Message-ID: <4C311A96.8000409 at googlemail.com>
> > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> > >
> > > On 03/07/10 11:50, Enrico Ranucci wrote:
> > > > Hi, there. I'm running the Justin's "moap" with a fresh mysql db.
> Web on
> > > > a prim works fine but using snowglobe 2.0.1 or sl 2, avatar
> appears as a
> > > > cloud. any suggestions ? (which viewer is using Justin for
> testing moap?)
> > >
> > > Hi Enrico. I'm using the SL version 2 viewer as well and see the
> same kind of problems with appearance. I believe this
> > > is because OpenSim has not yet implemented support for the
> appearance/clothing layer changes seen in the version 2 viewers.
> > >
> > > Either these changes will be implemented in OpenSim at some point
> and/or perhaps one of the third party viewers will
> > > implement support for the shared media capabilities.
> > >
> > > Just fyi, work on moap might be slow in the next week since I'm on
> holiday. It should pick up again after that.
> > >
> > > --
> > > Justin Clark-Casey (justincc)
> > > http://justincc.org
> > > http://twitter.com/justincc
> > >
> > >
> > > ------------------------------
> > >
> > > Message: 2
> > > Date: Mon, 05 Jul 2010 01:28:30 +0100
> > > From: Justin Clark-Casey <jjustincc at gmail.com>
> > > To: opensim-users at lists.berlios.de
> > > Cc: opensim-dev at lists.berlios.de
> > > Subject: Re: [Opensim-dev] [Opensim-users] OpenSim Roadmap
> > > Message-ID: <4C31272E.6030706 at googlemail.com>
> > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> > >
> > > On 03/07/10 12:07, Clive Gould wrote:
> > > > Hi
> > > >
> > > > We're presenting the results of Bromley Colleges OpenSim Project at
> > > > the Future Learningscapes: a 21st Century Challenge conference at
> > > > Greenwich University (UK) next Wednesday (7th July).
> > > >
> > > > Just in case we are asked, can anyone explain OpenSim's roadmap? Why
> > > > is it still in Alpha and what are the criteria for it getting into
> > > > Beta and eventually version 1.0?
> > >
> > > We haven't had a formal roadmap for quite a while. I think partly
> this is because of unpredictability about what's
> > > going to happen with virtual environments, partly because the
> project is still very young without surplus developers to
> > > spend time drawing them up :) and partly because the project isn't
> controlled by a single organization or person that
> > > could impose such a thing.
> > >
> > > However, I'll hazard a personal guess that in the medium-term
> future we'll see media on a prim and general compatibility
> > > with version 2 browsers, continued development of hypergrid, more
> code modularization, mesh support, continued
> > > improvements in base performance and reliability and scene object
> refactoring to enable features such as multi-level
> > > linking. Some of this will be driven by viewer development. And
> ultimately, everything is driven by user and developer
> > > requirements, desires and effort/money expenditure :)
> > >
> > > I would say that OpenSim is still considered alpha for various
> reasons, including but not limited to
> > >
> > > 1) Current instability in core OpenSim itself.
> > > 2) Instability in supporting platforms (e.g. mono appears to have
> issues with high load). This is particularly obvious
> > > on relatively high-use public grids such as OSGrid.
> > > 3) Current instability in some features (e.g. setting multiple
> textures is hit and miss).
> > > 4) Inconsistency in user-facing interfaces (e.g. help on the
> console is very unstructured).
> > > 5) Inconsistency and immaturity of module facilities.
> > > 6) The prospect of future changes in some fundamental structures
> (e.g. scene object refactoring).
> > > 7) Reasonably expected features missing (e.g. no coalesced objects).
> > > 8) Bad legacy communications interfaces (e.g. the 'wire' protocol
> for inventory service communication is low quality
> > > and inconsistent).
> > >
> > > This probably sounds rather pessimistic but I think that we've come
> an awful long way and it's far more valuable early
> > > on to have rough. working code than spend much time on up-front
> planning. But I also believe that we couldn't
> > > justifiably move to beta without addressing a reasonable number of
> these issues.
> > >
> > > Good luck with the conference! Hope you make a few OpenSim converts :)
> > >
> > > Regards,
> > >
> > > --
> > > Justin Clark-Casey (justincc)
> > > http://justincc.org
> > > http://twitter.com/justincc
> > >
> > >
> > > ------------------------------
> > >
> > > Message: 3
> > > Date: Mon, 05 Jul 2010 01:28:39 +0100
> > > From: Justin Clark-Casey <jjustincc at gmail.com>
> > > To: opensim-dev at lists.berlios.de
> > > Subject: [Opensim-dev] JSON or XML for serialization in the OpenSim
> > > database?
> > > Message-ID: <4C312737.7010103 at googlemail.com>
> > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> > >
> > > Hi folks,
> > >
> > > As part of the media-on-a-prim implementation, I'm serializing the
> parameters for a media texture to the database. This
> > > seems better than creating new database fields or even a whole new
> table for these parameters, both because there are
> > > lots of them (url, scaling, controls, whitelist, etc.) and because
> different future virtual environments may want to
> > > store different things.
> > >
> > > I'm going to serialize them as an OSDArray or MediaEntrys using the
> libopenmetaverse library. However, the question
> > > then becomes whether to use the JSON representation or the XML
> representation.
> > >
> > > I tend to prefer XML for storage representations. I believe that
> it's somewhat more human readable and that there is
> > > better tool support for manipulating it. However, I know other
> people would prefer storage in JSON and I accept that
> > > serialization/deserialization there may be slightly faster.
> > >
> > > The only other example of serialization that I know of in OpenSim
> currently is that of SceneObjectGroups into inventory,
> > > which encompasses object properties, object inventory properties
> and script state. This is done in XML and media
> > > entries would become part of that serialization.
> > >
> > > If there's a majority preference for JSON I don't mind using that
> instead, though I would want a justification for going
> > > this route rather than XML. If there's no real argument then I will
> go with XML.
> > >
> > > Also, I believe that we should try and be consistent, so picking
> one or the other now should make it more likely that
> > > the same approach would be used for the next serialization case.
> > >
> > > Regards,
> > >
> > > --
> > > Justin Clark-Casey (justincc)
> > > http://justincc.org
> > > http://twitter.com/justincc
> > >
> > >
> > > ------------------------------
> > >
> > > Message: 4
> > > Date: Sun, 4 Jul 2010 20:49:54 -0400
> > > From: Marc Adored <marc at inworlddesigns.com>
> > > To: opensim-dev at lists.berlios.de
> > > Subject: [Opensim-dev] compiling viewer-external with ubuntu 64bit
> > > Message-ID:
> > > <AANLkTikVu2ASPx9g972vn8U15UsEeTMZgk5EdT7T5G6o at mail.gmail.com>
> > > Content-Type: text/plain; charset=ISO-8859-1
> > >
> > > I was wondering if anybody had any success compiling snowglobe on
> > > ubuntu and if they have what steps they took to prepare their system
> > > for it. I have installed everything under the sun and my /usr/include
> > > folder is a mess and I still can't get it to compile in 64bit or
> > > 32bit.
> > >
> > > ./develop.py -m64 -t Release
> > > Gives me no errors until I do
> > >
> > > ./develop.py -m64 -t Release build then it gets to
> > >
> > > -- snip --
> > > [ 10%] Building CXX object
> llcommon/CMakeFiles/llcommon.dir/metaproperty.o
> > > [ 10%] Building CXX object
> llcommon/CMakeFiles/llcommon.dir/reflective.o
> > > [ 10%] Building CXX object llcommon/CMakeFiles/llcommon.dir/timing.o
> > > [ 10%] Building CXX object llcommon/CMakeFiles/llcommon.dir/u64.o
> > > Linking CXX shared library libllcommon.so
> > > /usr/bin/ld: cannot find -lbreakpad_client
> > > collect2: ld returned 1 exit status
> > > make[2]: *** [llcommon/libllcommon.so] Error 1
> > > make[1]: *** [llcommon/CMakeFiles/llcommon.dir/all] Error 2
> > > make: *** [all] Error 2
> > >
> > >
> > > and it fails. The output above is from me going into
> > > viewer-linux-x86_64-release and compiling with make to get the
> > > individual error because ./develop.py doesn't provide it. When I build
> > > with
> > >
> > > ./develop.py -m32 -t Release
> > >
> > > -- snip --
> > > -- Version of viewer is 2.1.0.206484
> > > -- Configuring done
> > > CMake Warning at newview/CMakeLists.txt:1393 (add_executable):
> > > Cannot generate a safe linker search path for target secondlife-bin
> because
> > > files in some directories may conflict with libraries in implicit
> > > directories:
> > >
> > > link library [libGLU.so] in /usr/lib may be hidden by files in:
> > >
> /media/Storage/src/snowglobe/viewer-external/indra/../libraries/i686-linux/lib_release_client
> > >
> > > Some of these libraries may not be found correctly.
> > >
> > >
> > > CMake Warning at integration_tests/llui_libtest/CMakeLists.txt:53
> > > (add_executable):
> > > Cannot generate a safe linker search path for target llui_libtest
> because
> > > files in some directories may conflict with libraries in implicit
> > > directories:
> > >
> > > link library [libGLU.so] in /usr/lib may be hidden by files in:
> > >
> /media/Storage/src/snowglobe/viewer-external/indra/../libraries/i686-linux/lib_release_client
> > >
> > > Some of these libraries may not be found correctly.
> > >
> > >
> > > -- Generating done
> > > -- Build files have been written to:
> > >
> /media/Storage/src/snowglobe/viewer-external/indra/viewer-linux-i686-release
> > >
> > >
> > > Which I assume is not good but it generated everything fine so I
> continue with
> > >
> > > ./develop.py -m32 -t Release build
> > >
> > > and get:
> > >
> > >
> > > [ 0%] Built target cmake
> > > [ 1%] Built target llaudio
> > > [ 1%] Built target llcommon_tests
> > > [ 4%] Built target stage_third_party_libs
> > > Linking CXX shared library libllcommon.so
> > > /usr/bin/ld: skipping incompatible
> > > /usr/lib/gcc/x86_64-linux-gnu/4.3.4/libstdc++.so when searching for
> > > -lstdc++
> > > /usr/bin/ld: skipping incompatible
> > > /usr/lib/gcc/x86_64-linux-gnu/4.3.4/libstdc++.a when searching for
> > > -lstdc++
> > > /usr/bin/ld: skipping incompatible
> > > /usr/lib/gcc/x86_64-linux-gnu/4.3.4/libstdc++.so when searching for
> > > -lstdc++
> > > /usr/bin/ld: skipping incompatible
> > > /usr/lib/gcc/x86_64-linux-gnu/4.3.4/libstdc++.a when searching for
> > > -lstdc++
> > > /usr/bin/ld: skipping incompatible
> > > /usr/lib/gcc/x86_64-linux-gnu/4.3.4/../../../libstdc++.so when
> > > searching for -lstdc++
> > > /usr/bin/ld: skipping incompatible /usr/lib/libstdc++.so when
> > > searching for -lstdc++
> > > /usr/bin/ld: cannot find -lstdc++
> > > collect2: ld returned 1 exit status
> > > make[2]: *** [llcommon/libllcommon.so] Error 1
> > > make[1]: *** [llcommon/CMakeFiles/llcommon.dir/all] Error 2
> > > make: *** [all] Error 2
> > >
> > > This is also after going into viewer-linux-i686-release and compiling
> > > with make to see what the actual error was.
> > >
> > > If anyone can help that would be greatly appreciated :) I really would
> > > like to get a 64bit version compiled so I have my gstreamer back. I
> > > will note that I can successfully compile the code previous to the 2.0
> > > viewer code and emerald viewer code.
> > >
> > >
> > > ------------------------------
> > >
> > > Message: 5
> > > Date: Sun, 4 Jul 2010 20:52:16 -0400
> > > From: Marc Adored <marc at inworlddesigns.com>
> > > To: opensim-dev at lists.berlios.de
> > > Subject: Re: [Opensim-dev] compiling viewer-external with ubuntu 64bit
> > > Message-ID:
> > > <AANLkTim7jfT3FGwFo5xq0pfe4lPdE-EoIEGsKcOF6V6_ at mail.gmail.com>
> > > Content-Type: text/plain; charset=ISO-8859-1
> > >
> > > I am really sorry guys posted to wrong list please forgive me
> > >
> > > On Sun, Jul 4, 2010 at 8:49 PM, Marc Adored
> <marc at inworlddesigns.com> wrote:
> > > > I was wondering if anybody had any success compiling snowglobe on
> > > > ubuntu and if they have what steps they took to prepare their system
> > > > for it. I have installed everything under the sun and my /usr/include
> > > > folder is a mess and I still can't get it to compile in 64bit or
> > > > 32bit.
> > >
> > >
> > > ------------------------------
> > >
> > > Message: 6
> > > Date: Mon, 5 Jul 2010 11:01:20 +0200
> > > From: Impalah Shenzhou <impalah at gmail.com>
> > > To: opensim-dev at lists.berlios.de
> > > Subject: Re: [Opensim-dev] JSON or XML for serialization in the
> > > OpenSim database?
> > > Message-ID:
> > > <AANLkTikJufDdnJOxSyX4Bozj4uxU_vCQBtKg1GglUbEn at mail.gmail.com>
> > > Content-Type: text/plain; charset=ISO-8859-1
> > >
> > > Hi:
> > >
> > > Correct me if I'm wrong but I think that JSON.NET most famous
> > > serializer/deserializer (http://json.codeplex.com/) works like
> > > standard .NET XML serializer...
> > >
> > > The advantage of using JSON is less storing space and some thing like
> > > "direct connection" with Javascript. If the first is not a problem and
> > > you won't publish this kind of information to an external web
> > > service... well, XML serializer is part of .NET core, and JSON
> > > serializer is part of a codeplex project... one of them could be
> > > discontinued some day.
> > >
> > > Personally I can't find any advantage on using JSON here except for
> > > saving disk space and so on.
> > >
> > > This is my opinion, I have others if you don't like it :-)
> > >
> > >
> > > Impalah
> > >
> > >
> > > 2010/7/5, Justin Clark-Casey <jjustincc at gmail.com>:
> > > > Hi folks,
> > > >
> > > > As part of the media-on-a-prim implementation, I'm serializing the
> > > > parameters for a media texture to the database. This
> > > > seems better than creating new database fields or even a whole
> new table for
> > > > these parameters, both because there are
> > > > lots of them (url, scaling, controls, whitelist, etc.) and
> because different
> > > > future virtual environments may want to
> > > > store different things.
> > > >
> > > > I'm going to serialize them as an OSDArray or MediaEntrys using the
> > > > libopenmetaverse library. However, the question
> > > > then becomes whether to use the JSON representation or the XML
> > > > representation.
> > > >
> > > > I tend to prefer XML for storage representations. I believe that it's
> > > > somewhat more human readable and that there is
> > > > better tool support for manipulating it. However, I know other
> people would
> > > > prefer storage in JSON and I accept that
> > > > serialization/deserialization there may be slightly faster.
> > > >
> > > > The only other example of serialization that I know of in OpenSim
> currently
> > > > is that of SceneObjectGroups into inventory,
> > > > which encompasses object properties, object inventory properties
> and script
> > > > state. This is done in XML and media
> > > > entries would become part of that serialization.
> > > >
> > > > If there's a majority preference for JSON I don't mind using that
> instead,
> > > > though I would want a justification for going
> > > > this route rather than XML. If there's no real argument then I
> will go with
> > > > XML.
> > > >
> > > > Also, I believe that we should try and be consistent, so picking
> one or the
> > > > other now should make it more likely that
> > > > the same approach would be used for the next serialization case.
> > > >
> > > > Regards,
> > > >
> > > > --
> > > > Justin Clark-Casey (justincc)
> > > > http://justincc.org
> > > > http://twitter.com/justincc
> > > > _______________________________________________
> > > > Opensim-dev mailing list
> > > > Opensim-dev at lists.berlios.de
> > > > https://lists.berlios.de/mailman/listinfo/opensim-dev
> > > >
> > >
> > >
> > > ------------------------------
> > >
> > > _______________________________________________
> > > Opensim-dev mailing list
> > > Opensim-dev at lists.berlios.de
> > > https://lists.berlios.de/mailman/listinfo/opensim-dev
> > >
> > >
> > > End of Opensim-dev Digest, Vol 35, Issue 7
> > > ******************************************
> >
> > _________________________________________________________________
> > Hotmail: Trusted email with Microsoft?s powerful SPAM protection.
> > https://signup.live.com/signup.aspx?id=60969
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL:
> <https://lists.berlios.de/pipermail/opensim-dev/attachments/20100713/93766a49/attachment.html>
> >
> > ------------------------------
> >
> > _______________________________________________
> > Opensim-dev mailing list
> > Opensim-dev at lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
> >
> >
> > End of Opensim-dev Digest, Vol 35, Issue 35
> > *******************************************
>
> ------------------------------------------------------------------------
> Hotmail: Trusted email with powerful SPAM protection. Sign up now.
> <https://signup.live.com/signup.aspx?id=60969>
>
>
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
--
Justin Clark-Casey (justincc)
http://justincc.org
http://twitter.com/justincc
More information about the Opensim-dev
mailing list