Re: [Opensim-dev] Error detection when storing an asset

[Mike Chase]

Or RabbitMQ...  Or even ZeroMQ if an external MQ service is deemed too
heavy.

Mike

-Original Message-
From: opensim-dev-boun...@lists.berlios.de
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Shaun T. Erickson
Sent: Friday, April 18, 2014 1:22 PM
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Error detection when storing an asset

There's also the free ActiveMQ.

On 4/18/14, 11:23 AM, Melanie wrote:
> MQ Series, IBM's message queue service

___
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] Error detection when storing an asset

[Mike Chase]

I'm inclined to agree with Oren.  Asset Writes could fail for a variety of
reasons and there are lots of use cases where you need to know the asset is
on disk.  I think propagating exceptions is the more sound approach IMO.

I also agree re: the custom comms vs a persistent queue mechanism but I
don't want to derail this topic.   That can wait for another day.

Mike

-Original Message-
From: opensim-dev-boun...@lists.berlios.de
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Oren Hurvitz
Sent: Friday, April 18, 2014 7:06 AM
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Error detection when storing an asset

Regarding the hiding of exceptions: to be clear, I was already bitten by
this behavior; that's why I started to investigate how assets are stored. I
have therefore already changed Kitely's version of OpenSim to propagate
exceptions, and the question is whether other people would like me to
contribute this change. If anyone has an opinion then please reply.

Regarding your suggestion to save assets to local disk and retry them later:
this is basically what a persistent message queue does. If you're going to
go that route then it would be best to add a real message queue rather than
a home-grown one. I would LOVE it if OpenSim used a message queue for
communications, as it would allow ripping out thousands of lines of homemade
communications code, and would be faster and more reliable to boot. But
that's a bigger issue and I'll put it aside for now.

In this particular case, using a persistent message queue isn't be the right
solution: the right solution is to report failures immediately. Otherwise
you'd get weird behavior such as a user who thinks they've successfully worn
a piece of clothing, but when they teleport to another region it disappears
because the other region can't load the asset (because it was never saved).
To prevent these problems you need to fail-fast, and tell the user
immediately when a problem happens. This doesn't mean to crash the sim; I
strongly doubt any asset failure would cause that, it would just fail the
specific packet or message that is currently being handled, as it should.



--
View this message in context:
http://opensim-dev.2196679.n2.nabble.com/Error-detection-when-storing-an-ass
et-tp7579223p7579225.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] Optimize pushing assets to other grids

[Mike Chase]

Yes I understand. That's why I said its no less secure than the protocol
it's based on.  And Diva I get that the external asset server is very
configurable.I don't expect changes.  I just don't believe HyperGrid as
its designed is correct or allows for the management of relationships.   It
would need to be able to allow the establishing of trust  between both users
and grids and services and grids as well as users and services.  And that
would need to be exposed at user level.  I should be able to say I don't
trust service X as a user. Or don't give me anything from Grid Y.  Same with
grid to grid/service.  That's partially there.

I never believed that hypergrid belonged in core.  I said so at the time.
But its there now so we live with it.  It would be nice if really this was
all looked at with fresh eyes. But I don't expect that will happen at this
stage either.

Mike


-Original Message-
From: opensim-dev-boun...@lists.berlios.de
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Oren Hurvitz
Sent: Sunday, March 30, 2014 11:39 AM
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Optimize pushing assets to other grids

It's already possible to know which assets are on the server by performing
GETs, so this method doesn't change the security situation.



--
View this message in context:
http://opensim-dev.2196679.n2.nabble.com/Optimize-pushing-assets-to-other-gr
ids-tp7579093p7579096.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] Optimize pushing assets to other grids

[Mike Chase]

It's a huge security hole. But then so is Hypergrid in general.  Not really
designed for trust relationships or capabilities between entities.
Otherwise it fits into the hypergrid wild west as a whole.  

Mike

-Original Message-
From: opensim-dev-boun...@lists.berlios.de
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Oren Hurvitz
Sent: Sunday, March 30, 2014 10:48 AM
To: opensim-dev@lists.berlios.de
Subject: [Opensim-dev] Optimize pushing assets to other grids

I want to improve how assets are transferred between grids in the Hypergrid.
Currently there are two ways this is done: push and pull. In both cases,
HGUuidGatherer is used to find all the assets that are embedded in the
top-level asset. The Pull operation is efficient because it won't load from
the remote grid an asset that already exists in the local grid. But the Push
operation is inefficient because it doesn't know which assets the remote
grid has, so it has to send all the assets (full data), and it never
remembers which assets the remote grid already has.

