Re: [Opensim-dev] Viewer doesn't render attachments after teleport

[Dahlia Trimble]

I've seen attachment rezzing failures in SL for years. Right-clicking
usually fixes it. If there is an issue then I suspect it's a long-standing
viewer bug that may be exacerbated by some combination of legal protocol.
If it is somehow related to packet ordering, then we might be able to send
it in a particular order but given the non-stream nature of UDP we cannot
guarantee it will be received in any order.


On Wed, Apr 2, 2014 at 4:44 AM, Dahlia Trimble wrote:

> Attachment positions are relative to bones. They really cannot be "too far
> away"
>
>
> On Wed, Apr 2, 2014 at 4:20 AM, Melanie  wrote:
>
>> I don't know if this may be related, but for some reason OpenSim
>> fails to update the viewer's notion of position properly.
>>
>> The most noticeable effect is that sometimes after changing regions
>> or even parcels, sound is no longer heard. The audibility check
>> happens viewerside, just as the object visibility check.
>>
>> If the viewer gets a wrong location, it may consider the attachments
>> as "too far away" and not render them - that is probably related to
>> why zooming can make them appear.
>>
>> Therefore I don't believe we need to send any extra packets related
>> to these objects, but rather we are missing some packet or sending
>> wrong data related to the avatar's location.
>>
>> This appears to be the case on moving in world as well as teleports,
>> but I have so far never observed it at login.
>>
>> Melanie
>>
>>
>> On 02/04/2014 13:16, Oren Hurvitz wrote:
>> > I got some great advice off-list from Nicky Perian. When there's a
>> problem of
>> > missing prims, go to the Graphics Preferences and toggle the option
>> "Basic
>> > shaders". I tried this, and toggling this option (on or off, both work)
>> > makes the missing prims appear immediately.
>> >
>> > This proves that the viewer has the correct data, and it's just not
>> showing
>> > it. But I still want to find some combination of packets that will make
>> the
>> > viewers show the prims, since obviously most users will not know to use
>> this
>> > trick, and it's a hassle.
>> >
>> >
>> >
>> > --
>> > View this message in context:
>> http://opensim-dev.2196679.n2.nabble.com/Viewer-doesn-t-render-attachments-after-teleport-tp7579143p7579146.html
>> > Sent from the opensim-dev mailing list archive at Nabble.com.
>> > ___
>> > Opensim-dev mailing list
>> > Opensim-dev@lists.berlios.de
>> > https://lists.berlios.de/mailman/listinfo/opensim-dev
>> >
>> >
>> ___
>> Opensim-dev mailing list
>> Opensim-dev@lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Viewer doesn't render attachments after teleport

[Dahlia Trimble]

Attachment positions are relative to bones. They really cannot be "too far
away"


On Wed, Apr 2, 2014 at 4:20 AM, Melanie  wrote:

> I don't know if this may be related, but for some reason OpenSim
> fails to update the viewer's notion of position properly.
>
> The most noticeable effect is that sometimes after changing regions
> or even parcels, sound is no longer heard. The audibility check
> happens viewerside, just as the object visibility check.
>
> If the viewer gets a wrong location, it may consider the attachments
> as "too far away" and not render them - that is probably related to
> why zooming can make them appear.
>
> Therefore I don't believe we need to send any extra packets related
> to these objects, but rather we are missing some packet or sending
> wrong data related to the avatar's location.
>
> This appears to be the case on moving in world as well as teleports,
> but I have so far never observed it at login.
>
> Melanie
>
>
> On 02/04/2014 13:16, Oren Hurvitz wrote:
> > I got some great advice off-list from Nicky Perian. When there's a
> problem of
> > missing prims, go to the Graphics Preferences and toggle the option
> "Basic
> > shaders". I tried this, and toggling this option (on or off, both work)
> > makes the missing prims appear immediately.
> >
> > This proves that the viewer has the correct data, and it's just not
> showing
> > it. But I still want to find some combination of packets that will make
> the
> > viewers show the prims, since obviously most users will not know to use
> this
> > trick, and it's a hassle.
> >
> >
> >
> > --
> > View this message in context:
> http://opensim-dev.2196679.n2.nabble.com/Viewer-doesn-t-render-attachments-after-teleport-tp7579143p7579146.html
> > Sent from the opensim-dev mailing list archive at Nabble.com.
> > ___
> > Opensim-dev mailing list
> > Opensim-dev@lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
> >
> >
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Viewer doesn't render attachments after teleport

[Dahlia Trimble]

I'd probably check the order of the packets. I'd suspect the ObjectUpdate
for the agent should be sent first, then any attachment ObjectUpdate
packets. It probably wouldn't hurt if the root prim is sent before any
child prims but I'd hope the viewers could handle that situation.


On Wed, Apr 2, 2014 at 2:05 AM, Oren Hurvitz  wrote:

> Here's another interesting finding: even when the attachments aren't
> visible,
> I can click on them to edit them. The viewer renders a yellow outline
> around
> the shape of the attachment (in Singularity), even while the area inside
> the
> outline still doesn't show the attachment.
>
>
>
> --
> View this message in context:
> http://opensim-dev.2196679.n2.nabble.com/Viewer-doesn-t-render-attachments-after-teleport-tp7579143p7579144.html
> Sent from the opensim-dev mailing list archive at Nabble.com.
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] REST handlers use partial string matching

[Dahlia Trimble]

Not sure about this particular application but keeping a connection open
can eliminate the need to instantiate a connection whenever a request is
made; a process that can make several round trips to multiple endpoints.


On Tue, Apr 1, 2014 at 12:52 PM, Mic Bowman  wrote:

> Do you really save much with a single request vs a keep alive on the
> connection? HTTP connection overhead is likely much smaller than the
> database operations... do you have a feel for how much we'll save with the
> multiplexed call?
>
> --mic
>
>
>
> On Tue, Apr 1, 2014 at 12:49 PM, Oren Hurvitz  wrote:
>
>> Re: why use POST instead of HEAD: because this lets me check the
>> existence of
>> many assets at once with a single HTTP request. The main use of the
>> AssetsExist call is with HGAssetGatherer, which knows the full list of
>> assets that it wants to send, so it's able to check all of them at once.
>>
>>
>>
>> --
>> View this message in context:
>> http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119p7579127.html
>> Sent from the opensim-dev mailing list archive at Nabble.com.
>> ___
>> Opensim-dev mailing list
>> Opensim-dev@lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>
>
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Stop saving SculptData in serialized SceneObjects

[Dahlia Trimble]

Twisted torii are quite complex prims and usually take the longest time to
create a physics proxy (on the order of 5 milliseconds or more) and usually
use the most memory. Using integer sizes in your case would reduce the
amount of proxies stored in the mesh cache and make better use of it.
However, torus prims are procedurally generated and don't rely on sculpt or
mesh assets and therefore aren't really affected by the changes being
proposed in this thread; at least unless the conversation veers towards
optimizing the mesh cache in the sim to reduce or eliminate unused meshes.


On Thu, Mar 27, 2014 at 1:32 PM, Mike Higgins  wrote:

> Ha! I submitted a mantis about this "rare case" once:
> http://opensimulator.org/mantis/view.php?id=6080
>
> I textured branches and  leaves on a twisted sculpt tree, and then had the
> trees grow up from a sapling (resize once a second) and this brought
> OpenSim to its knees (SIM FPS drops to near zero). I found that a helix (a
> twisted torus prim) had the same problem. I 'solved' the problem by having
> the trees change only to integer quantized sizes. I assume this worked
> because someone (viewer or sim) cashed the sculpt data at each different
> size and now there is only a finite number of sizes...
>
>
> On 3/27/14 12:48 PM, Oren Hurvitz wrote:
>
>> The mesh/texture data is needed only if the prim is resized or otherwise
>> edited as you've described. But in the vast majority of cases, prims are
>> just viewed. We should optimize for the common case, i.e. release the
>> memory. If the asset is needed again it will be loaded from the cache,
>> which
>> is very fast (not a network operation).
>>
>>
>>
>> --
>> View this message in context: http://opensim-dev.2196679.n2.
>> nabble.com/Stop-saving-SculptData-in-serialized-SceneObjects-
>> tp7579079p7579087.html
>> Sent from the opensim-dev mailing list archive at Nabble.com.
>> ___
>> Opensim-dev mailing list
>> Opensim-dev@lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>>
>>
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Stop saving SculptData in serialized SceneObjects

[Dahlia Trimble]

Then you will see problems when prims are edited.


On Thu, Mar 27, 2014 at 12:48 PM, Oren Hurvitz  wrote:

> The mesh/texture data is needed only if the prim is resized or otherwise
> edited as you've described. But in the vast majority of cases, prims are
> just viewed. We should optimize for the common case, i.e. release the
> memory. If the asset is needed again it will be loaded from the cache,
> which
> is very fast (not a network operation).
>
>
>
> --
> View this message in context:
> http://opensim-dev.2196679.n2.nabble.com/Stop-saving-SculptData-in-serialized-SceneObjects-tp7579079p7579087.html
> Sent from the opensim-dev mailing list archive at Nabble.com.
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Stop saving SculptData in serialized SceneObjects

[Dahlia Trimble]

Yes, it probably should stay there and just be excluded from the
serialization. The memory impact probably wouldn't be too bad unless it's a
unique (per SOP) reference and there are a lot of non-phantom mesh and
sculptie objects in the region. Hopefully it's not a unique reference, but
I didn't write the part that fetches that data and I haven't looked at it
in a long time. I'd suggest just excluding it from serialization and see if
that fixes the problem at hand.


On Thu, Mar 27, 2014 at 11:42 AM, Melanie  wrote:

> Attachments can be dropped and then need the proxy again.
>
> Melanie
>
> On 27/03/2014 19:29, Dahlia Trimble wrote:
> > Another strategy may be do something along the lines of deleting it if
> the
> > SOP is part of an attachment. Attachments are phantom and do not need
> > physics proxies.
> >
> >
> > On Thu, Mar 27, 2014 at 11:26 AM, Dahlia Trimble <
> dahliatrim...@gmail.com>wrote:
> >
> >> That field contains the asset data, which, in the case of a sculptie is
> >> not a mesh but a texture. For ODE, the resulting mesh will be cached
> once
> >> generated and reused, however the asset will need to be reaccessed
> later if
> >> a mesh with another scale is required, or one with different optional
> >> parameters such as invert or mirror being set. If you remove the asset
> >> data, it will need another asset fetch and multiple attempts to create a
> >> mesh until the asset becomes available again. I'd suggest *not* removing
> >> the asset data, but rather exclude it from the serialization when it's
> >> being stored for attachment purposes so as to reduce as many asset
> fetches
> >> as possible and keep sim startup/load time low.
> >>
> >>
> >> On Thu, Mar 27, 2014 at 10:41 AM, James Stallings II <
> >> james.stalli...@gmail.com> wrote:
> >>
> >>> Knock 'em dead Oren xD
> >>>
> >>>
> >>> On Thu, Mar 27, 2014 at 11:29 AM, Melanie  wrote:
> >>>
> >>>> Looks like you found the culprit! All those suggestions sound good.
> >>>>
> >>>> Melanie
> >>>>
> >>>> On 27 Mar 2014, at 17:03, Oren Hurvitz  wrote:
> >>>>
> >>>> When a prim is a Sculptie or Mesh, the prim's shape contains a field
> >>>> called
> >>>> SculptData which stores the full mesh or texture (for sculpties). If
> the
> >>>> prim is serialized then the field "SculptData" is also serialized,
> which
> >>>> is
> >>>> a problem because it contains the entire contents of the mesh or
> texture.
> >>>> This makes actions such as detaching a mesh attachment extremely slow.
> >>>>
> >>>> I think that we should remove SculptData from the serialized XML
> format
> >>>> of
> >>>> prims. This means that we'll stop serializing it, and when we get an
> XML
> >>>> with SculptData we'll ignore it.
> >>>>
> >>>> See also: http://opensimulator.org/mantis/view.php?id=7038("Unwearing
> >>>> mesh
> >>>> attachments very slow").
> >>>>
> >>>> As far as I can tell, the shape's SculptData field (in memory) should
> >>>> usually be empty. It only needs to be filled with the asset data in
> two
> >>>> cases:
> >>>> 1. When the mesh is first uploaded
> >>>> 2. If the Physics system needs to create a physics mesh
> >>>>
> >>>> In both cases, after the mesh data has been used it should be cleared
> >>>> immediately, to save memory.
> >>>>
> >>>> Regarding the behavior of the physics system, I see a few things that
> >>>> could
> >>>> be a problem with the way it's currently implemented. What currently
> >>>> happens
> >>>> is this: ODEPrim.CheckMeshAsset() loads the mesh/sculptie data if it's
> >>>> needed. Later, Meshmerizer.CreateMeshFromPrimMesher() clears the data
> >>>> once
> >>>> it has finished using it. This raises a couple of questions:
> >>>>
> >>>> 1. Where does BulletSim load the mesh data? It doesn't use ODEPrim.
> >>>> 2. It looks like Meshmerizer.CreateMeshFromPrimMesher() can sometimes
> >>>> return
> >>>> early, without clearing the mesh data. Seems to me that it should
> always

Re: [Opensim-dev] Stop saving SculptData in serialized SceneObjects

[Dahlia Trimble]

Another strategy may be do something along the lines of deleting it if the
SOP is part of an attachment. Attachments are phantom and do not need
physics proxies.


On Thu, Mar 27, 2014 at 11:26 AM, Dahlia Trimble wrote:

> That field contains the asset data, which, in the case of a sculptie is
> not a mesh but a texture. For ODE, the resulting mesh will be cached once
> generated and reused, however the asset will need to be reaccessed later if
> a mesh with another scale is required, or one with different optional
> parameters such as invert or mirror being set. If you remove the asset
> data, it will need another asset fetch and multiple attempts to create a
> mesh until the asset becomes available again. I'd suggest *not* removing
> the asset data, but rather exclude it from the serialization when it's
> being stored for attachment purposes so as to reduce as many asset fetches
> as possible and keep sim startup/load time low.
>
>
> On Thu, Mar 27, 2014 at 10:41 AM, James Stallings II <
> james.stalli...@gmail.com> wrote:
>
>> Knock 'em dead Oren xD
>>
>>
>> On Thu, Mar 27, 2014 at 11:29 AM, Melanie  wrote:
>>
>>> Looks like you found the culprit! All those suggestions sound good.
>>>
>>> Melanie
>>>
>>> On 27 Mar 2014, at 17:03, Oren Hurvitz  wrote:
>>>
>>> When a prim is a Sculptie or Mesh, the prim's shape contains a field
>>> called
>>> SculptData which stores the full mesh or texture (for sculpties). If the
>>> prim is serialized then the field "SculptData" is also serialized, which
>>> is
>>> a problem because it contains the entire contents of the mesh or texture.
>>> This makes actions such as detaching a mesh attachment extremely slow.
>>>
>>> I think that we should remove SculptData from the serialized XML format
>>> of
>>> prims. This means that we'll stop serializing it, and when we get an XML
>>> with SculptData we'll ignore it.
>>>
>>> See also: http://opensimulator.org/mantis/view.php?id=7038 ("Unwearing
>>> mesh
>>> attachments very slow").
>>>
>>> As far as I can tell, the shape's SculptData field (in memory) should
>>> usually be empty. It only needs to be filled with the asset data in two
>>> cases:
>>> 1. When the mesh is first uploaded
>>> 2. If the Physics system needs to create a physics mesh
>>>
>>> In both cases, after the mesh data has been used it should be cleared
>>> immediately, to save memory.
>>>
>>> Regarding the behavior of the physics system, I see a few things that
>>> could
>>> be a problem with the way it's currently implemented. What currently
>>> happens
>>> is this: ODEPrim.CheckMeshAsset() loads the mesh/sculptie data if it's
>>> needed. Later, Meshmerizer.CreateMeshFromPrimMesher() clears the data
>>> once
>>> it has finished using it. This raises a couple of questions:
>>>
>>> 1. Where does BulletSim load the mesh data? It doesn't use ODEPrim.
>>> 2. It looks like Meshmerizer.CreateMeshFromPrimMesher() can sometimes
>>> return
>>> early, without clearing the mesh data. Seems to me that it should always
>>> clear it.
>>>
>>> So besides removing "SculptData" from the XML format of prims, I also
>>> want
>>> to make Meshmerizer clear the data more aggressively. And I don't know
>>> how
>>> BulletSim uses meshes, but perhaps it also needs to be changed.
>>>
>>> Thoughts?
>>>
>>> Oren
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://opensim-dev.2196679.n2.nabble.com/Stop-saving-SculptData-in-serialized-SceneObjects-tp7579079.html
>>> Sent from the opensim-dev mailing list archive at Nabble.com.
>>> ___
>>> Opensim-dev mailing list
>>> Opensim-dev@lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>
>>>
>>> ___
>>> Opensim-dev mailing list
>>> Opensim-dev@lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>
>>
>>
>>
>> --
>> ===
>> http://osgrid.org/
>> http://simhost.com
>> http://twitter.com/jstallings2
>>
>>
>> ___
>> Opensim-dev mailing list
>> Opensim-dev@lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Stop saving SculptData in serialized SceneObjects

[Dahlia Trimble]

That field contains the asset data, which, in the case of a sculptie is not
a mesh but a texture. For ODE, the resulting mesh will be cached once
generated and reused, however the asset will need to be reaccessed later if
a mesh with another scale is required, or one with different optional
parameters such as invert or mirror being set. If you remove the asset
data, it will need another asset fetch and multiple attempts to create a
mesh until the asset becomes available again. I'd suggest *not* removing
the asset data, but rather exclude it from the serialization when it's
being stored for attachment purposes so as to reduce as many asset fetches
as possible and keep sim startup/load time low.


On Thu, Mar 27, 2014 at 10:41 AM, James Stallings II <
james.stalli...@gmail.com> wrote:

> Knock 'em dead Oren xD
>
>
> On Thu, Mar 27, 2014 at 11:29 AM, Melanie  wrote:
>
>> Looks like you found the culprit! All those suggestions sound good.
>>
>> Melanie
>>
>> On 27 Mar 2014, at 17:03, Oren Hurvitz  wrote:
>>
>> When a prim is a Sculptie or Mesh, the prim's shape contains a field
>> called
>> SculptData which stores the full mesh or texture (for sculpties). If the
>> prim is serialized then the field "SculptData" is also serialized, which
>> is
>> a problem because it contains the entire contents of the mesh or texture.
>> This makes actions such as detaching a mesh attachment extremely slow.
>>
>> I think that we should remove SculptData from the serialized XML format of
>> prims. This means that we'll stop serializing it, and when we get an XML
>> with SculptData we'll ignore it.
>>
>> See also: http://opensimulator.org/mantis/view.php?id=7038 ("Unwearing
>> mesh
>> attachments very slow").
>>
>> As far as I can tell, the shape's SculptData field (in memory) should
>> usually be empty. It only needs to be filled with the asset data in two
>> cases:
>> 1. When the mesh is first uploaded
>> 2. If the Physics system needs to create a physics mesh
>>
>> In both cases, after the mesh data has been used it should be cleared
>> immediately, to save memory.
>>
>> Regarding the behavior of the physics system, I see a few things that
>> could
>> be a problem with the way it's currently implemented. What currently
>> happens
>> is this: ODEPrim.CheckMeshAsset() loads the mesh/sculptie data if it's
>> needed. Later, Meshmerizer.CreateMeshFromPrimMesher() clears the data once
>> it has finished using it. This raises a couple of questions:
>>
>> 1. Where does BulletSim load the mesh data? It doesn't use ODEPrim.
>> 2. It looks like Meshmerizer.CreateMeshFromPrimMesher() can sometimes
>> return
>> early, without clearing the mesh data. Seems to me that it should always
>> clear it.
>>
>> So besides removing "SculptData" from the XML format of prims, I also want
>> to make Meshmerizer clear the data more aggressively. And I don't know how
>> BulletSim uses meshes, but perhaps it also needs to be changed.
>>
>> Thoughts?
>>
>> Oren
>>
>>
>>
>> --
>> View this message in context:
>> http://opensim-dev.2196679.n2.nabble.com/Stop-saving-SculptData-in-serialized-SceneObjects-tp7579079.html
>> Sent from the opensim-dev mailing list archive at Nabble.com.
>> ___
>> Opensim-dev mailing list
>> Opensim-dev@lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>>
>> ___
>> Opensim-dev mailing list
>> Opensim-dev@lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>
>
>
> --
> ===
> http://osgrid.org/
> http://simhost.com
> http://twitter.com/jstallings2
>
>
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] How many sides does a tapered torus have?

[Dahlia Trimble]

Radius > 0 may or may not add a side, or add 2 sides, depending on other
parameters. Taper > 0 may add 1 but could add 2 unless one or both tapers
are 1.0. It's all very complex with lots of interactions. We could probably
get together sometime and hash it all out but I probably wont have time for
a while. One could also probably make the prim with PrimMesher and count
the number of sides, but PrimMesher occasionally adds an extra side (well
actually fails to delete an extra side) so may not be a perfect solution,
and would also be somewhat inefficient way of doing it.


On Tue, Mar 25, 2014 at 11:40 PM, Oren Hurvitz  wrote:

> Yikes! How can I know these things in order to fix GetNumberOfSides()?
>
> If shape.pathTaperX>0 or shape.pathTaperY>0 then +1 side? But I think this
> doesn't actually happen unless Radius is also >0. I really don't understand
> how these parameters interact.
>
> Maybe we should just drop GetNumberOfSides() altogether. Every place that
> currently uses this function should simply check all 32 possible sides, and
> Bob's your uncle.
>
>
>
> --
> View this message in context:
> http://opensim-dev.2196679.n2.nabble.com/How-many-sides-does-a-tapered-torus-have-tp7579043p7579059.html
> Sent from the opensim-dev mailing list archive at Nabble.com.
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Having struggled with the privs inherited from SL I wish to object.

[Dahlia Trimble]

You're free to change your permissions as you would like them to be. Nobody
is restricting your freedom. If the defaults were changed for everyone just
to suit your convenience, then others would be inconvenienced. If the
permission system doesn't suit your needs, you're also free to use other
software that you find better suits your needs.


On Tue, Mar 25, 2014 at 12:25 PM, Jim Williams  wrote:

> No...Clearly default ought to be no restrictions.  This is a simple matter
> of freedom of speech.  If I have to tell you you are free to repeat my
> speech then I am not free.  My speech is restricted.
>
> If someone wants to charge for receiving their speech it is fine with me,
> as long as I am not encumbered by their desires.  You may invent whatever
> controls you want for people to use to limit the reach of their speech, as
> long as I have to do nothing to ignore them.  All I want is the default of
> freedom to speak rather than the assumed default that I don't want to speak.
>
> Also, kill what??
>
>
>
> On Tue, Mar 25, 2014 at 2:48 PM, R.Gunther  wrote:
>
>>  Uhmm, or you type it wrong or you think wrong.
>> default stuff must have no perms. so the owner decide what transfer or
>> copy perms need to be set. if it need to be set.
>> Set everything default to full perms is a killer and very wrong.
>>
>> On 2014-03-25 15:23, Jim Williams wrote:
>>
>> I don't really care much what controls are allowed the creator, but I
>> care a whole lot about the defaults.  My speech is not free if I have to
>> tell you it is free.
>>
>>  I think that any privs set to default to restricting copying are both
>> evil and wrong -- especially those involved in scripting, since that is
>> what I wish to spend my time on in the Metaverse.
>>
>>  All privs need to be adjusted such that the people wanting to restrict
>> access to their stuff are the ones who have to do something.
>>
>>  Thank you,
>> Dharma Galaxy@metropolis
>> Dharma Glaxy @osg
>>
>>  --
>> No essence.  No permanence.  No perfection.  Only action.
>>
>>
>> ___
>> Opensim-dev mailing 
>> listOpensim-dev@lists.berlios.dehttps://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>>
>>
>> ___
>> Opensim-dev mailing list
>> Opensim-dev@lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>
>
>
> --
> No essence.  No permanence.  No perfection.  Only action.
>
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] How many sides does a tapered torus have?

[Dahlia Trimble]

a tapered torus which contains no cuts or hollows will have either 2 or 3
texture faces, or "sides", depending on the taper. If the taper results in
one end which converges in a single point then it will have 2 sides. The
taper you describe should result in a prim with 3 texture faces.


On Tue, Mar 25, 2014 at 2:08 AM, Oren Hurvitz  wrote:

> I found a bug in OpenSim: it doesn't count correctly the number of sides
> in a
> Torus if the torus uses tapering.
>
> How to reproduce the problem:
>
> 1. Create a torus, and set TaperY=0.85 and Radius=0.7.
> 2. Change the prim's texture. The texture will change momentarily and
> immediately revert to the default texture.
>
> The function that contains the problem is
> SceneObjectPart.GetNumberOfSides(). It thinks that this prim has 1 face,
> but
> actually there are at least 2 faces.
>
> I'm not sure how to fix this because I don't know what is considered a
> "side". Can someone who understands shapes in SL/OpenSim help out? Perhaps
> whoever wrote this function originally? The bug is described here:
> http://opensimulator.org/mantis/view.php?id=7059
>
> Thanks!
>
>
>
> --
> View this message in context:
> http://opensim-dev.2196679.n2.nabble.com/How-many-sides-does-a-tapered-torus-have-tp7579043.html
> Sent from the opensim-dev mailing list archive at Nabble.com.
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Texture encoding in database

[Dahlia Trimble]

Are you looking at the blob which is part of a primitive? There is an
encoder/decoder in libopenmetaverse, it's
OpenMetaverse.Primitive.TextureEntry. Here's a link to the source if you're
curious:
https://github.com/openmetaversefoundation/libopenmetaverse/blob/master/OpenMetaverse/Primitives/TextureEntry.cs



On Thu, Jan 16, 2014 at 12:24 PM, Jeff Kelley  wrote:

> I can find no documentation about the way textures and per-side attributes
> are encoded in table primshapes. Breaking the binary string into 17 bytes
> blocks, I retrieve a variable number of textures at the beginning :
>
>
> Textures for prim 0b1a30a5-bc36-4c19-8710-2b1508927606
> Blob size=107 (6 entries + 5 bytes)
> +--+---+
> --+
> |  Texture |  Side | |
> +--+---+
> --+
> | c0dc594d-ec52-4634-8d00-1213adad6690 |20 | e8support06c.jpg |
> | 25df78a4-647b-434f-8f42-6d19504bcb89 | 9 | AF_steel_wire |
> | 20a88b5d-ba7d-4896-980b-17bcd38b6714 | 2 | ME - J_metal03.jpg |
> | cb323153-9c2b-4cc8-b397-52d36809a0a2 | 0 | totallyclear |
> | -00cd-cc4c-3e14-8040 | 0 | -- not found -- |
> | 80401e00-00c0-3f00-- | 0 | -- not found -- |
> | ---- | 0 | -- not found -- |
>
>
> then, non uuid entries (I suppose we should find colors, repeats, etc
> since this is the only place they can be). Can somebody points me to the
> documentation or source code?
>
>
> -- Jeff
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] opensim-libs out of date ?

[Dahlia Trimble]

the openjpeg libs come from the OpenMetaverse distribution, not from Aurora


On Sat, Dec 21, 2013 at 2:07 AM, M.E. Verhagen  wrote:

> the openjpeg lib wich is in the 0.8 git master is 2.1.5 and the source in
> opensim-libs is 2.1.3, it looks like the openjep dll, so and dylibs in the
> git master were compiled with the openjpeg 2.1.5 implementation pulled from
> the aurora repo.
>
> The bullet physics in the git master is probably 2.8.2 and in the source
> in the opensim-libs is 2.8.1
>
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] opensim-libs out of date ?

[Dahlia Trimble]

OpenMetaverse (libom) libraries (including openjpeg) come from the
libOpenmetaverse project and are not modified, so they probably should not
exist in opensim-libs. If the are there, they are probably old versions
that may have been modified but were later replaced by unmodified versions.
You should be able to find the source for the libs included with current
OpenSimulator at https://github.com/openmetaversefoundation

Not sure about the bullet stuff, but there have been several attempts to
add bullet physics in the past and some of those in opensim-libs may be
from those attempts. MisterBlue would hopefully know more about where to
find the latest.


On Sat, Dec 21, 2013 at 1:20 AM, M.E. Verhagen  wrote:

> Some of the libraries in de opensim-libs repo appear to be out of date.
> There appear to be dll in the opensim master git wich have been compiled
> with higher versions then there are in the opensim-libs.
>
> It seems that openjpeg is outdated (libomv, metaverse) and also I suspect
> that bulletsim in the repo is an old version.
>
> Can some of the devs bring the source in the opensim-libs repo up to date
> ?
>
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] [Opensim-users] OpenSim Source fixed yet?

[Dahlia Trimble]

This is obviously an extreme case, however, git master is the main
development branch and as such can often be in a state of partial
functionality. Those wishing for the latest, most stable code should use
the release tags or the most recent post fixes branch. Git master should
*never* be used in any sort of production environment.


On Fri, Dec 20, 2013 at 4:07 PM, BoneZ  wrote:

> Thank you for the updates.
>
> With no disrespect intended here, what/how exactly did the master become
> unusable?
> I thought by using a setup like this (GIT) we would avoid issues like this?
> Like I said, I mean no disrespect... just trying to find out what happened
> as it may be a lesson we all can learn from.
>
> ~BoneZ
>
>
>
>
> On 12/20/2013 5:35 PM, Justin Clark-Casey wrote:
>
>> We had the yearly Overte meeting today so I got a chance to talk to
>> Melanie directly.  She is looking to put in the rest of the code soon over
>> Christmas and before the New Year and that master should actually be in a
>> reasonable state at the moment, albeit with unpredictable regressions.
>>  However, I will leave it to her to post specifically about that (she is
>> planning to) so that I don't muck up the details.
>>
>> In the meantime, anybody looking for a 'stable' level of code may want to
>> look at the git branch "justincc-master". This is branched just before the
>> merge (commit 08750501617ca332ab196b2f25030e3c635c9dd6) and contains
>> various patches from myself and other contributors under normal master
>> conditions.  All these changes will also get back into master. Feel free to
>> raise bugs, etc. against this branch.
>>
>> On 20/12/13 20:58, Dahlia Trimble wrote:
>>
>>> Melanie made a few commits but I believe she wanted to do more. I don't
>>> think git master is in a good state and I don't
>>> really know what her commits may have broken. I also don't know when she
>>> plans on completing this work. Perhaps she will
>>> post a message to these lists and let us know what her plans are?
>>>
>>>
>>>
>>>
>>> On Fri, Dec 20, 2013 at 5:37 AM, BoneZ >> bo...@dogzhouse.com>> wrote:
>>>
>>> Hi all,
>>>
>>> Does anyone know if the source code has been fixed?
>>> Last I heard Melanie was merging some code and it was down for some
>>> time?
>>>
>>> I don't recall seeing an update in some time now.
>>>
>>> Thanks,
>>> ~BoneZ
>>> _
>>> Opensim-users mailing list
>>> opensim-us...@lists.berlios.de <mailto:Opensim-users@lists.
>>> berlios.de>
>>> https://lists.berlios.de/__mailman/listinfo/opensim-users <
>>> https://lists.berlios.de/mailman/listinfo/opensim-users>
>>>
>>>
>>>
>>>
>>> ___
>>> Opensim-users mailing list
>>> opensim-us...@lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/opensim-users
>>>
>>>
>>
>>
> ___
> Opensim-users mailing list
> opensim-us...@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-users
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] [Opensim-users] OpenSim Source fixed yet?

[Dahlia Trimble]

Melanie made a few commits but I believe she wanted to do more. I don't
think git master is in a good state and I don't really know what her
commits may have broken. I also don't know when she plans on completing
this work. Perhaps she will post a message to these lists and let us know
what her plans are?




On Fri, Dec 20, 2013 at 5:37 AM, BoneZ  wrote:

> Hi all,
>
> Does anyone know if the source code has been fixed?
> Last I heard Melanie was merging some code and it was down for some time?
>
> I don't recall seeing an update in some time now.
>
> Thanks,
> ~BoneZ
> ___
> Opensim-users mailing list
> opensim-us...@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-users
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] GIt master is broken until further notice

[Dahlia Trimble]

I agree... however I'm just the messenger so please don't shoot me :)
*ducks*


On Thu, Dec 12, 2013 at 4:54 PM, Justin Clark-Casey <
jjusti...@googlemail.com> wrote:

> This needs to be done very soon or we need some imminent timeframe.  The
> rest of the code needs to be merged in so that master can be fixed and we
> can move forward.  Leaving it broken over Christmas would be a very poor
> show.
>
>
> On 11/12/13 02:05, Dahlia Trimble wrote:
>
>> Melanie has begun merging her region crossing code into git master and
>> expects that the changes will break the
>> repository for some indefinite period. The last usable commit was
>> 08750501617ca332ab196b2f25030e3c635c9dd6 made on
>> December 10th. Please do not use commits after this until master is fixed.
>>
>> -dahlia
>>
>>
>> ___
>> Opensim-dev mailing list
>> Opensim-dev@lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>>
> --
> Justin Clark-Casey (justincc)
> OSVW Consulting
> http://justincc.org
> http://twitter.com/justincc
>
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

[Opensim-dev] GIt master is broken until further notice

[Dahlia Trimble]

Melanie has begun merging her region crossing code into git master and
expects that the changes will break the repository for some indefinite
period. The last usable commit was 08750501617ca332ab196b2f25030e3c635c9dd6
made on December 10th. Please do not use commits after this until master is
fixed.

-dahlia
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Direction of Opensim and its relationship with viewers

[Dahlia Trimble]

On Sat, Nov 9, 2013 at 5:14 PM, Mircea Kitsune <
mircea_the_kits...@hotmail.com> wrote:

> I decided to google parts of my questions earlier. Although I hate asking
> something publicly to later answer myself, I think I am a bit more clear
> after the info I found as well as the replies here.
>
> First of all, something I forgot to clarify: I wouldn't expect or want
> Opensim to be a perfect replication of the SL server. On the contrary...
> Opensim has the ability to fix things Linden never will in their server
> software and add new features, which it should totally use. But IMO only
> for changes that are compatible with all viewers, and don't introduce new
> protocols for all sorts of software, which was the concern some of my
> questions started from.
>
>
So are you saying if someone wanted to use OpenSimulator as a server for a
MMO-like game and they used a custom client with a custom protocol that was
not compatable with SL viewers, it should not be allowed? Given that it's
open source and MIT licensed, it's highly unlikely anything could be done
to stop such from happening.



> Part of that was clarified by this page:
> http://opensimulator.org/wiki/Communication_Protocols It describes how
> communication with viewers works, and how I assume it plans to stay. The
> interface (which that page names "the Linden Lab viewer protocol") is one
> thing I wondering about, and if it's a fixed interface that doesn't need to
> be maintained for various viewers. Of course there's more than just the
> protocol, such as being limited to the prim and avatar shapes viewers can
> recognize. For this reason, I assume prim types like "cube", "sphere",
> "torus" will have to stay hard coded in Opensim and follow what Linden has.
> These sort of things are usually was I unclear about.
>
>
That wiki page is incomplete in that it does not mention IClientAPI, which
is the interface in OpenSimulator *specifically designed for implementing
new protocols* and is what the LL protocol uses to interface with the
simulation.
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Direction of Opensim and its relationship with viewers

[Dahlia Trimble]

It has been and still is a goal of OpenSimulator to be somewhat of a
general purpose virtual world simulation platform. Much of the fundamental
design of the core server reflects this goal. There have also been several
attempts to integrate diverse viewers into OpenSimulator, with varying
levels of success.

However, much of what drives development is community expectations.
OpenSimulator exists in the minds of many users as a "Open Source Second
Life" and those users are quite vocal when any features that SL has are not
accurately implemented in OpenSImulator. Even those which could be
considered bugs in SL are expected when certain content exploits them and
makes them "features". Given these community expectations and influences,
it's very difficult to deviate from the way SL is perceived to work and
thus the vast majority of code in OpenSimulator is there to support SL
compatability, which in turn can reduce it's attractiveness for other uses.

So in essence your statement that building a viewer specifically for
OpenSimulator that does all that the LL viewer does the same way it does it
would be a waste of time is likely true. The only possible benefit from
such efforts would be an alternative license than the GPL/LGPL that current
viewers must abide by. However, even with much effort to duplicate the LL
viewer functionality, there will likely still be subtle differences that
the community will find objectionable and they will continue to prefer to
pick from the many TPVs out there. The only non-LL based viewer I've seen
with 3D capability that has achieved long-term success is Radegast and many
prefer it for low-end use as it's 3D view can be turned on and off and it
doubles as a fairly complete text-only client.

Where alternative implementations may find their niche is in other
applications where end-user content creation and management is not a goal,
such as games. OpenSimulator has been used as a server for such efforts
many times in the past and I suspect will continue to be used. Often,
however, such use may conflict with the SL-ness of OpenSimulator and the
users of such a system may fork off and move in their own direction and/or
abandon OpenSimulator completely for their own design or use some other
platform.

OpenSimulator remains capable of interfacing with non-SL clients and some
of us strive to maintain this capability and use it in other projects. I
hope these capabilities can continue as OpenSimulator development continues.


On Sat, Nov 9, 2013 at 2:03 PM, Mircea Kitsune <
mircea_the_kits...@hotmail.com> wrote:

> I remember at least one non-SL viewer written from scratch (forgot its
> name though). Last time I tested it years ago, it was only able to render
> terrain and prims against a black background, while I think used a Quake 1
> model for avatars. I believe non-SL viewers deserve the appreciation any
> program does, as well as Opensim keeping them compatible if they have the
> same basic functionality as the SL viewer. All I'm saying is, such viewers
> will 99.9% likely never have someone motivated enough to develop them
> anywhere near SL quality. And even if that happened, they probably wouldn't
> turn out that different, since the base mechanics and features would have
> to be the same. So it's unlikely they'll have a bright future, which is why
> I'm hoping they won't become a focus for Opensim. I'd also be worried if OS
> would ever had to dedicate itself to multiple programs, and supporting the
> changes each unique viewer might add if others aren't going to add it too.
>
> I'll probably look at that video a bit later... missed watching Opensim
> meetings like in the old days. As for the relationship part, I meant
> Opensim not being directly involved with any of the viewer code using it
> (as far as I know). Although it's comforting to know the Firestorm team is
> decided to make sure FS works well in Opensim, it's still a different team
> and a different application. It doesn't solve the situation of a server
> (Opensim) without any clients of its own. It's not that hard to find your
> own viewer of course, but it tends to give the feeling that things aren't
> that stable and in harmony, and if something happens to one side the other
> might not be there to help. And yeah, don't get me started on Linden lol.
>
> > From: cinder.rox...@phoenixviewer.com
> > To: opensim-dev@lists.berlios.de
> > Date: Sat, 9 Nov 2013 14:11:42 -0700
> > Subject: Re: [Opensim-dev] Direction of Opensim and its relationship
> with viewers
>
> >
> > On 9 Nov 2013, at 13:38, Taoki wrote:
> >
> > Non-SL based viewers *do* exist though.
> >
> > A lot of these questions were addressed in the OSCC Viewers and
> > OpenSimulator Panel this year http://www.ustream.tv/recorded/38459235
> >
> > Not sure what you mean by colder relationship with viewers? As the
> > OpenSim compatibility developer for Firestorm, I've never felt that way.
> > Whenever I've had a question, many people have been welcoming and
> 

Re: [Opensim-dev] Needing Mono.Security.dll on Windows at PostgreSQL module

[Dahlia Trimble]

Why do we need crypto in a database for OpenSimulator?


On Tue, Oct 15, 2013 at 8:08 PM, Fernando Francisco de Oliveira <
ferna...@oliveira.eti.br> wrote:

> Hello
>
> I was investigating the bug (
> http://opensimulator.org/mantis/view.php?id=6803) found that
> Mono.Security.dll which is packaged with Npgsql.dll library is needed on
> Windows, but can't be distributed on Linux, because mono already have it
> and gives conflicts error.
>
> I would like to discuss about distributing the Mono.Security.dll on a
> folder above bin like "bin/windows" folder, which could contains the
> libraries that only is needed on windows.
>
> I did a change on PGSQL project to load dynamicaly Mono.Security only if
> it's running on Windows, and from that folder.
> If it running on Mono, it load it from GAC (if available) and don't load
> the windows dll.
>
> http://pastebin.com/WdzfmbSr
>
> Let's talk about it ?
>
> Fernando Oliveira
> http://oliveira.eti.br
>
>
>
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Test: opensm with PostGreSQL connection - Crash...

[Dahlia Trimble]

Ok I guess a lot of your initial message was truncated when it was
forwarded to the official berlios list, or when gmail picked it up. Usually
sending a message directly to opensim-dev@lists.berlios.de works.


On Sun, Oct 13, 2013 at 6:45 PM, OpenSimFan  wrote:

> see link to opensim.log in my first post...
>
>
>
> -
> _
> Keep up the good work.!!! - OpenSimFan
> My Opensim/Second Life Blog
> http://verwijs.wordpress.com
> (Dutch, basic hardware/software help  windows, Mac, Linux)
> http://verwijs-pc.nl
> My Twitter Page:
> http://twitter.com/OpenSimFan
> My Facebook page (be my friend, please )
> http://www.facebook.com/andre.verwijs
> --
> View this message in context:
> http://opensim-dev.2196679.n2.nabble.com/Test-opensm-with-PostGreSQL-connection-Crash-tp7578810p7578814.html
> Sent from the opensim-dev mailing list archive at Nabble.com.
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Test: opensm with PostGreSQL connection - Crash...

[Dahlia Trimble]

"It crashes" is a little too ambiguous. Perhaps you could post the section
of your OpenSim.log file where the crash occurred?


On Sun, Oct 13, 2013 at 2:42 PM, OpenSimFan  wrote:

> ive been testing opensm git master with PostGreSQL connection, it Crashes
> ...
>
>
>
> not sure if Fernando's version still exists, if yes i can test it..
>
>
>
> André
>
>
>
>
> -
> _
> Keep up the good work.!!! - OpenSimFan
> My Opensim/Second Life Blog
> http://verwijs.wordpress.com
> (Dutch, basic hardware/software help  windows, Mac, Linux)
> http://verwijs-pc.nl
> My Twitter Page:
> http://twitter.com/OpenSimFan
> My Facebook page (be my friend, please )
> http://www.facebook.com/andre.verwijs
> --
> View this message in context:
> http://opensim-dev.2196679.n2.nabble.com/Test-opensm-with-PostGreSQL-connection-Crash-tp7578810.html
> Sent from the opensim-dev mailing list archive at Nabble.com.
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Please help evaluate/test PostgreSql support for OpenSimulator

[Dahlia Trimble]

Fernando's contributions have been merged into git master so a fresh pull
from there will now include his postgresql support. Please try it :)

Also, *please remember* that git master is a development repository and
should *never* be used in a production environment!
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

[Opensim-dev] Please help evaluate/test PostgreSql support for OpenSimulator

[Dahlia Trimble]

Fernando Francisco de Oliveira has graciously decided to contribure his
modules to support Postgresql databases for OpenSimulator. Several core
developers believe this would be an excellent addition to the code base,
however we could use some help evaluating the patches. If you have
experience with both OpenSimulator and Postgresql and are willing to act as
a guinea pig, please pull his changes from
https://github.com/ffoliveira/opensimulator/tree/PostgreSQL and let the
list know how it works for you.

Your help is appreciated!

Thanks,
-dahlia

On 10/10/2013 7:09 PM, Fernando Francisco de Oliveira wrote:

Hello

 I just requested a push from my fork of opensim to the nebadon git opensim
repository, that I created the PostgreSQL project to use this database in
opensim.

 https://github.com/ffoliveira/opensimulator/tree/PostgreSQL

 I already have a Mantis Account.

 I hope the code and it's use may improve opensim performance and gain more
users.

 Fernando Oliveira
http://oliveira.eti.br

http://twitter.com/oliveira_lands




___
Opensim-dev mailing
listOpensim-dev@lists.berlios.dehttps://lists.berlios.de/mailman/listinfo/opensim-dev



__
_
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] OpenSim.exe console - progress messages with mesh uploads

[Dahlia Trimble]

I don't think the mesh is decompressed during the upload but it is
decompressed when first rezzed in the scene, in order to generate a physics
collision proxy.

Mike, I'm surprised you got it to work with the .Net decompression
libraries. When I first did the mesh physics collider code, the compression
the viewer used was not compatable with the .Net gzip decompressor. Are you
using something other than that library?

Also, with regards to the viewer hanging during upload, has anyone
determined whether the problem is in the viewer, or in the simulator? The
simulator really shouldn't care about size until the mesh is actually
rezzed in a region, otherwise it's just a large blob that will be stored in
the asset system.  Perhaps trying to upload that same mesh to one of the
Linden grids might provide some insight.


On Fri, Aug 30, 2013 at 6:56 AM, Mike Chase <
mike.ch...@alternatemetaverse.com> wrote:

>  On 08/30/2013 08:58 AM, Robert Martin wrote:
>
> one thing that might help things here is have some way of having the
> simulator "bounce"/return zero when it is doing the calculate cost stage of
> a mesh upload.
>
>
> That's not  really going to help I don't think.  I don't believe the
> OpenSim implementation does anything or even looks for the mesh data when
> the cost stage is executed.
>
> Mesh upload happens in 2 stages.  When you push the calculate button the
> client crunches data and sends a snapshot of it along with the
> NewAgentInventory request to the server.The server returns the upload
> cap along with any optional cost calculations it has done.  The client then
> re-contacts the server at the new cap and transmits the data (again) for
> the actual upload.
>
> There are two likely places for bottlenecks and depending on what core
> opensim does an additional place where a failure is possible.
>
> 1) The initial calculations done by the client.  If this is the case its
> going to be seen prior to the upload button enabling.
> 2) The actual data transmission.  Probably not a problem because it's
> using HTTP for the transfer in both cases.  Also if you are seeing the
> upload button enable then that transmission has already happened once.
> Which would indicate its probably not the issue.
>
> There is an additional scenarios I hit when I did the implementation for
> InWorldz.   The zlib.net decompression code occasionally throws
> indicating an invalid code stream.  IDK if the upstream code actually
> cracks open the mesh in any way but if so its entirely possible thats what
> is failing and the exception is being eaten.In the InWorldz case I
> replaced the zlib calls with the compression/decompression code in .NET and
> resolved the issue that way.  Its something additional to check.
>
> So more than likely from the description the issue is with asset creation
> or something that's done after the transmission takes place.
>
> Hope this helps a bit.
>
> Mike
>
>
>
> On Thu, Aug 29, 2013 at 6:48 PM, Justin Clark-Casey <
> jjusti...@googlemail.com> wrote:
>
>> I'm not sure this will be possible as I believe mesh is uploaded via a
>> single HTTP post, which isn't easy to monitor server-side.  It's also
>> possible that the mesh you're trying to upload is unfortunately simply too
>> large and that we should have (optional) server-side enforced limits.  But
>> this is speculation on my part.
>>
>> Is this a purely local upload or one to a server not on the same system?
>>  If the server is on a different system, possibly you could install a
>> monitoring tool to check your rate of data upload.  Naturally, one would
>> expect a server on a local LAN to be very quick, but a remote one might be
>> different and even on the local scenario, things like slow wifi might come
>> into play.
>>
>> Perhaps you could install a monitoring tool on your system
>>
>> On 24/08/13 17:22, Ai Austin wrote:
>>
>>> I wonder if its possible to get any debugging related to mesh uploads
>>> and their progress (or otherwise).
>>>
>>> I think I am timing out even when I set the AckTimeout = 600   as
>>> suggested by Justin and want to try to figure out
>>> the stage at which the problems occur.
>>>
>>> I am uploading some Collada meshes that are 20MB up to 100MB in size..
>>> and got them in once.. but cannot reliably repeat
>>> that especially f I try to vary the upload options to scale the incoming
>>> mesh, or if I add any physics details.
>>>
>>> ___
>>> Opensim-dev mailing list
>>> Opensim-dev@lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>
>>>
>>
>>   --
>> Justin Clark-Casey (justincc)
>> OSVW Consulting
>> http://justincc.org
>> http://twitter.com/justincc
>>
>> ___
>> Opensim-dev mailing list
>> Opensim-dev@lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>
>
>
> --
> Robert L Martin
>
>
> ___
> Opensim-dev mailing 
>

Re: [Opensim-dev] Command lines - use of hyphens and verb subject flipping

[Dahlia Trimble]

I think the problem with verb-object is that the command handling code is
designed such that multiple modules can add additional commands when they
are instantiated, and Opensimulator uses the first word in the command to
dispatch the command to whatever module "owns" it. If it were verb-object
then it (currently) would not know how to dispatch the command as many
modules could share the verb. It might be possible to rewrite the command
dispatching code to handle the verb-object form but then existing modules
that are not in core would need to be updated or their registered commands
would not work.


On Fri, Aug 30, 2013 at 6:57 AM, R.Gunther  wrote:

> i agree verb-object is a bit confuseing with typeing compared to verb
> object.
> delete-region is for me not really logic, delete region is more clear.
>
>
> On 2013-08-30 15:32, Ai Austin wrote:
>
>> At 11:00 30/08/2013, 
>> opensim-dev-request@lists.**berlios.dewrote:
>>
>>> I'm still not sure whether verb-object is better (e.g. send appearance)
>>> or object-verb (e.g. appearance send).
>>>
>>
>> I strongly vote for verb object in such computer script languages.
>>
>> This works well also where there are more than one main parameter too, as
>> that can get confusing otherwise. Its also the way most commands already
>> are.
>>
>> There are just a few hyphenated commands as you say.  I spotted
>> delete-region and remove-region
>>
>> command-script is an odd on as really its just run 

Re: [Opensim-dev] Timeout on uploading large Collada Meshes

[Dahlia Trimble]

I believe the mesh upload is all (or mostly) done via Caps so there would
be few, if any, UDP packets involved. If you were doing this in SL then the
viewer would convert the mesh to the LL format, send it to the sim where
the sim would calculate the cost and notify the viewer and then the viewer
would display it. The viewer does not compute cost at all, it's entirely
done server side. Since OpenSimulator has no implementation, no cost is
sent back to the viewer. It would require a viewer modification to remove
the cost from the uploader.

If you are seeing excessive uploading delays with very large meshes it's
possible your mesh is too large or there is a viewer bug. I believe meshes
are limited to 65536 vertices and I'm not sure about triangles but I've
seen rez failures on some viewers with meshes with more than 32767
triangles. If your mesh is larger than that then you may be reaching some
internal limitation in the viewer you are using, and if you do succeed in
uploading it, other viewers may fail when trying to display it. If your
mesh is not that large then I'd probably try a different viewer just to
make sure it's not something in that particular viewer you are using.


On Thu, Aug 15, 2013 at 7:09 AM, Justin Clark-Casey <
jjusti...@googlemail.com> wrote:

> Austin, that means that during the mesh upload either the viewer is
> sending no UDP packets or they're all being crowded out by the upload.
>
> A very short term 'fix' would be to increase the connection timeout using
> the AckTimeout setting in [ClientStack.LindenUDP].  If the viewer is
> genuinely sending no UDP data during the upload then this is something that
> needs to be considered separately (though I would find that rather
> surprising).
>
> Robert, all cost calculations are done on the viewer - there is no code
> for this in OpenSim and no viewer numbers are used by OpenSim (which would
> be dangerous anyway as one cannot trust the viewer).  The viewer would have
> to disable this calc if it detects that it's working with OpenSim.
>
>
> On 15/08/13 12:26, Robert Martin wrote:
>
>> on a related note is there a way for the "cost" part to be disabled (i
>> have seen it take like 7 minutes for the cost
>> calc to timeout)?
>> Also what is the recommended limits for 1 Avatar meshes 2 "static" meshes
>> ?
>>
>>
>>
>>
>> On Wed, Aug 14, 2013 at 4:05 PM, Ai Austin > ai.ai.aus...@gmail.com**>> wrote:
>>
>> When I try uploading some large meshes I am seeing timeouts every now
>> and then.. but I can see no errors in the mesh
>> upload...
>>
>> Is there a hard wired limit somewhere on the time and the mesh upload
>> might be blocking any acknowledgements that
>> the viewer is ant to give to the server?
>>
>> 21:02:41 - [LLUDPSERVER]: Ack timeout, disconnecting root agent for
>> Simona Stick in simonastick 1
>>
>> __**___
>> Opensim-dev mailing list
>> Opensim-dev@lists.berlios.de 
>> > >
>> 
>> https://lists.berlios.de/__**mailman/listinfo/opensim-dev<
>> https://lists.berlios.de/**mailman/listinfo/opensim-dev
>> >
>>
>>
>>
>>
>>
>> --
>> Robert L Martin
>>
>>
>> __**_
>> Opensim-dev mailing list
>> Opensim-dev@lists.berlios.de
>> https://lists.berlios.de/**mailman/listinfo/opensim-dev
>>
>>
>
> --
> Justin Clark-Casey (justincc)
> OSVW Consulting
> http://justincc.org
> http://twitter.com/justincc
>
> __**_
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/**mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] I need a small favor - add bulletsim log to OpenSim.exe.config

[Dahlia Trimble]

you could also filter the log with something like:
>> grep "[BULLET" OpenSim.log > bullet.log


On Thu, Aug 1, 2013 at 10:47 AM, Adams, Robert wrote:

> If you would like the regular "OpenSim.log" entries for BulletSim to go
> into a different file or to happen at a different log level, there are
> examples for that in the existing "bin/OpenSim.exe.config". Probably, an
> addition similar to:
>
> 
> 
> 
>
> You can also add an "" to this "" section to have
> the log messages go into a different file. So, extend the example you gave
> with another "" section that specifies the BulletSim DLL as the
> 'name'.
>
> BulletSim has its own VERY DETAILED logging that outputs all the gritty
> details of operation to separate log files. This logging is enabled from
> your INI file with:
>
> [BulletSim]
> PhysicsLoggingEnabled = True
> PhysicsLoggingDir = "."  ; can be set to any
> directory
> VehicleLoggingEnabled = False; set to 'True' to also get
> messages on vehicle computations
>
> To understand the output of the detail log files, you will need to refer
> to the sources.
>
> -- ra
>
>
> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:
> opensim-dev-boun...@lists.berlios.de] On Behalf Of OpenSimFan
> Sent: Wednesday, July 31, 2013 5:50 PM
> To: opensim-dev@lists.berlios.de
> Subject: [Opensim-dev] I need a small favor - add bulletsim log to
> OpenSim.exe.config
>
> I need a small favor. I want to add bulletsim log to OpenSim.exe.config as
> a separate logfile for debugging, but not sure how.. please help
>
> here is mine
> OpenSim.exe.config
> 
>
> maybe add this as a ".example"  to git master...
>
>
> Thank you..
>
>
>
>
> -
> _
> Keep up the good work.!!! - OpenSimFan
> My Opensim/Second Life Blog
> http://verwijs.wordpress.com
> (Dutch, basic hardware/software help  windows, Mac, Linux)
> http://verwijs-pc.nl My Twitter Page:
> http://twitter.com/OpenSimFan
> My Facebook page (be my friend, please )
> http://www.facebook.com/andre.verwijs
> --
> View this message in context:
> http://opensim-dev.2196679.n2.nabble.com/I-need-a-small-favor-add-bulletsim-log-to-OpenSim-exe-config-tp7578687.html
> Sent from the opensim-dev mailing list archive at Nabble.com.
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Documentation for IClientNetworkServer

[Dahlia Trimble]

Actually the 2nd link is for libopenmetaverse, the library which implements
the Second Life protocol. It's used in OpenSimulator for generating the UDP
packets and other messages which allow communications with the various
viewers. The wiki often has information which cannot be found in the Second
Life wiki, and the code is quite well structured and complete and contains
a good understanding of the protocol.

Good luck with your protocol. I've designed a couple alternative protocols
and I found it to be quite challenging; there are many "gotchas" lurking
around. I've also implemented alternative protocols both as IClientAPI
modules and as region modules, and I found region modules to be a better
place for experimenting as the IClientApi interface is constantly changing
and it's difficult to keep private modules in sync with core. Region module
interfaces are much more simple and stable, and you really only need to ask
for events that you care about thru EventManager. If you want to
instantiate avatars, the NPC facilities can be invoked from region modules
as well.


On Sat, Apr 20, 2013 at 4:08 AM, Sergiy Byelozyorov wrote:

> Thank you for the links. I've seen the first one - it did gave me
> sufficient introduction, but it is not detailed enough. Many messages are
> only described by their structure, but not the meaning of each field, e.g. 
> this
> one <http://wiki.secondlife.com/wiki/ParcelAccessListUpdate> (what flags
> can be set?) or this one<http://wiki.secondlife.com/wiki/AgentHeightWidth> 
> (what's
> agent's client and width, gen counter?). This information can be found in
> the code and I have compiled a short description for a few messages:
> https://docs.google.com/spreadsheet/ccc?key=0AtS8km6a08YmdGZUS0FINkhibGZ1U2RVZnJSSXMzZ1E&usp=sharing
>
> The second one seems like a guide for developing scripts in-world, while I
> am currently looking into writing an alternative protocol for client-server
> communication. I have some plans to work on scripting APIs too, so it will
> be useful for me at some point in the future.
>
>
> Sergiy
>
>
> On Sat, Apr 20, 2013 at 8:11 AM, Dahlia Trimble 
> wrote:
>
>> If you're interested in LL protocol,
>> http://wiki.secondlife.com/wiki/Protocol might be a good place to start.
>> There's also http://lib.openmetaverse.org/wiki/Developer_Portal which
>> contains a lot of useful information.
>>
>>
>> On Fri, Apr 19, 2013 at 2:58 PM, Sergiy Byelozyorov wrote:
>>
>>> I can only view source, but can't edit the page. Perhaps you can create
>>> a new page "Linden Lab viewer protocol", grant me the rights to edit it and
>>> link it from the Client-Server protocol section. My username in the wiki is
>>> Rryk.
>>>
>>>
>>> Sergiy
>>>
>>>
>>> On Fri, Apr 19, 2013 at 9:26 PM, Justin Clark-Casey <
>>> jjusti...@googlemail.com> wrote:
>>>
>>>> A great place to do this would be on new wiki page(s) linked from [1].
>>>>  Please feel free just to create a wiki account and start editing!  I
>>>> haven't yet written up any general information the LL viewer-server
>>>> protocol and it would be great to have some.
>>>>
>>>> Another place for protocol information might be the libomv wiki [2],
>>>> though on a (very) casual glance I don't see any protocol-level doc apart
>>>> from the auto-extracted UDP message templates.
>>>>
>>>> The other sources of protocol information would be the LL wiki.
>>>>
>>>> [1] 
>>>> http://opensimulator.org/wiki/**Communication_Protocols<http://opensimulator.org/wiki/Communication_Protocols>
>>>> [2] 
>>>> http://lib.openmetaverse.org/**wiki/Developer_Portal<http://lib.openmetaverse.org/wiki/Developer_Portal>
>>>>
>>>>
>>>> On 19/04/13 20:10, Sergiy Byelozyorov wrote:
>>>>
>>>>> Thank you. This mailing list is in principle some kind of
>>>>> documentation. :-)
>>>>>
>>>>> Btw, I have done some study of the LL protocol and wrote a small
>>>>> summary for a few messages (that were logged by the
>>>>> server while a client has performed a few simple actions such as
>>>>> walking and flying). I haven't found any documentation
>>>>> on the protocol other than the one in the code, which is where I have
>>>>> got the information from. Perhaps someone can use
>>>>> my research - where can I post my study? Would be also great if I
>>>>> co

Re: [Opensim-dev] Documentation for IClientNetworkServer

[Dahlia Trimble]

If you're interested in LL protocol,
http://wiki.secondlife.com/wiki/Protocol might be a good place to start.
There's also http://lib.openmetaverse.org/wiki/Developer_Portal which
contains a lot of useful information.


On Fri, Apr 19, 2013 at 2:58 PM, Sergiy Byelozyorov wrote:

> I can only view source, but can't edit the page. Perhaps you can create a
> new page "Linden Lab viewer protocol", grant me the rights to edit it and
> link it from the Client-Server protocol section. My username in the wiki is
> Rryk.
>
>
> Sergiy
>
>
> On Fri, Apr 19, 2013 at 9:26 PM, Justin Clark-Casey <
> jjusti...@googlemail.com> wrote:
>
>> A great place to do this would be on new wiki page(s) linked from [1].
>>  Please feel free just to create a wiki account and start editing!  I
>> haven't yet written up any general information the LL viewer-server
>> protocol and it would be great to have some.
>>
>> Another place for protocol information might be the libomv wiki [2],
>> though on a (very) casual glance I don't see any protocol-level doc apart
>> from the auto-extracted UDP message templates.
>>
>> The other sources of protocol information would be the LL wiki.
>>
>> [1] 
>> http://opensimulator.org/wiki/**Communication_Protocols
>> [2] 
>> http://lib.openmetaverse.org/**wiki/Developer_Portal
>>
>>
>> On 19/04/13 20:10, Sergiy Byelozyorov wrote:
>>
>>> Thank you. This mailing list is in principle some kind of documentation.
>>> :-)
>>>
>>> Btw, I have done some study of the LL protocol and wrote a small summary
>>> for a few messages (that were logged by the
>>> server while a client has performed a few simple actions such as walking
>>> and flying). I haven't found any documentation
>>> on the protocol other than the one in the code, which is where I have
>>> got the information from. Perhaps someone can use
>>> my research - where can I post my study? Would be also great if I could
>>> update it as I will continue to learn more about
>>> the protocol with time.
>>>
>>>
>>> Sergiy
>>>
>>>
>>> On Tue, Apr 16, 2013 at 11:06 PM, Justin Clark-Casey <
>>> jjusti...@googlemail.com 
>>> >
>>> wrote:
>>>
>>> This is very old code, some of which was originally present for load
>>> balancing experiments which have long been
>>> defunct and the original coders unavailable.  Its purpose was also
>>> completely undocumented.  Therefore, I have
>>> removed NetworkStop().
>>>
>>> As for AddScene, you can assume it will only be called once.  There
>>> is a mechanism in OpenSimBase which looks like
>>> it was intended as a bypass (presumably so that AddScene() could be
>>> called multiple times on a single
>>> INetworkClientServer).  But I believe this was again present for the
>>> above load balancing experiments and is
>>> effectively defunct.
>>>
>>> I'm afraid no general documentation really exists for the client
>>> stack interfaces and mechanisms.  The best we can
>>> do is try and fill in the blanks on request.
>>>
>>>
>>> On 15/04/13 15:27, Sergiy Byelozyorov wrote:
>>>
>>> Also what's the difference between Stop and NetworkStop?
>>>
>>>
>>> Sergiy
>>>
>>>
>>> On Mon, Apr 15, 2013 at 4:21 PM, Sergiy Byelozyorov <
>>> rryk...@gmail.com 
>>>  >> wrote:
>>>
>>>  Hi,
>>>
>>>  I am implementing a new client network server class. Is
>>> there any documentation on IClientNetworkServer? In
>>>  particular I am interested whether AddScene may be called
>>> several times or not.
>>>
>>>  Sergiy
>>>
>>>
>>>
>>>
>>> __**___
>>> Opensim-dev mailing list
>>> Opensim-dev@lists.berlios.de >> berlios.de >
>>> 
>>> https://lists.berlios.de/__**mailman/listinfo/opensim-dev<
>>> https://lists.berlios.de/**mailman/listinfo/opensim-dev
>>> >
>>>
>>>
>>>
>>>
>>> --
>>> Justin Clark-Casey (justincc)
>>> OSVW Consulting
>>> http://justincc.org
>>> http://twitter.com/justincc
>>> __**___
>>> Opensim-dev mailing list
>>> Opensim-dev@lists.berlios.de 
>>> >> >
>>> 
>>> https://lists.berlios.de/__**mailman/listinfo/opensim-dev<
>>> https://lists.berlios.de/**mailman/listinfo/opensim-dev
>>> >
>>>
>>>
>>>
>>>
>>>
>>> __**_
>>> Opensim-dev mailing list
>>> Opensim-dev@lists.berlios.de
>>> https://lists.berlios.de/**mailman/listinfo/opensim-

Re: [Opensim-dev] can't load opensimulator within VS 2012 Windows 8

[Dahlia Trimble]

It works fine for me if I use the "for Windows Desktop" version of Visual
Studio 2012. I think the version for "Windows 8" is only for Metro apps.

On Sat, Apr 6, 2013 at 10:09 AM, OpenSimFan  wrote:

> true, VS 2012 is very new, it will take a lot of work to make it
> compatible...
>
>
> André
>
>
>
> -
> _
> Keep up the good work.!!! - OpenSimFan
> My Opensim/Second Life Blog
> http://verwijs.wordpress.com
> (Dutch, basic hardware/software help  windows, Mac, Linux)
> http://verwijs-pc.nl
> My Twitter Page:
> http://twitter.com/OpenSimFan
> My Facebook page (be my friend, please )
> http://www.facebook.com/andre.verwijs
> --
> View this message in context:
> http://opensim-dev.2196679.n2.nabble.com/can-t-load-opensimulator-within-VS-2012-Windows-8-tp7578617p7578623.html
> Sent from the opensim-dev mailing list archive at Nabble.com.
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] can't load opensimulator within VS 2012 Windows 8

[Dahlia Trimble]

I think you have the wrong version of Visual Studio. Try using "Microsoft
Visual Studio Express 2012 for Windows Desktop"

On Sat, Apr 6, 2013 at 3:39 AM, OpenSimFan  wrote:

>can't load opensimulator within VS 2012 Windows 8...  why...
>
> <
> http://opensim-dev.2196679.n2.nabble.com/file/n7578617/opensim-vs2012-small.png
> >
>
>
>
>
>
>
>
>
> -
> _
> Keep up the good work.!!! - OpenSimFan
> My Opensim/Second Life Blog
> http://verwijs.wordpress.com
> (Dutch, basic hardware/software help  windows, Mac, Linux)
> http://verwijs-pc.nl
> My Twitter Page:
> http://twitter.com/OpenSimFan
> My Facebook page (be my friend, please )
> http://www.facebook.com/andre.verwijs
> --
> View this message in context:
> http://opensim-dev.2196679.n2.nabble.com/can-t-load-opensimulator-within-VS-2012-Windows-8-tp7578617.html
> Sent from the opensim-dev mailing list archive at Nabble.com.
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Detach screen fails with opensim 0.7.5 and mono 3.0.4

[Dahlia Trimble]

Screen should capture ctrl-a d and act on it before sending anything to
OpenSimulator. I suspect it's a problem with the version of screen you are
using and/or perhaps with your terminal emulator.

On Wed, Mar 20, 2013 at 1:57 PM, R.Gunther  wrote:

> For some reason opensim thats running on mono 3.0.4 (dont have other mono)
> is ignoring the ctrl-A d key compleet. tried a screen session with MC and
> that works fine.
> is there a problem with opensim 0.7.5 and ctrl key ?
> __**_
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/**mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] asset type vs inventory type

[Dahlia Trimble]

I would think it might affect what the viewer can do with inventory items,
such as wearing a skin or a body part or trying to rez an object by drag
and drop.

On Wed, Mar 13, 2013 at 7:37 PM, Mic Bowman  wrote:

> Thanks...
>
> This is for that filesystem-based inventory tool I mentioned to you the
> other day. Since I don't have to worry about icons and nice viewer
> operations, I think I'm just going to ignore the existence of the inventory
> types and stick to asset types.
>
> --mic
>
>
> On Wed, Mar 13, 2013 at 4:47 PM, Justin Clark-Casey <
> jjusti...@googlemail.com> wrote:
>
>> On 13/03/13 12:40, Jeff Kelley wrote:
>>
>>> At 8:57 PM -0700 3/12/13, Mic Bowman wrote:
>>>
>>>  maybe a better question... are inventory types used for anything other
 than to put
 the right icon in the viewer (without the need to pull the asset) and
 put stuff in the
 right default folder?

>>>
>>>
>>> According to 
>>> http://opensimulator.org/wiki/**Custom_Libraries
>>>
>>> « Inventory type is what tells the viewer which sort of icon to show
>>> next to the inventory item's name. »
>>>
>>>
>>> It also controls the variable part of the contextual menu ("Open",
>>> "Wear", "Attach", "Play", "Teleport") and which
>>> editor to use.
>>>
>>
>> Yes, it does seem a messy crossover with much of the inventory type
>> covered by equivalent asset type enums.  But it's not a subset - inventory
>> type has an attachment enum for instance.  Although whether that particular
>> enum is actually used I couldn't say.
>>
>> --
>> Justin Clark-Casey (justincc)
>> OSVW Consulting
>> http://justincc.org
>> http://twitter.com/justincc
>>
>> __**_
>> Opensim-dev mailing list
>> Opensim-dev@lists.berlios.de
>> https://lists.berlios.de/**mailman/listinfo/opensim-dev
>>
>
>
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Raise minimum .net framework version to 4.0 and mono version to 2.8 (with 2.10 strongly recommended) in 2Q2013

[Dahlia Trimble]

Not all of the users of OpenSimulator are sysadmins. Have you ever worked
in a corporate environment? Often the computers that people use are managed
by a central IT department and deviating from the long-term supported IT
mandated solution is not allowed. Similar situations exist in education.
OpenSimulator is not necessarily designed for the sole benefit of a few
for-profit grids, in fact, much of the code base has been contributed by
people who use *and develop* it in such restricted environments. This is
true for content development as well.

Likewise, not all of the contributors have a large R&D budget. For some,
upgrading to the latest and greatest is not an option, in fact, it could
disable other applications they need to use a shared computer for. Some of
these users have contributed major functionality to the code base. As
stewards of the code base, we need to keep the needs of *all* users in
mind. These are some of the reasons these traditions exist.


On Tue, Jan 29, 2013 at 9:59 AM, Ilan Tochner  wrote:

> It's nice to want to support old Linux versions but anyone who is going to
> install OpenSim on Linux, which is not something anyone who isn't a capable
> sysadmin will do, can easily set up that machine with a modern version of
> Ubunto where Mono 2.10 is supported (or use some other distro and manually
> install OpenSim from a third-party website). Had we said that upgrading to
> Mono 2.10 would make it harder for non-technical people to run OpenSim then
> there would have been some (small) justification for holding back on
> advancing OpenSim. However, to do so in order to save sysadmins from
> upgrading their outdated distros is putting the needs of the very few above
> those of the great majority of OpenSim users.
>
> Delaying advancement of a software project that is labeled Alpha for the
> stated reason places enterprise-level legacy support requirements on an
> open-source project that is developed and used by people that have nothing
> preventing them from upgrading their systems (Windows and Mac users have no
> problem using the latest Mono versions as it is). No end-user is going to
> be affected by this upgrade, if any of them is using Linux at home (which I
> doubt more than a few dozen are) then they are likely either using Ubunto
> in the first place and/or are capable of downloading and installing Mono
> from a third-party site.
>
> How many people are going to be served by delaying an upgrade to .NET 4.0?
> How many people will have an inferior OpenSim because of that delay?
>
> It's not that we're preventing anyone from using the existing OpenSim
> version. We're just saying that if you want to use the latest version on
> Linux you need to have Mono 2.10 or later installed. If it doesn't come
> with your distro then search for a third-party site that provides it and
> download it from there. People who can't be bothered to doing either one of
> those things can continue using the existing OpenSim version.
>
> Again, let's focus on advancing OpenSim and not on saving some sysadmins
> the few hours it will take them to install and setup Mono and/or a new
> Linux distro on their server(s).
>
> Cheers,
>
> Ilan Tochner
> Co-Founder and CEO
> Kitely Ltd.
>
>
> On Tue, Jan 29, 2013 at 6:16 PM, Mike Chase <
> mike.ch...@alternatemetaverse.com> wrote:
>
>> Just curious.  Call me crazy and stuff but why are you worrying about
>> ancient distros with LTS for cases where upgrades to Mono are clearly
>> available.  And this is to support software that is perpetually alpha?  So
>> you are concerned about adopting .NET 4.0 features because someone might
>> be
>> running an ancient version of debian or Ubuntu presumably in some
>> production
>> scenarios using software you've branded as Alpha.
>>
>> Why don't we call OpenSim what it is.  A research project.   People have
>> taken and with considerable effort doe some hardening to that sufficient
>> to
>> run a production grid.  But it is what it is.
>>
>> And sorry Justin I don't meant to jump on you. You're a good guy.  You
>> have
>> to deal with the other members of a board drawing lines in the sand left
>> and
>> right that suit themselves and their own business interests.  Sorry
>> Melanie,
>> the "it's never gonna happen" comments are so out of place for a board
>> member of an open public project.  Really you have no business being in
>> the
>> position you are. But that's what it is as well.
>>
>> Ok enough ranting.  If you feel that upgrading to the 4.0 .NET apis would
>> benefit OpenSim as a whole (I do) then do it.  Deciding what versions of
>> mono to use and what distribution to use it on are deployment
>> considerations
>> that someone should be considering carefully based on what they want to
>> use
>> the software for.  And if they are trying to run anything close to a
>> production service then they need to be aware of the issues involved in
>> the
>> various versions of mono and make their choice based on that.
>>
>> I do

Re: [Opensim-dev] Raise minimum mono version to 2.6

[Dahlia Trimble]

Nobody is asking you to use an older version. The minimum version is simply
the earliest version that would be required to run OpenSimulator. Anyone is
free to use any later version if they so choose.

It's also not true that later versions are necessarily better. I've
personally had to disable features in OpenSimulator and remove them from
core due to newer versions of Mono which introduced new bugs that made such
features unusable.


On Sun, Jan 27, 2013 at 1:05 AM, Ilan Tochner  wrote:

> Mono 2.10 was released Feb 15th, 2011, i.e almost two years ago. I don't
> think there is any target platform that mono 2.6 runs on that doesn't have
> mono 2.10 working on it as well.
>
> There have been many bug fixes in mono between the 2.6 release and the
> 2.10 release, some of which can definitely effect OpenSim performance and
> stability. Who would choose to use the older mono version when a better one
> has been available for at least two years? If someone reports a problem
> with OpenSim I think we should require them to at least test it using mono
> 2.10 so we can rule out the older mono being the cause of the problem.
>
>
> Cheers,
>
> Ilan Tochner
> Co-Founder and CEO
> Kitely Ltd.
>
> On Sun, Jan 27, 2013 at 4:28 AM, Dahlia Trimble 
> wrote:
>
>> I think the point is raise it to the minimum version which supports the
>> codebase. If there was some feature in 2.10 that did not exist in 2.6 and
>> that feature was required for proper execution, then 2.10 would be a better
>> target. Otherwise it would just be forcing people to upgrade who would not
>> otherwise need to.
>>
>> There's nothing stopping anyone from upgrading to 2.10 if they desire,
>> however, requiring a higher version than is really necessary limits
>> potential users of the software to those who are able to install those
>> versions in their setups. If a goal of OpenSimulator developers is wide
>> adoption, then it makes sense to have it be usable on as many existing
>> hardware/software configurations as possible.
>>
>>
>>
>> On Sat, Jan 26, 2013 at 11:51 AM, Ilan Tochner  wrote:
>>
>>> I second setting 2.10 as the base. If we'll be forcing people to upgrade
>>> I think we should upgrade to the latest stable release and not to one that
>>> is outdated.
>>>
>>> If OpenSim works fine with 3.0 then I'd vote for it to be the base. If
>>> we're still calling OpenSim alpha we should at least get the benefits of
>>> doing so. Supporting old versions of mono is a waste of developer resources.
>>>
>>> Cheers,
>>>
>>> Ilan Tochner
>>> Co-Founder and CEO
>>> Kitely Ltd.
>>>
>>>
>>>
>>> On Sat, Jan 26, 2013 at 9:20 PM, Trinity  wrote:
>>>
>>>> if we can get a way with it why not go to 2.10 else quickly be out of
>>>> date agian
>>>>
>>>>
>>>> On Sat, Jan 26, 2013 at 9:38 AM, James Hughes >>> > wrote:
>>>>
>>>>> +1
>>>>>
>>>>> On 01/24/2013 10:29 PM, Justin Clark-Casey wrote:
>>>>>
>>>>>> Whilst writing JsonStore regression tests this evening, I hit the
>>>>>> problem where modInvoke script methods of more than 4 parameters
>>>>>> cannot
>>>>>> be registered on Mono 2.4.3 as it doesn't implement the required
>>>>>> larger
>>>>>> multi-parameter Func generic types.
>>>>>>
>>>>>> Therefore, I want to bump the minimum Mono version for OpenSimulator
>>>>>> up
>>>>>> to 2.6 which was released more than 3 years ago. This also involves
>>>>>> bumping the minimum .net framework version up to 4.0, as also detailed
>>>>>> at [1]
>>>>>>
>>>>>> [1] 
>>>>>> http://opensimulator.org/**mantis/view.php?id=5971<http://opensimulator.org/mantis/view.php?id=5971>
>>>>>>
>>>>>> Any comments?
>>>>>>
>>>>>>
>>>>> __**_
>>>>> Opensim-dev mailing list
>>>>> Opensim-dev@lists.berlios.de
>>>>> https://lists.berlios.de/**mailman/listinfo/opensim-dev<https://lists.berlios.de/mailman/listinfo/opensim-dev>
>>>>>
>>>>
>>>>
>>>> ___
>>>> Opensim-dev mailing list
>>>> Opensim-dev@lists.berlios.de
>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>>
>>>
>>>
>>> ___
>>> Opensim-dev mailing list
>>> Opensim-dev@lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>
>>
>>
>> ___
>> Opensim-dev mailing list
>> Opensim-dev@lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>
>
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Raise minimum mono version to 2.6

[Dahlia Trimble]

I think the point is raise it to the minimum version which supports the
codebase. If there was some feature in 2.10 that did not exist in 2.6 and
that feature was required for proper execution, then 2.10 would be a better
target. Otherwise it would just be forcing people to upgrade who would not
otherwise need to.

There's nothing stopping anyone from upgrading to 2.10 if they desire,
however, requiring a higher version than is really necessary limits
potential users of the software to those who are able to install those
versions in their setups. If a goal of OpenSimulator developers is wide
adoption, then it makes sense to have it be usable on as many existing
hardware/software configurations as possible.


On Sat, Jan 26, 2013 at 11:51 AM, Ilan Tochner  wrote:

> I second setting 2.10 as the base. If we'll be forcing people to upgrade I
> think we should upgrade to the latest stable release and not to one that is
> outdated.
>
> If OpenSim works fine with 3.0 then I'd vote for it to be the base. If
> we're still calling OpenSim alpha we should at least get the benefits of
> doing so. Supporting old versions of mono is a waste of developer resources.
>
> Cheers,
>
> Ilan Tochner
> Co-Founder and CEO
> Kitely Ltd.
>
>
>
> On Sat, Jan 26, 2013 at 9:20 PM, Trinity  wrote:
>
>> if we can get a way with it why not go to 2.10 else quickly be out of
>> date agian
>>
>>
>> On Sat, Jan 26, 2013 at 9:38 AM, James Hughes 
>> wrote:
>>
>>> +1
>>>
>>> On 01/24/2013 10:29 PM, Justin Clark-Casey wrote:
>>>
 Whilst writing JsonStore regression tests this evening, I hit the
 problem where modInvoke script methods of more than 4 parameters cannot
 be registered on Mono 2.4.3 as it doesn't implement the required larger
 multi-parameter Func generic types.

 Therefore, I want to bump the minimum Mono version for OpenSimulator up
 to 2.6 which was released more than 3 years ago. This also involves
 bumping the minimum .net framework version up to 4.0, as also detailed
 at [1]

 [1] 
 http://opensimulator.org/**mantis/view.php?id=5971

 Any comments?


>>> __**_
>>> Opensim-dev mailing list
>>> Opensim-dev@lists.berlios.de
>>> https://lists.berlios.de/**mailman/listinfo/opensim-dev
>>>
>>
>>
>> ___
>> Opensim-dev mailing list
>> Opensim-dev@lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>
>
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] IRegisterInterface for extending scene entities

[Dahlia Trimble]

I'm not seeing the rationale for rule #1. Could you explain it a bit?
Anyway, if there is a good technical reason for it, perhaps OSDMap could be
subclassed and code added to enforce the rule?

On Fri, Jan 18, 2013 at 3:46 PM, Justin Clark-Casey <
jjusti...@googlemail.com> wrote:

> Alright, I'm going to suggest
>
> 1.  That all attributes must be within their own OSDMap, which must be a
> minimum of 4 chars long (maybe this could be relaxed for 'core' stuff).
>
> 2.  Within this map, attribute names and further OSDMap or other
> structures are entirely up to the caller.
>
> 3.  At the initial development stage, everything may change such that
> existing data may no longer be retrieved (e.g. the way this is stored or
> the entire approach may change).  One must not rely on data being present.
>
> 4.  If at all possible, this must be backward and forward compatible with
> other versions of OpenSimulator no matter whether it remains or is altered
> radically.  This should be fine since deserialization will ignore any
> top-level xml nodes that it doesn't recognize.  But we must preserve a
> Postel's law - this was a painful lesson to learn.
>
>
> On 18/01/13 22:09, Adams, Robert wrote:
>
>> I have a need to add more attributes to an SOP (use specified
>> center-of-gravity, user specified mass, rolling friction, ...) and the
>> implementation of Justin's dynamic attributes is just what I need. It does
>> not fulfill my other wishes of adding functionality to SOPs, but it does
>> allow the dynamic addition of new and serialized objects attributes.
>>
>> Can we Just Do It(r)(tm)(sm)? Some comments in the code suggesting a top
>> level naming convention ("prepend attribute names with your module name" or
>> some such) and an admonition to not store large things might be sufficient
>> to control the use of a simple OSDMap.
>>
>> What do you say? I am +1. How about everyone else? It is a start.
>>
>> -- ra
>>
>> -Original Message-
>> From: 
>> opensim-dev-bounces@lists.**berlios.de[mailto:
>> opensim-dev-bounces@**lists.berlios.de]
>> On Behalf Of Justin Clark-Casey
>> Sent: Friday, January 04, 2013 5:18 PM
>> To: opensim-dev@lists.berlios.de
>> Subject: Re: [Opensim-dev] IRegisterInterface for extending scene entities
>>
>> No problem in making this e-mails, Robert - I think this is exactly the
>> kind of discussion that we need.  These are the kind of decisions that
>> we'll be stuck with for a long time so I think we need to think them
>> through, both through discussion and review or proof-of-concept code.
>>
>> I hadn't really properly considered that the JSONStore is close to this.
>>  I suppose one other significant difference is that the current
>> dynamic-attributes effectively stores data per part rather than through a
>> single datastore for the whole region.
>>
>> But even if it does use the blackboard pattern, there still has to be an
>> underlying persistence store, which in this case would be a serialized JSON
>> object that is functionally identical with the OSD Map (I've run out of
>> time today to see if the JSON store enforces type safety in some way).
>>  Really, the code could be very similar, though in terms of formats I would
>> prefer if to avoid further schizophrenia over data storage in
>> OpenSimulator.  If we stored as JSON, for instance, we end up transporting
>> a JSON object in XML... :p
>>
>> On 04/01/13 21:22, Adams, Robert wrote:
>>
>>> I think adding a module allowing scripts to attach dynamic variables to
>>> SOPs is the right level of functionality. Just adding a key/value store is
>>> way too low a level.
>>>
>>> For instance, the JSONStore module (http://opensimulator.org/**
>>> wiki/JsonStore_Module )
>>> creates a dynamic variable storage to share between scripts. Since it's
>>> made for sharing, a script can request events when values are updated. The
>>> module adds, as one piece, functionality for extension and communication
>>> between scripts.
>>>
>>> Does this attribute store enable such? Would a script want to know when
>>> one of the key/value pairs changed? Is polling suitable? Does the usage
>>> case just need static variable addition?
>>>
>>> As to the practical, implementation angle, yes, you are correct that
>>> adding an OSD store on a scene object is simpler. This is an open source
>>> project, after all, so this is just my opinion.
>>>
>>> -- ra
>>>
>>> -Original Message-
>>> From: 
>>> opensim-dev-bounces@lists.**berlios.de
>>> [mailto:opensim-dev-bounces@**lists.berlios.de]
>>> On Behalf Of Oren
>>> Hurvitz
>>> Sent: Friday, January 04, 2013 11:22 AM
>>> To: opensim-dev@lists.berlios.de
>>> Subject: Re: [Opensim-dev] IRegisterInterface for extending scene
>>> entities
>>>
>>> The typing problem is already solved since the dynamic attributes are
>>> implemented using OSD.
>>>
>>> Your proposal is much more complicated than the currently proposed
>>> attributes, and I don't want to suppress a go

Re: [Opensim-dev] Opensimulator / Second Life non-server based NPC navigation

[Dahlia Trimble]

I guess I should take this opportunity for a little shameless
self-promotion ;)

http://vimeo.com/51836266
http://vimeo.com/51377266


On Tue, Jan 8, 2013 at 6:00 PM, Dave Gubser  wrote:

> I thought the following might generate a little interest in NPC
> capablilites. :)
>
> http://www.youtube.com/watch?v=krPKVey7LgU&feature=youtu.be
>
> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de
> [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of
> opensim-dev-requ...@lists.berlios.de
> Sent: Tuesday, January 08, 2013 3:00 AM
> To: opensim-dev@lists.berlios.de
> Subject: Opensim-dev Digest, Vol 65, Issue 6
>
> Send Opensim-dev mailing list submissions to
> opensim-dev@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-requ...@lists.berlios.de
>
> You can reach the person managing the list at
> opensim-dev-ow...@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. Re: 0.7.5 rc1, missing support for the DTL/NSL module
>   (Justin Clark-Casey)
>
>
> --
>
> Message: 1
> Date: Mon, 07 Jan 2013 23:02:40 +
> From: Justin Clark-Casey 
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] 0.7.5 rc1, missing support for the DTL/NSL
> module
> Message-ID: <50eb5410.5080...@googlemail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> I suspect the compiled DTL/NSL module is looking for Mono.Addins v0.5
> whereas recent changes now mean that Mono.Addins
> v0.6 is shipped.
>
> If this is so, you really either need to recompile the DTL/NSL module (or
> ask the authors to do so in preparation for the final release of 0.7.5), or
> redirect the DTL/NSL assembly [1] to load the 0.6 module even though it's
> looking for
> 0.5 (or ask the authors).  I can't say for sure if this will work though
> there's a good chance.
>
> [1] http://msdn.microsoft.com/en-us/library/twy1dw1e%28v=vs.90%29.aspx
>
> On 07/01/13 01:31, James Hughes wrote:
> > Yes, please paste a full error output on pastebin.com and the link
> > here. Be sure no passwords or other sensitive information is included.
> >
> > Thanks!
> > BlueWall
> >
> > On 01/06/2013 05:32 PM, What Virtual World - Guy Quicksand wrote:
> >> Hello James,
> >>
> >> I have been searching for additinal dll''s in system paths, none found.
> >> I am using the Mono.addons from the opensimulator, and no the module
> >> does not come with its own version.
> >> Personaly i dont think the module is failing as i get the same error
> >> on a fresh ( without anny aditional modules ) opensim 0.7.5 rc1.
> >> My effort you point out below was that i replaced the effected files
> >> from git changes on this subject to see if i get it running.
> >> I am probably over 30 hours now trying to solve this isue, that is
> >> why i called out for help as i cant pinpoint this isue.
> >> I even tried to use the .config files from 0.7.3 as they where
> >> different.. also no solution.
> >>
> >> Strange thing is that the older git 13c4fd7 is running fine.
> >> I cant find any other mono.addin* files in any path that could be
> >> accesed, i dont know if the mono.addins search locations by them selfs?
> >> The robust is running just fine, only the simulator is giving this
> error.
> >> ( i asume this error couses all external modules to not load, as i
> >> dont have this error on the win7 box and modules are working there
> >> just fine )
> >>
> >> If you need a full error output, please let me know.
> >>
> >> Best regards,
> >> Martin forster
> >>
> >>
> >> - Original Message - From: "James Hughes"
> >> 
> >> To: 
> >> Sent: Sunday, January 06, 2013 8:57 PM
> >> Subject: Re: [Opensim-dev] 0.7.5 rc1, missing support for the DTL/NSL
> >> module
> >>
> >>
> >>> On 01/06/2013 09:15 AM, What Virtual World - Guy Quicksand wrote:
>  Hello all.. hope to post this to the right section.
>  I have been trying to update our beta simulators to 0.7.5 rc1.
>  It seems it has a problem at the mono.addins.
>  Error log(part):
>  log4net:ERROR DefaultRepositorySelector: Unhandled exception in
>  GetInfoForAssembly
>  System.IO.FileLoadException: Could not load file or assembly
>  'Mono.Addins, Versi on=0.5.0.0, Culture=neutral,
>  PublicKeyToken=0738eb9f132ed756' or one of its depe ndencies. The
>  located assembly's manifest definition does not match the assembly
>  reference. (Exception from HRESULT: 0x80131040) File name:
>  'Mono.Addins, Version=0.5.0.0, Culture=neutral,
>  PublicKeyToken=0738eb..
> >>>
> >>> Can you see any other copies of Mono.Addins in the path on that
> >>> system, or does the module distribute it's own ve

Re: [Opensim-dev] IRegisterInterface for extending scene entities

[Dahlia Trimble]

The existing 2 level SOG/SOP concept may be a usable concept but it is far
from optimal for anything other than emulating SL as it appears to exist
*today*. There really is no forced 2-level hierarchy defined in the LLUDP
protocol from which much of OpenSimulator is modeled. In fact, the
existence parent id and local id in both root parts and child parts
suggests a underlying  multi-level hierarchy and this suggests that SOG/SOP
may not adequately emulate what SL servers may be capable of doing.

If you're concerned that individual nodes in a tree each need to contain
all the properties that any other node need to contain, they really don't
have to. An "entity node" only need contain the properties and methods
which are common to all nodes, and a collection of "components", then the
other nodes can contain individual components which can really be anything
from executable code, collections of properties, generic objects, geometry,
even physics engine simulation instances. Often implementations will
include means for addressing and passing messages between entities in a
tree or even in different trees. There can even be a co-existing flat
collection of references to the tree entity nodes that can be used to speed
up addressing single nodes without having to traverse a tree or pass
messages around; i.e., receiving a network message or event destined to a
single node. In the SL/OpenSImulator model there may exist properties which
are used on a per-linkset basis however such properties could also be
stuffed into a "object properties collection object" and added to a entity
node in the form of a component.

I'll repeat what I've learned from my prototyping efforts: the
SL/OpenSimulator 2 level model can fit well into an entity-component design
and from there be extended into a more flexible system.

Unity3D uses an implementation of a entity-component architecture which
seems to be well regarded; perhaps it could serve as a reference.


On Mon, Dec 31, 2012 at 4:04 PM, Justin Clark-Casey <
jjusti...@googlemail.com> wrote:

> On 29/12/12 03:29, Dahlia Trimble wrote:
>
>> +2 on a hierarchical entity-component design. I have several prototype
>> servers and viewers implemented in various
>> languages which use variations of this architecture and I've found it to
>> be very efficient and flexible. I've also used
>> it in a prototype c++/opengl viewer which is compatible with
>> SL/OpenSimulator content (prims, sculpties, linksets,
>> avatars, meshes, terrain) and it's quite capable of functioning in this
>> type of scenario.and has performance which is
>> competitive with the fastest LL based viewers I've seen.
>>
>
> Yes, I think entity-component is the way forward.  There's a good, basic
> introduction in Programming Gems 6 [1], as well as Toni's links.  It would
> be interesting to see how this plays with region modules if this involves
> behaviour (the actions) as well as the data.
>
>
>
>> I do have mixed feelings about trying to refactor the existing
>> OpenSimulator codebase into such an architecture. So much
>> of the codebase assumes SOG/SOP as the foundation that it may be nearly
>> impossible task to convert. If this is the case,
>> I would suggest first doing a more detailed analysis of how other shared
>> online environments are implemented before
>> attempting a new design; other systems which don't duplicate the SL
>> model; This could result in a far more flexible
>> design which could take OpenSimulator far beyond what SL users expect in
>> a server.
>>
>
> I strongly agree that POC for review with a high-level explanation is
> essential for this, building on other people's experience.  Seeing
> Melanie's original ReX proposal would also be very good.  We need to have
> agreement amongst ourselves on the general direction.
>
> I have no real game coding experience, but I don't think that the basic
> SOG/SOP entities are too bad of a foundation.  I think something like a SOG
> is essential to hold attributes that only apply to the object as a whole -
> if every SOP has the required properties then you end up wasting memory,
> doing CPU busy work and having pointlessly confusing code.
>
> If you're referring to compatibility with the existing SOG/SOP properties
> and methods then I think that these should migrate over time.  If all the
> existing stuff was left as 'legacy' code then it would be horribly crufty.
>  Now is the time for change whilst OpenSimulator is still 'alpha' and none
> of the internals are a blessed API for region modules. We must increase
> flexibility otherwise we'll end up in a dead-end over the long term.  But
> we must also alway

Re: [Opensim-dev] IRegisterInterface for extending scene entities

[Dahlia Trimble]

+2 on a hierarchical entity-component design. I have several prototype
servers and viewers implemented in various languages which use variations
of this architecture and I've found it to be very efficient and flexible.
I've also used it in a prototype c++/opengl viewer which is compatible with
SL/OpenSimulator content (prims, sculpties, linksets, avatars, meshes,
terrain) and it's quite capable of functioning in this type of scenario.and
has performance which is competitive with the fastest LL based viewers I've
seen.

I do have mixed feelings about trying to refactor the existing
OpenSimulator codebase into such an architecture. So much of the codebase
assumes SOG/SOP as the foundation that it may be nearly impossible task to
convert. If this is the case, I would suggest first doing a more detailed
analysis of how other shared online environments are implemented before
attempting a new design; other systems which don't duplicate the SL model;
This could result in a far more flexible design which could take
OpenSimulator far beyond what SL users expect in a server.

On Fri, Dec 28, 2012 at 3:13 PM, James Hughes wrote:

> The original proposal to the dev list is here: http://lists.berlios.de/**
> pipermail/opensim-dev/2009-**December/008098.html
>
> And the attached document here: https://lists.berlios.de/**
> pipermail/opensim-dev/**attachments/20091211/6e190ca7/**attachment.pdf
>
> -BlueWall
>
>
> On 12/28/2012 02:24 PM, Adams, Robert wrote:
>
>> Sounds perfect. The reason I started this here was to get the discussion
>> bouncing.
>>
>> I'm interested in seeing past proposals. I searched around the
>> OpenSimulator wiki looking for Adam's old proposal (Wiki's are just useless
>> for finding and organizing things) but I could not find it.
>>
>> -- ra
>>
>> -Original Message-
>> From: 
>> opensim-dev-bounces@lists.**berlios.de[mailto:
>> opensim-dev-bounces@**lists.berlios.de]
>> On Behalf Of Melanie
>> Sent: Friday, December 28, 2012 10:59 AM
>> To: opensim-dev@lists.berlios.de
>> Subject: Re: [Opensim-dev] IRegisterInterface for extending scene entities
>>
>> I suggest we bounce this about a bit and maybe cooperatively work on a
>> test case/POC. That will certainly clarify issues. I could also pull out
>> the prosal I did for ReX which deals with this
>>
>> Melanie
>>
>> On 28 Dec 2012, at 18:38, "Adams, Robert"
>>  wrote:
>>
>>  I agree with "not reinventing the wheel".  And your valid concerns about
>>> the implementation are probably just the tip of the iceberg.
>>>
>>> I have been toying with the architectural idea that OpenSim core only
>>> provides a basic framework. Functionalities are added as plugin modules
>>> rather than implemented as if's and tests imbedded in core. For instance,
>>> could linksets be implemented as a plugin module[1]? Or maybe entity
>>> physical representation (meshing)?
>>>
>>> I merely consider llSetKeyFrameMotion as a test case to expose needed
>>> core features which support plugin modules (Necessary events available?
>>> Correct data-structures exposed/hidden? ...)  Like you, I am pretty sure
>>> the ability to programmatically extend scene entities will be needed and is
>>> a Good Thing.
>>>
>>> Since llSetKeyframeMotion has already been completed and will be
>>> incorporated soon, I'll look for another simple test case to exercise the
>>> requirements for full featured plugin modules.
>>>
>>> -- ra
>>>
>>> [1] Why would one want to do this? I've been thinking about fancy
>>> linksets where the joints are not fixed and static but could be
>>> parameterized and dynamic (hinges, sliders, 6DOF, ...). This could be used
>>> to support skeletons, doors with real hinges and/or weird and wonderful
>>> vehicles. Rather than mangling OpenSim core with lots of experimental code,
>>> it would be nice if I could build an "ExtendedLinksets" module that could
>>> be plugged in and experimented with.
>>>
>>> -Original Message-
>>> From: 
>>> opensim-dev-bounces@lists.**berlios.de
>>> [mailto:opensim-dev-bounces@**lists.berlios.de]
>>> On Behalf Of Melanie
>>> Sent: Friday, December 28, 2012 12:44 AM
>>> To: opensim-dev@lists.berlios.de
>>> Subject: Re: [Opensim-dev] IRegisterInterface for extending scene
>>> entities
>>>
>>> Hi,
>>>
>>> first off, extending scene entities is a Good Thing. I'll think a bit
>>> about the ins and outs of it and the caveats (for instance, module load
>>> order will have some hidden traps for the unwary) and serialization - well,
>>> there be dragons, you can't serialize module refs/interfaces since the
>>> destination may not have them.
>>>
>>> llSetKeyfranedMotion can most likely not be implemented that way. We
>>> know, because we have implemented it. Also, there is no need to reinvent
>>> the wheel - llSetKeyframedMotion has been slated for core release for a
>>> whi

Re: [Opensim-dev] PRIM_PHYSICS_SHAPE_TYPE and PRIM_PHYSICS_SHAPE_CONVEX missing.

[Dahlia Trimble]

standard opensim with ODE physics does not support convex hull collision
shapes. I believe BulletSim does but I don't know if it's been extended
into the LSL API.

On Fri, Dec 21, 2012 at 4:43 PM, R.Gunther  wrote:

>  i just wanted to try a default example of llSetKeyframedMotion script on
> http://wiki.secondlife.com/wiki/LlSetKeyframedMotion
> The "Universal Hinged Motion in 8 Key Frames" is useing
>
>  llSetLinkPrimitiveParamsFast(LINK_THIS,  [PRIM_PHYSICS_SHAPE_TYPE,
> PRIM_PHYSICS_SHAPE_CONVEX]);
>
> It seems opensim dopnt support [PRIM_PHYSICS_SHAPE_TYPE,
> PRIM_PHYSICS_SHAPE_CONVEX] as setting ?
> Time to dig my own example script up
>
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] ScriptEvents Module

[Dahlia Trimble]

Hi Diva,

With pathfinding, a NPC has to navigate between virtual "waypoints" along a
path to reach a goal. Currently I have a region module that can be queried
by scripts and will generate a path that a NPC should be able to follow,
then the NPC controller script checks the position of the NPC every 0.5
seconds and makes a decision if a waypoint has been reached or passed and
which direction to travel in to reach the next waypoint. One problem I have
is that the NPCs don't have a "at_target" event and that the 0.5 second
default minimum timer interval is really too long to wait. Another issue is
knowing when a NPC has reached a waypoint; it's possible that something may
have influenced the NPC's direction and position while travelling to a
waypoint and it has deviated from the straight path that was assumed when
the path was generated. This becomes especially difficult when navigating
around narrow areas with tight corners and many potential obstructions.
Ideally I'd like the NPCs to be controlled by scripts but if I could
generate events from a region module that the script could process, then
the region module could use more complex logic to determine how well a path
is being followed and if any corrections are necessary. I've not researched
how such events can be passed to a script yet, but if you think this may be
a potential application for your event system, I'd like to look into it
further and maybe try a few ideas.

-dahlia

On Sun, Nov 18, 2012 at 5:28 PM, Diva Canto  wrote:

> Hi,
>
> I am working on a module that passes interesting scene events up to the
> scripts in a manner that's very easy to act upon. An example is attached at
> the end of this message.
>
> Question: What other events would people like to grab? The idea is to have
> the module do all the complicated logic, and pass only simple facts to the
> scripts.
>
>
> state_entry()
> {
> llSay(0, "Script running");
> modSendCommand("Script Events", "subscribe|AvatarArrived",
> llGetKey());
> modSendCommand("Script Events", "subscribe|LastAvatarLeft",
> llGetKey());
> }
>
> link_message(integer sender_num, integer num, string message, key id)
> {
> list parts = llParseString2List(message, ["|"], []);
> if (llGetListLength(parts) >= 2) {
> if (llList2String(parts, 1) == "AvatarArrived") {
> // message is: event|AvatarArrived|True or False <--
> LocalTeleport or HG Teleport
> if (llGetListLength(parts) >= 3) {
> if (llList2String(parts, 2) == "True") {
> llInstantMessage(id, "Welcome to the Gateway!
> Choose your destination by walking into one of the teleporters.");
> llRegionSay(region_channel, "ports foreign");
> } else {
> llInstantMessage(id, "Welcome to the Virtual Lab's
> Gateway! Choose your local destination by walking into one of the
> teleporters.");
> llRegionSay(region_channel, "ports local");
> }
> } else {
> llSay(0, "Malformed message " + message + " " +
> (string)llGetListLength(parts)**);
> }
> play_music();
> } else if (llList2String(parts, 1) == "LastAvatarLeft") {
> // message is: event|LastAvatarLeft
> llRegionSay(region_channel, "ports reset");
> }
> }
> }
>
> __**_
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/**mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] [Windows] possible intresting registery setting.

[Dahlia Trimble]

Can you describe the symptoms you are seeing that this registry setting
corrects for you?


On Mon, Nov 5, 2012 at 12:40 PM, R.Gunther  wrote:

> Mijn sims zijn nu 4 dagen up met een aangepaste registery setting in
> windows.
> Het lijkt hier voor mijn gevoel even wat soepeler te lopen. Ik he aan
> windows7 de volgende key toegevoegt.
> "**NonBlockingSendSpecialBufferin**g" Its also available for other
> windows version, only location is slightly different in registery.
> So, am curious what others think.  Here are some Microsoft KB articles
>
> http://support.microsoft.com/**kb/126967
> http://support.microsoft.com/**kb/823764
>
>
> ALso because this, is opensim useing the push bit for tcp ? DOnt useing
> the p[ush bit can give some problems with tcp,
> That maby explains why this setting works better for me ? Keep testing
> here..
>
>
>
> __**_
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/**mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Update for group module & flotsam

[Dahlia Trimble]

Justin, would that conflict with this?
http://opensimulator.org/viewgit/?a=commit&p=opensim&h=1e899704c1c19a8c42ff313677a13f35b46605da


On Fri, Oct 19, 2012 at 7:32 PM, Justin Clark-Casey <
jjusti...@googlemail.com> wrote:

> Regarding the groups work, I have now implemented an OpenSimulator
> experimental option, MessageOnlineUsersOnly in [Groups] as of git master
> 1937e5f.  When set to true this will only send group IMs to online users.
>  This does not require a groups service update.  I believe OSGrid is going
> to test this more extensively soon though it appears to work fine on Wright
> Plaza.
>
> It's temporarily a little spammy on the console right now (what isn't!)
> with a debug message that says how many online users it is sending to and
> how long a send takes.
>
> Unlike Michelle's solution, this works by querying the Presence service
> for online users, though it also caches this data to avoid hitting the
> presence service too hard.
>
> Even though I implemented this, I'm not convinced that it's the best way
> to go - I think Michelle's approach of sending login/logoff status directly
> from simulator to groups service could still be better.  My chief concern
> with the groups approach is the potential inconsistency between online
> status stored there and in the Presence service.  However, this could be a
> non-issue.  Need to give it more thought.
>
>
> On 14/10/12 22:53, Akira Sonoda wrote:
>
>> IMHO finding out which group members are online and sending group
>> IM/Notice etc. to them actually should not be done by
>> the region server from which the group IM/notice etc. is sent.
>> This is a task which should be done centrally in case of OSgrid in Dallas
>> TX (
>> http://wiki.osgrid.org/index.**php/Infrastructure).
>>  The region server should only collect the group IM/notice etc. and
>> send it to the central group server or in the other way receiving
>> IM/notice etc. from the central group server and
>> distribute it to the Agents active on the region(s).
>>
>
> That concentrates all distribution on a central point rather than
> spreading it amongst simulators.  Then OSGrid has the problem of scaling
> this up.
>
> Having said that, there are advantages to funnelling things through a
> reliable central point.  As to which is better is a complicated engineering
> issue - the kind of which there are many in the MMO/VW space.
>
>
>
>> But there are even other places which can and should be improved. I did
>> some tests with some viewers counting the web
>> requests to the central infrastructure:
>>
>> Test 1: Teleport from a Plaza to one of my regions located on a server in
>> Europe and afterwards logging out:
>>
>> Cool VL Viewer: 912 Requests mostly SynchronousRestForms POST
>> http://presence.osgrid.org/**presence( 
>> i guess to inform
>> all my 809 friends [mostly only 5% online] I am going offline because the
>> calls to the presence service were done after
>> i closed the viewer)
>> Singularity Veiwer: 921 Requests mostly calls to presence after logoff
>> Teapot viewer: 910 Requests mostly calls to presence after logoff
>> Astra Viewer: 917 Requests mostly calls to presence after logoff
>> Firestorm: 1005 Requests mostly calls to presence after logoff
>> Imprudence: 918 mostly calls to presence after logoff
>>
>> So far so good. I have no idea why my 760 offline friends have to be
>> informed that I went offline ...
>> (Details can be found here: https://docs.google.com/open?**id=**
>> 0B301xueh1kxdNG1wLWo2YVVfYjA)
>>
>> Test 2: Direct Login onto my Region and then Logoff-( with
>> FetchInventory2 disabled )
>>
>> Cool VL Viewer: 2232 Requests mostly calls to presence ~800 during login
>> and ~800 during logout and xinventory
>> Singularity Viwer: 2340 Requests mostly calls to presence and xinventory
>> Teapot Viewer: Produced 500+ Threads in a very short time and then the
>> OpenSim.exe crashed
>> Astra Viewer: 2831 Request mostly calls to presence and xinventory
>> Firestorm Viwer: ACK Timeout for me. OpenSim.exe survived on 500 Threads
>> for 30+ minutes producing 4996 Requests mostly
>> xinventory
>> Imprudence: 1745 Requests mostly presence
>>
>> Again why do all my 809 friends have do be verified with single requests?
>> Then why this difference in xinventory
>> Requests? And why are both Teapot and Firestorm producing so many Threads
>> in such a short time? and bring OpenSim.exe to
>> crash or closely to crash ...
>> ( Details can be found here: https://docs.google.com/open?**id=**
>> 0B301xueh1kxdMDJxWm5UR2QtU2c)
>>
>
> The presence information is useful data and it was possible in git master
> commit da2b23f to change the Friends module to fetch all presence data in
> one call for status notification when a user goes on/offline, rather than
> make a separate c

Re: [Opensim-dev] Whats best way to get more debug info on linux mono.

[Dahlia Trimble]

I've recently been made aware of http://mono-project.com/Profiler but I'm
not at all very familiar with it yet so I can't really comment on how
effective it may be for what you want to do.

On Mon, Oct 1, 2012 at 3:57 PM, R.Gunther  wrote:

> Well i switched back to linux.
> But my train is crashing the sim regulair sofar in 24 hours with
> stacktrace.
> My train is a good stresstest. grin.
>
> Maby i can get more intressting data for the devs.
> Only need to keep a bit simple to get the data.
>
> Useing opensuse.
> __**_
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/**mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] partially functional llSetKeyframedMotion implementation

[Dahlia Trimble]

I think llSetKeyFramedMotion() is non-physical motion and it also uses a
list of "keyframes" to define a path which is not necessarily straight and
can have multiple points and turns. I believe part of the motivation behind
the function was to provide a low-overhead non-physical motion system that
allowed objects to move smoothly rather than in discreet steps. Using the
function, a script just provides the keyframe path and then the sim does
the rest; therefore the script doesn't need to consistently and
periodically update the object position and rotation. I'm not certain about
protocol but the function could eliminate the need for sending many update
packets by specifying velocity and angular velocity in just a few packets,
probably as few as one for each keyframe.

On Fri, Sep 28, 2012 at 6:36 PM, Justin Clark-Casey <
jjusti...@googlemail.com> wrote:

> Looks interesting.  I'd like to take a look but unfortunately I have
> various other things queued right now.  However, I did leave a couple of
> notes on the mantis.
>
> Perhaps you could explain to me why llSetKeyFramedMotion() is better than
> llMoveToTarget()?  I know OpenSimulator works somewhat differently to the
> LL simulator (e.g. scripts do not run within time slices of the scene loop
> - which is what I'm guessing happens on LL) so things might be different on
> OpenSimulator.
>
>
> On 27/09/12 19:25, SignpostMarv Martin wrote:
>
>> I started work on an implementation of llSetKeyframedMotion at work the
>> other day, but ran into some issues.
>>
>> Would be nice if other devs could take a look and try to get it working?
>> http://opensimulator.org/**mantis/view.php?id=6112
>>
>> I've only tested it with ping-pong translations (it goes too far when
>> going backwards) and rotations are untested and
>> known to be borked.
>>
>>
>> ~ Marv.
>> __**_
>> Opensim-dev mailing list
>> Opensim-dev@lists.berlios.de
>> https://lists.berlios.de/**mailman/listinfo/opensim-dev
>>
>>
>
> --
> Justin Clark-Casey (justincc)
> OSVW Consulting
> http://justincc.org
> http://twitter.com/justincc
>
> __**_
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/**mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Is it OK performance-wise to long-poll a money module?

[Dahlia Trimble]

I've had excellent luck serving many simultaneous long-poll requests with
the HTTP server that comes with OpenSimulator. Bear in mind though that
each active request may consume a thread so you might need to increase
available threads if you see problems. I'm not certain if the request
threads are managed by the threadpool in OpenSimulator or if they are
direct calls into .NET framework. I did search through the code once and
found many threads that were not treadpool managed but I can't remember if
HTTP threads were or not.


On Fri, Sep 14, 2012 at 9:07 PM, Edmund Edgar wrote:

> I've got a situation with the money module I'm working on where I'd
> like an external program (running on the client PC in parallel to the
> viewer) to be able to be in almost constant contact with the server
> while the user is logged in. (I want it to be able to find out
> whenever the user wanted to buy something.)
>
> I figure I can do this by having the external program long-poll the
> OpenSim server. (The external program makes a request, the server
> waits such time as it has something to tell the external program, then
> responds. It gives up and responds if there's nothing to say after 30
> seconds or so, at which point the external program will make a new
> request and start the cycle again.)
>
> At this point if I was serving a web application with Apache I'd start
> worrying that I was hogging a bunch of threads and eating through the
> memory. Is this the kind of thing I should be worrying about with
> OpenSim, or can I merrily go ahead and long-poll without worrying?
>
> The kind of thing I'm thinking of follows:
>
>
> public void FirstRegionLoaded ()
>
> MainServer.Instance.AddHTTPHandler ("/checkfortransactions/",
> CheckForTransactions);
>
> }
>
> public Hashtable CheckForTransactions(Hashtable request) {
>
> UUID userUUID = (get a user id using a session ID passed in the
> request or something);
>
> int i;
> // poll for 30 seconds then give up
> for (i=0; i<30; i++) {
> if
> (m_transactionsAwaitingNotification.containsKey("userUUID")) {
> // Reply to the request
> Hashtable reply = new Hashtable ();
> reply["int_response_code"] = 200;
> reply["str_response_string"] = "{ Some JSON goes
> here }";
> reply["content_type"] = "text/json";
> return reply;
> }
> Thread.Sleep (1000);
> }
>
> Hashtable reply = new Hashtable ();
> reply["int_response_code"] = 204; // No Content
> return reply;
>
> // The client will get this reply then hit /checkfortransactions/
> again.
>
> }
>
> PS. Thanks for the replies to my C#-ignorant questions on previous threads.
>
> --
> Edmund Edgar
> Avatar Classroom
> Your classroom, on the web, in a virtual world.
>
> e...@avatarclassroom.com
> +81 090 3912 3380
> Skype: edmundedgar
> Second Life: Edmund Earp
> Linked In: edmundedgar
> Twitter: @edmundedgar
> http://www.avatarclassroom.com
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] within second life, with "basic shaders" turned on, everything turns purple...

[Dahlia Trimble]

That's a viewer/driver/graphics card/shader problem.

I thought i heard somewhere that if a shader fails to compile in the LL
viewer that it turns things pink or purple but I'm not sure I heard it
correctly. Anyway try showing it to whoever distributes the viewer you are
using.


On Tue, Jul 31, 2012 at 12:54 AM, OpenSimFan  wrote:

> within second life (with SL viewer), with "basic shaders" turned on,
> everything turns purple...
>
> Basic Shaders turned 
> on...
> Basic Shaders turened 
> off...
>
> I think this is a graphic driver problem, with opensimulator i'm getting
> the same
> _
> Keep up the good work.!!! - OpenSimFan
>
> My Opensim/Second Life Blog
> http://verwijs.wordpress.com
>
> (Dutch, basic hardware/software help windows, Mac, Linux)
> http://verwijs-pc.nl
>
> My Twitter Page:
> http://twitter.com/OpenSimFan
>
> My Facebook page (be my friend, please )
> http://www.facebook.com/andre.verwijs
>
>
> --
> View this message in context: within second life, with "basic shaders"
> turned on, everything turns 
> purple...
> Sent from the opensim-dev mailing list 
> archiveat Nabble.com.
>
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Opensim and BSOD ??? (debuginfo added)

[Dahlia Trimble]

I don't remember exactly but it was probably around 2-3 hours.
Bad memory was the problem in my case, you could have other
hardware/OS/driver problems. However, OpenSim should not be able to cause
such an error as it runs in user space.

Good luck :)

On Sun, Jul 29, 2012 at 11:57 AM, R.Gunther  wrote:

> Dahlia, how long did you run memtest ?
> Bad memory is already replaced 10 days ago.
> Almost done 2 memtest passes. without any errros 5 hours running. so i
> dont suspect memory problems, unless its a very rare case/combination.
>
>
> On 2012-07-29 20:45, Dahlia Trimble wrote:
>
>> I've seen that error before, although I don't think I was using Opensim
>> at the time. In my case it was flaky memory. The odd part is the BIOS
>> memory check reported that the memory was fine. I ran memtest86 (
>> http://memtest.org/  ) for a couple hours and it found it, and replacing
>> the memory fixed it.
>>
>> Anyway OpenSim, as a .NET application running in user space, should be
>> prevented by the computer hardware from causing any such errors.
>>
>
> __**_
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/**mailman/listinfo/opensim-dev<https://lists.berlios.de/mailman/listinfo/opensim-dev>
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Opensim and BSOD ??? (debuginfo added)

[Dahlia Trimble]

I've seen that error before, although I don't think I was using Opensim at
the time. In my case it was flaky memory. The odd part is the BIOS memory
check reported that the memory was fine. I ran memtest86 (
http://memtest.org/  ) for a couple hours and it found it, and replacing
the memory fixed it.

Anyway OpenSim, as a .NET application running in user space, should be
prevented by the computer hardware from causing any such errors.

On Sun, Jul 29, 2012 at 7:49 AM, R.Gunther  wrote:

> Just want to keep this not back.
> It can be the system. The system the give problems is under testing, and
> get reinstalled anyway without some program that i suspect it gives
> problems.
> But opensim is so visible in the debug file that it looks like its doing
> maby something wrong to.
>
> But i dont think its opensim, maby a bad combination of opensim + that
> other program. (acronis)
>
> --**--
>
> Microsoft (R) Windows Debugger Version 6.2.8400.4218 AMD64
> Copyright (c) Microsoft Corporation. All rights reserved.
>
>
> Loading Dump File [C:\Windows\Minidump\072912-**15615-01.dmp]
> Mini Kernel Dump File: Only registers and stack trace are available
>
> Symbol search path is: SRV*c:\symbols*http://msdl.**
> microsoft.com/download/symbols
> Executable search path is:
> Windows 7 Kernel Version 7601 (Service Pack 1) MP (6 procs) Free x64
> Product: WinNt, suite: TerminalServer SingleUserTS
> Built by: 7601.17835.amd64fre.win7sp1_**gdr.120503-2030
> Machine Name:
> Kernel base = 0xf800`02a1a000 PsLoadedModuleList = 0xf800`02c5e670
> Debug session time: Sun Jul 29 01:12:11.702 2012 (UTC + 2:00)
> System Uptime: 4 days 5:08:03.481
> Loading Kernel Symbols
> ..**..**...
> ..**..**
> .
> Loading User Symbols
> Loading unloaded module list
> ..
> 
> ***
> * *
> *Bugcheck Analysis
>*
> * *
> 
> ***
>
> Use !analyze -v to get detailed debugging information.
>
> BugCheck A, {0, 2, 1, f80002a78c7f}
>
> *** WARNING: Unable to verify timestamp for MpFilter.sys
> *** ERROR: Module load completed but symbols could not be loaded for
> MpFilter.sys
> Probably caused by : MpFilter.sys ( MpFilter+22e3f )
>
> Followup: MachineOwner
> -
>
> 4: kd> !analyze -v
> 
> ***
> * *
> *Bugcheck Analysis
>*
> * *
> 
> ***
>
> IRQL_NOT_LESS_OR_EQUAL (a)
> An attempt was made to access a pageable (or completely invalid) address
> at an
> interrupt request level (IRQL) that is too high.  This is usually
> caused by drivers using improper addresses.
> If a kernel debugger is available get the stack backtrace.
> Arguments:
> Arg1: , memory referenced
> Arg2: 0002, IRQL
> Arg3: 0001, bitfield :
> bit 0 : value 0 = read operation, 1 = write operation
> bit 3 : value 0 = not an execute operation, 1 = execute operation
> (only on chips which support this level of status)
> Arg4: f80002a78c7f, address which referenced memory
>
> Debugging Details:
> --
>
>
> WRITE_ADDRESS: GetPointerFromAddress: unable to read from f80002cc8100
> GetUlongFromAddress: unable to read from f80002cc81c0
>   Nonpaged pool
>
> CURRENT_IRQL:  2
>
> FAULTING_IP:
> nt!KeSetEventBoostPriority+3f
> f800`02a78c7f f00fba2907  lock bts dword ptr [rcx],7
>
> CUSTOMER_CRASH_COUNT:  1
>
> DEFAULT_BUCKET_ID:  WIN7_DRIVER_FAULT
>
> BUGCHECK_STR:  0xA
>
> PROCESS_NAME:  OpenSim.exe
>
> TRAP_FRAME:  f88007bebab0 -- (.trap 0xf88007bebab0)
> NOTE: The trap frame does not contain all registers.
> Some register values may be zeroed or incorrect.
> rax=0002 rbx= rcx=
> rdx=fa800f9186f8 rsi= rdi=
> rip=f80002a78c7f rsp=f88007bebc40 rbp=fa801275fb50
>  r8=  r9= r10=
> r11=f88007bebce0 r12= r13=
> r14= r15=
> iopl=0 nv up ei ng nz na pe nc
> nt!KeSetEventBoostPriority+**0x3f:
> f800`02a78c7f f00fba2907  lock bts dword ptr [rcx],7
> ds:`=
> Resetting default scope
>
> LAST_CONTROL_TRANSFER:  from f80002a98769 to f80002a991c0
>
> STACK_TEXT:
> f880`07beb968 f800`02a98769 : `000a `
> `0002 `0001 : nt!KeBugCheckEx
> f880`07beb970 f800`02a973e0 : ` 0

Re: [Opensim-dev] IRC for Groups

[Dahlia Trimble]

Group IM may be difficult as presence in IRC may not be straightforward to
implement given the region acts as a proxy for IM. Another issue is IM can
be larger than the normal IRC message length limit of 512 bytes. XMPP may
work better given the more flexible message formats and lengths but I
suspect it would also be difficult to manage presence also. Either protocol
would likely need to be modified before a usable solution could be reached.

I've done some experimentation using a gridproxy (part of libomv) plugin to
facilitate XMPP for groups. The project is available here:
http://forge.opensimulator.org/gf/project/jabberimproxy/  It effectively
adds a XMPP client to any viewer by injecting spoof IM packets into the
packet stream between the region and the viewer.

There are also bots which act as IRC/Group IM bridges out there, the one I
am most familiar with is the one Latif Kahlifa (lkalif on IRC) runs that
connects the freenode IRC channel #awg to the Second Life group "Advanced
Worlds Group". A conversation with Latif might bring some insight into
using IRC for group IM.


On Tue, Jul 24, 2012 at 4:26 PM, Justin Clark-Casey <
jjusti...@googlemail.com> wrote:

> On 24/07/12 18:29, Blake wrote:
>
>> Hey All,
>>
>> I'm putting together a plan to implement a groups module that will use
>> IRC as the backend. I'm hoping this will provide
>> the scability needed for large grids like OSGrid.
>>
>> I'm emailing, as I wanted to hear some thoughts from the smart people on
>> the list here.
>>
>
> I don't see how this would work as groups storage simply requires a
> persistent backend from which other simulators retrieve information.  IRC
> is not these things and you would also need some form of group info push
> which would be super complicated and fragile.
>
> Now group IM, on the other hand, may be interesting to do in IRC.
>
> --
> Justin Clark-Casey (justincc)
> http://justincc.org/blog
> http://twitter.com/justincc
> __**_
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/**mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] TimerEvent to slow, do/while faster.

[Dahlia Trimble]

There's a setting which can be added to the [XEngine] section of the
OpenSim.ini file:
MinTimerInterval = 0.5

Note that if you have high speed timers and you do scene updates with them,
you will likely overflow queues in many places and cause all sorts of
problems. I seem to not have too many problems  with it set at 0.1 and with
just a couple scripts with timers that fast.

Note also that doing scene updates (moving objects) sends at least one
packet to each client connected to the sim and you really never want to
send updates faster than they can be displayed. If you send 100 packets per
second to each viewer, and most viewers are running about 30 FPS, you are
sending 70 scene updates to each viewer that cant even be displayed. If
your goal is smooth motion this will probably work against you as you will
likely have a lot of packet loss and the lazy send queues in llClientView
will send the state of the prim when the packet is sent, not as it was when
the timer event occurred, which means you could get a bunch of packets in a
row that send the same position. So, in essence, you are making the sim do
more work and probably causing instability in many areas while not
accomplishing your desired goal.

Using not_at_target() is probably the best event as it likely wouldn't send
any updates any faster than they can change in the simulator. I suspect
even using not_at_target could cause issues when lots of clients are in the
sim and/or lots of prims are moving/changing at the same time.

Also be aware that if you are changing the shape of prims, it's probably
best to make them phantom while doing many quick shape changes in a row,
otherwise the code which creates physics shapes may not be able to keep up
and you could run into memory problems as each shape is stored.

Hopefully eventually OpenSimulator will have implemented
llSetKeyFrameMotion() which would be a much more efficient way of doing
smoothly moving objects.


On Tue, Jul 17, 2012 at 5:05 PM, Justin Clark-Casey <
jjusti...@googlemail.com> wrote:

> not_at_target is currently triggered through the main scene rather than in
> the aync lsl command thread.  So it will fire at least every 1/11 of a
> second.  For some reason, the target check is also performed at
> SceneObjectGroup.**ScheduleGroupForUpdate() so it may fire even more
> often.
>
> Looking briefly at the web, sources only mention that not_at_target may
> fire multiple times before reaching a target. They say nothing about the
> periodicity of such firing.
>
>
> On 18/07/12 00:45, R.Gunther wrote:
>
>> On 2012-07-18 01:31, Justin Clark-Casey wrote:
>>
>>> If you want to increase timer resolution the current thing to do would
>>> be to change
>>>
>>> cmdHandlerThreadCycleSleepms = 100;
>>> Intressting, then i get the question why it seems the event "
>>> not_at_target" seems to have o restriction.
>>>
>> with that function i always get some sort if filled query. not_at_target
>> can fire at the same speed as do/while
>> It looks like its getting faster called then processed. i think
>> "timerevent" is right now to slow and "not_at_target"
>> is way to fast and seems to require lots of lsl time.
>>
>> The whole event triggering is sometimes tricky.
>>
>> --
>>
>>  in AsyncCommandManager.**ReadConfig().  It appears that configurability
>>> was disabled almost 4 years ago for reasons
>>> unknown.
>>>
>>> The fact that it's 100 means that you can never get timers that fire
>>> less than 100ms apart.  Moreover, timers are tied
>>> into the general AsyncCommandManager.**DoOneCmdHandlerPass(), which
>>> performs operations for listeners, sensors and
>>> dataserver events as well as timers.  So the resolution will be even
>>> less accurate.  At some point I think it may be
>>> good to do some of these in separate threads to reduce the variability
>>> of performance.
>>>
>>> However, even if these issues were to go away, the timer events would
>>> still have to be fired through the event
>>> mechanism.  I'm not sure how efficient firing lots of timers is, or what
>>> impact it would have on other scripts in the
>>> region.
>>>
>>> On 16/07/12 15:13, R.Gunther wrote:
>>>
 I work on some project that move prims.
 Right now i do it with small do/while loop. thats the fastest way to
 move a prim smooth.
 But have technical some problems.

 If i move the prim with timer event. and i have set it to 0.01 because
 its anyway not seems todo much below 0.5
 not sure whats the lowest working setting. And thats also the problem.
 the object moves way slower != smooth compared to
 do/while loop.
 Would be nice if there's option to speed the timer event up. But need
 to agree i dont know the effects.

 A timer thats doing lets say 0.01 sounds better then a do/while loopt
 thats running 20 meters with steps of 0.5 meters.
 would be nice if the timers where a bit faster. But maby i make a
 thinking error to.  Still dont see why i cant get the
>>>

Re: [Opensim-dev] llDetectedType and NPC's

[Dahlia Trimble]

So what happens when LL defines "NPC" and it means something different that
what is defined in OpenSimulator?

And yes, I believe the probability is quite high that they will eventually
define it.


On Wed, Jul 11, 2012 at 5:01 PM, Justin Clark-Casey <
jjusti...@googlemail.com> wrote:

> That's a neat solution, Argus.  Since the intention of
> OS_NPC_SENSE_AS_AGENT was to provide compatibility rather than 'fool', I
> think returning both NPC and AGENT flags would be perfectly acceptable.
>  Let's see if there are any other comments, otherwise I think we can
> proceed along those lines.  I'm still not that happy with extending
> llDetectedType() but leakage has already occurred and I suspect its
> inevitable.
>
> On another note, I'm not sure what 'plausibility' checks you're referring
> to.
>
>
> On 11/07/12 13:04, Argus wrote:
>
>> I am fully aware of the open source factor and that in each open grid
>> everything can be changed, which is why one always
>> needs backend function to make sure no fals information is passed on to
>> the central service. One can however filter 99%
>> of the fals data in the local sim which helps the central service because
>> it does not need to process every single
>> plausability checks. In a multi grid environment with closed grids we
>> even have a lower chance of false data beeing
>> passed than in a open grid only environment.
>>
>>   We have the same situations in opensim were the simulator often does
>> some local plausability checks before it send
>> data to the gridservers. The gridservers again do a plausability check
>> combined with other methods which are not
>> available on the local sim. Only if all steps are plausable the data gets
>> processed further.
>>
>> Anyway, I added a new patch for llDetectedType were NPCs always return
>> NPC and useing OS_NPC_SENSE_AS_AGENT will returns
>> AGENT + NPC. I think that is an acceptable compromize... I also added an
>> example script were the true NPC detection
>> always makes sense  ;)
>>
>>
>> Am 11.07.2012 02:01, schrieb Justin Clark-Casey:
>>
>>> Argus, if your system relies on always reliably identifying unique
>>> avatars then that is simply not possible in any
>>> OpenSimulator environment where simulators are controlled by third
>>> parties or where hypergrid travel is allowed.
>>>
>>> Even if OS_NPC_SENSE_AS_AGENT did not exist, then people would be able
>>> to compile a version of the code that did have
>>> that functionality. This is not about ideology - it's about what is
>>> physically possible!
>>>
>>> Equally, it is perfectly possible to create duplicate HG details -
>>> anything can be put in the agent data that comes
>>> from a foreign grid (jus...@hg.osgrid.org or whatever).  You cannot
>>> rely on these to be unique either.
>>>
>>> Without any central authority (like DNS, the secure certificate
>>> infrastructure of something like Bitcoin block chains)
>>> it is simply not possible to uniquely identify avatars.
>>>
>>> I don't see this as much different from the web where one has to get
>>> people to create unique accounts with passwords
>>> in order to identify them later.  Such a thing has to be done in some
>>> authority system outside of OpenSimulator itself.
>>>
>>> If your point is that without OS_NPC_SENSE_AS_AGENT then the vast
>>> majority of systems would always present NPCs as
>>> NPCs (rather than agents) then I would agree.  In fact, in practice most
>>> people won't use OS_NPC_SENSE_AS_AGENT anyway
>>> as it's the option rather than the default.  But you cannot rely on
>>> uniquely identifying avatars on any environment
>>> outside those that you directly control.
>>>
>>> On a minor note, script functions that don't make any sense for NPCs
>>> should behave as if the UUID they received did
>>> not relate to a valid entity for that function.
>>>
>>>
>>
>> __**_
>> Opensim-dev mailing list
>> Opensim-dev@lists.berlios.de
>> https://lists.berlios.de/**mailman/listinfo/opensim-dev
>>
>>
>
> --
> Justin Clark-Casey (justincc)
> http://justincc.org/blog
> http://twitter.com/justincc
>
>
> __**_
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/**mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] llDetectedType and NPC's

[Dahlia Trimble]

In general it's not a good idea to extend any "ll" function beyond the
equivalent SL definition as there is no guarantee that LL may add any new
functionality that may conflict in the future. If this were to happen it
would be difficult to resolve the conflicts as there would be scripts in
use that depend on the conflicting definitions. Also some scripters don't
always use symbolic constants (a terrible practice but it does happen) so
it's not just a matter of changing a conflicting value for  a constant and
recompiling. If your solution is dependent on deviating from  the SL
definition for any "ll" API call, it may be easier for all involved in the
future if you can redesign it such as to avoid future incompatibilities.

On Sun, Jul 8, 2012 at 3:14 AM, Argus  wrote:

> Hi.
>
>  I have a problem with the way that NPCs might be implemented in
> llDetectedType. A patch can be found in Mantis 6066.
>
>  In the events touch, collision and sensor one can use the function
> llDetectedType which return some basic infos on what type of
> object/agent... has been detected by the event. To complete this function,
> we still need to add NPCs as type. Sofar, so good...
>
>  NPC do however also have the possebility to be created using
> OS_NPC_SENCE_AS_AGENT. This was implemented sothat NPCs would work with
> sensor events ( without changing the lsl script). At that time NPCs were
> not implemented to llDetectedType which one could have easely used to
> change the lsl script to work with NPCs and/OR agents instead of
> implementing OS_NPC_SENCE_AS_AGENT. The result is, that using
> OS_NPC_SENCE_AS_AGENT would return an agent when using llDetected AND that
> there is NO way to know if the event was triggered by an agent or NPC
> without forcing the users to enable osIsNPC for everybody,  and I do realy
> mean everybody. For me and some other projects I know of, this will have
> fatal sideeffects.
>
>
>
>   Let look at our 3 avatar type, normal agent, liblibomv bot and NPC's and
> how these can be used for identification.
>
> Situation 1) A closed grid with hypergrid disabled.
>
> - Normal agent = registered at grid, unique uuid + name within grid,
> controled by human
> - Bots = basicaly same as agent, registered at grid,  with unique uuid +
> name within grid, but remotly controled by software
> - NPC = NOT registered, unique uuid within grid, ANY fictional OR existing
> name possible and like bots remotly controled.
>
> If llDetectedType return agent for NPCs using OS_NPC_SENSE_AGENT we only
> could detect the NPC using llRequestAgentData to see if we get a posetive
> respone via DATA_NAME (unless the region itself detects the online NPC as
> agent and returns the NPC data, havnt tested that yet.) In any case, the
> uuid remains unique and can always be used to identify a single
> agent/npc/bot
>
> Situation 2) Multigrid system with hypergrid enabled.
>
> - Normal agent = registered at grid, unique uuid + name within grid,
> controled by human, surname changes with hypergrid, name supplies griddata
> on hypergrid travels
> - Bots = basicaly same as agent, registered at grid,  with unique uuid +
> name within grid, but remotly controled by software, surname changes with
> hypergrid, name supplies griddata on hypergrid travels
> - NPC = NOT registered, unique uuid within grid, ANY fictional OR existing
> name possible and like bots remotly controled.
>
>  The uuid - name relation is still unique WITHIN a grid, but the same
> uuid-name relationship can be used in multiple grids by DIFFRENT users.
> However when hypergrid traveling the name changes and one can extract the
> agents origin grid sothat one recieves a unique uuid+name+grid
> relationship. In a multigrid system were llDetectedType return agent for
> NPCs using OS_NPC_SENSE_AGENT there is NO method using plain lsl to get the
> unique uuid+name+grid relationship,  llRequestAgentData is not available in
> all grids from the hypergrid visitor. The names of NPCs are NOT unique
> within a grid AND the uuid could already exist in another grid for an
> agent. The uuid alone CAN'T be used to identify a single agent/bot/npc in a
> multi grid system which is hypergrid enabled.
>
>  Short summary: In a mutligrid system with hypergrid each agent/bot has a
> unique uuid - name - grid relationship were 2 elements are needed for
> identification, in a single grid without hypergrid the uuid is enough to
> identify each agent/bot/npc. In a multigrid system NPC have to be
> identified as NPC sothat one can identify the NPC using uuid + grid.
>
>
>
> As mentioned there is no plain lsl method for identification in a multiple
> grid system with hypergrid if llDetectedType returns an Agent for NPCs
> using OS_NPC_SENSE_AGENT. In Opensim we do have OSSL function which could
> be used to help to distinguish between a registered agent and a NPC, eg.
> osIsNPC. The problem is however, that a multigrid system would have to have
> multiple scripts available for all sorts of ossl combinati

Re: [Opensim-dev] Opensim and hemispheric screen

[Dahlia Trimble]

If I understand you correctly, one way to accomplish this may be as
follows: render the scene off-screen and store it in a texture buffer, then
render that texture on the surface of a spherical object and display it.
I'm not familiar with LL viewer code but I would think most programs that
use OpenGL could be modified to do something like this.



On Sat, Jun 16, 2012 at 6:39 AM, Tom Willans wrote:

> I am carrying out a research project into emotion within virtual worlds
> and am potentially using opensim as the platform. I will however be using a
> hemispheric screen within my quasi-experiment which requires projection
> through a fisheye lens (or similar). This requires that the image from the
> display is suitably distorted. Before I start on further work does any one
> know of a viewer adapted to do this.  I appreciate that you folks will be
> more focused upon opensim rather than viewer technology.  I am assuming an
> additional shader will need to be added at the end of the pipeline.
> The alternative technology uses the unity platform but I will require 2-3
> avatars meeting together and am more familar with OpenSim/SL.
>
> Apologies if this is a repost.
>
> Thanks
> Tom
>
>
> Tom Willans  BSc(Hons)  MBCS  CITP
> PhD Student
> Serious Games Institute, Coventry University
> United Kingdom
>
> Managing Director Bessacarr Publications Ltd
> Senior Research Representative:Engineering and Computing
> +44 (0)121 288 0281
> email: tom.will...@bessacarr.com
> skype: tom.willans
> Second Life and OSGrid: Tom Tiros
>
>
>
> Sent from my iPad
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Questions about Vehicle scripting calls

[Dahlia Trimble]

Timers in opensimulator are usually limited to 0.5 seconds minimum
duration. There is a ini setting to change it at the simulator level,
 however, I've found that using the not_at_target() event gives better
results as it will fire once per simulation frame which is probably what
you would want anyway.

Using llSetPos() and friends is probably not a good idea as it generates a
*lot* of network traffic and overhead in the client stack code in the
simulator. I've heard several LL engineers lament the use of these
functions for motion but "the cat is out of the bag now" and there's not
much they can do about it except promote the use of llSetKeyFramedMotion().

I've had difficulties with the opensimulator implementation of
llMoveToTarget() and I've written my own velocity feedback loop in LSL
(which is kind of an abstract PID controller) and I use it on both SL and
opensimulator. I usually only have to change one constant to get it to
behave the same on either platform. I use not_at_target() and
llApplyImpulse() to correct velocity at each simulation frame. I don't use
any timers at all. It works in all 3 global axes so object rotation doesn't
affect velocity, and motion is fairly constant and smooth. I have made
attempts to understand the existing PID code in opensimulator but it's
unfortunately not very well documented and has a lot of commented out code
and much of the code uses variable names that are not very descriptive, so
I haven't been able to successfully modify it to work as well as my LSL
solution. I'm also somewhat hesitant to commit any changes to that code as
I don't really have much experience with scripting LSL physics and I don't
have confidence that I would make changes that would break other's scripts.
I'm also not sure if any of the PID controller code affects vehicle
functions or not, or if it just applies to llMoveToTarget() and agent
motion.



On Thu, Jun 7, 2012 at 12:09 AM, Mike Higgins  wrote:

>  On 6/6/12 12:48 AM, Bengt Falke wrote:
>
> I am also interested in physics for vehicles mainly for creating working
> yacht and for making my free moving scripted animals to work in a smooth
> way.
> If there is a way I can contribute I will try to do so.
>
>  Also at the recent OpenSim developers meeting, Andrew Hellershanks
> said (about llSetTImerEvent minimum time limits) "Not sure why you would
> want to use something other [less] than 1.0". I think the developers need
> to know that there are 1000's of scripters in SL DESPERATELY trying to find
> ANY WAY to make simple things like a fish move smoothly through the water
> at a constant velocity. In SL you can usually get timer() events as often
> as once every 0.2 seconds, which is not quite often enough for smooth
> looking motion. timer events more often would be one way to get smoother
> looking motion. I've seen people write scripts that had abominations like:
> while (1) { moveit(); llSleep(0.05); }  The OpenSim developers need to
> throw these guys a bone so they will NOT DO THAT HERE!
>
> Of course, LL only recently threw them the llSetKeyframedMotion()
> bone. Before that, people tried to use physics and llMoveToTarget() which
> was NEVER DESIGNED TO GENERATE LINEAR MOTION (it is always damped).
> Although you can play games with it and find reasonably linear portions of
> the curve. But that requires accurate llSetTimerEvent durations to stop the
> llMoveToTarget part way through a damped move. And in OpenSim,
> llMoveToTarget is damped 9 times faster than SL (mantis issue 5968) which
> requires pushing it nine times harder to try to capture a linear section
> and even more accurate llSetTimerEvent times to prevent the object from
> running away from you...
>
>  The only other way in SL (before llSetKeframedMotion) to get
> something to move smoothly at a constant velocity is to make it a vehicle.
> Which is sort of like using a 4 ton hydrolic press to insert thumbtacks in
> a cork board.  And even in SL, the vehicle functions are really squirrely.
>
> So the major reason I am testing the OpenSim vehicle routines is to
> see if I can find a reliable subset of them, or a set of workarounds, that
> will allow me to move a fish smoothly through the water at a constant
> velocity.
>
> So far I have found a few problems and some workarounds:
> 1) Vehicles crash and burn at the sim boundary, the workaround is to add
> code to detect the sim boundary before the vehicle gets there and prevent
> it from even getting close. But if llSetTimerEvent is not accurate, if your
> timer() event is not called regularly to do this check, the vehicle runs
> into the sim boundary and goes crazy.
> 2)  The angular motor rotates around the wrong axes, but you can
> workaround that by multiplying your vectors by llGetRot (mantis issue
> 6039). I'm guessing that nobody noticed this before because cars and boats
> and helicopters are usually horizontal and their local Z axis is aligned
> with the region Z axis.
> 3) The linear moto

Re: [Opensim-dev] Issues with the Simulator under high load

[Dahlia Trimble]

I was able to re-create the "slow get" error. In my case I had a region
with many unique textures. As my viewer was downloading them I was
apparently running short of memory and the computer started swapping and
thrashing the disk and the viewer would momentarily freeze. During the
freezes the OpenSimulator console would show several of the "slow get"
messages. Apparently the viewer was not able to receive and process the
requested textures as fast as the simulator wanted to send them and this is
when the messages appeared. I reduced the draw distance and graphics
quality level in the viewer and the messages stopped. Given this experience
I suspect some of the users at your parties may be having similar viewer
issues and the problem may be mitigated by suggesting they lower their draw
distance and graphics quality settings.

I believe most viewers send information back to the simulator about memory
use and graphics performance but I'm not aware if OpenSimulator is
collecting and making these data available for analysis.


On Sun, Apr 22, 2012 at 3:43 PM, Akira Sonoda wrote:

> Hi Justin,
>
> I am still investigating the Slow GetTexture problem and the resulting
> instability under high Load.
>
> What i did so far:
>
>
>1. I'm still using opensim-0007711 ( i didn't have the time to
>upgrade, the first upgrade was not so good due an error on my side and
>since then i did not look too much into it)
>2. I've created a Windows Instance in the Amazon cloud in order to be
>able to connect some profiling tools.
>3. I've run the last two Friday Parties from there the first Party was
>quite okay ( MaxPoolThreads=90 in the SmartPoolThreads settings, but i saw
>more on peaks, strange )
>4. The second party from the 20. April went crazy after 3 hours here's
>a picture:
>
> http://farm9.staticflickr.com/8017/6957771466_4412ee83c4_b_d.jpg
>
> Most of the threads had a stack trace like this:
>
> http://farm9.staticflickr.com/8155/6957875232_0203631ed0_b_d.jpg
>
> Wondering why this increase started after approx 3 hours. We had at max
> about 18 avies on the region/sim with various different viewers. Because I
> did not attach this amazon Cloud instance to my splunk server i have no
> statistics about the viewers during the party ... i probably should do that
> in future.
>
> I will upgrade to a more recent version next week ...
>
> Thanks a lot!
>
> Akira
>
>
> Am 19. März 2012 01:57 schrieb Justin Clark-Casey <
> jjusti...@googlemail.com>:
>
> It's quite possible the 3rd party HTTP server doesn't use the threadpool
>> though I've never looked in detail.
>>
>> You could supply any other http address in the GetTexture cap (e.g. the
>> asset service directly with a suitable handler).  However, I'm not sure
>> that asset serving is such a bottleneck at the moment compared with
>> scripting and physics issues.
>>
>>
>> On 17/03/12 21:10, Dahlia Trimble wrote:
>>
>>> I've done a bit of tracing through the code and I can't seem to find
>>> where the http server in OpenSimulator uses
>>> threadpool threads. I did find them used in the LLUDP server and in
>>> asyncronous requests from the asset service, but I
>>> have yet to find any other uses. is it possible that the http server is
>>> still using system threads, bypassing the
>>> threadpool? I'm rather curious as I use the built-in http server in a
>>> few personal applications and I'm concerned about
>>> performance.
>>>
>>> On another note, I believe part of the impetus behind LL designing the
>>> texture fetch capability was to allow a separate
>>> service from the simulator to supply assets to viewers, thereby reducing
>>> load on the individual simulator processes.
>>> Perhaps this is something OpenSimulator can take advantage of? Probably
>>> some kind of asset proxy cache could do a much
>>> better job of serving textures and other assets to viewers than the
>>> existing monolithic process? I believe it could even
>>> be moved to a separate server with a different IP address.
>>>
>>>
>>> On Fri, Mar 16, 2012 at 8:36 PM, Justin Clark-Casey <
>>> jjusti...@googlemail.com 
>>> <mailto:jjustincc@googlemail.**com>>
>>> wrote:
>>>
>>>Hi Akira.  I have now updated the "show threads" method to show
>>> threadpool statistics for the main threadpool.
>>>  Please note that each XEngine script engine will also have it's own
>>> threadpool (which can be seen using th

Re: [Opensim-dev] joystick 3D cursor not returning to rest

[Dahlia Trimble]

OpenSimulator is only a consumer of camera rotation and doesn't really
affect it at all from the client's perspective. The viewer sends the camera
rotation with every "AgentUpdate" message in the form of 3 direction
vectors (up, left, and forward) which are relative to world space, so the
rotation is more or less absolute and not dependent on prior rotations.
Given such, your application is most likely entirely client-side and you
may find more information in a viewer forum.

Good luck! Sounds interesting :)


On Mon, Mar 26, 2012 at 7:37 AM, CJ Davies  wrote:

> (Apologies if you have read this already on Opensim-users but it didn't
> get any repsonses there so I thought I would try here as well.)
>
> I have an accelerometer connected to an Arduino that has been reflashed to
> imitate a standard USB HID joystick which I can use with a Second
> Life/OpenSim viewer using the standard joystick support - it's kinda fun
> actually!
>
> I want to use it to control the angle/gaze of the camera according to the
> angle of the accelerometer - eg if I tilt upwards the camera tilts upwards
> the same amount, but when I stop tilting the camera stops moving - the
> project involves running the client on a tablet which the user can point
> around like a digital camera to 'look' in a particular direction. This
> behaviour is captured by the '3D cursor' option but that only seems to work
> when in flycam mode. I can live with that, but I'm running into a problem.
>
> Whenever the accelerometer is flat, it sends '0' from the Y axis
> (arbitrary number for explanation) which should always equate to the camera
> looking straight forward, parallel to the ground. So if I tilt the
> accelerometer up, then tilt it back to flat, the camera should look up by
> that amount & then come back to straight forward/parallel to the ground.
>
> However if I tilt up & back to flat, or down & back to flat, a few times,
> the camera begins to drift from the straight forward/parallel position. The
> further & more that I tilt up/down, the worse this gets, until with the
> accelerometer level & sending '0' along the Y axis, the camera is pointing
> straight down at the floor, or even behind the avatar! The only solution I
> have come across so far is to do Reset View & then re-enable Joystick
> Flycam, which is far from convenient.
>
> Does anybody know what may be causing this? I have set the relevant
> deadzones to 0, tried changing feathering & smoothing, changing the
> relevant scale, etc. but all to no avail. It's as if the flycam actually
> changes what it considers to be 'level' or '0' as it 'moves'?
>
> Regards,
> CJ Davies
> __**_
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/**mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Adding custom LSL functions

[Dahlia Trimble]

Nice!

Any thoughts on best practices for including LSL type mapping in C# sources?


On Thu, Mar 15, 2012 at 1:59 PM, Mic Bowman  wrote:

> I've check the modInvoke code into master. It lets you register functions
> in a region module with the script engine so that scripts in your region
> can access the region module directly.
>
> An example region module and script is described here:
> http://opensimulator.org/wiki/OSSL_Script_Library/ModInvoke
>
> Note that this is still experimental & I wouldn't be surprised if the
> interface continues to evolve. And there are some limitations for
> parameters that I will be removing over the next few days (for example,
> lists, vectors and rotations do not currently work unless they are
> converted into strings).
>
> --mic
>
>
> On Tue, Mar 13, 2012 at 2:21 PM, Mic Bowman  wrote:
>
>> odd. it was there last night.
>> anyway... i uploaded it again.
>>
>> --mic
>>
>>
>> On Tue, Mar 13, 2012 at 2:12 PM, Per Mint  wrote:
>>
>>> Mic,
>>>
>>> wow, thanks ! I didn't find in the mantis any link to the patch. Is
>>> there anyway I can help testing this out ?
>>>
>>> Best,
>>> PMint.
>>>
>>> ___
>>> Opensim-dev mailing list
>>> Opensim-dev@lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>
>>>
>>
>
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Issues with the Simulator under high load

[Dahlia Trimble]

I've done a bit of tracing through the code and I can't seem to find where
the http server in OpenSimulator uses threadpool threads. I did find them
used in the LLUDP server and in asyncronous requests from the asset
service, but I have yet to find any other uses. is it possible that the
http server is still using system threads, bypassing the threadpool? I'm
rather curious as I use the built-in http server in a few personal
applications and I'm concerned about performance.

On another note, I believe part of the impetus behind LL designing the
texture fetch capability was to allow a separate service from the simulator
to supply assets to viewers, thereby reducing load on the individual
simulator processes. Perhaps this is something OpenSimulator can take
advantage of? Probably some kind of asset proxy cache could do a much
better job of serving textures and other assets to viewers than the
existing monolithic process? I believe it could even be moved to a separate
server with a different IP address.


On Fri, Mar 16, 2012 at 8:36 PM, Justin Clark-Casey <
jjusti...@googlemail.com> wrote:

> Hi Akira.  I have now updated the "show threads" method to show threadpool
> statistics for the main threadpool.  Please note that each XEngine script
> engine will also have it's own threadpool (which can be seen using the
> "xengine status" command).  Might need to improve this further.
>
> "show threads" will also show all in-use threads.  However, at least on
> mono 2.6.7 this isn't reported by the VM so won't be shown.
>
> I'm not sure whether this will help you or not in tracking down
> performance issues.  In some situations it could help (e.g. if threads are
> encountering deadlock the number of 'in use' threads will leap up, though
> you've probably already noticed deadlock by the long-running threads
> reporting monitoring failures and the sim locking up).
>
> So I'd be happy to hear suggestions for additional data and I'll implement
> them if I can, since I think this is going to be a growing area of concern.
>  Unfortunately pinning down performance issues with a system as complex as
> OpenSimulator (with massive numbers of threads and user generated scripts)
> is likely to remain a significant challenge for the forseeable future.
>
>
> On 11/03/12 19:15, Akira Sonoda wrote:
>
>> Am 10. März 2012 03:25 schrieb Justin Clark-Casey <
>> jjusti...@googlemail.com 
>> > >>:
>>
>>
>>I'm sorry to say that you'll have to take the ThreadPool numbers with
>> a very very very large pinch of salt.  I
>>believe they only refer to the built-in mono thread pool and not the
>> SmartThreadPool which is the one actually used
>>(and beyond that the core simulator and xengine use separate pools).
>>  I will try and improve this situation soon.
>>
>>
>> Thank you Justin!
>>
>> Would be nice to have some meaningful statistics for all those
>> ThreadPools! Maybe there is a possibility to write those
>> statistics to the log from time to time ( e.g. every 30 seconds).
>> Together with some documented "best practices" from
>> those who operate Sims, with lots of avatars on it - I'm thinking mainly
>> the OSgrid Plazas are good references - this
>> could be highly valuable information for those who operate Sims for
>> similar purposes ( meeting points, parties, concerts
>> etc. )
>>
>>
>>
>>
>>
>>
>> __**_
>> Opensim-dev mailing list
>> Opensim-dev@lists.berlios.de
>> https://lists.berlios.de/**mailman/listinfo/opensim-dev
>>
>
>
> --
> Justin Clark-Casey (justincc)
> http://justincc.org/blog
> http://twitter.com/justincc
> __**_
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/**mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Issues with the Simulator under high load

[Dahlia Trimble]

wouldn't the thread pool in OpenSim be using mono threads?

Also perhaps I wasn't clear, the application I found the benefit in from
increasing mono threads was *not* Opensim, but rather it was a different
application that uses the same http server as OpenSim uses.

On Fri, Mar 9, 2012 at 6:25 PM, Justin Clark-Casey  wrote:

> I'm sorry to say that you'll have to take the ThreadPool numbers with a
> very very very large pinch of salt.  I believe they only refer to the
> built-in mono thread pool and not the SmartThreadPool which is the one
> actually used (and beyond that the core simulator and xengine use separate
> pools).  I will try and improve this situation soon.
>
>
> On 09/03/12 11:46, Akira Sonoda wrote:
>
>> 600 on a 8 core machine ( i guess the hyperthreaded cores are visible to
>> mono as real cores, at least in nmon they are
>> reported as such ) is quite a lot of threads. This morning I went big and
>> configured 1000, but I'm not really sure which
>> approach to go...
>>
>> seeing the stats:
>>
>> Region (Close Encounter) # show threads
>> 9 threads are being tracked:
>> ID  NAME   LAST UPDATE (MS)
>> LIFETIME (MS) PRIORITY
>> STATE
>>  8  PollServiceWorkerThread0137
>>  27996479   Lowest
>> WaitSleepJoin
>>  9  PollServiceWorkerThread1   27996478
>>  27996478   Lowest
>> WaitSleepJoin
>> 10  PollServiceWorkerThread2   27996478
>>  27996478   Lowest
>> WaitSleepJoin
>> 11  PollServiceWatcherThread137
>>  27996478   Lowest
>> WaitSleepJoin
>> 15   MapItemRequestThread (Close Encounter)383
>>  27992497   LowestBackground,
>> WaitSleepJoin
>> 18Incoming Packets (Close Encounter) 19
>>  27979915   Lowest
>> WaitSleepJoin
>> 19Outgoing Packets (Close Encounter)  0
>>  27979915   Lowest
>> WaitSleepJoin
>> 20   Heartbeat (Close Encounter) 55
>>  27979914   Lowest
>> WaitSleepJoin
>> 34  AsyncLSLCmdHandlerThread 33
>>  27964827   LowestBackground,
>> WaitSleepJoin
>>
>> *** ThreadPool threads ***
>> workers: 0 (500); ports: 0 (1000)
>>
>> the ThreadPool shows worker/port threads 1500 so on a 8 CPU Machine 200
>> MONO_THREADS_PER_CPU should be sufficient if i
>> interpret those numbers correctly guessing the numbers in brackets are
>> the max of the Pools. Therefore 1000 is possibly
>> too much, Will be interesting to  see if i still run into problems with
>> 300 Threads per CPU.
>>
>>
>>
>>
>> Am 9. März 2012 08:14 schrieb Dahlia Trimble > dahliatrimble@gmail.**com >>:
>>
>>
>>Sorry I don't really know much about it. In my case it was an
>> application that used the http server dll from OpenSim
>>and served probably 40-60 simultaneous requests. Mono was defaulting
>> to 25 threads per cpu but I changed it to 75
>>and I stopped having download problems. This was on a 4-core machine.
>>
>>I would guess if you are using 150 and seeing problems that a good
>> place to start might be somewhere around 450-600
>>and see what happens.
>>
>>On Thu, Mar 8, 2012 at 9:44 PM, Akira Sonoda 
>> > akira.sonoda.1@gmail.**com >> wrote:
>>
>>Ooopps... my MONO_THREADS_PER_CPU=150 are obviously not enough.
>> 2000 as stated in the article is quite a lot ...
>>what are your settings? do you go with the 2000?
>>
>>
>>Am 9. März 2012 00:07 schrieb Dahlia Trimble <
>> dahliatrim...@gmail.com 
>> <mailto:dahliatrimble@gmail.**com
>> >>:
>>
>>
>>Are you using Mono? I've seen poor performance of the http
>> server used in OpenSimulator when insufficient
>>threads are available. Manipulating the environment variable
>> MONO_THREADS_PER_CPU has worked for me when
>>I've encountered this problem before. Take a look at
>>
>> http://www.mono-project.com/**Article:ThreadPool_Deadlocks<http://www.mono-project.com/Article:ThreadPool_Deadlocks>for
>>  some background on this problem.
>>
>>As far as network performance tools go I'd probably just
>> search the web for "network performance tool" and
>>pick w

Re: [Opensim-dev] Issues with the Simulator under high load

[Dahlia Trimble]

Sorry I don't really know much about it. In my case it was an application
that used the http server dll from OpenSim and served probably 40-60
simultaneous requests. Mono was defaulting to 25 threads per cpu but I
changed it to 75 and I stopped having download problems. This was on a
4-core machine.

I would guess if you are using 150 and seeing problems that a good place to
start might be somewhere around 450-600 and see what happens.

On Thu, Mar 8, 2012 at 9:44 PM, Akira Sonoda wrote:

> Ooopps... my MONO_THREADS_PER_CPU=150 are obviously not enough. 2000 as
> stated in the article is quite a lot ... what are your settings? do you go
> with the 2000?
>
>
> Am 9. März 2012 00:07 schrieb Dahlia Trimble :
>
> Are you using Mono? I've seen poor performance of the http server used in
>> OpenSimulator when insufficient threads are available. Manipulating the
>> environment variable MONO_THREADS_PER_CPU has worked for me when I've
>> encountered this problem before. Take a look at
>> http://www.mono-project.com/Article:ThreadPool_Deadlocks for some
>> background on this problem.
>>
>> As far as network performance tools go I'd probably just search the web
>> for "network performance tool" and pick whatever works for you.
>>
>> On Thu, Mar 8, 2012 at 2:28 PM, Akira Sonoda wrote:
>>
>>> Hi Dahlia,
>>>
>>> Am 5. März 2012 01:14 schrieb Dahlia Trimble :
>>>
>>> A couple thoughts, not sure if it's your problem or not.
>>>>
>>>> I would probably check to make sure the cache is set up properly and
>>>> the file system it's on has plenty of space. Also make sure the disk isnt
>>>> being thrashed by other processes and that the disk is healthy and not
>>>> fragmented. There's probably some system utilities that can show disk I/O
>>>> activity and disk health.
>>>>
>>>
>>> There is plenty of free space on the disk.
>>>
>>>
>>>> You may also have network congestion problems that could slow retrieval
>>>> from the asset servers or slow sending of assets to other clients.
>>>>
>>>
>>> How can i figure them out?
>>>
>>> I've made a other report from the party from Wednesday on "Pyramid@osgrid".
>>>
>>>
>>>
>>> https://docs.google.com/open?id=0B301xueh1kxdVmVZZ18tbi1TdzZ2cGlRaFhDTlo4UQ
>>>
>>> The server where "Pyramid" is located is similar to my server. The major
>>> difference is the mono version. There was a time when i had high quite high
>>> network load but is this network congestion?
>>>
>>> Status right now: we survive.
>>>
>>>
>>>
>>> ___
>>> Opensim-dev mailing list
>>> Opensim-dev@lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>
>>>
>>
>> ___
>> Opensim-dev mailing list
>> Opensim-dev@lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>>
>
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Issues with the Simulator under high load

[Dahlia Trimble]

Are you using Mono? I've seen poor performance of the http server used in
OpenSimulator when insufficient threads are available. Manipulating the
environment variable MONO_THREADS_PER_CPU has worked for me when I've
encountered this problem before. Take a look at
http://www.mono-project.com/Article:ThreadPool_Deadlocks for some
background on this problem.

As far as network performance tools go I'd probably just search the web for
"network performance tool" and pick whatever works for you.

On Thu, Mar 8, 2012 at 2:28 PM, Akira Sonoda wrote:

> Hi Dahlia,
>
> Am 5. März 2012 01:14 schrieb Dahlia Trimble :
>
> A couple thoughts, not sure if it's your problem or not.
>>
>> I would probably check to make sure the cache is set up properly and the
>> file system it's on has plenty of space. Also make sure the disk isnt being
>> thrashed by other processes and that the disk is healthy and not
>> fragmented. There's probably some system utilities that can show disk I/O
>> activity and disk health.
>>
>
> There is plenty of free space on the disk.
>
>
>> You may also have network congestion problems that could slow retrieval
>> from the asset servers or slow sending of assets to other clients.
>>
>
> How can i figure them out?
>
> I've made a other report from the party from Wednesday on "Pyramid@osgrid".
>
>
> https://docs.google.com/open?id=0B301xueh1kxdVmVZZ18tbi1TdzZ2cGlRaFhDTlo4UQ
>
> The server where "Pyramid" is located is similar to my server. The major
> difference is the mono version. There was a time when i had high quite high
> network load but is this network congestion?
>
> Status right now: we survive.
>
>
>
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Problem registering region module

[Dahlia Trimble]

Try setting your project target framework to ".NET Framework 3.5", or to
whatever version you compiled OpenSim for. It's in the project properties
in visual studio under the Application section.

On Thu, Mar 8, 2012 at 4:08 AM, Olli Aro  wrote:

> It seems to be this line:
>
> [assembly: AddinDependency("OpenSim", "0.7")]
>
> If I keep it as above or remove it completely the dll is ignored.  If I
> change it to:
>
> [assembly: AddinDependency("OpenSim", "0.5")]
>
> OpenSim does pick it up at start up, but then crashes with:
>
> ** **
>
> 12:06:23 - [PLUGINS]: Plugin Loaded: MyModule
>
> 12:06:23 - [APPLICATION]:
>
> APPLICATION EXCEPTION DETECTED: System.UnhandledExceptionEventArgs
>
> ** **
>
> Exception: System.BadImageFormatException: Could not load file or assembly
> 'file
>
> :///C:\opensim\bin\MyModule.dll' or one of its dependencies. This a
>
> ssembly is built by a runtime newer than the currently loaded runtime and
> cannot
>
> be loaded.
>
> ** **
>
> Which I assume is because it has gone to some kind of OpenSim 0.5 mode and
> I have compiled with DLL with 0.7.3 libraries.
>
> ** **
>
> Any ideas what might be going wrong here?****
>
> ** **
>
> Regards,
>
> ** **
>
> Olli
>
> ** **
>
> *From:* opensim-dev-boun...@lists.berlios.de [mailto:
> opensim-dev-boun...@lists.berlios.de] *On Behalf Of *Dahlia Trimble
> *Sent:* 07 March 2012 23:59
> *To:* opensim-dev@lists.berlios.de
> *Subject:* Re: [Opensim-dev] Problem registering region module
>
> ** **
>
> Do you have a "using Mono.Addins;" statement and a reference to the
> Mono.Addins dll? That's the only difference I see between yours and a
> region module of mine that works.
>
> On Wed, Mar 7, 2012 at 7:31 AM, Olli Aro  wrote:
>
> Hi all,
>
>  
>
> I am migrating my old region modules to the latest OpenSim and have
> problems registering the module with OpenSim. I have added the following
> lines in my code:
>
>  
>
> [assembly: Addin("MyModule", "0.1")]
>
> [assembly: AddinDependency("OpenSim", "0.7")]
>
>  
>
> …
>
>  
>
> [Extension(Path = "/OpenSim/RegionModules", NodeName = "RegionModule", Id
> = "MySharedModule")]
>
> public class MyModule : ISharedRegionModule
>
>  
>
> But when I drop this to OpenSim bin directory and start up OpenSim, the
> module is not picked up. At the moment I have only the following line in
> the initialise method:
>
>  
>
> m_log.Error("[MYMODULE]: hello hello hello");
>
> Any pointers why my module might not be picked up? For example are the
> modules still put into bin/ or now to some other directory?
>
>  
>
> Regards,
>
>  
>
> Olli
>
>
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
> ** **
>
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Problem registering region module

[Dahlia Trimble]

Do you have a "using Mono.Addins;" statement and a reference to the
Mono.Addins dll? That's the only difference I see between yours and a
region module of mine that works.

On Wed, Mar 7, 2012 at 7:31 AM, Olli Aro  wrote:

> Hi all,
>
> ** **
>
> I am migrating my old region modules to the latest OpenSim and have
> problems registering the module with OpenSim. I have added the following
> lines in my code:
>
> ** **
>
> [assembly: Addin("MyModule", "0.1")]
>
> [assembly: AddinDependency("OpenSim", "0.7")]
>
> ** **
>
> …
>
> ** **
>
> [Extension(Path = "/OpenSim/RegionModules", NodeName = "RegionModule", Id
> = "MySharedModule")]
>
> public class MyModule : ISharedRegionModule
>
> ** **
>
> But when I drop this to OpenSim bin directory and start up OpenSim, the
> module is not picked up. At the moment I have only the following line in
> the initialise method:
>
> ** **
>
> m_log.Error("[MYMODULE]: hello hello hello");
>
> 
>
> Any pointers why my module might not be picked up? For example are the
> modules still put into bin/ or now to some other directory?
>
> ** **
>
> Regards,
>
> ** **
>
> Olli
>
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Issues with the Simulator under high load

[Dahlia Trimble]

A couple thoughts, not sure if it's your problem or not.

I would probably check to make sure the cache is set up properly and the
file system it's on has plenty of space. Also make sure the disk isnt being
thrashed by other processes and that the disk is healthy and not
fragmented. There's probably some system utilities that can show disk I/O
activity and disk health.

You may also have network congestion problems that could slow retrieval
from the asset servers or slow sending of assets to other clients.

On Sun, Mar 4, 2012 at 10:51 AM, Akira Sonoda wrote:

> Hello everybody,
>
> Dorothea Lundquist and JayMaze Yao are organizing a party in the OSgrid
> each Friday during the last three years. I am the tech staff of the which
> maintains the server and the Software. The parties always are visited by 10
> to 20 avatars. The max was at around 30 avatars simultaneously at the
> party. That was in the past. Nowadays approx since end of November 2011 it
> is virtually impiossible to host parties with more than 15 people without
> huge Lag or even crashes. Here's the report from the party from 24.
> February:
>
> https://docs.google.com/open?id=0B301xueh1kxdZ1JYcU1HRzZSdEtOeE9WSmZtM3BVZw
>
> and here's the report from the last party:
>
> https://docs.google.com/open?id=0B301xueh1kxdNGpuX1kzazFSNXVOdFEwazA1ZmlTdw
>
> The question how can we come back to parties without hassle?
>
> Thank you for your attention
>
> Akira Sonoda @ osgrid
>
>
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Question about the suitable interface

[Dahlia Trimble]

The protocol between the sim and the viewer allows for clients to initiate
and stop animation sequences. There are packets defined for it, and I
believe they are the basis for "client side animation overriders" that are
a feature of many third-party viewers. You should be able to modify a
viewer to send these packets at will and your avatar should respond as soon
as the sim is able to relay the packet, provided the sequence you specified
has been downloaded and cached by the viewer. Otherwise there will be a
short delay while the viewer requests and downloads the sequence.

Other possibilities exist also: a LSL script in an attachment worn by the
avatar can control the animations played by that avatar, and could also use
repeating long-poll http queries to your computer where the kinect box is
connected to receive animation commands and then tell the avatar to play
them. Another means may be to have a plug-in packet injector for the
GridProxy program that comes with libomv  http://openmetaverse.org/  which
could either send animation packets, or send chat commands to a script worn
by the avatar which could then start animations.

Any of these solutions should work for either SL or unmodified OpenSim
installations. None of them are probably considered "production quality"
but they could get you to the point where you have a reasonably functional
solution.

On Tue, Feb 21, 2012 at 9:54 AM, Georg Janke wrote:

>  Hello developers of OpenSim!
>
> ** **
>
> My Name is Georg and would be very happy if you could answer my question.
> 
>
> Short description of what my aim is:
>
> I am working on a application that is able to recognize gestures from a
> Kinect controller. With the help of this I want to control an avatar in
> OpenSim. So I have the recognition application and OpenSim running parallel
> on the client pc. The database on the OpenSim server contains the
> appropriate animations for the gestures.
>
> Question:
>
> Does OpenSim has a suitable interface that my application can use to tell
> OpenSim it has recognized a certain gesture and thus controlling the avatar
> to perform the appropriate animation from the database?
>
> ** **
>
> Thanks for reading,
>
> ** **
>
> Georg
>
> ** **
>
> ** **
>
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] OpenSimulator / Hyper Grids / Region Statistics

[Dahlia Trimble]

There's a list of grids at  http://opensimulator.org/wiki/Grid_List

Perhaps if it were in some kind of XML format it could serve as a source
for TPV grid selector?

I don't think this list is by any means considered a complete list and as
it's a wiki then inclusion of any grid on the list is usually voluntary and
the list may not be up to date. However if it were to be used as a source
for TPVs then perhaps that may encourage timely maintenance.


On Mon, Feb 20, 2012 at 5:49 PM, Trinity  wrote:

> what we need is a central grid manager database that the tpv's use to look
> up grids in the grid manager that every one can go to to list there grid or
> sims
>
> On Mon, Feb 20, 2012 at 2:33 PM, Nebadon Izumi wrote:
>
>> this does not seam feasible to me, for one, what if everyone sets it to
>> false, or even 1/2 of everyone sets it to false, it somewhat defeats the
>> purpose, and secondly who runs the centralized operation? and even if we
>> did decide to do this the numbers could be wildly off, it would be very
>> intensive to insure that every region was running we would be polling 10's
>> of 1000's of regions quite often to get accurate counts, I just don't think
>> its going to be possible and I would also have to -1 this idea for being in
>> core, if anything it would need to be a external module and be 100%
>> volunteer practice to those wanting to participate. But i still say the
>> counts would be no where near what would actually be running.
>>
>>
>> On Mon, Feb 20, 2012 at 12:38 PM,  wrote:
>>
>>>
>>> Hi@all ..
>>> who is/feels "responsible" for the Hypergrid implementation ?
>>>
>>> I have an idea in regards to the last "flame war" for the opensim region
>>> count
>>> currently going on on the internets.. Wouldn`t it be a good idea to have
>>> a
>>> true/false option in the openism.ini to e.g let your (Hyper)Grid add +1
>>> to a
>>> counter
>>> somewhere, so "we" could get figures for how many Grids and regions are
>>> online at the moment .. ?
>>>
>>> This could be refinded by e.g. the numbers of regions running on this
>>> grid
>>> etc, so people
>>> really interested in a broader view or need to make decision "to go
>>> opensim
>>> or not" get a better overview ?
>>>
>>> just a thought,
>>> best regards,
>>> Wordfromthe Wise
>>>
>>>
>>> ___
>>> Opensim-dev mailing list
>>> Opensim-dev@lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>
>>
>>
>>
>> --
>> Michael Emory Cerquoni - Nebadon Izumi @ http://osgrid.org
>>
>> ___
>> Opensim-dev mailing list
>> Opensim-dev@lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>>
>
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Prospective ODE physics changes

[Dahlia Trimble]

Would a Wright Plaza meeting even have multiple point collisions? Most
(all?) of the active physical objects are avatar agents and they use
capsule colliders rather than meshes. Also, most are sitting and the few
that aren't are standing on or moving across a flat surface, probably far
away from any vertex in a collision mesh.

I suspect if you are seeing different physics statistics it's probably
something else that's contributing to it.

On Tue, Jan 3, 2012 at 1:32 PM, Justin Clark-Casey  wrote:

> On 02/01/12 20:56, Melanie wrote:
>
>> Hi,
>>
>> On 02/01/2012 21:51, Justin Clark-Casey wrote:
>>
>>> I'm thinking of making two ODE related changes.
>>>
>>> 1) Replace the current ODE libraries in OpenSimulator with ones compiled
>>> using the older GIMPACT collider instead of
>>> OPCODE.  This is to address ODE crashes in simulators with more than one
>>> region as detailed in [1] and [2].  These don't
>>> appear to occur with GIMPACT.
>>>
>>
>> I'm not happy with that as a general decision. We should, if
>> anything like that is done, include both versions to give users the
>> choice. The OPCODE should remain the default in order to not
>> jeopardize existing setups and the GIMPACT libs can be copied in by
>> those experiencing the bug.
>> Many people don't run multiregion at all and would see only
>> downsides if this were done.
>>
>
> Multi-region is a non-experimental configuration that is useful to a large
> number of people.  In my view, it's not correct for out-of-the-box
> OpenSimulator to continue with such crashes in the long term.  This hurts
> adoption and ultimate long-term success/survival.
>
> However, it just so happens that on scouring the Internet, GIMPACT is
> actually the newer collider, as per [1].  I don't know why I thought it was
> the other way around - I may have misinterpreted something that somebody
> said.
>
> Indeed, apparently for our common use case (mostly static objects),
> GIMPACT should perform better, so I was also wrong about the performance
> issue.  However, as I said, in my own testing I haven't yet noticed any
> significant difference and these questions are complex ones.  But it's
> certainly my experience that using GIMPACT eliminates the ODE crashes in
> stress-testing, possibly due to something connected with [2] where global
> object caches are shared between collision spaces.  But this is still a
> wild-assed guess (we can't use TLS as OpenSim crashes immediately upon
> startup).
>
>
>
>>  2) Reducing contacts_per_collision in [ODEPhysicsSettings] from 80 to
>>> something much lower, maybe even 1.  In my own
>>> testing, reducing this number can halve scene physics time.  Normal
>>> avatar operations, such as standing on prims or
>>> walking up ramps appear to be unaffected even at 1.  However, more
>>> testing is probably needed to arrive at a compromise
>>> number.
>>>
>>
>> This would greatly affect scripts using physics. I believe the
>> optimum would be 16-20, which would ensure that the scripting
>> maximum (16) collision contacts are always available.
>>
>
> According to [2], the maximum reported scripting collision contacts is 8.
>
> Testing with 8 on Wright Plaza today in the Tuesday meeting seemed to
> greatly reduce physics scene time compared to previously without any
> apparent loss of required fidelity (50ms with 18 avatars, albeit mostly
> sitting down - unfortunately I didn't record previous week's numbers but
> they were higher.  Nebadon tested one of his vehicles).
>
> Testing will continue on the osgrid plazas.
>
> [1] 
> http://www.ode.org/old_list_**archives/2006-October/020664.**html
> [2] http://groups.google.com/**group/ode-users/browse_thread/**
> thread/f38c56584c650536#
> [3] 
> http://wiki.secondlife.com/**wiki/Collision
>
>
> --
> Justin Clark-Casey (justincc)
> http://justincc.org/blog
> http://twitter.com/justincc
> __**_
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/**mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] help with between-region crossings

[Dahlia Trimble]

not sure if it's your problem, but I believe wearing a lot of scripted
attachments can cause quite a bit of lag when crossing between regions.


On Tue, Dec 13, 2011 at 2:40 PM, Ovi Chris Rouly  wrote:

> Folks,
>
> Is there a setting in the Configs that will help with between-region
> crossings?
>
> When "walking" across regions that are contiguous my avatar momentarily
> freezes, drops into the scenery almost up to its waist, and then re-emerges
> 5-10 seconds later many, many meters farther ahead of its last controlled
> position than seems reasonable.
>
> I have set PersistBakedTextures = true and it is not feasible to extend
> prims across every region boundary in my Sim (256 contiguous regions).
>
> This is a human-controlled avatar.  My client-side NPCs experience far less
> of an upset when walking autonomously between regions.
>
> Moreover, knowing this will happen, I usually only "barely," "timidly"
> hand-cross into the adjacent region (anticipating the above) and yet
> still encounter the very same events.
>
> Thank you in advance for your advice.
>
> Chris
>
> PS Jerry and Lindy special thanks!
>
>
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Sit position changes in OpenSimulator b6df9e9 (Sat 5th Nov 2011)

[Dahlia Trimble]

In SL, sitting behavior differs between objects which have a sit target set
and those which do not. When a sit target is set, sitting will occur
immediately when an object is selected and "Sit" is chosen from the menu,
even from a large distance. For default sit positions distance appears to
have an effect, the avatar must be close to the object or the sit is
ignored or fails.

The suggested existence of an unset sit target state offers another
alternative: don't change any sit target properties in a prim, rather alter
the sitting procedure to compute a sit target on the fly if no target has
been explicitly set in the object. Setting it on the fly could offer
additional benefits, such as a future enhancement to allow multiple sitters
on a single larger object with no preset targets.



On Fri, Dec 2, 2011 at 1:55 PM, Justin Clark-Casey  wrote:

> OpenSimulator commit b6df9e9 (dev code) changed the sit target adjustment
> to better match that used in Second Life.
>
> Unfortunately, this has the effect of making all existing sit positions
> set by scripts using llSitTarget() inaccurate (e.g. avatar ends up hovering
> above a chair).
>
> From a user/scripter point of view this is a bad thing.  Not only do
> existing objects with user inventory/prim inventory now have wrong values,
> but positions loaded from OARs/IARs will now be wrong without adjustment,
> and OARs/IARs saved in dev code or future 0.7.3 will have wrong sit values
> when loaded into older OpenSim releases.
>
> However, I believe that's it's practically impossible to have old objects
> correctly use the old sit adjustment and new objects the new one.  Here are
> the alternative courses of action and my considered pros/cons of each
>
> 1.  Change sit adjustment with no other action.
> PROS: llSitTarget() is now implemented correctly.  No legacy mess in the
> code.  No extra complexity required.  No development work required.
> CONS: Without adjustment, all region, inventory objects and scripts now
> use wrong sit values.  Wrong sit values in OARs and IARs.  Wrong sit values
> when OARs/IARs/objects moved between dev/future 0.7.3 versions and older
> OpenSim versions.
>
> 2.  Provide a tool to correct sit values in scripts
> CONS: Too difficult since requires massive amount of script analysis.
>  Might be possible in a limited way to catch 80/20 cases.
>
> 3.  Use different sit adjustment depending on prim creation date (pre Sat
> 5 Nov 2011 use old value).
> PROS: Stops older sit positions from being wrong.  Doesn't require much
> code change.
> CONS: A user has to know an opaque magic date when the sit position
> changed.  Somewhat messy legacy code.  Future upgraders from 0.7.2 will get
> some prims with 'wrong' sit positions and others with 'right' depending on
> when they were created, which is in the long term possibly more confusing
> than everything needing adjustment.
>
> 4.  Revert llSitTarget() behave and create an osSitTarget() using the new
> adjustment instead.
> PROS: All existing sit targets continue to be 'correct', and old scripts
> still work correctly in new objects.
> CONS: llSitTarget() remains wrong for all time (could warn on use and
> eventually change, but users don't pay attention to such warnings).
>
> 5.  Store new sit positions in a different field on SOP and use this if
> present with new sit adjustment, otherwise use old field with old sit
> adjustment.
> PROS: Works invisibly as long as old scripts don't set new values.
> CONS: Messy legacy code.  Old scripts probably will set new values - then
> would need to act differently on script item creation date, with same
> issues as 3.
>
> 6.  Provide a config switch to use old sit adjustment or new.
> PROS: Administrator controllable.  In a future OpenSim release, admin can
> decide when they are going to flip to using the 'new' value.  This might be
> done anyway for the use case where OpenSim is being used with content in
> isolation from elsewhere.
> CONS: Encourages the creation of more objects using the old sit values,
> encouraging a continuous mix of old and new values which can't both be used
> on the same region.
>
> Doubtless there are other strategies, but on the face of it there doesn't
> seem to be an ideal solution.  It's made much more difficult by the fact
> that these values can only be scripts rather than as properties on the part
> (a decision which I find hard to swallow).
>
> On the whole, I think that it's better to accept the pain of change as
> early as possible and move to a world where all values are correct rather
> than remain with one where things are incorrect or a mish-mash in the long
> term.  As I said to Akira, the alpha nature of OpenSim is meant to be a
> signal that these things can change as bugs are fixed.
>
> However, I'm certainly happy to hear alternative opinions or
> well-researched and intelligent alternative proposals.
>
> --
> Justin Clark-Casey (justincc)
> http://justincc.org/blog
> http://twitter.com/justincc
> ___

Re: [Opensim-dev] Supporting shell environment variables

[Dahlia Trimble]

Also, I'm pretty sure that for both *nix and Windows a process inherits a
*copy* of the environment from the parent process and can only change the
copy.. so unless that program spawns processes, it cant really manipulate
an environment that any other program will be able to see. I don't believe
there's any way for a program to manipulate an environment for the parent
process unless the parent process is specifically written to provide a
means for a child process to do so.

On Wed, Nov 23, 2011 at 12:55 AM, Dahlia Trimble wrote:

> At one time I had some code in there that would look at an environment
> variable and use it to set the external hostname for the region. I think
> that code has since been removed by someone else but I remember I did use a
> standard .NET call to do it, probably
> System.Environment.GetEnvironmentVariable()
>
> -d
>
>
> On Tue, Nov 22, 2011 at 3:34 PM, BlueWall wrote:
>
>>
>> Hi All,
>>
>> About a year ago, I was working on the Fortis-OpenSim project and had
>> started digging into the configuration system a bit. One of the things I
>> wanted to to was provide the means to interact with shell environment
>> variables during the configuration. So, I studied the insides of Nini and
>> added support for the environment variables in a way that lets it deal with
>> the shell environment like already interacts with ini/xml/registry
>> configuration media. I tried contacting the Nini author to ask if they
>> would incorporate the changes into their distribution, but Nini development
>> has been dormant for some time and I never got a response.
>>
>> A few days ago, I had a conversation in IRC about environment variable
>> support and decided to look at putting it into OpenSim. And today I was
>> able to use the modified Nini to get it working. I have done some testing
>> here and it works well. I want to push this to core, but I wanted to
>> discuss the forking of Nini. How does everyone feel about that? I think
>> having the ability to manipulate shell variables is pretty good for us, and
>> seeing that the Nini development has been dormant so long it shouldn't be
>> as much of an issue. If development starts back up on it, then I'm pretty
>> sure we could get the changes into the distributed version.
>>
>> Thanks!
>> BlueWall
>>
>> PS: for reference - http://pastebin.com/f3R0sk5N
>>
>> __**_
>> Opensim-dev mailing list
>> Opensim-dev@lists.berlios.de
>> https://lists.berlios.de/**mailman/listinfo/opensim-dev<https://lists.berlios.de/mailman/listinfo/opensim-dev>
>>
>
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Supporting shell environment variables

[Dahlia Trimble]

At one time I had some code in there that would look at an environment
variable and use it to set the external hostname for the region. I think
that code has since been removed by someone else but I remember I did use a
standard .NET call to do it, probably
System.Environment.GetEnvironmentVariable()

-d

On Tue, Nov 22, 2011 at 3:34 PM, BlueWall  wrote:

>
> Hi All,
>
> About a year ago, I was working on the Fortis-OpenSim project and had
> started digging into the configuration system a bit. One of the things I
> wanted to to was provide the means to interact with shell environment
> variables during the configuration. So, I studied the insides of Nini and
> added support for the environment variables in a way that lets it deal with
> the shell environment like already interacts with ini/xml/registry
> configuration media. I tried contacting the Nini author to ask if they
> would incorporate the changes into their distribution, but Nini development
> has been dormant for some time and I never got a response.
>
> A few days ago, I had a conversation in IRC about environment variable
> support and decided to look at putting it into OpenSim. And today I was
> able to use the modified Nini to get it working. I have done some testing
> here and it works well. I want to push this to core, but I wanted to
> discuss the forking of Nini. How does everyone feel about that? I think
> having the ability to manipulate shell variables is pretty good for us, and
> seeing that the Nini development has been dormant so long it shouldn't be
> as much of an issue. If development starts back up on it, then I'm pretty
> sure we could get the changes into the distributed version.
>
> Thanks!
> BlueWall
>
> PS: for reference - http://pastebin.com/f3R0sk5N
>
> __**_
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/**mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Any way for the server to get the viewer to send some information to another process on the client PC?

[Dahlia Trimble]

I've used gridproxy (part of libomv -
http://lib.openmetaverse.org/wiki/Main_Page ) to interface to other
processes without modifying the LL viewer by writing a *gridproxy
plugin*which is basically a small c# program in the form of a dll
file. I believe
there are some examples that come with libomv. Gridproxy monitors traffic
between the server and the  viewer and allows messages to be modified and
injected into the traffic stream. It's probably not the most user-friendly
way to accomplish what you want but it could be packaged into a fairly
simple to use program.

Another method I've seen is to set up a process that monitors the chat/IM
log files that the viewer can create. I've seen this method used fairly
successfully for adding accessability features such as chat text-to-speech
for visually impaired users.

Good luck with whatever path you choose :)

On Fri, Nov 11, 2011 at 12:43 AM, Edmund Edgar  wrote:

> Not sure if this is the right place to ask, but wondering if anyone
> can help me with a problem I'm trying to solve while tinkering around
> with OpenSim/BitCoin integration. (I'm doing this mainly for my own
> entertainment - when we discussed it on opensim-users the other day
> the community didn't seem that into it).
>
> My ultimate aim is that rather than money being stored in a database
> on a central server, everyone would be in control of their own money,
> which would be stored locally on their PC. There would be a money
> module on the server which would deal with managing BitCoin addresses
> for avatars and confirming transactions, but rather than making
> transactions itself like the existing DTL server, it would just tell
> the client on the PC how much to pay and to what address, then confirm
> that the transaction had been made and deliver inventory etc.
>
> Rather than hacking BitCoin integration into the viewer, I'm thinking
> it might be good to run a separate piece of client software - a custom
> BitCoin client responsible for managing the user's money - alongside
> the viewer. When the money module on the server thinks the client
> should spend some money on something (eg because the user made a "buy"
> request with their viewer), I want it to send a message to the viewer,
> and have that message somehow get to the BitCoin client program.
>
> I think I know how to do this if I don't mind putting a human in the
> middle of the process: The money module tell the viewer to show the
> user a message saying, "Please pay 0.1 BitCoins to address xyz", and
> the user would open the BitCoin client and pay the money, then the
> server would check the payment and complete the transaction. But it
> would be better if I could somehow get the viewer to pass the
> information on to the client behind the scenes, without bothering the
> user.
>
> So without altering existing viewers, can anyone suggest a way to get
> a message from the server, via the viewer, to another process? The
> other process could be listening on a local port, watching a file or
> doing whatever it needs to do. I'm open to nasty hacks, but not
> really, really nasty hacks.
>
> PS. I'm new to OpenSim module development and I've never tried to hack
> the viewer, so be gentle with me if there's some kind of fundamental
> misunderstanding behind my question...
>
> --
> Edmund Edgar
> Founder, KK Social Minds
> Educational Technology for the Web and Virtual Worlds
>
> e...@socialminds.jp
> +81 090 3912 3380
> Skype: edmundedgar
> Second Life: Edmund Earp
> Linked In: edmundedgar
> Twitter: @edmundedgar
> http://www.socialminds.jp
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] The case for greater than 1024x1024 pixel textures.

[Dahlia Trimble]

I dont believe OpenSimulator restricts texture sizes; these restrictions
are in the uploader in the viewer. There are good reasons for the limits:
oversize textures decrease OpenGL performance dramatically and too many
large textures will quickly drop frame rates to the point where the
application is unusable. Too many unique textures will have similar
effects. If you really need large areas to have higher definition, try
segmenting your large textures and make the area of several prims. This may
actually be a better solution as the viewer will only have to display high
resolution for the prims near the camera and can use a lower resolution
(mipmap) for prims further away.

As far as the avatar goes, the baking process produces textures that are
512x512 for most avatar parts with I believe one exception, the eyes are
256x256. Higher resolution textures for skins and non-prim clothing will be
reduced.


On Sun, Nov 6, 2011 at 8:53 PM, Amy Smith  wrote:

> This is part of an effort to increase the awareness in
> the developer community of a longstanding need among
> OpenSim content creators and designers of simulator
> environments, for higher resolution pixel textures
> (images greater than current 1024x1024 pixels)
> to be used in stand-alone and/or grid operation of
> sim regions using OpenSimulator.
>
> We are cartoons...
> The present limit of 1024x1024 pixels contributes
> to a "cartoon-like" or sub-optimum look and feel to
> OpenSimulator. If we are to make progress in 21st century
> 3D graphics, higher resolution imagery is needed.
>
> Is it in only in the Viewer?
> Some devs point to the viewer clients being coded to limit
> the image size at upload. Since OpenSimulator project has
> recently changed license and participation method, to provide
> increased interaction between viewer developers and simulator
> developers, perhaps there is a renewed possibility to solve
> this problem in the near future. Some TPV viewers have provided
> compatibility switches in the Grid Manager section for
> use with OpenSimulator.
>
> Is there a SIMULATOR or server-side solution?
> If the only limits are in the viewer UPLOAD, then perhaps
> a method of image insertion at the database level or
> in the simulator console could be provided for higher
> resolution textures.
>
> What should the limit be?It is estimated that increasing the limit to
> at least 4096 x 4096 pixels would suffice for
> most applications. But, for future expansion,
> it should be up to the designer, the sim operator, or
> the grid operator to set such limits (if any).
>
> The areas of design that suffer the most from
> current texture size limits (1024x1024 pixels) are:
>
> 1. AVATARS: Avatar skin and system clothing. (Currently: very blurry! )
> 2. HUGE PRIMS: Large prim objects, such as buildings, environment/ space/
> sky/ backdrops/ backgrounds, etc.
> 3. SCULPTY: Visible texture applied to surface of sculpted objects.
> 4. MESH: Visible texture applied to surface of mesh objects.
> 5. LAND: Teraform, land/ground RAWs, textures, and data maps.
>
> Reproduction of the current situation:
> 1. Upload a 4096x4096 image for use with avatar upper body UV wrapped
> texture for system avatar.
> 2. Observe after upload, that the image has been converted by
> down-sampling and poorly compressing to a resulting 1024x1024 texture.
> 3. Apply the texture to the upper body of the system avatar in the
> opensimulator region.
> 4. Look at the avatar in the opensimulator region, and observe that the
> texture is fuzzy.
> 5. Compare the difference in sharpness of the original design image to the
> fuzziness of the inworld texture.
>
> Respectfully,
> Amy Smith
> aka. Lani Global
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Baked Texture persistence?

[Dahlia Trimble]

I've heard that LL sims will pass baked textures around from one sim to the
next as the avatar teleports around, (or at least they used this method
once, not sure if they still do). That way asset servers aren't overburdoned
with temporary textures and excessive uploads are avoided. I believe the
temporary texture feature in some third party viewers exploits this
mechanism to provide temporary, free texture uploads.

On Sun, Sep 25, 2011 at 11:38 AM, Mic Bowman  wrote:

> I will carefully disagree with Justin on this one. The viewer doesn't
> upload textures by default. It only uploads the textures if it believes
> something has changed. OpenSim doesn't currently respond correctly to the
> v2/v3 packets for cached appearance and earlier versions of the viewer can
> be told that that appearance parameters haven't changed so that textures are
> never uploaded (this saves a lot of bw... remember that if you upload
> textures they have to be sent out to everyone in the scene so it isn't the
> upload bw... its like putting new textures on objects every time the sim
> starts). In practice, people change appearance so infrequently that the
> baked textures do not fill up the asset database. And even when the do, so
> long as you don't get stuck in the "assets can never be deleted" way of
> thinking... (baked textures are marked as temporary anyway)... its pretty
> easy to clean up the asset db based on a reasonable set of policies.
>
>
>
> On Sun, Sep 25, 2011 at 1:25 AM, Neil Canham  wrote:
>
>> Ah - I hadn't appreciated that NPCs need to be cloned from a logged in AV.
>>  That makes sense.
>>
>> As for the persistence, like Mic I think there is potentially an argument
>> for it, as an option, for closed private sims for example, or sims where you
>> expect a lot of people to log in at roughly the same time.  However, I
>> appreciate that would be a big change so thanks for clarifying how it
>> operates now.
>>
>>
>> On Sat, Sep 24, 2011 at 11:18 PM, Justin Clark-Casey <
>> jjusti...@googlemail.com> wrote:
>>
>>> For ordinary avatars, baked textures don't need permanent persistence
>>> since the avatar uploads them on every login or when any body part/wearable
>>> is changed.  This will have no effect on slow rezzing or cloudiness - if a
>>> viewer is in the region it should always have uploaded the textures that it
>>> bakes.
>>>
>>> Indeed, there's little value in persisting these since the client will
>>> upload them on every login/region entrance. Persisting baked textures would
>>> bloat the asset service more than is already the case.
>>>
>>> An NPC, on the other hand, has no viewer from which these baked textures
>>> are uploaded.  So they have to be disk persisted at the point from which it
>>> is cloned from a 'live' avatar.
>>>
>>>
>>> On 24/09/11 19:28, Neil Canham wrote:
>>>
 I confess that I am puzzled.  I found this fantastic description from
 Mic of how 0.7 appearance works
 http://opensim-dev.2196679.n2.**nabble.com/What-I-ve-Learned-**
 About-AvatarAppearance-**td5655933.htmland
  it fits with what I
 see analysing the packets against 0.7.1.  So that seems quite clearly to
 say that baked textures are never persisted,
 and that would explain the slow rezzing and 'cloudiness' of avatars that
 I see regularly.  However, the new npc code
 seems to require that a baked texture is available to copy from. So are
 baked textures now persisted in the latest code?



 __**_
 Opensim-dev mailing list
 Opensim-dev@lists.berlios.de
 https://lists.berlios.de/**mailman/listinfo/opensim-dev

>>>
>>>
>>> --
>>> Justin Clark-Casey (justincc)
>>> http://justincc.org/blog
>>> http://twitter.com/justincc
>>> __**_
>>> Opensim-dev mailing list
>>> Opensim-dev@lists.berlios.de
>>> https://lists.berlios.de/**mailman/listinfo/opensim-dev
>>>
>>
>>
>> ___
>> Opensim-dev mailing list
>> Opensim-dev@lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>>
>
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Will an SSD drive make OS any faster?

[Dahlia Trimble]

Once it's started and the regions have loaded, OpenSim is mostly memory
resident. One exeption is the local asset cache which may be frequently
accessed when new users arrive in a region and assets are delivered to them
(textures, etc.). This is often mitigated by each user's viewer cache
(assuming they visit the region frequently). I suspect if you have a region
with many unique textures and very many first time or infrequent visitors,
you might see an improvement by having your asset cache reside on a
high-speed storage device. Otherwise I'm not sure it would be of much
benefit at all over lower cost mass-storage options.

Grid services and databases may benefit from higher speed storage if your
user base is sufficiently large and active.


On Fri, Sep 16, 2011 at 11:46 AM, David Kaplan
wrote:

> I'm getting ready to build a box specifically to run bunch of HG OS
> regions. The box will likely have no other purpose. It's not going to be
> expensive... I'm basically going to pour my money into a nice quad core CPU
> and RAM. But, I wanted to know if anyone here has any experience running OS
> using a high speed drive such as Seagate's Cheetah or SSDs. I'm really
> interested to hear if anyone has any experience with SSDs as they seem to be
> the fastest in terms of retrieval and storage.
>
> My theory is that OS is read/write intensive. Would a regular 7200 RPM
> drive create a bottleneck? If so, would and SSD drive help?
>
> TYIA!
>
> David Kaplan
> __**_
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/**mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Some thought about OpenSim Wiki future

[Dahlia Trimble]

My concern is that your prior message appears to describe in depth an
interpretation of a "user" but does little to describe what OpenSimulator is
or does. I would think that someone who is not familiar with OpenSimulator
may be looking at the site trying to understand what the software itself is
and does instead.

On Wed, Aug 3, 2011 at 10:28 AM, Nomura Makiko wrote:

> Sorry if I have posted again and again - I can't still see my post in my
> mail client... I remember I have clicked "sent" at least ten times before I
> received the mail from dahila.
>
> Which page(s) are you considering replacing? Or are you suggesting adding
> pages which define a user, in addition to the existing wiki pages which
> describe OpenSimulator?
>
>
> We are considering "refactoring" of wiki as a whole. Each contents won't be
> changed for now, just  the moving of existing page would be the start point.
>
>
>
> On 2011/08/04, at 2:21, Dahlia Trimble wrote:
>
> Which page(s) are you considering replacing? Or are you suggesting adding
> pages which define a user, in addition to the existing wiki pages which
> describe OpenSimulator?
>
> On Wed, Aug 3, 2011 at 10:05 AM, Makiko Nomura (Makopoppo) <
> nomura.mak...@googlemail.com> wrote:
>
>> Hi, nice to meet you all. I'm Makopoppo.
>>
>> In OpenSimulator Wiki, Fritigern told me his idea about dividing wiki into
>> user parts and developer parts.
>>
>> http://opensimulator.org/wiki/User_talk:Makopoppo#An_Idea_Which_Has_Been_On_My_Mind_For_Some_Time
>>
>> It would be nice to implement it. And more, I'd like to hear your thought
>> about wiki future as well, especially if you haven't use OpenSimulator wiki
>> ever or recently. (This is rather my personal activity than as a wiki admin
>> job)
>>
>> Here is my idea about what OpenSimulator wiki will be:
>>
>> * The definition of "User"
>>
>> OpenSimulator software, as itself, is a framework for 3D virtual
>> environment. It can be included into enterprise systems; i.e. some might
>> want to bundle it into their web servers, groupwares, or such. Some wants to
>> create their own kins for their use. Some wants to simply use this
>> distribution out-of-the-box. Some doesn't want to own their sims, just wants
>> to connect to them from their viewers. All of them are "Users". They will be
>> categorized into three types:
>>
>> Client Users: Who connects to (or logins to) OpenSimulator-based grids
>> with their viewer, websites, or some other possible methods. They don't need
>> any computer-specific knowledges, they can be teenagers, or even infants.
>> Documentation for them might be out of focus of OpenSimulator project, it is
>> rather client vendor's area, but having minimal instruction and links to
>> their document for further information is not so bad idea.
>>
>> Grid Users: Who connects their OpenSimulator-based regions to
>> OpenSimulator-based grids, or just using it standalone. They needs minimal
>> knowledge of operation systems, databases, or some other related softwares
>> such as web servers to run their own simulators. Since there are already
>> many resources for them, and especially for personal use, kins projects
>> doing great job to make clear documents, maintain them and providing support
>> for years. We can encourage or help them to improve their documents, such
>> as, providing link list to their pages, or bollowing their article with huge
>> credits.
>>
>> Framework Users: Who enhances OpenSimulator software for their use. The
>> purpose varies amongst each other, from personal use to enterprise use. For
>> example, the person who implements *Module, script functions, connectors or
>> such. To say in another word, who using OpenSimulator as a framework. I
>> personally think that one of the role of our OpenSimulator core project is
>> provider of the best documentation for them. And I know currently we don't
>> have enough documents for them, or if exists, it hasn't been maintenanced
>> for years.
>>
>> So, who will be the "Developers"? It will be the contributors who
>> contributes OpenSimulator framework itself. They should know OpenSim
>> internal architectures, implementing guidelines, or licensing matters. Some
>> experts can understand them only by reading codes (yikes!), but it would be
>> nice to have such documents, if we can keep updating them forever.
>>
>> * Possible Wiki Structure
>>
>> Considering these points above, we can divide the wiki into three domains:
>>
&g

Re: [Opensim-dev] Some thought about OpenSim Wiki future

[Dahlia Trimble]

Which page(s) are you considering replacing? Or are you suggesting adding
pages which define a user, in addition to the existing wiki pages which
describe OpenSimulator?

On Wed, Aug 3, 2011 at 10:05 AM, Makiko Nomura (Makopoppo) <
nomura.mak...@googlemail.com> wrote:

> Hi, nice to meet you all. I'm Makopoppo.
>
> In OpenSimulator Wiki, Fritigern told me his idea about dividing wiki into
> user parts and developer parts.
>
> http://opensimulator.org/wiki/User_talk:Makopoppo#An_Idea_Which_Has_Been_On_My_Mind_For_Some_Time
>
> It would be nice to implement it. And more, I'd like to hear your thought
> about wiki future as well, especially if you haven't use OpenSimulator wiki
> ever or recently. (This is rather my personal activity than as a wiki admin
> job)
>
> Here is my idea about what OpenSimulator wiki will be:
>
> * The definition of "User"
>
> OpenSimulator software, as itself, is a framework for 3D virtual
> environment. It can be included into enterprise systems; i.e. some might
> want to bundle it into their web servers, groupwares, or such. Some wants to
> create their own kins for their use. Some wants to simply use this
> distribution out-of-the-box. Some doesn't want to own their sims, just wants
> to connect to them from their viewers. All of them are "Users". They will be
> categorized into three types:
>
> Client Users: Who connects to (or logins to) OpenSimulator-based grids with
> their viewer, websites, or some other possible methods. They don't need any
> computer-specific knowledges, they can be teenagers, or even infants.
> Documentation for them might be out of focus of OpenSimulator project, it is
> rather client vendor's area, but having minimal instruction and links to
> their document for further information is not so bad idea.
>
> Grid Users: Who connects their OpenSimulator-based regions to
> OpenSimulator-based grids, or just using it standalone. They needs minimal
> knowledge of operation systems, databases, or some other related softwares
> such as web servers to run their own simulators. Since there are already
> many resources for them, and especially for personal use, kins projects
> doing great job to make clear documents, maintain them and providing support
> for years. We can encourage or help them to improve their documents, such
> as, providing link list to their pages, or bollowing their article with huge
> credits.
>
> Framework Users: Who enhances OpenSimulator software for their use. The
> purpose varies amongst each other, from personal use to enterprise use. For
> example, the person who implements *Module, script functions, connectors or
> such. To say in another word, who using OpenSimulator as a framework. I
> personally think that one of the role of our OpenSimulator core project is
> provider of the best documentation for them. And I know currently we don't
> have enough documents for them, or if exists, it hasn't been maintenanced
> for years.
>
> So, who will be the "Developers"? It will be the contributors who
> contributes OpenSimulator framework itself. They should know OpenSim
> internal architectures, implementing guidelines, or licensing matters. Some
> experts can understand them only by reading codes (yikes!), but it would be
> nice to have such documents, if we can keep updating them forever.
>
> * Possible Wiki Structure
>
> Considering these points above, we can divide the wiki into three domains:
>
> http://opensimulator.org/ <-- for "Client Users" and "Grid Users"
> http://framework.opensimulator.org/ <-- for "Framework Users"
> http://dev.opensimulator.org/ <-- for the contributors of OpenSimulator
> core project (coders, document writers, issue managers, wiki admins)
>
> Although MediaWiki can create namespaces and we can use it for this
> purpose, I feel sub-domaining provides more straight-forward way to access
> to them (this is probably because I am an address bar lover). Again, this is
> just my idea.
>
> * Should we create anything on our own?
>
> I personally think we don't need to "reinvent the wheel" to create all
> OpenSimulator documentation from the scratch, there are already nice
> documents all around the web. Why not make great use of them? I don't mean
> we can copyright violations and bring them all. Instead, it would be nice to
> have links to their project websites with simple descriptions about their
> project goal or feature on our wiki pages. Or, using their documents with
> big credit would be nice too(Cons is duplicated documentation will be more
> difficult to maintenance).
>
> I wonder why kin projects (i.e. OSGrids, Inworlds, AuroraSim, …) are not
> feathered as kin developers. They are the good OpenSimulator framework users
> and the good OpenSimulator "User" documents provider. And communities. I
> know there are many other OpenSimulator-forums and many experts grandly help
> so-called "noobs". We can encourage and help them to support others in their
> community, such as, again, adding link to their forums. B

Re: [Opensim-dev] I ran across this a few days ago...

[Dahlia Trimble]

At first glance it seems similar to BSON

Do you have a specific application in mind?

On Tue, May 17, 2011 at 2:53 PM, BlueWall  wrote:

> Hi,
>
> I ran across this serializer a few days ago. The license is Apache and
> it supports many languages. Any interest?
>
>http://msgpack.org/
>
> BlueWall
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Licensing question for region modules

[Dahlia Trimble]

Hi Neal,

http://forge.opensimulator.org/gf/ is provided for distribution of modules
and other software that might not me included in core for BSD license
compatibility or other reasons. You might also consider using github in
addition to forge if you want to increase visibility.

Changes are also in progress which may relax contribution guidelines given
the change of the LL client source from GPL to LGPL but unfortunately
progress is somewhat slow.

On Sat, May 14, 2011 at 10:26 AM, Neil Canham  wrote:

> A recent discussion about options for logging from scripted objects made me
> realise that I would really benefit from being able to have configurable
> logging, so I should write a region module.  However, I have the issue that
> I have worked on the Linden client.  I'm looking for advice on how I could
> make this region module available to the OpenSim community given the
> constraints on committing to the core.
>
> Neil Canham
>
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Capabilities

[Dahlia Trimble]

Is eventqueue the same as a capability? Perhaps it's a special case and
might deserve special naming, but still under
OpenSim.Region.ClientStackLinden somewhere.

Also I'd be in favor of a generic capability object  or base class or some
such that other client stacks and services could make use of, similar to the
http server we have now.


On Fri, Apr 29, 2011 at 2:19 PM, Diva Canto  wrote:

> I would like to clean up the way OpenSim handles capabilities. Here are my
> goals:
> (1) move everything-capabilities into LL space, because this is something
> that's very specific to the Linden-family of clients; and
> (2) make Capability URLs be externally configurable so that some of those
> services can be served from a Robust server, if operators see that need
>
> More specifically, I would like to:
>
> - rename OpenSim.Region.ClientStackLindenUDP to
> OpenSim.Region.ClientStackLinden
> - create two folders in there: UDP and Capabilities
> - Move everything that's currently under
> OpenSim.Region.ClientStackLindenUDP to the subfolder UDP
> - Move OpenSim.Framework.Capabilities to the subfolder Capabilities
> - Move the module that's currently in
> OpenSim.Region.CoreModules.Agent.Capabilities (CapabilitiesModule) to
> OpenSim.Region.ClientStackLinden.Capabilities
> - Move what's currently in OpenSim.Region.CoreModules.Framework.EventQueue
> to OpenSim.Region.ClientStackLinden.Capabilities
> - Move what's currently in
> OpenSim.Region.CoreModules.Framework.Avatar.Assets to
> OpenSim.Region.ClientStackLinden.Capabilities
> - refactor some of these modules, so that the handlers themselves are in
> OpenSim.Server.Handlers, so that they can be served from a Robust server
>
> Thoughts? Objections? Cautions?
>
> Crista / Diva
>
>
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

[Opensim-dev] Configuration changes for experimental mesh support

[Dahlia Trimble]

If you are using the experimental mesh support in OpenSimulator, please note
that there is a new configuration section that must be added to your
OpenSim.ini file. You can find an example of the new [Mesh] section in
OpenSimDefaults.ini:

These configuration parameters were previously in the [Startup] section but
have been moved on recent versions of OpenSimulator core.
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] networking issues

[Dahlia Trimble]

I'm not sure how often the viewer adjusts but I have seen message on the
linux viewer console which mentioned throttle adjustments. At the time they
seemed quite frequent, perhaps in tens of seconds between messages.

On Mon, Mar 28, 2011 at 12:34 PM, Mic Bowman  wrote:

> comments below...
>
> On Mon, Mar 28, 2011 at 11:49 AM, Dahlia Trimble 
> wrote:
>
>> a couple thoughts..
>>
>> Perhaps resend timeout period could be a function of throttle setting
>> and/or measured packet acknowledgement time per-client? (provided we measure
>> it). That may prevent excessive resend processing that may not be necessary.
>>
>>
> how/when does the viewer change its throttles? i have an "interesting"
> network connection to the public internet from intel (very long cable -->
> periodic high error rates)... i've seen 300% packet loss rates (explain that
> one!)... but never see a "throttle down" packet that would drop the update
> rates back to a range where the network can reasonably handle it.
>
> dan & i were talking today about how to adjust the throttles simulator-side
> when we start to see large number of packet retransmissions.
>
>
>> On the distance prioritization, could small changed in object translations
>> be discarded from the prioritization queues/resend buffers for distant
>> objects when new updates occur for those objects? Small changes may not be
>> noticeable from the viewer perspective anyway.
>>
>>
> dropping the update altogether is one approach but seems like it could mess
> up state. deprioritizing based on the magnitude of change seems like a
> better approach?? i think meru uses a version of angular distance. however,
> the computation of that is pretty expensive.
>
> with deprioritizing... we see updates accumulating. since the entity stays
> in the queue longer, you tend to accumulate greater and greater changes.
>
>
>>
>>
>> On Mon, Mar 28, 2011 at 10:48 AM, Teravus Ovares wrote:
>>
>>> Here are a few facts that I've personally discovered while working
>>> with LLClientView.
>>>
>>> 1. It has been noted that people with poor connections to the
>>> simulator do consume more bandwidth, cpu, and have a generally worse
>>> experience.   This has been tested and profiled extensively.This
>>> may seem like a small issue because what it's doing is so basic...
>>> however the frequency in which this occurs is a real cause of
>>> performance issues.
>>>
>>> 2. It's also noted that the CPU used in these cases reduces the CPU
>>> available to the rest of the simulator resulting in a lower quality of
>>> service for the rest of the people on the simulator.
>>> This has been seen in the profiling and has been qualitatively
>>> observed by a large number of users connected and everything is OK and
>>> then a 'problem connection' user connecting causing a wide range of
>>> issues.
>>>
>>> 3. It's also noted that lowering the outgoing UDP packet throttles
>>> beyond a certain point results in perpetual queuing and resends.
>>> This was tested by using a throttle multiplier last year that was
>>> implemented by justincc.  I'm not sure if the multiplier is still
>>> there.   It's most easily seen with image packets.   Again, I note
>>> that the packets are not rebuilt going from the regular outbound queue
>>> to the resend queue.The resend queue is /supposed/ to be used to
>>> quickly get data that is essential to the client after attempting to
>>> send once already.   The UDP spec declares the maximum resend to be 2
>>> times, however there has been some considerable debate on whether or
>>> not OpenSimulator should follow that specific specification item
>>> leading to a configuration option to enable perpetual resends
>>> (Implemented by Melanie).  The configuration item was named similar
>>> to, 'reliable is important' or something like that.   I'm not sure if
>>> the configuration item survived the many revisions however I suspect
>>> that it did.
>>>
>>> 4. It's also noted that raising the packet throttles beyond what the
>>> connection can support results in resending almost every packet the
>>> maximum amount of times before the limit is reached.
>>> This is easily reproducible by setting the connection (in the client)
>>> to the maximum and connecting to a region that you've never been to
>>> before on a sub par connection.   Before the client adjusts and
>

Re: [Opensim-dev] networking issues

[Dahlia Trimble]

yes, which is why I said discard them when new updates occur.

On Mon, Mar 28, 2011 at 12:03 PM, Melanie  wrote:

> For avatars yes. But prim updates can never be discarded, no matter
> how trivial, because they establish new persistent state.
>
> Melanie
>
> Dahlia Trimble wrote:
> > the viewer discards small changes anyway if avatar imposters are enabled
> >
> > On Mon, Mar 28, 2011 at 11:54 AM, Melanie  wrote:
> >
> >> No, we can't discard small changes. As the avatar comes closer, they
> >> would be seen out of place, e.g. someone building in the distance
> >> would move prims and then you come closer to look and all prims
> >> would be out of place.
> >>
> >> Melanie
> >>
> >> Dahlia Trimble wrote:
> >> > a couple thoughts..
> >> >
> >> > Perhaps resend timeout period could be a function of throttle setting
> >> and/or
> >> > measured packet acknowledgement time per-client? (provided we measure
> >> it).
> >> > That may prevent excessive resend processing that may not be
> necessary.
> >> >
> >> > On the distance prioritization, could small changed in object
> >> translations
> >> > be discarded from the prioritization queues/resend buffers for distant
> >> > objects when new updates occur for those objects? Small changes may
> not
> >> be
> >> > noticeable from the viewer perspective anyway.
> >> >
> >> >
> >> > On Mon, Mar 28, 2011 at 10:48 AM, Teravus Ovares 
> >> wrote:
> >> >
> >> >> Here are a few facts that I've personally discovered while working
> >> >> with LLClientView.
> >> >>
> >> >> 1. It has been noted that people with poor connections to the
> >> >> simulator do consume more bandwidth, cpu, and have a generally worse
> >> >> experience.   This has been tested and profiled extensively.This
> >> >> may seem like a small issue because what it's doing is so basic...
> >> >> however the frequency in which this occurs is a real cause of
> >> >> performance issues.
> >> >>
> >> >> 2. It's also noted that the CPU used in these cases reduces the CPU
> >> >> available to the rest of the simulator resulting in a lower quality
> of
> >> >> service for the rest of the people on the simulator.
> >> >> This has been seen in the profiling and has been qualitatively
> >> >> observed by a large number of users connected and everything is OK
> and
> >> >> then a 'problem connection' user connecting causing a wide range of
> >> >> issues.
> >> >>
> >> >> 3. It's also noted that lowering the outgoing UDP packet throttles
> >> >> beyond a certain point results in perpetual queuing and resends.
> >> >> This was tested by using a throttle multiplier last year that was
> >> >> implemented by justincc.  I'm not sure if the multiplier is still
> >> >> there.   It's most easily seen with image packets.   Again, I note
> >> >> that the packets are not rebuilt going from the regular outbound
> queue
> >> >> to the resend queue.The resend queue is /supposed/ to be used to
> >> >> quickly get data that is essential to the client after attempting to
> >> >> send once already.   The UDP spec declares the maximum resend to be 2
> >> >> times, however there has been some considerable debate on whether or
> >> >> not OpenSimulator should follow that specific specification item
> >> >> leading to a configuration option to enable perpetual resends
> >> >> (Implemented by Melanie).  The configuration item was named similar
> >> >> to, 'reliable is important' or something like that.   I'm not sure if
> >> >> the configuration item survived the many revisions however I suspect
> >> >> that it did.
> >> >>
> >> >> 4. It's also noted that raising the packet throttles beyond what the
> >> >> connection can support results in resending almost every packet the
> >> >> maximum amount of times before the limit is reached.
> >> >> This is easily reproducible by setting the connection (in the client)
> >> >> to the maximum and connecting to a region that you've never been to
> >> >> before on a sub par connection.   Bef

Re: [Opensim-dev] networking issues

[Dahlia Trimble]

I believe the buffer-bloat problem is more related to TCP than UDP. UDP is
probably affected as some ISPs may choose to discard UDP traffic when
excessive congestion occurs.

On Mon, Mar 28, 2011 at 11:41 AM, James Hughes wrote:

>
> Thanks Mic,
>
> I look forward to testing this. I have been chasing network issues that
> show up as wildly different performance experienced by users that are in
> the same simulator with others having similar connections and
> workstations. A couple of weeks ago I heard about something called
> bufferbloat and dark buffers in the Internet. I posted links to the
> information in IRC and would like to add it here as well ...
>
>http://www.bufferbloat.net/projects/bloat/news
>http://mirrors.bufferbloat.net/Talks/BellLabs01192011/
>
> I think this issue may a lot of bearing on our networking in the open
> Internet where packets in-transit are routed through devices with large
> built-in buffering. The packets are held in these devices for forwarding
> at a time that seems convenient for the device, rather than using
> congestion management and dropping the packets when needed. It is
> possible that a packet may experience this several times in-transit. As
> the packets are held in the buffers, latency is added to the circuit and
> may reach the point where we resend packets because we didn't get the
> acknowledgment in time.
>
> Hopefully this is, at least, somewhat related.
>
> Thanks,
> BlueWall
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] networking issues

[Dahlia Trimble]

the viewer discards small changes anyway if avatar imposters are enabled

On Mon, Mar 28, 2011 at 11:54 AM, Melanie  wrote:

> No, we can't discard small changes. As the avatar comes closer, they
> would be seen out of place, e.g. someone building in the distance
> would move prims and then you come closer to look and all prims
> would be out of place.
>
> Melanie
>
> Dahlia Trimble wrote:
> > a couple thoughts..
> >
> > Perhaps resend timeout period could be a function of throttle setting
> and/or
> > measured packet acknowledgement time per-client? (provided we measure
> it).
> > That may prevent excessive resend processing that may not be necessary.
> >
> > On the distance prioritization, could small changed in object
> translations
> > be discarded from the prioritization queues/resend buffers for distant
> > objects when new updates occur for those objects? Small changes may not
> be
> > noticeable from the viewer perspective anyway.
> >
> >
> > On Mon, Mar 28, 2011 at 10:48 AM, Teravus Ovares 
> wrote:
> >
> >> Here are a few facts that I've personally discovered while working
> >> with LLClientView.
> >>
> >> 1. It has been noted that people with poor connections to the
> >> simulator do consume more bandwidth, cpu, and have a generally worse
> >> experience.   This has been tested and profiled extensively.This
> >> may seem like a small issue because what it's doing is so basic...
> >> however the frequency in which this occurs is a real cause of
> >> performance issues.
> >>
> >> 2. It's also noted that the CPU used in these cases reduces the CPU
> >> available to the rest of the simulator resulting in a lower quality of
> >> service for the rest of the people on the simulator.
> >> This has been seen in the profiling and has been qualitatively
> >> observed by a large number of users connected and everything is OK and
> >> then a 'problem connection' user connecting causing a wide range of
> >> issues.
> >>
> >> 3. It's also noted that lowering the outgoing UDP packet throttles
> >> beyond a certain point results in perpetual queuing and resends.
> >> This was tested by using a throttle multiplier last year that was
> >> implemented by justincc.  I'm not sure if the multiplier is still
> >> there.   It's most easily seen with image packets.   Again, I note
> >> that the packets are not rebuilt going from the regular outbound queue
> >> to the resend queue.The resend queue is /supposed/ to be used to
> >> quickly get data that is essential to the client after attempting to
> >> send once already.   The UDP spec declares the maximum resend to be 2
> >> times, however there has been some considerable debate on whether or
> >> not OpenSimulator should follow that specific specification item
> >> leading to a configuration option to enable perpetual resends
> >> (Implemented by Melanie).  The configuration item was named similar
> >> to, 'reliable is important' or something like that.   I'm not sure if
> >> the configuration item survived the many revisions however I suspect
> >> that it did.
> >>
> >> 4. It's also noted that raising the packet throttles beyond what the
> >> connection can support results in resending almost every packet the
> >> maximum amount of times before the limit is reached.
> >> This is easily reproducible by setting the connection (in the client)
> >> to the maximum and connecting to a region that you've never been to
> >> before on a sub par connection.   Before the client adjusts and
> >> requests a lower throttle setting there's massive data loss and
> >> massive re-queuing.
> >>
> >> 5. The client tries to adjust the throttle settings based on network
> >> conditions.   This can be observed by monitoring the packet that sets
> >> the throttles and dragging the bar to maximum.   After a certain
> >> amount of resends, the client will call the set throttle packet with
> >> reduced settings (some argue that it doesn't do that fast enough).
> >>
> >> 6. A user who has connected previously to the simulator will use less
> >> resources then a user who has never connected to the simulator.  (this
> >> is mostly because of the image cache on the client).Any client
> >> that uses CAPS images will use less resources then one that uses
> >> LLUDP.
> >>
> >> When 

Re: [Opensim-dev] networking issues

[Dahlia Trimble]

Also, acknowledgement time is not necessarily a function of network health.
Often viewers process packets in the frame draw loop and the time per frame
is affected by many factors, including object density and animation
processing. Many animated avatars in the viewport could delay
acknowledgements significantly simply because of client processing time.


On Mon, Mar 28, 2011 at 11:49 AM, Dahlia Trimble wrote:

> a couple thoughts..
>
> Perhaps resend timeout period could be a function of throttle setting
> and/or measured packet acknowledgement time per-client? (provided we measure
> it). That may prevent excessive resend processing that may not be necessary.
>
> On the distance prioritization, could small changed in object translations
> be discarded from the prioritization queues/resend buffers for distant
> objects when new updates occur for those objects? Small changes may not be
> noticeable from the viewer perspective anyway.
>
>
>
> On Mon, Mar 28, 2011 at 10:48 AM, Teravus Ovares wrote:
>
>> Here are a few facts that I've personally discovered while working
>> with LLClientView.
>>
>> 1. It has been noted that people with poor connections to the
>> simulator do consume more bandwidth, cpu, and have a generally worse
>> experience.   This has been tested and profiled extensively.This
>> may seem like a small issue because what it's doing is so basic...
>> however the frequency in which this occurs is a real cause of
>> performance issues.
>>
>> 2. It's also noted that the CPU used in these cases reduces the CPU
>> available to the rest of the simulator resulting in a lower quality of
>> service for the rest of the people on the simulator.
>> This has been seen in the profiling and has been qualitatively
>> observed by a large number of users connected and everything is OK and
>> then a 'problem connection' user connecting causing a wide range of
>> issues.
>>
>> 3. It's also noted that lowering the outgoing UDP packet throttles
>> beyond a certain point results in perpetual queuing and resends.
>> This was tested by using a throttle multiplier last year that was
>> implemented by justincc.  I'm not sure if the multiplier is still
>> there.   It's most easily seen with image packets.   Again, I note
>> that the packets are not rebuilt going from the regular outbound queue
>> to the resend queue.The resend queue is /supposed/ to be used to
>> quickly get data that is essential to the client after attempting to
>> send once already.   The UDP spec declares the maximum resend to be 2
>> times, however there has been some considerable debate on whether or
>> not OpenSimulator should follow that specific specification item
>> leading to a configuration option to enable perpetual resends
>> (Implemented by Melanie).  The configuration item was named similar
>> to, 'reliable is important' or something like that.   I'm not sure if
>> the configuration item survived the many revisions however I suspect
>> that it did.
>>
>> 4. It's also noted that raising the packet throttles beyond what the
>> connection can support results in resending almost every packet the
>> maximum amount of times before the limit is reached.
>> This is easily reproducible by setting the connection (in the client)
>> to the maximum and connecting to a region that you've never been to
>> before on a sub par connection.   Before the client adjusts and
>> requests a lower throttle setting there's massive data loss and
>> massive re-queuing.
>>
>> 5. The client tries to adjust the throttle settings based on network
>> conditions.   This can be observed by monitoring the packet that sets
>> the throttles and dragging the bar to maximum.   After a certain
>> amount of resends, the client will call the set throttle packet with
>> reduced settings (some argue that it doesn't do that fast enough).
>>
>> 6. A user who has connected previously to the simulator will use less
>> resources then a user who has never connected to the simulator.  (this
>> is mostly because of the image cache on the client).Any client
>> that uses CAPS images will use less resources then one that uses
>> LLUDP.
>>
>> When working with the packet queues, it's essential to understand
>> those 6 observations.   Even though, the place where you tend to see
>> the issues with queuing is the image queue over LLUDP, the principles
>> apply to all of the udp queues.
>>
>> Regards
>>
>> Teravus
>>
>>
>> On Mon, Mar 28, 2011 at 1:00 PM, Mic Bowma

Re: [Opensim-dev] networking issues

[Dahlia Trimble]

a couple thoughts..

Perhaps resend timeout period could be a function of throttle setting and/or
measured packet acknowledgement time per-client? (provided we measure it).
That may prevent excessive resend processing that may not be necessary.

On the distance prioritization, could small changed in object translations
be discarded from the prioritization queues/resend buffers for distant
objects when new updates occur for those objects? Small changes may not be
noticeable from the viewer perspective anyway.


On Mon, Mar 28, 2011 at 10:48 AM, Teravus Ovares  wrote:

> Here are a few facts that I've personally discovered while working
> with LLClientView.
>
> 1. It has been noted that people with poor connections to the
> simulator do consume more bandwidth, cpu, and have a generally worse
> experience.   This has been tested and profiled extensively.This
> may seem like a small issue because what it's doing is so basic...
> however the frequency in which this occurs is a real cause of
> performance issues.
>
> 2. It's also noted that the CPU used in these cases reduces the CPU
> available to the rest of the simulator resulting in a lower quality of
> service for the rest of the people on the simulator.
> This has been seen in the profiling and has been qualitatively
> observed by a large number of users connected and everything is OK and
> then a 'problem connection' user connecting causing a wide range of
> issues.
>
> 3. It's also noted that lowering the outgoing UDP packet throttles
> beyond a certain point results in perpetual queuing and resends.
> This was tested by using a throttle multiplier last year that was
> implemented by justincc.  I'm not sure if the multiplier is still
> there.   It's most easily seen with image packets.   Again, I note
> that the packets are not rebuilt going from the regular outbound queue
> to the resend queue.The resend queue is /supposed/ to be used to
> quickly get data that is essential to the client after attempting to
> send once already.   The UDP spec declares the maximum resend to be 2
> times, however there has been some considerable debate on whether or
> not OpenSimulator should follow that specific specification item
> leading to a configuration option to enable perpetual resends
> (Implemented by Melanie).  The configuration item was named similar
> to, 'reliable is important' or something like that.   I'm not sure if
> the configuration item survived the many revisions however I suspect
> that it did.
>
> 4. It's also noted that raising the packet throttles beyond what the
> connection can support results in resending almost every packet the
> maximum amount of times before the limit is reached.
> This is easily reproducible by setting the connection (in the client)
> to the maximum and connecting to a region that you've never been to
> before on a sub par connection.   Before the client adjusts and
> requests a lower throttle setting there's massive data loss and
> massive re-queuing.
>
> 5. The client tries to adjust the throttle settings based on network
> conditions.   This can be observed by monitoring the packet that sets
> the throttles and dragging the bar to maximum.   After a certain
> amount of resends, the client will call the set throttle packet with
> reduced settings (some argue that it doesn't do that fast enough).
>
> 6. A user who has connected previously to the simulator will use less
> resources then a user who has never connected to the simulator.  (this
> is mostly because of the image cache on the client).Any client
> that uses CAPS images will use less resources then one that uses
> LLUDP.
>
> When working with the packet queues, it's essential to understand
> those 6 observations.   Even though, the place where you tend to see
> the issues with queuing is the image queue over LLUDP, the principles
> apply to all of the udp queues.
>
> Regards
>
> Teravus
>
>
> On Mon, Mar 28, 2011 at 1:00 PM, Mic Bowman  wrote:
> > Over the last several weeks, Dan Lake & I have been looking some of the
> > networking performance issues in opensim. As always, our concerns are
> with
> > the problems caused by very complex scenes with very large numbers of
> > avatars. However, I think some of the issues we have found will generally
> > improve networking with OpenSim. Since the behavior represents a fairly
> > significant change in behavior (though the number of lines of code is not
> > great), I'm going to put this into a separate branch for testing (called
> > queuetest) in the opensim git repository.
> > We've found several problems with the current
> > networking/prioritization code.
> > * Reprioritization is completely broken for SceneObjectParts. On
> > reprioritization, the current code uses the localid stored in the scene
> > Entities list but since the scene does not store the localid for SOPs,
> that
> > attempt always fails. So the original priority of the SOP continues to be
> > used. This could be the cause of some problems

Re: [Opensim-dev] Temporary cooldown

[Dahlia Trimble]

The temporary moderation is no longer in effect and the list is now open
again. Please try to keep discussions focused on appropriate topics.
Discussion of specific patents is *not* considered appropriate.

On Thu, Feb 3, 2011 at 10:25 AM, Teravus Ovares  wrote:

> Hey there everyone
>
> After reading the discussion on OpenSim-dev the past few days, I've
> decided to follow through with what diva said earlier.The
> conversation hasn't ended and there hasn't been anything of value
> added to it after the fact.  There are people who feel strongly on
> both sides of the issue and, the issue cannot be resolved or changed
> being hashed out here.I've put the OpenSim-dev list into full
> moderation mode for the next several hours.   Lets take this time to
> remember that the conversation was asked to be ended and/or taken
> elsewhere.
>
> Regards
>
> Teravus
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] [opensource-dev] Where is MXP implementation ?

[Dahlia Trimble]

I'm not sure about RealXtend, but there is a MXP implementation in
IdealistViewer. You should be able to see the code here:
http://forge.opensimulator.org/gf/project/idealistviewer/scmsvn/?action=browse&path=%2Ftrunk%2FIdealistViewer%2FNetwork%2F


On Thu, Jan 20, 2011 at 12:34 AM, Rustam Rakhimov wrote:

> Where is MXP implementation ?
>
> hi everybody,
>
> RealXtend uses MXP but where exactly, i mean which part and where its used
> or implemented
>
> please let me know. if possible file name and function name
>
> thank you in advance !!
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] [vwrap] Departing from virtual world development

[Dahlia Trimble]

Best of luck in your new field. You will be sorely missed.

I hope to hear more about your new endeavors, I've done some work in the
field of machine vision and learning in the past and I understand what a
rewarding field it can be. Please continue to stay in touch and let us know
how you are doing and what research you can share.


On Thu, Jan 13, 2011 at 4:28 PM, John Hurliman wrote:

> Hi everyone,
>
> I'm sad to announce that I've decided to leave my position at Intel
> and the virtual world development sphere. This is my last official
> week, although I will be tying up development ends in the open source
> virtual world arena for a bit longer.
>
> 2011 marks my fifth year working on virtual worlds, from the beginning
> of libsecondlife/libopenmetaverse to the current OpenSim and
> SimianGrid development. Things have come a long way from reverse
> engineering the terrain packet encoding, and we now have a
> decentralized network of worlds and a protocol to link them together.
>
> My departure is the beginning of a new adventure into machine learning
> with an early stage startup. This endeavor is a full-time commitment
> and won't leave me enough time to contribute to
> OpenSim/SimianGrid/libOpenMetaverse/Fortis/Aurora/VWRAP in any
> substantive way. Although I'm transitioning into a different area of
> technology, I'm still interested in the progress of the open metaverse
> and keeping in contact with everyone, and can be reached any time at
> this e-mail.
>
> On a related note, Intel's Virtual Worlds Infrastructure team is
> looking for a software researcher. Working with the VWI team has been
> great; I can't say enough good things about being a member of the team
> and advancing research in the virtual worlds and distributed computing
> field. Ping Mic Bowman if you are interested in working in the field
> in a research capacity.
>
> I am going to miss working with all of you, and I wish the best of
> luck to everyone in this area. I'll pop into IRC periodically to say
> hello.
>
> Best,
> John
> ___
> vwrap mailing list
> vw...@ietf.org
> https://www.ietf.org/mailman/listinfo/vwrap
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Serving textures in different formats

[Dahlia Trimble]

I have no current preference for one over the other. I suspect that there
may be more options desired in the future besides format so whichever is
most easily extended and widely accepted may be the better choice.

On Wed, Dec 8, 2010 at 7:36 AM, Diva Canto  wrote:

> So far, all textures in OpenSim are stored and served as jp2. However, some
> viewers can't use jp2. Example: Unity3d, for the time being. I would like to
> improve the GetTexture cap service by adding the ability for it to make
> conversions on the fly depending on extra data provided by the caller.
>
> There are two ways of doing this. Which one do people prefer?
>
> A) Add an extra query parameter: http://foo.com/GetTexture/?texture_id=
> &format=
>
> B) Use the Accept and Content-Type headers appropriately.
> The request might have
> Accept: image/png, image/jp2
> And the response might have
> Content-Type: image/png
>
> Diva / Crista
>
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] config changes for HG

[Dahlia Trimble]

Thanks for the heads up Diva :)

Would this affect regions where Hypergrid is not enabled?


On Mon, Nov 29, 2010 at 10:20 AM, Diva Canto  wrote:

> WARNING: DO NOT USE DEVELOPER'S CODE IN ANYTHING OTHER THAN DEVELOPMENT AND
> TESTING.
>
> * For those of you following the master branch:
>
> In order to preserve creator information on HG asset transfers, I just
> committed some changes that affect the HG configs quite substantially.
> Please make sure to look at the diffs of Robust.HG.ini.example (many
> changes), and config-include/StandaloneCommon.ini.example and
> config-include/GridCommon.ini.example (just minor changes). Non-HG configs
> aren't affected.
>
> In a nutshell, I added a separate HGAssetService that is now the one that
> sticks its head as the interface to the outside world. For now, it just
> rewrites the creator information of objects that go out. In the near future
> it will perform authorization checks and all sorts of other filtering on
> inter-grid asset requests.
>
> Bugs ==> mantis ==> thanks!
>
> * For everyone else, all of this will be documented when the next release
> comes out.
>
> WARNING: DO NOT USE DEVELOPER'S CODE IN ANYTHING OTHER THAN DEVELOPMENT AND
> TESTING.
>
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] [opensource-dev] Web login

[Dahlia Trimble]

I think the web login code has been bitrotting for probably a couple
years now, if you're referring to the same code I'm thinking of.
Anyway probably better to ask this question in the opensim-dev mailing
list.


On 11/20/10, Olli Aro  wrote:
> Hi all,
>
>
>
> Anyone using the web login with the latest version of OpenSim?
>
>
>
> We are in process of porting our OpenSim management system to the latest
> version and seem to have problems with the web login functionality that
> worked fine previously.
>
>
>
> Any chance that could have got broken when the database was restructured?
>
>
>
> Regards,
>
>
>
> Olli
>
>
>
>
>
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Havok Physics Engine

[Dahlia Trimble]

Hi,

I'm not familiar with the Havok APIs or if it's even capable of using
triangle meshes as colliders, but I felt a brief description of the ODE
interface may be a good starting point.

In a nutshell...

ODE has some internal collider types that it uses for basic shapes such as a
box or sphere. There is logic in OpenSimulator that tests a prim shape can
be represented by an internal ODE collider, and if so, instructs ODE to use
the appropriate internal shape. If the shape is more complex, CreateMesh()
in Meshmerizer.cs is called which creates a triangle mesh suitable for a
collider. Once the mesh is created, the mesh
methods getVertexListAsPtrToFloatArray() and getIndexListAsPtrToIntArray()
are called  (both in Mesh.cs) which return pointers to arrays containing the
mesh data. The data are arranged as strided arrays of 32 bit floats for the
vertex data, and 32 bit ints for the face index data.  The vertex positions
are the only component of a triangle face as face normals are implied by the
index order, and ODE only collides on the outward facing side of a triangle.
These pointers reference arrays which are "pinned" in memory, as ODE is
unmanaged code and is not able to safely access managed data structures.
There is also a caching function built into the meshing system which
attempts to keep all the pinned mesh data in one place in the heap and share
the meshes as often as possible to save memory, however you shouldnt need to
worry about that if you only use the pinned vertex arrays. If you need other
formats, Mesh.cs contains the code which formats the arrays for ODE.

 Good luck  and keep us posted on your progress :)
-dahlia
On Thu, Oct 28, 2010 at 12:17 PM, ftechz  wrote:

> Hello devs,
>
> I'm attempting to create a wrapper for the free version of Havok to hook-up
> with opensim. I'm quite new to this so I'm not quite sure what exactly is
> required by opensim to make this possible. I'm especially confused by the
> mesher, how it integrates with ODE and how it may be used by Havok... among
> other things...
> If anyone can give me some advice to point me in the right direction it
> would be helpful. I understand that not everyone will be able to use Havok
> in their sims due to licencing issues but I hope that people who are
> eligible may be able to use it in the future.
>
> Thanks,
> Phil
>
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] What I've Learned About AvatarAppearance

[Dahlia Trimble]

Persisting visual params makes sense for those types of clients which dont
generate them, such as some libomv bots. Typically these clients rely on
params generated from prior logins with a normal viewer.



On Wed, Oct 20, 2010 at 12:31 PM, Melanie  wrote:

> Hi Mic,
>
> that all sounds great.
>
> To address your questions:
>
> Persisting visual params doesn't appear to make sense, as far as I
> know they are regenerated on each login anyway, and they are < 256
> bytes. Not really a load factor to worry about.
>
> Persisting baked textures would require them to be uploaded to the
> asset server, which would cause unacceptable asset bloat. While I
> can see where there are scenarios where that is an advantage, for a
> normal social grid this is an unacceptable volume. It needs to be
> optional, and not on by default.
> However, encoding the actual baked textures into AgentCircuitData
> could improve performance, as it would no longer be required to
> re-upload them in each sim one crosses or teleports into.
> The avatar appearance (avatar service) is a name-value pair storage
> anyway, so it could easily hold the UUIDs of baked textures along
> with the components of the avatar appearance. It could also hold the
> visual params, the question there is to what degree that is useful.
>
> Compatibility is not really an issue. For something as tremendously
> beneficial as this could become, we can easily bump the interface
> version.
>
> As for testing, we can either branch it on opensimulator.org, and
> then work with the branch, or you can branch in your repo and we
> pull from it and then debug and fix it in opensimulator.org.
>
> Melanie
>
> Mic Bowman wrote:
> > just to set some context... we started looking at appearance because the
> > cost of logins was very high and grows quadratically (it takes 3+ hours
> to
> > start up our 1000 avatar demonstration).
> >
> >
> > the current version of opensim does not persist either baked avatar
> textures
> > or visual parameters. as a result, when an avatar logs in, the login
> service
> > sends to the simulator a packet that includes wearables and attachments.
> as
> > part of the login process the incomplete appearance is sent to the client
> > and the client "fixes" it. the "fixing" process involves multiple packets
> > being sent by the viewer to the simulator to set various visual
> parameters,
> > uploading multiple baked textures (in my case i see 6 textures uploaded
> on
> > the typical login), then a final setappearance packet to assign the baked
> > textures to the avatar's appearance.
> >
> >
> > each one of these updates causes the current state of the avatar's
> > appearance to be sent to every connected client. and, since currently
> baked
> > textures are not persisted, baked textures must be uploaded/downloaded on
> > every login. so 10 clients logging in simultaneously means that the
> > simulator is sending appearance 10x10xN times where N is the number of
> > packets it takes for one avatar to establish its appearance (N == 8 for
> my
> > avatar).  with 1000 clients logging in... the numbers are in the
> millions...
> >
> >
> > to get around this problem we set out to persist visual parameters and
> baked
> > textures. there is no easy fix
> >
> >
> > to summarize what we are testing (see below for question about how to get
> it
> > published... too big for a simple patch)...
> >
> >
> >
> > we moved all packing/unpacking of appearance into AvatarAppearance. this
> > works really well except that the four places where the appearance was
> > packed before (all four using slightly different encodings) now break
> > backward compatibility unless we leave all the old code in place (which
> sort
> > of defeats the purpose). I’m not sure what to do about backward
> > compatibility, more on that in a minute.
> >
> >
> >
> > the packing includes baked textures and visual params. the net effect of
> > that is that if you appearance hasn’t changed, there are no baked
> textures
> > uploaded and no visual params set on login. that cuts out 6-ish baked
> > texture uploads and multiple (4-6 depending on the avatar) updates of the
> > visual params.
> >
> >
> >
> > we added [Set|Get]Appearance calls to IAvatarService but left in the
> Set/Get
> > avatar calls which pass avatar data. The Robust implementation of
> > Set|GetAppearance just calls the Set|GetAvatar operations. That should
> > encode the data in the same way it was encoded before (the Appearance
> > encoding/decoding in AvatarData remains) with no baked textures or visual
> > parameters saved. And all values that will be stored in the user database
> > should continue to be short-ish (no change, in theory) to fit into the
> > current 256 character size limit on userdata.
> >
> >
> > we cleaned out a bunch of unused code from avatarfactory and moved
> several
> > of the appearance handling routines from scenepresence into that module.
> at
> > some point... appearance updates should be held bri