[Opensim-dev] MOAP : avatar appearance works fine now

Wed Jul 14 00:16:39 UTC 2010

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 :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 ;)You can register to the demo-MOAP here : http://95.110.224.250/GridFrontEnd/Download Snowglobe last release and login with loginuri http://95.110.224.250/Grid/login/ (note the trailing slash !!!)Current release is R13260. We will follow Justin's job everynight and install the newest release.Join and test it hardly ;)In the next days we will try to install all scalable modules (search, voice...etc) any help by devs for installation is appreciated;)If any of u needs to load iar/oar to the demo server contact me
Ty again Justin and ty to all of u devs !!!
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.
https://signup.live.com/signup.aspx?id=60969
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20100714/03c12951/attachment-0001.html>