In order to improve this, I'm thinking of adding a Hypergrid method that
will let the local grid know which assets the remote grid already has, so it
won't have to send them again. Something like this:

bool[] AssetExists(string[] uuid);

Thoughts?

Oren



--
View this message in context:
http://opensim-dev.2196679.n2.nabble.com/Optimize-pushing-assets-to-other-gr
ids-tp7579093.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] Detaching mesh objects causes the region set send full asset data -- including geometry -- to the asset server

[Mike Chase]

I don't get this. I thought assets were immutable.  Why would you ever
update an asset.  Contents yes I can see that but not the asset itself.  I
suppose that's the bug?

Mike

-Original Message-
From: opensim-dev-boun...@lists.berlios.de
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Melanie
Sent: Wednesday, March 26, 2014 8:33 AM
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Detaching mesh objects causes the region set send
full asset data -- including geometry -- to the asset server

And the answer is: NO.

That should NEVER happen. It's a BIG hairy-legged bug!

Melanie

On 26/03/2014 12:52, Aine wrote:
> Bingo!
> 
> I just ran my test again with a newly created test mesh and did not 
> observe the mass of data being sent to the asset server when I unwore 
> it (as per Oren's post in the mantis). I then wore it again and added 
> a generic empty script
> 
> default
> {
> state_entry()
> {
> llSay(0, "Script running");
> }
> }
> 
> I then unwore it and saw the massive amount of data sent. I guess I've 
> been observing this so frequently with attached meshes because I often 
> add a script to allow me to conveniently tint and texture it 
> (selecting faces on a conforming mesh can be an exercise in frustration).
> 
> So the issue shifts to "is it really necessary to resend the entire 
> mesh geometry data every time it's unworn if the mesh contains a script?"
> 
> 
> 
> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de
> [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Melanie
> Sent: Tuesday, March 25, 2014 10:50 PM
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] Detaching mesh objects causes the region 
> set send full asset data -- including geometry -- to the asset server
> 
> Hi,
> 
> this is a potentially very serious bug.
> 
> For prims, OpenSim will indeed save the prims back into an asset when 
> they are unworn if they have changed or contain scripts.
> This is because script states are saved as part of the object.
> Mesh of course needs to be detected and treated differently.
> Resaving mesh is incredibly wasteful and should just not happen.
> 
> Melanie
> 
> ___
> 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] GIt master is broken until further notice

[Mike Chase]

On Sat, 2013-12-14 at 14:59 +0700, Akira Sonoda wrote:
> It is not a problem of distributed version control Mike. IMHO such
> things can be done properly. For example:
> http://nvie.com/posts/a-successful-git-branching-model/
> 
> Most git tools like SourceTree or SmartGit nowadays have builtin git
> flow support.
> 
> 
> Akira
> 
> 
Sorry Akira.  I was being sarcastic.  Probably not constructive.  My
real point was exactly that git and DSCM systems provide the tools to
manage such a merge without breaking HEAD and affecting other
developers. I very much agree the tools exist to manage it.

Mike
> 
> 2013/12/11 Mike Chase 
> O.o
> 
> So much for distributed version control.  Hopefully the
> changes are
> worth it.
> 
> Mike
> 
> 
> On Tue, 2013-12-10 at 18:05 -0800, 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
> 
> 
> ___
> 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] GIt master is broken until further notice

[Mike Chase]

O.o

So much for distributed version control.  Hopefully the changes are
worth it.

Mike


On Tue, 2013-12-10 at 18:05 -0800, 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


___
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

[Mike Chase]

On 08/30/2013 01:54 PM, Dahlia Trimble wrote:
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?


You need to skip the first 2 bytes of the stream..

From the code:

