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

[Kyle Hamilton]

The original design was derivative, how 'bout that?  The current one
(and set of interfaces) is much less so.  Still, limiting a single
region to a certain amount of virtually-physical space seems a fair
relic of the derivation of the design. :)

I also rather like your idea for the design.  I'm wondering if a
schema's been settled on for SceneXML?  (If it has been, a moderately
cursory glance at the devdocs and userdocs pages on the wiki don't
seem to link to anything that would have a link to it.)

-Kyle H

On Wed, Sep 3, 2008 at 3:35 PM, Diva Canto <diva at metaverseink.com> wrote:
> 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
>
>
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>