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

Tue Jul 13 17:17:24 UTC 2010

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: <http://opensimulator.org/pipermail/opensim-dev/attachments/20100713/93766a49/attachment-0001.html>