using(MemoryStream inMs =new MemoryStream(data, offset, size))
{
/*
*Skippingpastthefirsttwobytes,whicharepartofthezlibspecification
*(RFC1950),notthedeflatespecification(RFC1951).Thosebytescontain
*informationaboutthecompressionmethodandflags.
*/
int streamType = inMs.ReadByte();
int streamFlags = inMs.ReadByte();

using(MemoryStream outMs =new MemoryStream())
{
using(DeflateStream zOut 
=new DeflateStream(inMs, CompressionMode.Decompress))

{
zOut.CopyTo(outMs);
byte[] decompressedBuf = outMs.ToArray();
return OSDParser.DeserializeLLSDBinary(decompressedBuf)as OSDArray;
}
}



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.


Yeah being able to characterize exactly when the hang happens (what 
phase of the upload) would help.  There is a specific set of steps taken 
from calculate to the upload that actually have some intermediate server 
interactions.  Knowing where the failure occurs from a UI perspective 
would help track it down.


Mike




On Fri, Aug 30, 2013 at 6:56 AM, Mike Chase 
<mailto: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 <http://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
mailto: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

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

[Mike Chase]

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 
mailto: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 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

[Mike Chase]

What happens when someone rezzes an item that points to your offline asset?
Just confuzzled.  Your behavior is exactly the opposite of what opensim
expects.  That is, that assets are immutable and inventory references can
come and go.

 

Mike

 

From: opensim-dev-boun...@lists.berlios.de
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Mic Bowman
Sent: Wednesday, March 13, 2013 11:58 PM
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] asset type vs inventory type

 

i don't have a viewer. :-)

 

putting objects in a scene (and getting them out) with bash scripts... 

 

for x in `seq 150 5 200` ; do 

  for y in `seq 150 5 200`; do 

./inventory.pl put -p TestObject -s 'Scratch 01' -l $x $y 50; 

  done; 

done

 

just testing some ideas for moving inventory completely out of the simulator
(which isn't possible yet, but a lot of progress in that direction is
possible). i'm basically creating a local inventory tree in the file system
that looks a little like a blown out iar file. and then using my dispatcher
interface to interact with the scene. (the dispatcher is a transport
independent interface to the scene that communicates via json messages all
with authenticated access.) the inventory module can convert an object into
an asset and pull it off the simulator. then turn around and upload it to
the simulator prior to rezzing an object. that means that all my assets are
local & temp and only loaded into the simulator when i need them. and... the
inventory the viewer has to load is *much* smaller and a LOT faster. and i
get to use file system tools for managing it.

 

--mic

 

On Wed, Mar 13, 2013 at 8:39 PM, Dahlia Trimble 
wrote:

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
 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

 

___
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

[Mike Chase]

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 doubt I get a vote but if I did I'd vote to advance the API version of
.NET and pick up the new features therein.  Document the dependencies and
let people doing deployment sort out the environment that best meets their
requirements.  My 2 cents.

Mike

-Original Message-
From: opensim-dev-boun...@lists.berlios.de
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Justin
Clark-Casey
Sent: Monday, January 28, 2013 10:42 PM
To: opensim-dev@lists.berlios.de
Subject: [Opensim-dev] Raise minimum .net framework version to 4.0 and mono
version to 2.8 (with 2.10 strongly recommended) in 2Q2013

After some further investigation, it turns out that Mono 2.6 does not make
the higher parameter Func calls available unless it has been built in a
special preview mode.  This is not available on at least the Ubuntu Mono
package and I suspect most, if not all, of the other distro packages as
well.

