[Opensim-dev] 0.5.9 Problems: Linking prims via libomv

[Diva Canto]

That depends on what you call "derivative" (I could go on a tangent 
about this... ;-)

In this particular case, I think it would be a really good idea for this 
tool to spit out OpenSim's Scene XML, rather than that  other 
representation that it seems to be generating; then, for SL, have the 
libomv bots read the XML files and to their thing. For OpenSim, the bots 
become unnecessary.

Kyle Hamilton wrote:
> No need to use bot-based hacks in OpenSim, but there is still a need
> to use bot-based hacks in SL (at least until they make an avatar's
> inventory available from their inventory servers via some web
> service).  I'm assuming that there's a stronger case for
> cross-platform capability than for it to be limited to a (particularly
> easy-to-interface-with) derivative.
>
> (More's the pity. :/)
>
> Shack, did you file a jira report on this?
>
> -Kyle H
>
> On Wed, Sep 3, 2008 at 1:58 PM, Diva Canto <diva at metaverseink.com> wrote:
>   
>> Hi Shack,
>>
>> Great work! Other people will certainly fix the problem soon, but I'd
>> like to make a suggestion.
>> There's no need to use  bot-based hacks in OpenSim, since the backend is
>> all open. Also, there are no annoying limitations on the size of prims, etc.
>> You can rewrite your tool without libomv, using OpenSim's region
>> modules. It will be 1000% easier to maintain (for you) and to use (for
>> your users).
>>
>> Ideally, one would simply want the XML description of those objects,
>> really. So make your tool spit out OpenSim's XML, and write a module for
>> importing the textures.
>>
>> Is your tool open-sourced?
>>
>> Crista
>>
>>
>> Shack Dougall wrote:
>>     
>>> As part of Prim Composer for 3ds Max, I'm writing a libomv-based
>>> importer for SL and OpenSim.  The importer, called maxport, performs
>>> this set of basic operations:
>>>
>>> * rezzes prims, sets their position, name, and permissions
>>> * uploads images, puts them in inventory, sets their permissions,
>>> applies them to prims
>>> * links prims
>>>
>>> This week I started using OpenSim's tags/0.5.9-released branch in SVN.
>>> Previously, I was running the 0.5.8 binary release.  All of my testing
>>> so far has been in standalone mode, basicphysics, and SQLite
>>>
>>> 0.5.8 seemed rock solid.  It took just about anything I could throw at
>>> it.  Sometimes, I had to slow things down for it, but it worked
>>> predictably.  0.5.9 seems less solid and in particular, I'm encountering
>>> huge problems with linking.
>>>
>>> I've created a series of data sets with 100, 200, and 400 prims.  And
>>> also different amounts of linking, from no linking to 100 prim
>>> linksets.  The naming convention is "link_x_boxes_y" which indicates
>>> that it contains y boxes that are linked into x linksets.  So,
>>> link_10_boxes_100 means that there are 100 prims that have been linked
>>> into 10 linksets of 10 prims each.  link_2_boxes_100 means 100 prims in
>>> 2 linksets of 50 prims each.
>>>
>>> I started seeing problems immediately in 0.5.9.  link_2_boxes_4 should
>>> produce 4 prims that are linked into two pairs of 2.  And it did this in
>>> 0.5.8.  But in 0.5.9, it produced 3 prims that were linked together with
>>> a 4th prim that was unlinked and out of position.
>>>
>>> Larger linksets do even crazier things.  Linksets with 50 prims or more
>>> will spontaneously link to other prims in the sim that were never
>>> specified in the link request.  And I'm seeing duplicate prims that get
>>> linked in strange ways.  Some of the duplicates get their position set
>>> to half a sim away from where the originals were created.  It is bizarre.
>>>
>>> I would probably think that I'd done something wrong, except that the
>>> same program works perfectly when run against 0.5.8.
>>>
>>> Seems like there is a multi-threading issue or something similar going
>>> on that is causing things to go haywire inside of OpenSim 0.5.9 when
>>> linking is done.  It's probably a small bug, but it is doing serious damage.
>>>
>>> So, here's the thing.  I have more information that I can provide.  I've
>>> made a lot of observations.  I'd be glad to give you a compiled copy of
>>> the program I'm using and the data I use to perform the tests.  Just let
>>> me know what you'd like.
>>>
>>> --Shack
>>> _______________________________________________
>>> 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
>>
>>     
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20080903/4e288deb/attachment-0001.html>