<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
That depends on what you call "derivative" (I could go on a tangent
about this... ;-)<br>
<br>
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.<br>
<br>
Kyle Hamilton wrote:
<blockquote
 cite="mid:6b9359640809031404h4137b4e5sd159aa58f206a2ab@mail.gmail.com"
 type="cite">
  <pre wrap="">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 <a class="moz-txt-link-rfc2396E" href="mailto:diva@metaverseink.com"><diva@metaverseink.com></a> wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">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:
    </pre>
    <blockquote type="cite">
      <pre wrap="">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
<a class="moz-txt-link-abbreviated" href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a>
<a class="moz-txt-link-freetext" href="https://lists.berlios.de/mailman/listinfo/opensim-dev">https://lists.berlios.de/mailman/listinfo/opensim-dev</a>


      </pre>
    </blockquote>
    <pre wrap="">_______________________________________________
Opensim-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a>
<a class="moz-txt-link-freetext" href="https://lists.berlios.de/mailman/listinfo/opensim-dev">https://lists.berlios.de/mailman/listinfo/opensim-dev</a>

    </pre>
  </blockquote>
  <pre wrap=""><!---->_______________________________________________
Opensim-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a>
<a class="moz-txt-link-freetext" href="https://lists.berlios.de/mailman/listinfo/opensim-dev">https://lists.berlios.de/mailman/listinfo/opensim-dev</a>

  </pre>
</blockquote>
<br>
</body>
</html>