Therefore, the minimum version of Mono that will use them is 2.8 (for which
C# 4.0 is the default).  Polling the earliest supported release versions of
various Linux distros, the situation is

Debian 6.0 (squeeze)Mono 2.6.7
Ubuntu 8.04 LTS Mono 1.2.6
Ubuntu 10.04 LTSMono 2.4
Ubuntu 11.10Mono 2.10.8.1
Ubuntu 12.04 LTSMono 2.10.8.1
openSUSE 11.4   Mono 2.8.2
openSUSE 12.1   Mono 2.10.6
CentOS 5no Mono package
CentOS 6no Mono package

I see Debian squeeze as the sticking point here.  Debian 7.0 (wheezy) will
ship Mono 2.10.8.1 and has been frozen since 2012-06-30.  Debian does not
work to release dates so it's impossible to say when it will be released,
though the indications are that it will be in the first half of this year.
Even when it is released, Debian squeeze will most probably be supported
until early 2014.

In light of this, I am going to recommend that we do not update the minimum
version of Mono until Debian wheezy is released.  We've already effectively
been living with this situation for a while so I don't think that a bit
longer is going to hurt, though making modInvoke() properly useable is
important.  If wheezy is not released by the time that OpenSimulator 0.7.6
is here, which I anticipate being shortly after Easter, then we can revisit
the topic.

This means that existing binary packages will continue to be compiled
against .NET 3.5 (though ironically the current 0.7.5-RC packages have been
compiled to work with Mono >2.8 only, which will be fixed for the final
release).

When the update occurs, everything will compile and run against Mono 2.8 but
Mono 2.10 will be strongly recommended as the Mono 2.8 series has proved
considerably buggy in the past.

Once the update is made, the target framework will be .net 4.0 rather than
.net 3.5.  This will allow c# 4.0 language features to be used and will
require the Microsoft .NET Framework 4 packages to be installed on Windows.

We've already heard arguments both ways so I doubt that it's worth rehashing
them.  However, I also think this would be a marginal decision so I welcome
any new points.

--
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
htt

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

[Mike Chase]

The crash is in mpfilter. I'd suspect malware or a virus.I doubt it has
anything to do with OpenSim except perhaps that opensim is busy doing stuff.
But the problem is likely elsewhere.

Mike

-Original Message-
From: opensim-dev-boun...@lists.berlios.de
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of R.Gunther
Sent: Sunday, July 29, 2012 10:50 AM
To: opensim-dev@lists.berlios.de
Subject: [Opensim-dev] Opensim and BSOD ??? (debuginfo added)

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 : `
00df`fd4cc640 f880`07bec2d0 f880`009b2180 : 
nt!KiBugCheckDispatch+0x69
f880`07bebab0 f800`02a78c7f : fa80`0141c100
f880`0002 fa80` `0002 : nt!KiPageFault+0x260
f880`07bebc40 f800`02a8e7ef : 00

Re: [Opensim-dev] Proposal: Implement a de-duplicating core ROBUST asset service

[Mike Chase]

On Fri, 2012-03-09 at 16:47 +0100, Bo wrote:
> Hello,
> allow me a few noob comments, please :
> 
> 1) worst thing you can have in a big table is a VERY variable row length.
> 2) systems like http://en.wikipedia.org/wiki/Google_File_System have very 
> good 
> performance and are perfectly scalable
> 3) you can have floatsam cache also on multiple disks (eg assets with 
> checksums starting at a-g) on one disk and so long
> 4) it is easy to BACKUP such a storage. For example you can use rsyncand 
> download only the new assets
> 5) it is easy to develop custom scalable solutions
> etc etc...
> 
> Have assets in the MySql is a fine solution for standalones and very small 
> grids. Please, don't change it, if you feel this as the only OS future..

Yeah...  If the focus of the core code out of the box is small sims and
standalones as Justin implied then even doing de-dup sounds like rather
a waste of time.  Better to validate the interface can handle a real
commercial grade asset server using something like NoSQL.  De-dup sounds
risky at best and probably not worth the cycles if your going to scale
and probably need to replicate data in a clustered configuration anyway.
Honestly there are other fish to fry as the saying goes. I'd leave this
one alone.

Mike


> Bo
> 
> On Friday 09 of March 2012 16:36:50 M.E. Verhagen wrote:
> > 2012/3/9 Wade Schuette 
> 
> > And as the opensim worlds are user generated worlds, lots of people do not
> > really care about things like small textures or small meshes.
> ___
> 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] Proposal: Implement a de-duplicating core ROBUST asset service

[Mike Chase]

On Fri, 2012-03-09 at 08:07 -0800, Diva Canto wrote:
> OpenSim has the backend storage as a plugin. As such, anyone can 
> implement their own storage backend however way they want -- files 
> systems, databases of several kinds, duplication, non-duplication, etc. 
> There can be many without that interfering with the rest of the components.
> 
> Justin at this moment is implementing yet another plugin option, 
> additionally to the existing ones.

Just a suggestion then, but given you have the architecture to support
it, maybe this sort of thing should be developed out of tree in the same
way that other 3rd party region modules would be developed rather than
bloat the already complex "framework" that *already* has many choices as
you also indicated.

Mike

> On 3/9/2012 7:47 AM, Bo wrote:
> > Hello,
> > allow me a few noob comments, please :
> >
> > 1) worst thing you can have in a big table is a VERY variable row length.
> > 2) systems like http://en.wikipedia.org/wiki/Google_File_System have very 
> > good
> > performance and are perfectly scalable
> > 3) you can have floatsam cache also on multiple disks (eg assets with
> > checksums starting at a-g) on one disk and so long
> > 4) it is easy to BACKUP such a storage. For example you can use rsyncand
> > download only the new assets
> > 5) it is easy to develop custom scalable solutions
> > etc etc...
> >
> > Have assets in the MySql is a fine solution for standalones and very small
> > grids. Please, don't change it, if you feel this as the only OS future..
> >
> > Bo
> >
> > On Friday 09 of March 2012 16:36:50 M.E. Verhagen wrote:
> >> 2012/3/9 Wade Schuette
> >> And as the opensim worlds are user generated worlds, lots of people do not
> >> really care about things like small textures or small meshes.
> > ___
> > 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] Roadmap To Beta

