The Simian developers apparently don't test with Robust at all. So
they don't catch bugs where Simian is not properly disabled.
Groups has been tested and works perfectly well with .69 -- and the last
time it was tested with the .7 branch it worked just fine.
Jor3l Boa wrote:
It was not
the code is,
OpenSim/Region/CoreModules/Asset/FlotsamAssetCache.cs
Cheers,
--
Michael Cortez
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
:
$groupRequireAgentAuthForWrite = FALSE;
--
Michael Cortez
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
branch I took the path of lest work when back-porting the changes
(including the config param names.)
--
Michael Cortez
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
:
http://www.openmetaverse.org/viewvc/index.cgi/omf/libopenmetaverse/trunk/OpenMetaverse/_VisualParam_.cs?view=co
--
Michael Cortez
aka Static Sprocket
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim
/master --
any bleeding edge groups work will be there first in one or more
branches. The groups-core-contrib branch will contain changes
scheduled to be, or already submitted to opensimulator.org for
inclusion in the core repo.
Cheers,
--
Michael Cortez
no requirement for such a move to be completed in it's
entirety for people to continue working.
--
Michael Cortez
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
in a couple minutes of coding as
a proof of concept for a file cache. There is no limiting or expiration
mechanism, and as such is not appropriate for production use. If
testing proves that it's useful, then I'll submit to mantis for
inclusion in OpenSim SVN.
--
Michael Cortez
developer.
--
Michael Cortez
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
to the flotsam project website at gcode are
generally work-in-progress patches used by those testing new
functionality, or bug resolutions prior to their submission to SVN.
For more information see:
https://lists.berlios.de/pipermail/opensim-users/2009-April/002051.html
Hope that helps,
--
Michael
, or within the same private network.
I dunno if that helps or not, but just my 2 cents -- and if it wasn't
clear I'm +1 on collapsing the standalone vs grid -- so that it is
always grid, perhaps with a switch that allows direct in process access
to services {if available}
--
Michael Cortez
not
provide the full access token to it.
--
Michael Cortez
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
???
;-)
--
Michael Cortez
{still contending that a single instance of OpenSim is a Grid already...}
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
either 1000's of meters
vertically, under ground, or out of the region.
I was tempted to push what I had to the main SVN, but was unhappy with
the results so I never got around to it -- then got distracted by Sun,
Wind, Groups, etc...
--
Michael Cortez
Michael Cortez wrote:
My thoughts:
To me, a Grid is a virtual space that can be of any given size, and to
date, currently consists of one or more discrete Regions that are laid
out in a two dimensional grid pattern. A Grid allows for these
discrete individual spaces to be joined together
understand that it's not the general scenario of
people talking about hypergrid, but OpenSim is a platform that will be
used for things other then hypergridding and I don't want to see
alternative scenarios ruled out, or marginalized because of the current
focus on hypergrid.
Cheers,
--
Michael Cortez
also cut out entire usage scenarios where the
default is not to trust the client, or anything the client says {think
remote access to closed corporate networks or game scenarios.}
Just my half-awake two cents,
--
Michael Cortez
___
Opensim-dev
,
--
Michael Cortez
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
some bug exposed an exploitable asset copy mechanism, or
because someone connected a hacked region to the grid to suck assets out
-- perhaps having the default licensing be something like CC -- which
always guarantees redistribution isn't such a bad thing?
--
Michael Cortez
?
--
Michael Cortez
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
It would probably be a good idea to have llMoveTo() and llSetHoverHeight()
be mutually exclusive, so perhaps adding another flag to PhysicsActor for
PIDHover {True/False}, and then using that in the various physics
implementations to signal when only the Z axis should be used.
An alternative
I just noticed that the llSetHoverHeight() method uses PhysicsActor
PIDTarget/Tau/Active which is the same interface to the physics engine
that is used for llMoveTo().
This creates a problem because, llSetHoverHeight() should only dampen a
body's Z axis, not all three -- which is what the
22 matches
Mail list logo