[Mike Chase]

On Thu, 2011-12-01 at 00:20 +0100, Akira Sonoda wrote:
> Hello everybody,
> 
> For three years i live in a OSgrid, the test grid for the
> OpenSimulator Software.
> 
> A small change in the calculation of avatar positioning for a given
> explicit sit target produced big headache among the content creators
> in OSgrid, because a lot of existing content in the grid has to be
> changed now. A lot of discussion was going on in world and all of the
> discussion ended with the conclusion: "This is alpha Software, you
> have to be prepared for such changes".
> 
> Therefore to mitigate the risk of such issues, the logical question
> is: Is there any road map to Beta?

Good luck with this.  I've been asking for some time.  The consensus
from the main project team members is this is alpha software and
therefore a roadmap is not appropriate. I'll add a +1 to your request
though I expect it will go nowhere.

Mike


___
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.

[Mike Chase]

On 11/07/2011 09:02 AM, David Kaplan wrote:
I whole-heartedly support this proposal in whatever the solution may 
be - regardless if it's an issue with the viewers or the server. I 
don't see that have larger textures will create appreciably 
significant performance issues because, much like web designers, 
people who are competent in building on OS are aware of bandwidth and 
optimization concerns when it comes file size. If they aren't, 
awareness will have be raised on this issue but I don't think a lack 
of awareness should impede creativity. OS has a lot of competing 
products out there (e.g., Unity, etc) and they all manage to do the 
job well while also allowing for robust textured graphics. I 
understand software like Unity is implemented differently but there is 
little reason why this issue should different.
There isn't really a proposal here, IMO.  As Nebadon said, its the 
client that decides what the maximum resolution is.   So you could hack 
an OpenSIM specific client to support larger sizes.  But which client to 
use is a user centric issue (unless you've constrained it for your 
grid).  And if you do hack a client and only allow connects from that 
client then you can of course use larger textures but at the expense of 
limiting access to your grid.  There's no "fix" required for OpenSIM here.


Mike



My two cent.

On 11/7/2011 12:06 AM, Nebadon Izumi wrote:

Lani

This is a viewer issue and not really an OpenSimulator issue per say, 
it would be better taken up with the viewer devs, there are really no 
limitations on the server side for that limit the size of any 
texture, in fact the viewer also has no problem displaying larger 
textures, i have several 2048x2048 texture in SL, i believe they were 
uploaded with a special LibOMV client back in the day before LL 
closed some holes.  Technically the only place that limits the size 
of the texture is when the viewer converts the image to a jp2 image 
before it sends it to OpenSimulator, if this can be modified then we 
could upload larger textures, though there may be some other good 
reasons we would not allow this, such as performance and such, the 
files could be quite large, and having to download lots of these 
large textures could really cripple things, we would need to do some 
tests to be sure, there may also be other difficulties involved for 
TPVs with the Terms of Service of secondlife and making such 
modifications to the viewers, this really needs to be taken up with 
the Viewer Developers to see what they think.


On Sun, Nov 6, 2011 at 9: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

Re: [Opensim-dev] Considerations regarding long term development

[Mike Chase]

On Thu, 2011-09-22 at 15:33 +0200, Melanie wrote:
> Hi,
> 
> at this time we are refactoring and consolidating and fixing bugs.
> Enhancements will almost always be in modules and fully optional, so
> using OpenSim as a basis for something else is viable.
> 
> Melanie

So, I have to ask..  This sounds like maintenance.  If so why is the
project still considered Alpha?  

Mike


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

Re: [Opensim-dev] The Overte Foundation for OpenSimulator

[Mike Chase]

On 06/29/2011 09:21 PM, Justin Clark-Casey wrote:

Dear all,

As I'm sure everybody on these lists is aware, OpenSimulator currently 
has some restrictions on who can contribute code to the project 
(http://opensimulator.org/wiki/Contributions_Policy).






In order to grant a copyright license there needs to be a receiving 
entity.  To this end, we are in the process of setting up an 
organisation known as the Overte Foundation.  The Overte Foundation 
will receive the copyright licenses and become the official 
distributor of OpenSimulator rather than individual core developers.  
This will put it in a good position to deal with code origin or other 
issues, if any should ever arise.


Once the CLA is complete, the current contribution restrictions to 
OpenSimulator will be removed.  It will be down to each developer 
(including core developers) to affirm via the CLA that they have the 
necessary rights over the code that they are contributing.


One advantage of going down the foundation route is that it will also 
be able to promote and support OpenSimulator in other ways, quite 
possibly incorporating members of the community other than just 
developers.  The foundation could also extend to cover other 
open-source virtual-environment/virtual-world projects and 
components.  In the short term, though, we will be concentrating on 
establishing the CLA.






I will be acting as the first Overte Foundation president, with Diva 
as treasurer, Melanie as secretary and Nebadon and Ben as initial 
board members.  The foundation itself will not directly control 
OpenSimulator development - this will remain with the OpenSimulator 
team and community as it does now.


Discussion about this is very welcome, whether supporting or 
critical.  I'm logging off now so will likely answer any points 
tomorrow.  Of course, other core developers are very welcome to chip in.


Best,

Justin and team, I think this is a great move and a good start.  There 
are a number of people who have been unable to contribute to the project 
and hopefully this will address this abiliity.


I would like to add that an excellent additional goal for the foundation 
would be to produce and maintain a roadmap for the elements under its 
care.  Perhaps even a process for how a project is included, how it 
moves between stages, etc.


For OpenSim itself I think the project has suffered a bit with the 
"perpetual alpha" status and discussion towards and the publishing of a 
roadmap that moves it out of that state and into some more mature state 
would be welcome personally by me.   Of course the work is still done by 
volunteers but if this move increases contribution level and the 
foundation leadership shares vision in the form of a roadmap you may 
find these new contributors willing to pitch in to make that vision a 
reality.


Those kinds of things of course take time.   But I'd hope they could be 
considered.  In the meantime congratulations on what I see personally as 
an excellent first step!


Mike

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

Re: [Opensim-dev] worldsize map scaling

[Mike Chase]

On 06/23/2011 12:55 AM, Jeroen van Veen wrote:

Maybe cut this limit finally out of the viewer? (and apparently out of the
server as well) It doesn't make much sense to me. I just got the lgpl viewer 2
standalone to build properly on my system. I'll try to narrow it down at the
viewer side. Maybe with some help it's possible to get this limit finally out
of the way.

Jeroen
Just be aware, unless a policy change got announced, if you modify or 
use the viewer source code you can't contribute to OpenSim.  This has 
kept me from making any substantive contributions for a long while...


Mike

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

Re: [Opensim-dev] [Opensim-users] Turning gravity on for one object [ Was: Phantom and Physical Prim (to Mantis or not) ]

[Mike Chase]

I'd expect if you could make a prim phantom *and* phsical it would
basically "fall off" the SIM. That is, since its affected by gravity but
does not register collisions nothing stops it from falling through the
ground. So I guess I still dont see a case where phantom *and* physical
make sense...

Mike

On Tue, 2011-05-17 at 20:53 +0200, drwh...@spacefriends.de wrote: 
> 
> Hi,
> 
> as Mike pointed out it is true that flexi prims can not be physical even in
> SL .. BUT
> for phantom prims it still must be possible to set them physical. Therefore
> i have just
> added following Mantis on this issue:
> http://opensimulator.org/mantis/view.php?id=5487
> 
> I also crosspost this to Opensim-Dev to get some GridGod/Developer attention
> .. Please
> PhysixxsGod(s) help us on this issue .. 
> 
> Best regards,
> and thank you Mike for clarifing (and Simon for asking and pushing me to
> file that Mantis) 
> 
> Wordfromthe Wise
> 
> 
> -Ursprüngliche Nachricht-
> Von: opensim-users-boun...@lists.berlios.de
> [mailto:opensim-users-boun...@lists.berlios.de] Im Auftrag von Mike Chase
> Gesendet: Dienstag, 17. Mai 2011 18:53
> An: opensim-us...@lists.berlios.de
> Betreff: Re: [Opensim-users] Turning gravity on for one object
> 
> I've already replied to a seperate message about this.  Flexi's are client
> side while physics (such as it is in OpenSIM) is managed in the simulator.
> This is consistent with SL which operates the same way. And as long as we're
> dependant on an SL viewer I expect it will stay that way.  
> 
> The Lightsource prim attribute works because its not tied into physics in
> any way. A physical object can still give off light.
> 
> Mike
> 
> 
> -Ursprüngliche Nachricht-
> Von: opensim-users-boun...@lists.berlios.de
> [mailto:opensim-users-boun...@lists.berlios.de] Im Auftrag von Mike Chase
> Gesendet: Dienstag, 17. Mai 2011 18:49
> An: opensim-us...@lists.berlios.de
> Betreff: Re: [Opensim-users] Turning gravity on for one object
> 
> Umm, this is completely consistent with SL.  A flexible object is always
> phantom and cannot be physical. Flexies are managed by the client whereas
> physical prims are managed in the simulator.   
> 
> If you creat a prim in SL and click on flexible path then it will be made
> phantom and physical is grey-ed out.  
> 
> It might be nice to have a combination like this but I think its outside the
> scope of whats possible with SL compatible viewers.
> 
> Mike
> 
> 
> -Ursprüngliche Nachricht-
> Von: opensim-users-boun...@lists.berlios.de
> [mailto:opensim-users-boun...@lists.berlios.de] Im Auftrag von Simon Slavin
> Gesendet: Dienstag, 17. Mai 2011 17:27
> An: opensim-us...@lists.berlios.de
> Betreff: Re: [Opensim-users] Turning gravity on for one object
> 
> That was it.  Thanks.  Also, if you do set them to be flexible it
> automatically makes them phantom.  Weird.
> 
> Simon.
> 
> 
> -Ursprüngliche Nachricht-
> Von: opensim-users-boun...@lists.berlios.de
> [mailto:opensim-users-boun...@lists.berlios.de] Im Auftrag von
> drwh...@spacefriends.de
> Gesendet: Dienstag, 17. Mai 2011 16:58
> An: opensim-us...@lists.berlios.de
> Betreff: Re: [Opensim-users] Turning gravity on for one object
> 
> Hi,
> 
> if you are talking about making objects physical, i have (bad news) for you.
> I ran into the same issue.
> 
> Currently physical objects in Opensim CAN NOT BE PHANTOM or FLEXIBLE
> 
> I have talked about this issue with JustinCC and, as this behaviour is
> different to SL, he suggest, i could/should file a MANTIS on this.
> 
> The 'flexible part' was just discovered by me some nights ago so i have not
> yet file a MANTIS , but i will do it withing the next hours (when i return
> home from work)
> 
> There are a lot of situations where you need a object to be phantom or
> flexible AND physical. In my case my tentacle creatures have to be moved by
> a movetotarget script as it looks much better than the llSetpos function.
> Also if physical objects hit each other the movetotarget stops working as it
> can not 'make its way' through non phantom objects around the region.
> 
> i will reply to this post when i filed the MANTIS, and please let me know if
> you where talking about physical objects by saying "i want gravity to effect
> it"
> 
> best regards
> Wordfromthe Wise
> 
> 
> 
> > -Ursprüngliche Nachricht-
> > Von: opensim-users-boun...@lists.berlios.de
> [mailto:opensim-users-boun...@lists.berlios.de] Im Auftrag von Simon Slavin
> > Gesendet: Dienstag, 17. Mai 2011 16:19
> > An: opensim-us...@lists.berlios.de
> > Betr

Re: [Opensim-dev] Running OpenSim in the background

[Mike Chase]

You'd think with all the service Robustification this would be done.
Other than the console there's no obvious reason you shouldn't be able
to start opensim as a background process.   I'd argued a while back for
an XMLRPC based "console" but that got shot down pretty quickly by a few
folks, though there were a few that liked the idea.   IMO the missing
piece is a replacement for the console that uses a secure-able protocol.
Then the "console" could be in  a seperate process and accessed when
needed rather than running all the time.

Given the long term rules about access to client sources and
restrictions on contributions I can't do this but it shouldn't be hard
to do.  Maybe consider this a feature request for a future release...

Mike

On Tue, 2011-05-10 at 14:55 +0200, Lino Figueroa wrote:
> Not so difficult.
> 
> For Linux only: "screen Opensim". You can install
> Opensim/ROBUST as "services" (Webmin has a good service manager).
> 
> Take a look at: http://opensimulator.org/wiki/Automating_Tasks
> 
> And for the screen command:
> http://www.mattcutts.com/blog/a-quick-tutorial-on-screen/
> 
> You can change between screens for accessing the opensim console.
> 
> 
> For windows... no idea, I don't use windows for servers, but I suppose
> that the screen command has been "migrated" for windows too
> (http://www.gnu.org/software/screen/)
> 
> MAC OSX... even less idea.
> 
> 
> 2011/5/10 James Stallings II 
> This is a very broad topic involving the use of named pipes,
> complex shell scripts wrapped around ps, etc. 
> 
> 
> It isn't something that will be readily covered in an email as
> it is more about how to use your operating system to cause
> programs to behave like services than it is anything
> specifically germane to opensim.
> 
> 
> It -is- doable though, I've done it in the past on a fairly
> massive scale (hundreds of simulators on the box). 
> 
> 
> Good luck :-) 
> 
> 
> James/Hiro 
> 
> 
> 
> On Tue, May 10, 2011 at 5:45 AM, Pi And Company
>  wrote:
> 
> Just wondering if it is possible to run OpenSim and
> Robust in the background so an SSH tunnel is not
> nessessary to run it. If so, how do i set it up. 
> 
> 
> Jason
> 
> 
> 
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
> 
> 
> 
> 
> -- 
> ===
> http://simhost.com http://osgrid.org
> http://twitter.com/jstallings2
> http://www.linkedin.com/pub/5/770/a49
> 
> 
> ___
> 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] ReactionGrid Inc. files for US Patent

[Mike Chase]

Reading them can also be a really bad idea.  I'd second the request to take
discussion of any patent that may exist off list. It doesn't belong here.

 

Mike

 

From: opensim-dev-boun...@lists.berlios.de
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Cristina Videira
Lopes
Sent: Wednesday, February 02, 2011 4:44 PM
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] ReactionGrid Inc. files for US Patent

 

PLEASE DO NOT POST LINKS TO PATENTS ON THIS LIST. 

 

On Feb 2, 2011, at 1:41 PM, Mark Malewski wrote:





 

> Seems like Mark is upset lol

 

Just sick and tired of people trying to make FALSE patent claims on
OpenSource software, and attempting to claim "inventions" based on
OpenSource software.

 

Just so they can begin suing others that use the software...

 

It's just absurd.

 

Absolutely no reason why non-profits, educational institutions, or others
should have to deal with "Reaction Grid" legal nonsense due to some FALSE
patent claims (based on ignorant marketing nonsense written by Microsoft,
who probably never even heard of OpenSim prior to two or three fools asking
Microsoft for "help" because they're too stupid to setup their own Microsoft
2008 Server, or use Hyper-V.

 

 

 

On Wed, Feb 2, 2011 at 3:38 PM, Jor3l Boa  wrote:

Seems like Mark is upset lol

2011/2/2 Mark Malewski 

 

Does anyone actually have the Patent number?

 

 

 

On Wed, Feb 2, 2011 at 3:34 PM, Mark Malewski 
wrote:

Regardless, it's just another false claim.  Just like the silly IBM patent
claim about using LDAP with OpenSim.

 

This is just another false patent claim, attempting to make a false claim
that they "invented" using virtualization with OpenSim.

 

Completely absurd...

 

Mark

 

On Wed, Feb 2, 2011 at 3:31 PM, Melanie  wrote:

It really contains no useful information. However, it looks like
this is a "Business method patent" which will not be recognized
outside the US even if granted.

Melanie


Marcus Alexander Link wrote:
> Sorry, that was the wrong link. Here ist the correct one:
>
>
http://reactiongrid.blogspot.com/2011/02/reactiongrid-inc-files-for-us-paten
t.html
>
> Regards, Marcus
>
> On Wed, Feb 2, 2011 at 10:24 PM, Michael Cerquoni 
wrote:
>> This article seems to make no mention of a Patent filing.  The word
Patent
>> is not mentioned even once.
>>
>> On Wed, Feb 2, 2011 at 2:13 PM, Marcus Alexander Link

>> wrote:
>>>
>>> Hi everyone,
>>>
>>> just saw this posting. Thx to Pathfinder.
>>>
>>>
http://www.microsoft.com/casestudies/Case_Study_Detail.aspx?CaseStudyID=4000
004150
>>>
>>> Regards,
>>> Marcus
>>> ___
>>> 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



___
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] Serving textures in different formats

[Mike Chase]

On 12/08/2010 10: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.


Personally I prefer neither.  Doing format conversions on the client 
(rather than the server where the overhead affects all the users) seems 
more appropriate to me.  IMO standardizing on a single format from the 
server and then letting the client do a format conversion where thats 
necessary is the better solution.  Alternatively you could push the 
conversion off to a separate service. But again, that implies the core 
code doesn't need to address it.


Just my 2 cents.

Mike


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