Re: [Opensim-dev] Which revision is OpenMetaverse.StructuredData.dll now?
It would have been trunk at the time of commit. I asked John to add a feature in, and he did then updated it. Regards, Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Justin Clark-Casey Sent: Wednesday, 18 August 2010 3:38 PM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Which revision is OpenMetaverse.StructuredData.dll now? On 18/08/10 23:28, Michael Cerquoni wrote: heh dont you think after all this time and like sooo many times we have never been able to figure out what version of libomv we are using that we should add a file into the project that has libomv history? or atleast the revision thats included? maybe just a text file or something.. anyway something to think about.. it just seems like this is always a problem. Nah, people just wouldn't update the file :). I think the easiest thing is just to record the revision in the commit. Easy to forget, though. On Wed, Aug 18, 2010 at 3:19 PM, Justin Clark-Casey jjusti...@googlemail.com mailto:jjusti...@googlemail.com wrote: Hi John. For the record, which version or revision of libomv was used for this library update? Thanks. On 17/08/10 20:26, opensim-commits-boun...@lists.berlios.de mailto:opensim-commits-boun...@lists.berlios.de wrote: The branch, master has been updated via e1f2c32 * Updated to OpenMetaverse.StructuredData.dll that includes implicit typecasts going in the other direction from 53190e3 Updated to new OpenMetaverse.StructuredData.dll that includes implicit typecasts Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit e1f2c32284b38bc1116239bc0c8d2d5010214449 Author: John Hurlimanjohn.hurli...@intel.com mailto:john.hurli...@intel.com Date: Tue Aug 17 12:26:20 2010 -0700 * Updated to OpenMetaverse.StructuredData.dll that includes implicit typecasts going in the other direction e1f2c32284b38bc1116239bc0c8d2d5010214449 diff --git a/bin/OpenMetaverse.StructuredData.dll b/bin/OpenMetaverse.StructuredData.dll index 1c55e2c..54681e4 100644 Binary files a/bin/OpenMetaverse.StructuredData.dll and b/bin/OpenMetaverse.StructuredData.dll differ - -- Summary of changes: bin/OpenMetaverse.StructuredData.dll | Bin 102400 - 102400 bytes 1 files changed, 0 insertions(+), 0 deletions(-) ___ Opensim-commits mailing list opensim-comm...@lists.berlios.de mailto:opensim-comm...@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-commits -- Justin Clark-Casey (justincc) http://justincc.org http://twitter.com/justincc ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de mailto:Opensim- d...@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 -- Justin Clark-Casey (justincc) 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] LL Viewer code license change
It'll have to be all LGPL if parts of it are - since the GPL wont accept redistribution of a mix of LGPL and GPL - only pure GPL. Check the post on sldev about it - it looks to me from that one that the intention is for it all to be LGPL. Adam From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Dahlia Trimble Sent: Tuesday, 17 August 2010 3:53 AM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] LL Viewer code license change On Tue, Aug 17, 2010 at 2:36 AM, Ai Austin ai.ai.aus...@gmail.commailto:ai.ai.aus...@gmail.com wrote: From: Justin Clark-Casey jjusti...@googlemail.commailto:jjusti...@googlemail.com As regards to OpenSim contributions, I doubt that the viewer license change to LGPL will make any difference. LGPL just makes it possible to link non-GPL code to the viewer code. The viewer co de itself is still virally licensed. Justin, where did you get this information? Its not the way it was presented at SLCC (I watched the entire announcement and read the postings afterwards by LL). So, its not the way I read it, but we need to check. They even amended the licence from GPL to LGPL for a lot of the top level parts of the viewer source code as I examined some of the key commitdiffs. for a lot of the top level parts? Not the entire code base? I'm curious which parts are now LGPL and which are not, and if not, what license they are under? ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] JSON or XML for serialization in the OpenSim database?
Having just worked on a JSON project myself internally - I personally developed a bit of a loathing for the format. I'm personally partial to XML, ideally with a corresponding DTD. Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Teravus Ovares Sent: Monday, 5 July 2010 4:23 PM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] JSON or XML for serialization in the OpenSim database? Not a whole lot of feedback here yet, maybe people are on a long weekend type camping vacation.. I'm partial to OSD/json, myself.I'd also like to, at some point, get a version number in there along with a definition of the format for people who want to write integration tools..however, that last bit may be more of a 1.0 thing. I think a lot of tools are going to go the way of JavaScript in the future for various reasons... one being that.. it's generally implemented in all web enabled devices. Computers, 'tablets', 'smart phones'... Another reason is it's more compact, while still being fairly human readable. One last reason that I can think of at this moment is there are no external dependencies that 'get lost and turn into a 404', like with XML Schemas. I've done several XML based integrations using REST and noted that in 55% of the cases, the defining schema is a 404 which makes validation and automatic creation of XML Serialization classes impossible. Worse, in 15% of the cases, extensions are defined in the schema and then used in the XML.. Only, you won't ever know what tags and parameters the extensions provide because the schema is 'missing'. Regards Teravus On Sun, Jul 4, 2010 at 8:28 PM, Justin Clark-Casey jjusti...@gmail.com wrote: Hi folks, As part of the media-on-a-prim implementation, I'm serializing the parameters for a media texture to the database. This seems better than creating new database fields or even a whole new table for these parameters, both because there are lots of them (url, scaling, controls, whitelist, etc.) and because different future virtual environments may want to store different things. I'm going to serialize them as an OSDArray or MediaEntrys using the libopenmetaverse library. However, the question then becomes whether to use the JSON representation or the XML representation. I tend to prefer XML for storage representations. I believe that it's somewhat more human readable and that there is better tool support for manipulating it. However, I know other people would prefer storage in JSON and I accept that serialization/deserialization there may be slightly faster. The only other example of serialization that I know of in OpenSim currently is that of SceneObjectGroups into inventory, which encompasses object properties, object inventory properties and script state. This is done in XML and media entries would become part of that serialization. If there's a majority preference for JSON I don't mind using that instead, though I would want a justification for going this route rather than XML. If there's no real argument then I will go with XML. Also, I believe that we should try and be consistent, so picking one or the other now should make it more likely that the same approach would be used for the next serialization case. Regards, -- Justin Clark-Casey (justincc) 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] request change for contributor agreement
Hi Rob, I suspect the principles which allow the 6 month rule probably also allow an exemption to that rule (I would be surprised if they didn't.); but I would want to hear from legal advice before we could make any adjustments to the contributor agreement. Regards, Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Robert A. Knop Jr. Sent: Wednesday, 30 June 2010 8:46 PM To: opensim-dev@lists.berlios.de Subject: [Opensim-dev] request change for contributor agreement It is my hope in the next 6-9 months to be in a position where I'll be able to start making real contributions to OpenSim. There are some things I have to work out -- I have to make sure that the IP policies of the Unviersity where I'm going won't create problems. However, there's another issue: You have not witnessed, seen or been party to the development of the official Linden Lab Server Software. If you have been involved in the official server development your contributions may affect the licensing of the main codebase and we cannot accept the contributions without a waiver from Linden Lab disclaiming any interest in your contributions. Of course, I did see a bunch of that, way back when. The part that I actively worked on myself was something that has no analog in OpenSim (the region conductor, which dealt with figuring out which servers ran which regions). And, it's been more than a year -- will likely have been more than 18 months by the time I'm in a position where I'll be able to start making contributions. Six or eight months ago, I made some preliminary investigations into getting this sort of waiver, asking somebody who was most likely to be sympathetic to the need for it, and indications are that such a waiver is probably very difficult to get. I honestly do not believe that Linden would want to sign such a thing. However, I also don't think that they should have to. It's been long enough since I had access to that code that there's no practical way I can steal any of it at this point. Would it be possible to have some sort of timeout (say, 18 months) added to this clause in the contributor agreement? If that can't be done, then if I want to work on OpenSim I'm effectively going to have to make my own fork of it. I know I'll want to be working on things related to the Physics engine, and it would be sad to me if I were not able to contribute what I did back to core OpenSim. It would greatly undermine the value of what I hope to be able to do in the future. -- --Rob Knop E-mail:rk...@pobox.com Home Page: http://www.pobox.com/~rknop/ Blog: http://www.sonic.net/~rknop/blog/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] SOG refactoring?
Thanks Diva for digging that out - the plan hasn't changed from that document and the subsequent mailing list discussion (which follows that thread) Adam From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Cristina Videira Lopes Sent: Monday, 14 June 2010 3:46 PM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] SOG refactoring? This concerns some internals of the simulator itself. When Adam is done with this, not much will be immediately visible to users. But it will allow OpenSim to play well with viewers that have completely different ways of representing of 3D objects (e.g. meshes). http://lists.berlios.de/pipermail/opensim-dev/2009-December/008098.html On Jun 14, 2010, at 1:27 PM, Karen Palen wrote: How about a summary for us confused peasants? Karen On Mon, Jun 14, 2010 at 9:03 AM, d...@metaverseink.commailto:d...@metaverseink.com wrote: Hey Adam, That's great news! We were talking about it yesterday in the IRC; SOG reconceptualization seems like a daunting task, but it's very much needed. It looks like you already have something going. Would it be possible that you make that work in a public branch, so that we all get psychologically conditioned for what's coming? Thanks, Crista Frisby, Adam wrote: Hey Diva, Yep, I saw .7 get tagged - I'll be working pretty much to the original plan. Although I've got a lot of the groundwork already done, so this shouldn't take as long as the ROBUST/.69/7 work. I'll make up a small plan and post it here tomorrow. Regards, Adam -Original Message- From: opensim-dev-boun...@lists.berlios.demailto:opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-mailto:opensim-dev- boun...@lists.berlios.demailto:boun...@lists.berlios.de] On Behalf Of d...@metaverseink.commailto:d...@metaverseink.com Sent: Sunday, 13 June 2010 9:58 PM To: opensim-dev@lists.berlios.demailto:opensim-dev@lists.berlios.de Subject: [Opensim-dev] SOG refactoring? Hey Adam, What is the plan for the SOG refactoring that you nicely outlined here a few months ago? 0.7 is about to be tagged, we need some other massive change to keep trunk unstable :-) Diva / Crista ___ Opensim-dev mailing list Opensim-dev@lists.berlios.demailto:Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.demailto: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] SOG refactoring?
Hey Diva, Yep, I saw .7 get tagged - I'll be working pretty much to the original plan. Although I've got a lot of the groundwork already done, so this shouldn't take as long as the ROBUST/.69/7 work. I'll make up a small plan and post it here tomorrow. Regards, Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of d...@metaverseink.com Sent: Sunday, 13 June 2010 9:58 PM To: opensim-dev@lists.berlios.de Subject: [Opensim-dev] SOG refactoring? Hey Adam, What is the plan for the SOG refactoring that you nicely outlined here a few months ago? 0.7 is about to be tagged, we need some other massive change to keep trunk unstable :-) 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] SOG refactoring?
Yep - look for the sogrefactor branch. I'll be committing in there over the next week; until components are ready -- at which point, some of the more dramatic changes will be on the cards. Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of d...@metaverseink.com Sent: Monday, 14 June 2010 9:04 AM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] SOG refactoring? Hey Adam, That's great news! We were talking about it yesterday in the IRC; SOG reconceptualization seems like a daunting task, but it's very much needed. It looks like you already have something going. Would it be possible that you make that work in a public branch, so that we all get psychologically conditioned for what's coming? Thanks, Crista Frisby, Adam wrote: Hey Diva, Yep, I saw .7 get tagged - I'll be working pretty much to the original plan. Although I've got a lot of the groundwork already done, so this shouldn't take as long as the ROBUST/.69/7 work. I'll make up a small plan and post it here tomorrow. Regards, Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of d...@metaverseink.com Sent: Sunday, 13 June 2010 9:58 PM To: opensim-dev@lists.berlios.de Subject: [Opensim-dev] SOG refactoring? Hey Adam, What is the plan for the SOG refactoring that you nicely outlined here a few months ago? 0.7 is about to be tagged, we need some other massive change to keep trunk unstable :-) 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 ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] merge has happened
Is it now safe to tag off the object-refactor branch? Regards, Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of d...@metaverseink.com Sent: Monday, 1 March 2010 10:37 PM To: opensim-dev@lists.berlios.de Subject: [Opensim-dev] merge has happened News! Melanie tagged 0.6.9 from master with corresponding 0.6.9-post-fixes now waiting for improvements. Testers wanted for 0.6.9-post-fixes. The presence-refactor branch has been merged onto master, which is now pre-0.7. Anyone trying the master branch, please be aware of the architectural changes that happened: http://opensimulator.org/wiki/ROBUST#An_Example_Conversion_From_URM_To_ R The usual warning: don't use the master branch for anything that is vaguely similar to a production grid. We have been tagging releases for a reason... ___ 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] Status of presence refactor?
Very cool! Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of d...@metaverseink.com Sent: Sunday, 21 February 2010 9:43 AM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Status of presence refactor? News: the SQLite connector is done and working in the presence-refactor branch. UserAccount data is automatically migrated into the new table. People using SQLite-powered OpenSims will have to reset the passwords manually before they are able to login (with console command reset user password). This does not affect MySql-powered opensims, only SQLite. Hopefully Melanie_t will finish Friends today. We'll be ready to merge any time now. Frisby, Adam wrote: I would like to start the SOP refactor fairly soon - what if once 0.7 is tagged for the RC process; I go and and make a new branch; we can sic testers on the presence-branch, while dev happens on the branch I tag? Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Justin Clark-Casey Sent: Friday, 19 February 2010 3:25 PM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Status of presence refactor? Melanie wrote: I would not like to see the refactor start in the branch, because that would postpone a merge indefinitely. Yes, please whatever happens, do not start any sog refactoring in Master until presence-refactor has been merged and we've started a branch for 0.7. In fact, when presence-refactor is merged with Master I think that we should wait at least 2 weeks before branching for 0.7 in order for all active developers to iron out any significant bugs associated with the merge. At a minimum, the 0.7 branch itself would be subject to the same release candidate and bug triage procedure as was 0.6.8. Only after this would 0.7 be tagged. I think that this is the very minimum we need to do in order to be a credible project. This would also give us an opportunity to get the documentation into a shape where at least super-intelligent pandimensional mice can understand it :) At the same time as 0.7 is branched, I also think that it would be prudent to branch for a potential 0.7.0.1. If all goes well with the sog refactor this will never see the light of day. But I think we should give ourselves a means of working with the old sog code in case the refactor encounters trouble. The sog refactor is far from trivial. However, the refactor caould be started in a NEW branch that is based off the current presence-refactor. The friends and SQLite functionality could be merged back to that new branch when they are completed. Git allows this easily. That sounds like a good idea. Melanie d...@metaverseink.com wrote: I could, but I'm hesitant to make diva distro releases from branches that aren't the master branch. Plus, so far the differences between the two branches are purely internal; there is no functional difference, or new bug fixes, or anything like that. The new architecture will allow for lots of exciting things to happen, but, again, I'm hesitant in making them happen in the branch. I'd rather merge this to master. Robert Martin wrote: On Thu, Feb 18, 2010 at 10:15 AM, d...@metaverseink.com wrote: Sigh. It's ready. It's been fully operational for several weeks, modulo buglets. It hasn't been merged because the SQLite connector hasn't been redone and at least Melanie doesn't want to merge without it. could you release a copy of Diva with the updated code (since Diva of course does not use SQlite)? ___ 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 -- Justin Clark-Casey (justincc) 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] Status of presence refactor?
I would like to start the SOP refactor fairly soon - what if once 0.7 is tagged for the RC process; I go and and make a new branch; we can sic testers on the presence-branch, while dev happens on the branch I tag? Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Justin Clark-Casey Sent: Friday, 19 February 2010 3:25 PM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Status of presence refactor? Melanie wrote: I would not like to see the refactor start in the branch, because that would postpone a merge indefinitely. Yes, please whatever happens, do not start any sog refactoring in Master until presence-refactor has been merged and we've started a branch for 0.7. In fact, when presence-refactor is merged with Master I think that we should wait at least 2 weeks before branching for 0.7 in order for all active developers to iron out any significant bugs associated with the merge. At a minimum, the 0.7 branch itself would be subject to the same release candidate and bug triage procedure as was 0.6.8. Only after this would 0.7 be tagged. I think that this is the very minimum we need to do in order to be a credible project. This would also give us an opportunity to get the documentation into a shape where at least super-intelligent pandimensional mice can understand it :) At the same time as 0.7 is branched, I also think that it would be prudent to branch for a potential 0.7.0.1. If all goes well with the sog refactor this will never see the light of day. But I think we should give ourselves a means of working with the old sog code in case the refactor encounters trouble. The sog refactor is far from trivial. However, the refactor caould be started in a NEW branch that is based off the current presence-refactor. The friends and SQLite functionality could be merged back to that new branch when they are completed. Git allows this easily. That sounds like a good idea. Melanie d...@metaverseink.com wrote: I could, but I'm hesitant to make diva distro releases from branches that aren't the master branch. Plus, so far the differences between the two branches are purely internal; there is no functional difference, or new bug fixes, or anything like that. The new architecture will allow for lots of exciting things to happen, but, again, I'm hesitant in making them happen in the branch. I'd rather merge this to master. Robert Martin wrote: On Thu, Feb 18, 2010 at 10:15 AM, d...@metaverseink.com wrote: Sigh. It's ready. It's been fully operational for several weeks, modulo buglets. It hasn't been merged because the SQLite connector hasn't been redone and at least Melanie doesn't want to merge without it. could you release a copy of Diva with the updated code (since Diva of course does not use SQlite)? ___ 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 -- Justin Clark-Casey (justincc) 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] Status of presence refactor?
Does anyone know what is the current status of the presence refactor - is there any date on when that is going to hit trunk? I'd really like to see 0.7 get tagged soon, so we can begin the big object model refactor. Thanks! Adam ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] How to retreive pictures from the inventory ?
It's a JPEG2000 image, Bitmap doesn't support J2C. There's a Utility method for
converting to a Bitmap however. (not sure what it is)
Regards,
Adam
From: opensim-dev-boun...@lists.berlios.de
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Valentin Castan
Sent: Wednesday, 17 February 2010 8:26 AM
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] How to retreive pictures from the inventory ?
Thanks for your help, but I still have a problem, and I don't really know whats
wrong. This is my code :
AssetBase asset = scene.AssetService.Get(item.AssetID.ToString());
byte[] byteArray = asset.Data;
using (MemoryStream ms = new MemoryStream(byteArray))
{
Bitmap img = (Bitmap)Image.FromStream(ms); -
error, parameter is not valid
}
It seems that my MemoryStream is not valid, and I think it's because the byte
array is not correct to convert to Image. But the object I retreive is an
image, so I don't understand what's wrong. OpenSim does modification of this
array ?
Thank you a lot,
Valentin
On Wed, Feb 17, 2010 at 1:45 AM, Alan M Webb
alan_w...@us.ibm.commailto:alan_w...@us.ibm.com wrote:
Hi Valentin
If you look at the Rest application plug-in, it supports the retrieval and
uploading of inventory data, both catalog data and the assets themselves.
Best regards
Alan
---
T.J. Watson Research Center, Hawthorne, NY
1-914-784-7286
alan_w...@us.ibm.commailto:alan_w...@us.ibm.com
From:
Valentin Castan valentin.cas...@gmail.commailto:valentin.cas...@gmail.com
To:
opensim-dev@lists.berlios.demailto:opensim-dev@lists.berlios.de
Date:
02/15/2010 02:16 AM
Subject:
[Opensim-dev] How to retreive pictures from the inventory ?
Dear all,
I'm working on a project where I have to process images, using another
application, and then display something in OpenSim. I would like to let users
to upload their pictures on OpenSim, but I have to retreive these pictures, and
copy them in a special directory.
My problem is in the code of OpenSim, I only can find how to retreive an
InventoryItemBase from the inventory, but I didn't find any way to retreive a
picture, to be able to copy it.
Does someone know how can I retreive pictures from the Inventory, but not as an
InventoryItemBase, but as something I can use as a picture ?
Thank you a lot for your help,
Best regards,
Valentin Castan___
Opensim-dev mailing list
Opensim-dev@lists.berlios.demailto:Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.demailto: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 Was OpenSim Born?
I think it's probably missing some of the really ancient history, eg: Mid-2006: Me/JH work out chunks of the SL protocol from Ethereal dumps ... then we were told by another outside-of-SL [Rade someone?] developer that SL has its entire protocol stored in a file called 'message_template.dat' which is just a .txt file xor'd 0x43. Slightly later: We (mostly JH) write a basic client in C++ using BOOST. ... which turned out to be a complete unmitigated mess of thread crashes ... Then take 2 is written in C#/.NET and gets a lot further, a lot faster. Jan 17th-ish 2007: Darren/MW writes a simple server using libsl as the base; a lot of it is based on 'repeating' captured packet dumps in response to situations. Jan 2Xth 2007: LL releases the client code Jan 25-9th: MW releases his server emulator onto one of the forums, me a few others are intrigued. Feb?: MW/lbsa/Gareth/me are the first committers Feb-July: We rewrite the code from scratch at least 4 times. ... settling on '0.2' which forms the basis of a lot of the current architecture ... July: SDague from IBM gets signoff to start committing code to OpenSim. ... *stuff happens* ... Today. Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Justin Clark-Casey Sent: Thursday, 11 February 2010 2:41 PM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] How Was OpenSim Born? Len Brown wrote: Hello everyone! I know that the various versions of the viewer are derived from Linden Lab releasing the viewer source code as open source, but what about the server side of things? Is what we now call OpenSim the result of taking what we know about the viewer and working backwards to how we presume the server pushes the information to it? This would be my guess. I don't ever recall there being any releases of the early server source code ever made available. This thought hit me when I started wondering how Open Simulator originated if the Linden Lab server source was never made publicly available. The Open Simulator site dist directory goes back to OpenSim 0.4 so I'm a bit mystified. I started messing with OpenSim at version 0.6 and on. Thanks for any info offered on this topic. I've been active in Second Life since December 2003 and am just wanting to flesh out a bit of the historical side of things, when it comes to OpenSim beginnings. Len, have you seen this OpenSim history wiki page? http://opensimulator.org/wiki/History If you dig up any extra information it would be very welcome on there too. -- Justin Clark-Casey (justincc) 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] personal plea on patents
Guys, I've said this before. DO NOT POST PATENTS ON THIS MAILING LIST. AVOID LOOKING AT THEM IF POSSIBLE. Everyone who looks at them is now liable for wilful infringement if they submit code around that area after looking at it. Regards, Adam From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Mark Malewski Sent: Wednesday, 3 February 2010 1:09 PM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] personal plea on patents What exactly is going on? Did someone apply for a patent? Are ANY patents pending? If so, please let us know what patents are currently pending, so we can at least look them over and contest them. I've had virtual worlds running since 1991, with 3D shopping malls, online e-commerce, etc. I'd really like to see if anyone is currently attempting to put a patent through, so we can at least work on contesting/disputing the validity of any pending patents. Software patents are a bad idea, and it really hurts the creativity/innovation and development of 3D platforms. If anyone is aware of ANY pending patents, please let me know and please post the pending patent numbers to this forum. I'd be interested in working with legal counsel to dispute the validity of any pending patents, or at least begin work on shooting the patents down before they are approved. It's much easier to shoot them down (before they get approved), so please post any information that you may have about any pending patents. Are you referring to the patent that was filed by IBM? http://www.freepatentsonline.com/20090300582.pdf Is this the patent we are talking about? There are only THREE types of patents (Design, Utility, and Plant). I'm assuming that we're talking about Design patents, and in order for a patent to be valid it must be a NEW, or ORIGINAL idea. Design patents may be granted to anyone who invents a new, ORIGINAL, and ornamental design for an article of manufacture; and There is nothing new, and nothing original. If IBM is looking to use the OpenSim Infrastructure as a basis for their patent, or even attempting to claim that the things we discuss (or implement/plan/roll out/develop) are part of IBM's design then it's certainly not new, or original. I doubt that the patent application is valid, and I'll need to skim over their patent application, and see if we need to work on appealing the patent application. Companies attempt to file patents (on other people's ideas) simply as a way to make money (by litigation) in hopes to stifle innovation, development, creativity and an attempt to kill off any competition. As far as IBM's patent idea, it doesn't hold any water. It's not new, and it's not original. I'd developed platforms identical to that as early as 1991. I'd been doing synchronization of offline 3D virtual content for 3D shoppings malls since 1991 and developed a platform for the U.S. Army's Battlefield Visualization program using synchronization of offline content (for 3D Battlefield Visualization) as early as 1994. Even civilian projects like Active Worlds had been doing that (as part of their browser cache) as early as 1995/1996 (about 5+ years after work that I had done). So I hardly believe that IBM's silly patent application really holds much water. I'm willing to file an opposition to IBM's patent, if there are any other pending patent applications out there, then please let me know. I'd be more than happy to help nip this in the butt before some silly greedy business manager (or company) attempts to try and file a patent and kill off the creativity, innovation, and development of 3D platforms. James, I completely agree with your post, and we really do need to work on contesting this patent (if we're referring to the pending IBM patent). Prior art and prior work is there. There is nothing new or unique in IBM's pending patent application (if that is what this whole discussion is about). If there are ANY pending patents out there, please post the patent application numbers here in this forum, and we'll begin to address the issues (legally). I'd rather bring this silly patent nonsense to an end now, before this gets out of hand. Looks like IBM is attempting to do a smash and grab by filling out a silly patent application to try and hinder widespread use, or development of advanced 3D platform. It seems that managers ride on the coat tails of others and then attempt to go for the get rich quick by grabbing the IP quicker routine. This is nothing but hogwash, and it's really sad to see companies (and individuals) that stoop to this kind of level. Mark On Wed, Feb 3, 2010 at 2:05 PM, James Stallings II james.stalli...@gmail.commailto:james.stalli...@gmail.com wrote: Some history may be in order here; I wont drag you through each and every phase of virtual world development, but I can tell you that googling 'virtual worlds' turns up prior art
Re: [Opensim-dev] Refactoring status (take 2)
Are the database schemas now defined? (I wanted to know this before I begun the process of updating the OSgrid Elgg to use the new schema, ditto Gridmix). Regards, Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of d...@metaverseink.com Sent: Tuesday, 19 January 2010 6:59 PM To: opensim-dev@lists.berlios.de Subject: [Opensim-dev] Refactoring status (take 2) An FYI on the progress of the presence-refactor branch. Everything has been rewritten in the new style, and things are working. The branch has been in testing for the past week, and it's nice to see some people not being afraid to check that branch out and have a go at it. The merge with master hasn't happened yet, because of two and a half outstanding issues: (1) the friends feature hasn't been redone, therefore friends don't work in the branch yet; (2) SQLite, same; (0.5) HG is still in the process of being redone, it doesn't completely work in the branch yet. HG is only 0.5-an-issue because I don't hold the merge back on account of HG not working, and I don't think anyone does either; it can be fixed after the merge and before 0.7 is tagged. However, the other two, especially SQLite, seem to worry people a lot, including Melanie who wants to take care of it before the merge happens. For now, it would be great if people who can do it on their own, check the branch out and test things (on test DBs only please!). If anyone is in a hurry, help with SQLite and Friends would be most welcome, so that we get the merge done sooner. Melanie probably won't do it before next week. 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
Re: [Opensim-dev] Refactoring status (take 2)
Any idea on when the final state will be done? Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Melanie Sent: Tuesday, 19 January 2010 7:17 PM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Refactoring status (take 2) Almost there. There may be some HG related changed needed, but they will likely just be additional fields. Melanie Frisby, Adam wrote: Are the database schemas now defined? (I wanted to know this before I begun the process of updating the OSgrid Elgg to use the new schema, ditto Gridmix). Regards, Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of d...@metaverseink.com Sent: Tuesday, 19 January 2010 6:59 PM To: opensim-dev@lists.berlios.de Subject: [Opensim-dev] Refactoring status (take 2) An FYI on the progress of the presence-refactor branch. Everything has been rewritten in the new style, and things are working. The branch has been in testing for the past week, and it's nice to see some people not being afraid to check that branch out and have a go at it. The merge with master hasn't happened yet, because of two and a half outstanding issues: (1) the friends feature hasn't been redone, therefore friends don't work in the branch yet; (2) SQLite, same; (0.5) HG is still in the process of being redone, it doesn't completely work in the branch yet. HG is only 0.5-an-issue because I don't hold the merge back on account of HG not working, and I don't think anyone does either; it can be fixed after the merge and before 0.7 is tagged. However, the other two, especially SQLite, seem to worry people a lot, including Melanie who wants to take care of it before the merge happens. For now, it would be great if people who can do it on their own, check the branch out and test things (on test DBs only please!). If anyone is in a hurry, help with SQLite and Friends would be most welcome, so that we get the merge done sooner. Melanie probably won't do it before next week. 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 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] Refactoring SceneObjectGroup - Introducing Components
It's in the PDF attached to the original post - basically we merge SceneObjectGroup+Part together; then make it possible to chain them directly. IE: SceneObject.Parent SceneObject.Children[] Then you can represent hierarchies by making a group a parent of another group. Adam From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Morgaine Sent: Saturday, 19 December 2009 12:36 AM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Refactoring SceneObjectGroup - Introducing Components On Fri, Dec 11, 2009 at 11:47 AM, Frisby, Adam a...@deepthink.com.aumailto:a...@deepthink.com.au wrote: * Enable full inheritance linking (ie, hierarchical linking) This is terrific news, Adam! There's a bunch of us who have been hierarchical object activists in SL for some years, regularly trying to get the benefits of hierarchical objects across to Linden developers at their Office Hours. We have a wiki page on Prim and Object Hierarchyhttps://wiki.secondlife.com/wiki/Prim_and_Object_Hierarchy , and a number of Jiras also address the issue, including MISC-428http://jira.secondlife.com/browse/MISC-428, MISC-1434http://jira.secondlife.com/browse/MISC-1434, and MISC-2237http://jira.secondlife.com/browse/MISC-2237. We've been successful on the principle (several LL devs now support it wholeheartedly) but not in practice, because the development process within the Labs appears to be quite logjammed and stifled so that individual developer opinion has no effect. As noted on the wiki page above though, Lindens know that they made a mistake in not supporting object hierarchy. They just can't do anything about it now. Hierarchical objects provide many different types of benefit, so you'll hear different people advocate different aspects about them, but they're all complementary. My angle stems from the needs of pure engineering, in that hierarchical object composition is the basis of all engineered products in RL. Almost everything in modern life is manufactured by putting together complex components, not from raw materials, and that's how you ride on the shoulders of giants. You can't do that in SL. It's wonderful to see hierarchical objects finally gaining in profile in Opensim. Is there a design for this? We've been examining the pro's and con's of various approaches, including evolutionary ones that extend the current very poor linkset paradigm, as well as new designs that either encapsulate linksets transparently or else create a completely new and separate hierarchical object system in parallel with the current non-hierarchical one. Each approach has its own advantages and disadvantages. More info on your current thinking would be very welcome. Designs tend to stick around for longer than planned, and getting it partially right from the start would be a good idea. Morgaine. == On Fri, Dec 11, 2009 at 11:47 AM, Frisby, Adam a...@deepthink.com.aumailto:a...@deepthink.com.au wrote: Hi Folks, I've got a fairly complicated proposal to deliver here today - the short of it is; I'd like to go ahead and replace the current Scene Object representation model - at a fairly comprehensive complete level. Some of you have had the misfortune of working with SceneObjectPart/SceneObjectGroup and should understand what I am talking about. There are several stages to this proposal - but I would like to talk about today the first big one (and a small outline of the larger project - the reason for this being some of the later details require a little more nutting out before I have a complete proposal for them). So - the larger proposal in a nutshell; I would like to: * Merge SceneObjectGroup SceneObjectPart * Enable full inheritance linking (ie, hierarchical linking) * Make programming with SceneObjects possible reasonable from the outside (ie have a clean API). * Provide the ability to extend SceneObjects with components to introduce new properties and behaviours. The item I'd like to talk about today would be implementing Components. Components are small C# classes that may be attached to any SceneObject arbitrarily. A component is any class inheriting from IComponent - IComponent carries only two properties; a serialisation property (returns the current 'state' for serialisation purposes), and a type property (which recognises the 'type' of component that it is) - components allow you to attach arbitrary data to an object for the purposes of interacting with a region module. For instance, a Mesh module (which is my current best example) would have a MeshComponent that included all the extra data to tag an object with related to meshes - which would get serialised and passed around with the main object. When deserialized - a Factory handles making sure the MeshComponent is deserialized with the main object. I've attached a document
Re: [Opensim-dev] Refactoring SceneObjectGroup - Introducing Components
Bumpity Bump. If I don't hear any comments on this, I'm going to assume the proposal is sound and have carte blanche to break OpenSim at my whim. ;) (find the original post for the attachment.) Regards, Adam From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Frisby, Adam Sent: Friday, 11 December 2009 3:48 AM To: opensim-dev@lists.berlios.de Subject: [Opensim-dev] Refactoring SceneObjectGroup - Introducing Components Hi Folks, I've got a fairly complicated proposal to deliver here today - the short of it is; I'd like to go ahead and replace the current Scene Object representation model - at a fairly comprehensive complete level. Some of you have had the misfortune of working with SceneObjectPart/SceneObjectGroup and should understand what I am talking about. There are several stages to this proposal - but I would like to talk about today the first big one (and a small outline of the larger project - the reason for this being some of the later details require a little more nutting out before I have a complete proposal for them). So - the larger proposal in a nutshell; I would like to: * Merge SceneObjectGroup SceneObjectPart * Enable full inheritance linking (ie, hierarchical linking) * Make programming with SceneObjects possible reasonable from the outside (ie have a clean API). * Provide the ability to extend SceneObjects with components to introduce new properties and behaviours. The item I'd like to talk about today would be implementing Components. Components are small C# classes that may be attached to any SceneObject arbitrarily. A component is any class inheriting from IComponent - IComponent carries only two properties; a serialisation property (returns the current 'state' for serialisation purposes), and a type property (which recognises the 'type' of component that it is) - components allow you to attach arbitrary data to an object for the purposes of interacting with a region module. For instance, a Mesh module (which is my current best example) would have a MeshComponent that included all the extra data to tag an object with related to meshes - which would get serialised and passed around with the main object. When deserialized - a Factory handles making sure the MeshComponent is deserialized with the main object. I've attached a document which is my current state of the whole proposal which includes some examples more detail. Please note that Phase 2 is not finalised yet - and some decisions were discussed about changing two facets in particular. * Enabling inheritance of components+sceneobject to make speedy-classes for common use cases (eg PrimObject inherits PrimComponent and SceneObject) * Allowing more than one factory potentially; for manufacturing said speedy-classes. * Note that these shorthand classes would still use the standard .Has / .Get methods; they would just return 'this' where the particular component type is concerned. To begin with - I would like to implement components as an extra non-serialised property of the SceneObjectPart; this will occur very shortly after 0.7 is tagged; which I would like to do once ROBUST covers all the main services (I heard something about late-december/early-jan); this first stage should not break anything in particular - however once that Is complete, I would like to migrate properties into components in order to modularised the codebase better. An example of this would be PrimData - primdata is unique to the Second Life use case, and irrelevant to others; in this case, we'll move PrimData into a commonly accessed component (eg SceneObject.GetPrimData.Hollow = 0.9f;) - once the move to components is complete for the common data; then creating the final SceneObject class which merges SceneObjectGroup+Part should be a fairly painless process. Please take a read of the document attached for more information - and I am very keen to hear anyones thoughts as to use cases that this model will make more difficult; or could not support. The goal with this project is to make OpenSim support more with less - allowing third party modules to really take OpenSim as a framework to the next level; and make a more modular server for other clients platforms. Thanks! Adam ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Do we have any record of the patches applied to the XMLRPC library?
I have a feeling it came from another site than the SF one you posted. I'd check the namespace Nwc for clues. But yeah, that library is veritably ancient - it's worked well so no-one has touched it in quite some time. Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Justin Clark-Casey Sent: Monday, 14 December 2009 2:54 PM To: opensim-dev@lists.berlios.de Subject: [Opensim-dev] Do we have any record of the patches applied to the XMLRPC library? Hi folks, As part of trying to fix remaining issues in 0.6.8.RC1, I've been digging into our XMLRPC.dll library that comes from http://xmlrpccs.sourceforge.net/ Our version differs from the last released 1.10 (which is the version mentioned in CONTRIBUTORS.txt). For example, the XmlRpcRequest.Send() method takes two parameters (url and a timeout) rather than 1. The git log for XMLRPC.dll shows that it was last touched back in July 2007. Does anybody remember anything about this or where the patch changes might be found? I looked for the xmlrpccs repository but it appears to be missing (!) from sourceforge where it is apparantly hosted. Thanks, -- Justin Clark-Casey (justincc) 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] Synchronous or Asynchronous.. Packet handler synchronicity
Since we're defaulting to async - we should probably only make a list of what is known to run fast and what isn't. Just as a quick example - all the terrain packets require some heavyish number crunching and should all be async. Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Teravus Ovares Sent: Sunday, 13 December 2009 12:08 AM To: opensim-dev Subject: [Opensim-dev] Synchronous or Asynchronous.. Packet handler synchronicity Hello Again I just wanted to update the people subscribed to opensim-dev about the current situation with regards to packet handler synchronicity and thread context. The History: Shortly after OpenSimulator started, it was decided that each user should have it's own packet processing thread. This worked well at the time, but limited concurrency because of lock and thread contention. 5 UDP connections = 5 dedicated threads that spent most of their time waiting(this got expensive when child agents were considered). Recently: A few months ago, Intel provided some test results and provided a few developers to re-write the UDP server and client handling stack. One of the things that they did was make each UDP server use two threads. One for the incoming packet processing and one for the outgoing packet processing, regardless of how many clients were connected to OpenSimulator.Essentially, this made it 'one thread per network connection resource'. This was great because it reduced the amount of threads that opensimulator uses quite significantly. There were some problems though. Some code handling the upper level processing (Scene, SceneObjectGroup, SceneObjectPart.. etc.. ) of the data in the packet took long enough to process.. to cause the simulator to slowly come to a crawl over time and disconnect users. Because the infrastructure wasn't in place to selectively delegate which packets are handled asynchronously and synchronously, the choice was made to process each packet on the threadpool so that a long running packet processor wouldn't cause the UDP server to get backlogged and cause all users connected to get disconnected. This solution wasn't really optimal..because a single client, moving around, causes ~15 AgentUpdate packets to be sent to the server per second. 15 packets means that up to 15 threadpool requests were happening a second per connected root agent. There are various reasons why this isn't optimal, I won't go into them here :). Now: I'm happy to announce, that the infrastructure for selectively delegating whether a packet will be processed synchronously or asynchronously is in place as of 4ef8dc7d96fa2d4efd992ff7d304b8894f004c4f. You can find the way to set a packet handler as synchronous in OpenSim.Region.ClientStack.LindenUDP.LLClientView.RegisterLocalPacketHa ndler. Note that packet handlers with 3 parameters with the third one set to 'false' means that the packet handler is synchronous.Packet handlers in that method with 2 parameters or 3 parameters and the third one set to 'true' means that the packet is processed asynchronously on the threadpool using the method defined by async_call_method in OpenSim.ini I've also taken the liberty of setting the AgentUpdate Packet, the ViewerEffect Packet, and a few others as synchronous. The AgentUpdate Packet and ViewerEffect Packet are the two packets that are sent from the client the most often, so, these alone should reduce the threads required per client significantly. Testers: What users and testers should look for, however, is the Simulator suddenly disconnecting all users.If this occurs, then, likely, the UDP server is not moving fast enough to effectively process packets for the current amount of users. Developers: It's time to look at the length of time it takes for packet processors to finish processing and decide if the packet handler should be executed synchronously or asynchronously. Any synchronously processed packet is processed in the thread context beginning with the UDPServer. Hopefully, this will allow us to increase the number of concurrently connected users further. 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] Designing with reusability in mind
Re: Library My thought was to have a directory where we can save .iar files - and the library is built from all the IARs in that directory at time the inventory server is started. Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of d...@metaverseink.com Sent: Wednesday, 9 December 2009 10:39 AM To: opensim-dev@lists.berlios.de Subject: [Opensim-dev] Designing with reusability in mind In the same vein as Teravus' message about designing with instrumentation in mind... I would like to ask for us to design with reusability in mind. Let's get out of the model that we are developing an application, and always think that we are developing components that can be used both for putting together an application that looks like SL, and for other applications as well. Case in point: in the sequence of the conversation about free IARs, OARs, etc., I have been putting together a package with freebies. I thought about releasing it as an IAR, like everyone else is doing, but this has a problem: it requires operator access to the server -- not all users can take advantage of this free content. Solution: let's use the underused OpenSim Library and add more stuff in there. No one has changed that part of OpenSim for ages! There's a good reason for it: adding content to it manually is a huge PITA and extremely error-prone. So, idea: let's take any IAR and write an external tool that converts it into the OpenSim Library format. That way different operators can provide different libraries very easily: just take your favorite IAR and dump it into your OpenSim Library, therefore making it available to all of your users. This sounds easy enough. Justin has the code for unarchiving IARs... except that it's all tangled up with Scenes. :-/ The rule of thumb for reusability in the context of OpenSim is very easy: the region modules that come in OpenSim.Region.CoreModules.dll should be as thin as possible. They should only have enough meat to bridge between Scenes and whatever it is those modules actually do. Whatever it is they do, for the most part, is relatively generic and should be factored out into their own dll, so that it can be reused from elsewhere that has nothing to do with scenes. Example: all the service connectors now can be reused out of the box by other tools to access remote OpenSim servers. (OpenSim.Service.Connectors.dll) Counter-Example: inventory archiving/dearchiving. From looking at that code, the only reason why the actual worker code needs the Scene object is to be able to get to IInventoryService and IAssetService. So... it should get those instead of Scene, and it should be factored out from Region.CoreModules, because inventory archiving/dearchiving is a lot more generic than a Scene utility. That way I could write this tool that I want in 4 hours reusing Justin's code as a dll, instead of having to copy-and-paste Justin's code and purge it from all references to Scene. I would simply need to provide my own implementation of IInventoryService and IAssetService that would write things in bin/assets and bin/inventory instead of sending them to a server. The general request is this: let's not hide useful code under OpenSim.Region.*, which are components that only make sense for the live VW server. There's so many more tools/applications that can be done around it! -- let's not hide good code under there, where it can never be reused. 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
Re: [Opensim-dev] Designing with reusability in mind
Why not push the first time a file is added; then add some sort of marker 'assets from IAR with filesize X are already imported'. Frankly though - even on a big grid the time to import probably isn't that significant. Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Melanie Sent: Wednesday, 9 December 2009 4:34 PM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Designing with reusability in mind IARs also contain the assets, which would be stored to the asset server again and again. On large servers, this could take ages. So, I don't think IAR is a good idea, unless it's stipulated that the IAR must have been made on the same server/grid, and that any assets contained inside are ignored for the purpose of building the library, and are assumed to be present in the asset server. Melanie Frisby, Adam wrote: Re: Library My thought was to have a directory where we can save .iar files - and the library is built from all the IARs in that directory at time the inventory server is started. Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of d...@metaverseink.com Sent: Wednesday, 9 December 2009 10:39 AM To: opensim-dev@lists.berlios.de Subject: [Opensim-dev] Designing with reusability in mind In the same vein as Teravus' message about designing with instrumentation in mind... I would like to ask for us to design with reusability in mind. Let's get out of the model that we are developing an application, and always think that we are developing components that can be used both for putting together an application that looks like SL, and for other applications as well. Case in point: in the sequence of the conversation about free IARs, OARs, etc., I have been putting together a package with freebies. I thought about releasing it as an IAR, like everyone else is doing, but this has a problem: it requires operator access to the server -- not all users can take advantage of this free content. Solution: let's use the underused OpenSim Library and add more stuff in there. No one has changed that part of OpenSim for ages! There's a good reason for it: adding content to it manually is a huge PITA and extremely error-prone. So, idea: let's take any IAR and write an external tool that converts it into the OpenSim Library format. That way different operators can provide different libraries very easily: just take your favorite IAR and dump it into your OpenSim Library, therefore making it available to all of your users. This sounds easy enough. Justin has the code for unarchiving IARs... except that it's all tangled up with Scenes. :-/ The rule of thumb for reusability in the context of OpenSim is very easy: the region modules that come in OpenSim.Region.CoreModules.dll should be as thin as possible. They should only have enough meat to bridge between Scenes and whatever it is those modules actually do. Whatever it is they do, for the most part, is relatively generic and should be factored out into their own dll, so that it can be reused from elsewhere that has nothing to do with scenes. Example: all the service connectors now can be reused out of the box by other tools to access remote OpenSim servers. (OpenSim.Service.Connectors.dll) Counter-Example: inventory archiving/dearchiving. From looking at that code, the only reason why the actual worker code needs the Scene object is to be able to get to IInventoryService and IAssetService. So... it should get those instead of Scene, and it should be factored out from Region.CoreModules, because inventory archiving/dearchiving is a lot more generic than a Scene utility. That way I could write this tool that I want in 4 hours reusing Justin's code as a dll, instead of having to copy-and-paste Justin's code and purge it from all references to Scene. I would simply need to provide my own implementation of IInventoryService and IAssetService that would write things in bin/assets and bin/inventory instead of sending them to a server. The general request is this: let's not hide useful code under OpenSim.Region.*, which are components that only make sense for the live VW server. There's so many more tools/applications that can be done around it! -- let's not hide good code under there, where it can never be reused. 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
Re: [Opensim-dev] Mumble Voice
*that* is very clever; since it'd allow you to have backwards/forwards compatible. If you hooked that up with the current freeswitch solution - you could have standard clients getting crappy PCM8000, people with better clients would get whatever you could negotiate (Speex?) Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Stefan Andersson Sent: Monday, 7 December 2009 8:26 AM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Mumble Voice Since the SL viewer accepts command line options to tell it what port the SLVoice service is available on, and also whether to attempt to start SLVoice.exe, if you don't want to replace the exe, you could just as well have the custom voice exe start first, establish a service port, then let it (the voice exe) locate and launch the sl viewer with the correct args, instead of letting the sl viewer start the hardcoded SLVoice.exe. We did this in PIM; works like a charm. /Stefan -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Robert A. Knop Jr. Sent: den 7 december 2009 16:09 To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Mumble Voice On Mon, Dec 07, 2009 at 07:05:06AM -0800, Snoopy Pfeffer wrote: My friend told me, that he will simply replace SLVoice.exe. That module provides an interface for the viewer and as long as that interface stays the same, no viewer changes are need. Excellent. As I mentioned, I think that that interface *did* change somewhere in the viewer 1.22 or 1.23 cycle; I'm not sure how much it changed, and I may be wrong and it may be that it didn't change at all. -- --Rob Knop E-mail:rk...@pobox.com Home Page: http://www.pobox.com/~rknop/ Blog: http://www.sonic.net/~rknop/blog/ ___ 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 turns Three
I'd say some celebrations are in order definitely. It's pretty rare for an OSS project to maintain such momentum over a period as long - and the last 6 months have really begun to stabilise the codebase in a serious way (I blame John.). Adam From: opensim-users-boun...@lists.berlios.de [mailto:opensim-users-boun...@lists.berlios.de] On Behalf Of Stefan Andersson Sent: Wednesday, 2 December 2009 12:37 PM To: opensim-dev@lists.berlios.de; opensim-us...@lists.berlios.de Subject: [Opensim-users] OpenSim turns Three Hey people, Just figured I'd remind you out that in less than two months, on 29th of Jan 2010, OpenSim turns three. Celebrations and announcements are in order. As a starter, this is my blog post from the last birthday: http://lbsa71.net/2009/01/21/opensim-turns-two/ Love, /Stefan ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] [Opensim-users] OpenSim turns Three
You get some of the blame too! =p Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Melanie Sent: Wednesday, 2 December 2009 1:23 PM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] [Opensim-users] OpenSim turns Three Yeah, go on blame John. Everyone does, lately :) Melanie Frisby, Adam wrote: I'd say some celebrations are in order definitely. It's pretty rare for an OSS project to maintain such momentum over a period as long - and the last 6 months have really begun to stabilise the codebase in a serious way (I blame John.). Adam From: opensim-users-boun...@lists.berlios.de [mailto:opensim-users- boun...@lists.berlios.de] On Behalf Of Stefan Andersson Sent: Wednesday, 2 December 2009 12:37 PM To: opensim-dev@lists.berlios.de; opensim-us...@lists.berlios.de Subject: [Opensim-users] OpenSim turns Three Hey people, Just figured I'd remind you out that in less than two months, on 29th of Jan 2010, OpenSim turns three. Celebrations and announcements are in order. As a starter, this is my blog post from the last birthday: http://lbsa71.net/2009/01/21/opensim-turns-two/ Love, /Stefan - --- ___ 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] Designing with Instrumentation in mind.
I recently had the same idea - I started implementing the new MonitorModule in core, it should be pretty easy to extend with new instrumentation. The only gotcha is I have every instrument return a 'double' value so we can easily chart it externally (and make easy comparisons). Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Teravus Ovares Sent: Friday, 27 November 2009 6:10 PM To: opensim-dev@lists.berlios.de Subject: [Opensim-dev] Designing with Instrumentation in mind. Hey there, A while back, we had somewhat reasonable statistics being generated and presented to the client.They were not always accurate, but based on what I saw, I could, pretty much pin certain parts of the simulator as the limiting factor during load tests. I'd say, the number 1 reason that they were semi-accurate and not accurate.. in the past.. is because nobody ever thought about instrumentation during the functionality design. It was always 'tacked on later'. One example of this..is the current AssetCache implementation. There's no way, currently, to know, at a glance.. how many external requests it has open. Additionally, it will be extremely difficult to put one in because of the way the objects are designed and accessed. To put one in, an event needs to be added to the IAssetService interface and each AssetCache implementation will need an interlocked int to count how many gets and puts it currently has open to the external data source as well as it's own event calling schedule. Then, the IAssetService property in Scene, (AssetService) will need an event handler.. which updates the values in SimStatsReporter in Scene (StatsReporter). This idea of external access resource instrumentation should really have been built in to the design of the AssetService. This last recent load test, there were no real statistics that I could use to determine what the limiting factor was. Time Dilation was pegged at 1.0..even when the simulator was obviously struggling.Total Frame time (MS) was -50ms even when the simulation MS was 850ms and the Physics ms was 250ms, so the inconsistencies made it impossible to know what part of the simulator was struggling. Agent Updates were erratic.. sometimes high.. sometimes low when the simulator was fine and when it was struggling. Pending Uploads and Downloads were always 0, so there was no way to know how well the simulator was downloading and uploading assets to and from the grid. Packet stats were non-existant, so there was no way to know how well the UDP handlers were faring under the load. When it crashed, it crashed with a mono based stack trace which pointed to out of memory errors, so the only way that you could, scientifically, find out what the issue is.. is to run a load test under a memory profiler. We know, that running a public load test under a memory profiler is quite impractical. To make something better, I need to know two things, where it is, and where I want it to be.How can we make OpenSimulator better if we don't have statistics that point to where we are currently? On that note, I propose that, when designing objects for functionality in OpenSimulator, that we also consider if the objects should be instrumented and, what would be the best way to go about instrumenting the objects. We should incorporate instrumentation into the design of the objects. Some of that instrumentation is appropriate for a client to see, some of it might not be. Consider that, many of them should be client facing and be included in the SimStats that get sent to the client..so that we can have a reasonable idea of what's going on with a simulator at a glance. Also, in the design of the instrumentation, we make sure that the instrumentation is accurate and lightweight. The load test went reasonably... but, we didn't get half of the information on the simulator that we needed to be able to improve it. Please comment :) I look forward to hearing your responses. 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] Any objections to starting the OpenSim 0.6.8 release process?
I would like to start the ball rolling about tagging 0.7 soon. It's been well over a year since 0.6 was tagged, and a huge number of improvements. If we're averse to hitting 1.0, let's go to 0.25 if we have to, but I think with all the services now running under ROBUST and the wealth of features in trunk right now, 0.7 is the way to go. Adam From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of orion hax Sent: Tuesday, 24 November 2009 2:20 PM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Any objections to starting the OpenSim 0.6.8 release process? been very well for all my sims +1. On Tue, Nov 24, 2009 at 4:06 PM, Michael Cerquoni nebadon2...@gmail.commailto:nebadon2...@gmail.com wrote: I think its a good idea, i have gotten wide spread reports of better stability and uptimes. +1 On Tue, Nov 24, 2009 at 1:37 PM, Justin Clark-Casey jjusti...@googlemail.commailto:jjusti...@googlemail.com wrote: Hi folks, It seems that we've reached a good level of stability after the most recent set of changes and fixes. Therefore, I'd like to start the ball rolling on releasing OpenSim 0.6.8. As happened with 0.6.7, I think that we should branch from git master sometime in the next few days and spend a week or so testing the release candidate for super-critical show-stopping failures before making it official. I think that 0.6.8 will be considerably better than 0.6.7 due to the many recent stability fixes. Therefore, I'm keen to see the production of installers/binaries this time so any help in this area would be great when the time comes. The major configuration change for 0.6.8 is the addition of the grid service to the ROBUST framework (making the user service the only remaining hardcoded standalone grid service executable). I intend to update the existing configuration documentation to reflect this and hopefully improve it a bit, even if such documentation may be rewritten soon. I documented this lightweight release process at http://opensimulator.org/wiki/Release_Cycle Any thoughts about making a release at this time? -- Justin Clark-Casey (justincc) http://justincc.org http://twitter.com/justincc ___ Opensim-dev mailing list Opensim-dev@lists.berlios.demailto: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.demailto: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 objections to starting the OpenSim 0.6.8 release process?
What is missing right now? Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Teravus Ovares Sent: Tuesday, 24 November 2009 2:42 PM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Any objections to starting the OpenSim 0.6.8 release process? I'm definitely OK with 0.6.8 RC1 being tagged now. The only thing that I'm hesitant about with 0.7 is.. Meldiva wanted to have all services on ROBUST before 0.7 was released. Regards Teravus On Tue, Nov 24, 2009 at 5:24 PM, Frisby, Adam a...@deepthink.com.au wrote: I would like to start the ball rolling about tagging 0.7 soon. It's been well over a year since 0.6 was tagged, and a huge number of improvements. If we're averse to hitting 1.0, let's go to 0.25 if we have to, but I think with all the services now running under ROBUST and the wealth of features in trunk right now, 0.7 is the way to go. Adam From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of orion hax Sent: Tuesday, 24 November 2009 2:20 PM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Any objections to starting the OpenSim 0.6.8 release process? been very well for all my sims +1. On Tue, Nov 24, 2009 at 4:06 PM, Michael Cerquoni nebadon2...@gmail.com wrote: I think its a good idea, i have gotten wide spread reports of better stability and uptimes. +1 On Tue, Nov 24, 2009 at 1:37 PM, Justin Clark-Casey jjusti...@googlemail.com wrote: Hi folks, It seems that we've reached a good level of stability after the most recent set of changes and fixes. Therefore, I'd like to start the ball rolling on releasing OpenSim 0.6.8. As happened with 0.6.7, I think that we should branch from git master sometime in the next few days and spend a week or so testing the release candidate for super-critical show-stopping failures before making it official. I think that 0.6.8 will be considerably better than 0.6.7 due to the many recent stability fixes. Therefore, I'm keen to see the production of installers/binaries this time so any help in this area would be great when the time comes. The major configuration change for 0.6.8 is the addition of the grid service to the ROBUST framework (making the user service the only remaining hardcoded standalone grid service executable). I intend to update the existing configuration documentation to reflect this and hopefully improve it a bit, even if such documentation may be rewritten soon. I documented this lightweight release process at http://opensimulator.org/wiki/Release_Cycle Any thoughts about making a release at this time? -- Justin Clark-Casey (justincc) http://justincc.org http://twitter.com/justincc ___ 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
Re: [Opensim-dev] Leaving Project
OpenSim is not Second Life, is not intended to be like Second Life, nor ever will. I'll repeat that - most (all?) of the core devs will too. The Second Live viewer is convenient - since the protocol is documented and it gives us a good feature base to start with; but it's not the be-all-and-end-all. OpenSim is more like a series of tubes - events inputs go in one direction, get mashed around in the modules, then spat back out other tubes to be sent to clients. Second Life compatibility modules are definitely well numbered - but internally, we're not really aiming for a SL wannabe-world simulator. SL compatibility is the most prominent use of this - since there's been a lot of people interested in that; but Rock's original complaints are exactly spot on the mark - sticking to the SL feature set is a complete waste of time. SL's technology is dated - LL's inability to implement modern 3D graphics standards is going to bite them in the arse over the next few years. This is where OpenSim's internal commitment to moving towards things like IClientCore over IClientAPI - means we'll be supporting more advanced viewers as time goes on, and those are developed. I've got my eye personally on the Rex Naali project, even if it is 12 months away from having something user-friendly. But that ultimately said; right now there is pretty much nothing stopping you from building a kickass viewer with say the UDK, hooking up a decent clientstack and running with it (see the MXP implementation for a good example on how to implement a foreign clientstack using another viewer's protocol). I know some people have been doing just that with Unity lately. The big problem here is there's a very real lack of viewer developers in this community - there is some overlap between server network engineers (like the OS community) and 3D Viewer Developers here, but not much. If we do have 3D devs in the community who haven't done anything and feel like contributing - you really should be talking to some of the 'next gen viewer' projects and seeing if we can get something awesome done faster. Regards, Adam From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Len Brown Sent: Monday, 23 November 2009 5:07 AM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Leaving Project Rock, I sympathize with you on many levels. I've also had my doubts regarding the future of OpenSim, but I have also maintained some degree of faith that things will pull through in the end. For me the shock came when I was abruptly informed that OpenSim is not Second Life, is not intended to be like Second Life, nor ever will. I still haven't the foggiest idea what this developer had smoked for them to so strongly assert that incredibly false statement. For me, the enjoyment of OpenSim has come from my intense devotion to building and skinning. In fact, for the last few months I've been working on a full region that has many hundreds of skins, clothes, hair, furniture, etc, etc, that I'd like to package up as an OAR and give out freely, since repeatedly I've been told that instead of giving money to help further OpenSim I'd do more proactively by giving content. So I plan to do just that and give my money to other open source initiatives that matter to me. I have a passion for writing, and have thought many times that one of the greatest powers OpenSim would gain is having simple, straightforward, step-by-step instructions on how to download, compile, install, administer and overall just plain operate the core applications. What kills me is that everyone who does a search for OpenSim inevitably hits the opensimulator.orghttp://opensimulator.org site and that is where the massive roadblock presents itself. It's useless for most and irrelevant to the few who consider themselves OpenSim experts. Heck, even now on the configuration page it still displays info for 0.6.6 including (months old) known bugs in setting up region xml files. If there was appointed a volunteer whose sole job was to keep information on opensimulator.orghttp://opensimulator.org relevant that one task would resolve a mountain of negativity right there. I sit here in front of my computers a good 10 to 12 hours a day. I would sincerely love to contribute to the OpenSim project, especially in documentation support. But the thing holding me back is communication. If I cannot get a straight answer on who to GIVE money to in order to help, then I stand little chance of getting clear, straight answers from developers when asking about issues I need to consider and incorporate in documentation. If communication is a hurdle we can all overcome, with a genuine and heart-felt effort to relay information, motives, and plans with one another, then I'd sincerely appreciate having the opportunity to personally contribute. I'm not a programmer today,
Re: [Opensim-dev] Leaving Project
The problem is recreation reinterpretation may not be copyright-transfer free. Looking at the code, then reimplementing the mechanism may trans-include the copyright on the original into the new implementation. We've had umpteen different lawyers look into this problem for us and they all pretty much say the same thing. Ask Linden Lab for an indemnification against this or don't look at the viewer code for 3-6 months when moving projects. - we did the first, they said no, so we're doing the second. Unless you can get a qualified lawyer to say otherwise, that's the way the policy is going to stay. Regards, Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Kyle Hamilton Sent: Monday, 23 November 2009 3:46 PM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Leaving Project I've already explained the futility of the concept of trade secret protection when LL already released the viewer code, and the specifications for connecting to a server -- they told the secret, themselves, and to be a trade secret first something must be secret. The only thing they can claim is copyright protection, and since there's no means of automatedly transforming C++ code into C# code there's no transformation without reinterpretation and recreation, thus preventing any copyright claim from succeeding. (I am not a lawyer, but I've read Eben Moglen's essays. You know, the general counsel for the FSF?) -Kyle H On Mon, Nov 23, 2009 at 8:43 AM, Fly Man fly.man.open...@gmail.com wrote: Adam, You hit the nail right on his head with this passage: The big problem here is there’s a very real lack of viewer developers in this community – there is some overlap between server network engineers (like the OS community) and 3D Viewer Developers here, but not much. If we do have 3D devs in the community who haven’t done anything and feel like contributing – you really should be talking to some of the ‘next gen viewer’ projects and seeing if we can get something awesome done faster. And maybe someone should explain WHY people won't burn their hands on the viewer Main reason: There's a clausule on the Website and internally about Look at viewer code, and there's 6 months no working on OpenSim So any person that would like to keep working on OpenSim doesn't look at viewer code, and vice versa. That's about the main reason that some viewer developers won't co- operate with OpenSim and the other way, developers from OpenSim can't help viewer developers But that's just my 2 cents about that passage. ___ 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] New Website (was Leaving Project)
OK, last thing - I know everyone is complaining about the website. Infact the core devs (specifically me Melanie) spent some time last weekend setting up a new website - it is not done yet however; but we'll be seeking people to submit documentation articles - if you have any of the following, please send me (a...@deepthink.com.au) the text + images for inclusion. - Use cases (We at foo are using OpenSim for y, these are the features we use z, w, a... OpenSim works well for this because of b.) - Screenshots Multimedia - Documentation - full format 'HOWTO' articles, and the versions those articles are compatible against. - Technical References - Component Foo works like this. - Developer Tutorials (building programming) If you have any of the above you want to contribute, please send them to me - with the usual disclaimer that the final content on the site is at the whims of the core developers. Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Kyle Hamilton Sent: Monday, 23 November 2009 3:46 PM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Leaving Project I've already explained the futility of the concept of trade secret protection when LL already released the viewer code, and the specifications for connecting to a server -- they told the secret, themselves, and to be a trade secret first something must be secret. The only thing they can claim is copyright protection, and since there's no means of automatedly transforming C++ code into C# code there's no transformation without reinterpretation and recreation, thus preventing any copyright claim from succeeding. (I am not a lawyer, but I've read Eben Moglen's essays. You know, the general counsel for the FSF?) -Kyle H On Mon, Nov 23, 2009 at 8:43 AM, Fly Man fly.man.open...@gmail.com wrote: Adam, You hit the nail right on his head with this passage: The big problem here is there’s a very real lack of viewer developers in this community – there is some overlap between server network engineers (like the OS community) and 3D Viewer Developers here, but not much. If we do have 3D devs in the community who haven’t done anything and feel like contributing – you really should be talking to some of the ‘next gen viewer’ projects and seeing if we can get something awesome done faster. And maybe someone should explain WHY people won't burn their hands on the viewer Main reason: There's a clausule on the Website and internally about Look at viewer code, and there's 6 months no working on OpenSim So any person that would like to keep working on OpenSim doesn't look at viewer code, and vice versa. That's about the main reason that some viewer developers won't co- operate with OpenSim and the other way, developers from OpenSim can't help viewer developers But that's just my 2 cents about that passage. ___ 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] The notion of core
OK, since I have a nagging feeling no-one read Teravus's original post in this long thread (and with a hope of putting this to rest). There are guidelines for the -core list, which are the following: If the topic can be discussed on dev, it should be. Core's scope is limited to issues related to commit access, licensing, money, server administrator and other 'meta' issues relating to running the project. No-one on dev is missing out on any development or code related discussion. Membership is limited to active committers (min. one commit in last 6 mo to maintain commit access ML access). 'Votes' are done on consensus with any committer having full veto power. That said, DSVC is not a panacea to programming. Git is better than SVN at merging files; but it's still not excellent - Melanie puts in a ton of work each week in managing our various branches and bringing them together, conflicts and all. Until someone realises that DSVC needs to include language specific patterns (such as refactorings), there is still going to need to be a core project at the middle making sure the base works, and still a bunch more people who can update branches forks accordingly. Otherwise maintaining distributions becomes an effort in trying to hit moving targets. Since it'll probably satisfy some of the people who are curious about what is discussed on core, here's the last 10 threads. (this represents probably 3-5 months of traffic, as I said before, it's low volume.) - as you can see, they all do fall into the guidelines listed above. Last 10 threads on opensim-core: 1. Snowcrash's contributions - whether his eclectic license on SCEngine affects contributions to opensim master and specifically whether to accept patches relating to it. (Licensing.) 2. Mantis stopped sending emails, can someone look? 3. Where is the CS2JK license? 4. Forwarded a request for a spokesperson to speak to someone studying OSS communities. 5. Stefan announcing his resignation (cc:'d to dev) 6. JHurliman commit access [redux]? 7. Sean changing projects at IBM, resignation. 8. JHurliman commit access? 9. Request for moderator access on the wiki. 10. Vote on go/no-go on git after trial. Regards, Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Dr Scofield Sent: Tuesday, 20 October 2009 6:50 AM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] The notion of core Edward Middleton wrote: Teravus Ovares wrote: ... Your argument was that the advent of the distributed source control system made the 'commit right vote' obsolite, ... My point was that, with a DVCS, commit rights are really just the right to release manage the official repository. right. opensim-core is just a bunch of dudes and dudettes that manage the official repository. DrS -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ 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-core] snowcrash's contributions
Ter pretty much summed it up - both it and the irc channel are fairly low-volume, and the 'topic' is restricted to only 'personal' or 'meta' matters; such as discussion of approval of commit rights. It's pretty standard practice across open source projects with more than 5 committers for the committers to have a mailing list for these purposes, since realtime chats aren't practical across timezones. Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Teravus Ovares Sent: Monday, 19 October 2009 12:22 PM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] [opensim-core] snowcrash's contributions As far as there being opensim-core, yes. It exists. As far as it being Secret.. it's not ..Nor it it intended to be secret. It's been discussed before on IRC and in previous e-mail on opensim-dev. It has OpenSimulator core as it's members. It has a purpose as well, Just to be clear: * The core list is a list where interpersonal and political issues between the core developers are discussed. Despite how it may appear, we don't always agree on everything or even like each other from time to time. We would prefer to keep this interpersonal drama from distracting development. * The core list is also where core actions are decided upon, like voting on a new user's entry into core * We also discuss opensimulator.org server configurations (like using git for our repository) * Discussing the Development of OpenSimulator, however, is not appropriate in opensim-core. That's what opensim-dev is for. We also have a core IRC channel #opensim-core on freenode where the same rules apply. Regards Teravus On Mon, Oct 19, 2009 at 2:59 PM, Nebadon Izumi nebadon2...@gmail.com wrote: there is no secret mailing list, i don't know what he is talking about I suspect that email came from the opensim-users email list. Lets not keep feeding this thread, Crista asked everyone to ignore it. so lets not have this blow up, its not related to OpenSimulator development. On Mon, Oct 19, 2009 at 11:54 AM, Kyle G cre...@reactiongrid.com wrote: There's a secret mailing list to discuss such issue? Wow. That's interesting. I feel like Ryan now too. -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Ryan McDougall Sent: Monday, October 19, 2009 2:26 PM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] [opensim-core] snowcrash's contributions On Mon, Oct 19, 2009 at 8:30 PM, Cristina Videira Lopes lo...@ics.uci.edu wrote: dr scofield wrote: to me this is another piece from the legal FUD department (reminiscent of the money discussions). It's very easy to brush difficult issues under the rug of I don't care, this is ethics, not technical, hence it's FUD. You're entitled to that stand. Give your -1 on whatever is being proposed and stay out of the rest of the conversation, instead of trying to FUD the FUD. Some of us care about these difficult issues. Having a co-copyright holder who releases an addon to opensim under a discriminatory license (in this case based on country, but could be based on race, gender, sexual orientation,...) is not something some of us can ignore. Unclear if/what we should do about it, but clear that this is bugging a lot of people, not just core devs, and hence it should be discussed not ignored. Crista Nationality, or more to the point of the clause, political disposition, can be changed; unlike race or gender -- which is the kind of the point, to make a political stand in the face of potential human catastrophe. :D Have I mentioned that I'm not a fan of the secret mailing list? ... Here I am feeling like a member of a community, but largely without voice on the crucial matter of eccentric licenses(?)! :P Cheers, ___ 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 -- 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] VNC on CLient
Usual warning - please don’t link to anything involving viewer sourcecode on this list due to the problematic licensing conditions. (ie if you plan to submit patches to OpenSim, don’t go look at viewer code please) Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Mike Dickson Sent: Sunday, 18 October 2009 7:25 AM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] VNC on CLient On Sun, 2009-10-18 at 13:08 +, André Filipe wrote: I`d like to know HOW TO do it... the video shows the results of it. http://wiki.secondlife.com/wiki/Media_Rendering_Plugin_Framework Mike ___ 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] open sim UUID and Passwordhash
Just because other software may do it wrong does not mean it is secure. Drupal using a plain MD5 is alarming - since it allows for very quick plain lookups in existing databases (no need to calculate the dictionary + permuation with your fixed salt). Storing a custom salt for each user is essential if you wish to make dictionary attacks significantly more expensive. (Actually it also allows for plain collision attacks too.) Consider this case: · Calculate Every Permutation of the Dictionary plus a couple of common modifications, plus your fixed salt. (this will get ~80%+ of user passwords). Versus · Do the above, but for each user - since the salt is changing per user. The second will take 'n' times longer to calculate (where N is equivalent to the size of your database), it also works in the inverse - if you have a 10 million user database, it means you need 1/10millionth of the time to try calculate a valid hit. It adds up. Bigtime. A unique hash for the whole application helps against global world-wide MD5 databases, but it still does not help the above situation. Frankly the storage and transmission size arguments are complete bunk. We are talking 128-bits extra data per user for a good salt which adds up to about 'jack shit' when summed over the lifetime of the application. It takes very little extra time, and we already stuff that data into our default database schemas. Likewise, having a long salt versus a short salt makes very little difference - because it's the uniqueness that counts (see the two cases above.) Short summary of the above: Do it if you have any desire to follow good security practices with your users. It takes almost no extra time and gives you appreciable benefits. Adam From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Impalah Shenzhou Sent: Friday, 16 October 2009 4:37 AM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] open sim UUID and Passwordhash Thanks for the info Melanie. Adam, I consider Drupal, for example, a CMS with a decent security and it only uses md5(plain_password) to store user passwords. Some php frameworks (for example Code Igniter, Cake php...) use, but not mandatory, an unique hash for all the application. A random hash for every user improves security, you're right, but increases the data sent between DB and servers for every authentication. I prefer not to overload data transmission for something I think is overprotection. Maybe for 10 or 100 users there won't be no problems, but think on 1 and each byte will count (they aren't cheap). If you have a long, secret and unique hash for your servers, who can make an effective attack to you (at least in reasonable time)? Maybe the difference could be that Drupal used to be deployed over Apache, and it can be protected against dictionary attacks activating some modules, while Opensim/UGAIM are servers per se, basic servers. It's my opinion, if you don't like it, I have more :-P Greetings 2009/10/16 Frisby, Adam a...@deepthink.com.aumailto:a...@deepthink.com.au A long fixed salt doesn't help over the simple : in any practical way. The salt must be unique for each user for decent security. Adam From: opensim-dev-boun...@lists.berlios.demailto:opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.demailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Impalah Shenzhou Sent: Friday, 16 October 2009 3:44 AM To: opensim-dev@lists.berlios.demailto:opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] open sim UUID and Passwordhash This comes from UserManagerBase.AddUser (0.6.6): string md5PasswdHash = Util.Md5Hash(Util.Md5Hash(password) + : + String.Empty); The salt should be where String.Empty is. I think it doesn't change in the most recent versions, so the create user method of the console (both standalone and ugaim) are unsecure by default. Anyway, I agree with Melanie and Adam that the salt is needed for improving security, if not a random salt every time you create an user, at least a long and secret unique salt. Greetings 2009/10/16 Frisby, Adam a...@deepthink.com.aumailto:a...@deepthink.com.au +1 to Melanie, that code is *not* secure. It is salted with a : but that's a fixed known salt. This is what I suggest: $passwordSalt = md5(time() . utime() . mt_rand(0,mt_getrandmax())); // or any other good random source $passwordHash = md5(md5($password) . ':' . $passwordSalt); $passwordSalt should be unique among your database (very likely with the above code); if there are duplicates, then it allows dictionary attacks to be done, the more duplicates, the more effective it is. Adam -Original Message- From: opensim-dev-boun...@lists.berlios.demailto:opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-mailto:opensim-dev- boun...@lists.berlios.demailto:boun...@lists.berlios.de] On Behalf Of Melanie Sent: Thursday
Re: [Opensim-dev] open sim UUID and Passwordhash
Technically, the client only mandates the first MD5. It is possible for us to consider SHA256(MD5() . ':' . salt) instead. Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Dr Scofield Sent: Friday, 16 October 2009 8:20 AM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] open sim UUID and Passwordhash Alan M Webb wrote: If everyone is really concerned about security, then perhaps we should stop using MD5? ;-) who's going to tell the LL clients that? cheers, DrS/dirk Best regards Alan --- T.J. Watson Research Center, Hawthorne, NY 1-914-784-7286 alan_w...@us.ibm.com From: Frisby, Adam a...@deepthink.com.au To: opensim-dev@lists.berlios.de opensim- d...@lists.berlios.de Date: 10/16/2009 09:06 AM Subject:Re: [Opensim-dev] open sim UUID and Passwordhash - --- Just because other software may do it wrong does not mean it is secure. Drupal using a plain MD5 is alarming – since it allows for very quick plain lookups in existing databases (no need to calculate the dictionary + permuation with your fixed salt). Storing a custom salt for each user is essential if you wish to make dictionary attacks significantly more expensive. (Actually it also allows for plain collision attacks too.) Consider this case: · Calculate Every Permutation of the Dictionary plus a couple of common modifications, plus your fixed salt. (this will get ~80%+ of user passwords). Versus · Do the above, but for each user – since the salt is changing per user. The second will take ‘n’ times longer to calculate (where N is equivalent to the size of your database), it also works in the inverse – if you have a 10 million user database, it means you need 1/10millionth of the time to try calculate a valid hit. It adds up. Bigtime. A unique hash for the whole application helps against global world- wide MD5 databases, but it still does not help the above situation. Frankly the storage and transmission size arguments are complete bunk. We are talking 128-bits extra data per user for a good salt which adds up to about ‘jack shit’ when summed over the lifetime of the application. It takes very little extra time, and we already stuff that data into our default database schemas. Likewise, having a long salt versus a short salt makes very little difference – because it’s the uniqueness that counts (see the two cases above.) Short summary of the above: Do it if you have any desire to follow good security practices with your users. It takes almost no extra time and gives you appreciable benefits. Adam *From:* opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] *On Behalf Of *Impalah Shenzhou* Sent:* Friday, 16 October 2009 4:37 AM* To:* opensim-...@lists.berlios.de* Subject:* Re: [Opensim-dev] open sim UUID and Passwordhash Thanks for the info Melanie. Adam, I consider Drupal, for example, a CMS with a decent security and it only uses md5(plain_password) to store user passwords. Some php frameworks (for example Code Igniter, Cake php...) use, but not mandatory, an unique hash for all the application. A random hash for every user improves security, you're right, but increases the data sent between DB and servers for every authentication. I prefer not to overload data transmission for something I think is overprotection. Maybe for 10 or 100 users there won't be no problems, but think on 1 and each byte will count (they aren't cheap). If you have a long, secret and unique hash for your servers, who can make an effective attack to you (at least in reasonable time)? Maybe the difference could be that Drupal used to be deployed over Apache, and it can be protected against dictionary attacks activating some modules, while Opensim/UGAIM are servers per se, basic servers. It's my opinion, if you don't like it, I have more :-P Greetings 2009/10/16 Frisby, Adam _a...@deepthink.com.au_ mailto:a...@deepthink.com.au A long fixed salt doesn’t help over the simple “:” in any practical way. The salt *must* be unique for each user for decent security. Adam *From:* _opensim-dev-boun...@lists.berlios.de_ mailto:opensim-dev-boun...@lists.berlios.de [mailto:_opensim-dev-boun...@lists.berlios.de_ mailto:opensim-dev-boun...@lists.berlios.de] *On Behalf Of *Impalah Shenzhou* Sent:* Friday, 16 October 2009 3:44 AM * To:* _opensim-...@lists.berlios.de_ mailto:opensim- d...@lists.berlios.de* Subject:* Re: [Opensim-dev] open sim UUID and Passwordhash This comes from UserManagerBase.AddUser (0.6.6): string md5PasswdHash = Util.Md5Hash(Util.Md5Hash(password
Re: [Opensim-dev] open sim UUID and Passwordhash
+1 to Melanie, that code is *not* secure. It is salted with a : but that's a fixed known salt. This is what I suggest: $passwordSalt = md5(time() . utime() . mt_rand(0,mt_getrandmax())); // or any other good random source $passwordHash = md5(md5($password) . ':' . $passwordSalt); $passwordSalt should be unique among your database (very likely with the above code); if there are duplicates, then it allows dictionary attacks to be done, the more duplicates, the more effective it is. Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Melanie Sent: Thursday, 15 October 2009 4:14 PM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] open sim UUID and Passwordhash Please don't use that code. It creates unsalted hashes, which are not secure. The should be a ranndom salt, stored in the passwordSalt field in the DB. If that is blank, you're running a very insecure system Melanie Rich White wrote: here is the PHP code - $password_hash = md5(md5($password) . : .); an md5 hash of an md5 hash = 2009/10/15 Márcio Cardoso marciomai...@gmail.com: Good night, will be possible that someone could help me with 2 problems I have? I'm trying to create a stored procedure in mysql to add users, but do not know how UUID is generated. anyone have any idea how this happens? Another problem is how is the encoding of the password. The ideal was to have access to the code that opensim uses to add avatars. but I got tired of looking and nothing. I thank you for your help. Greetings, Márcio Cardoso ___ 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] [Opensim-users] 50+ avies
Actually, WP is running on positively ancient hardware. We're (DeepThink+simhost) scheduled to donate a new box to replace it this month coming (along with plaza03 which will also be getting an update). Adam -Original Message- From: opensim-users-boun...@lists.berlios.de [mailto:opensim-users- boun...@lists.berlios.de] On Behalf Of d...@metaverseink.com Sent: Thursday, 8 October 2009 2:22 PM To: opensim-dev@lists.berlios.de; opensim-us...@lists.berlios.de Subject: [Opensim-users] 50+ avies In case you are missing all the excitement, this morning we were able to pile 52 people-driven avies in OSGrid's Wright Plaza under 600M of RAM, and after that sim had been up for 10 hours, with a previous peak presence of 36. This sim is running on average hardware, nothing fancy. It eventually crashed, likely due to an overly conservative lock still present somewhere. But I think we just turned an important corner on the way to 1.0. ___ 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] 50+ avies
Adding to the impressiveness, this was achieved on Mono. I suspect by consequence we'll see 1000 on .NET. :P Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Kyle G Sent: Thursday, 8 October 2009 3:39 PM To: d...@metaverseink.com; opensim-dev@lists.berlios.de; opensim- us...@lists.berlios.de Subject: Re: [Opensim-dev] 50+ avies Fantastic! -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of d...@metaverseink.com Sent: Thursday, October 08, 2009 5:22 PM To: opensim-dev@lists.berlios.de; opensim-us...@lists.berlios.de Subject: [Opensim-dev] 50+ avies In case you are missing all the excitement, this morning we were able to pile 52 people-driven avies in OSGrid's Wright Plaza under 600M of RAM, and after that sim had been up for 10 hours, with a previous peak presence of 36. This sim is running on average hardware, nothing fancy. It eventually crashed, likely due to an overly conservative lock still present somewhere. But I think we just turned an important corner on the way to 1.0. ___ 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] Protocol Gateways
If you want to feed the data into the sim, your best bet might be a region module (or look at MRM scripting for a more powerful script engine). If you are feeding this data both in and out to clients speaking a special protocol, you want to write a ClientStack / ClientView. (see the IRCClientView for a good simple clientview example) Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Don McGregor Sent: Wednesday, 7 October 2009 9:52 AM To: opensim-dev@lists.berlios.de Subject: [Opensim-dev] Protocol Gateways I'm kicking around the idea of gatewaying into OpenSimulator an existing DoD Modeling and Simulation protocol, Distributed Interactive Simulation (DIS). DIS is used for virtual worlds in military simulations. Primarily it describes the position, orientation, velocity, etc, of entities in a virtual world. There may be multiple entities on the DIS side of the gateway; I want to inject them into the OpenSimulator server side. I've been poking around the various wikis for a while and haven't seen a good description of the (or a) client-server protocol for movement. What's a reasonable approach to this? Should I translate the DIS packets into an OpenSimualtor client/server protocol? Try to write a server-side module that speaks DIS? And, most importantly, where can I find some documentation on how to do this? ___ 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] Exception: System.IO.FileNotFoundException:
You need .NET 3.5 installed. Grab it from Windows Update. Adam From: opensim-users-boun...@lists.berlios.de [mailto:opensim-users-boun...@lists.berlios.de] On Behalf Of Huan Dau Sent: Wednesday, 30 September 2009 7:08 AM To: opensim-dev@lists.berlios.de; opensim-us...@lists.berlios.de Subject: [Opensim-users] Exception: System.IO.FileNotFoundException: Hi all I config to run Opensim as Grid Mode but have an error below 2009-09-30 08:58:35,187 INFO - OpenSim.Region.Physics.Manager.PhysicsPluginManager [PHYSICS]: creating meshing engine Meshmerizer 2009-09-30 08:58:35,187 INFO - OpenSim.Region.Physics.Manager.PhysicsPluginManager [PHYSICS]: creating OpenDynamicsEngine 2009-09-30 08:58:35,484 ERROR - OpenSim.Application [APPLICATION]: APPLICATION EXCEPTION DETECTED: System.UnhandledExceptionEventArgs Exception: System.IO.FileNotFoundException: Could not load file or assembly 'System.Core, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' or one of its dependencies. The system cannot find the file specified. File name: 'System.Core, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' at OpenSim.Region.Physics.OdePlugin.OdeScene..ctor(CollisionLocker dode, String sceneIdentifier) at OpenSim.Region.Physics.OdePlugin.OdePlugin.GetScene(String sceneIdentifier) in d:\OSGRID\OSGRID RELEASES\git.release\OpenSim\Region\Physics\OdePlugin\OdePlugin.cs:line 79 at OpenSim.Region.Physics.Manager.PhysicsPluginManager.GetPhysicsScene(String physEngineName, String meshEngineName, IConfigSource config, String regionName) in d:\OSGRID\OSGRID RELEASES\git.release\OpenSim\Region\Physics\Manager\PhysicsPluginManager.cs:line 95 at OpenSim.Region.ClientStack.RegionApplicationBase.GetPhysicsScene(String engine, String meshEngine, IConfigSource config, String osSceneIdentifier) in d:\OSGRID\OSGRID RELEASES\git.release\OpenSim\Region\ClientStack\RegionApplicationBase.cs:line 134 at OpenSim.OpenSimBase.GetPhysicsScene(String osSceneIdentifier) in d:\OSGRID\OSGRID RELEASES\git.release\OpenSim\Region\Application\OpenSimBase.cs:line 689 at OpenSim.OpenSimBase.SetupScene(RegionInfo regionInfo, Int32 proxyOffset, IConfigSource configSource, IClientNetworkServer clientServer) in d:\OSGRID\OSGRID RELEASES\git.release\OpenSim\Region\Application\OpenSimBase.cs:line 589 at OpenSim.OpenSimBase.CreateRegion(RegionInfo regionInfo, Boolean portadd_flag, Boolean do_post_init, IScene mscene) in d:\OSGRID\OSGRID RELEASES\git.release\OpenSim\Region\Application\OpenSimBase.cs:line 365 at OpenSim.OpenSimBase.CreateRegion(RegionInfo regionInfo, Boolean portadd_flag, IScene scene) in d:\OSGRID\OSGRID RELEASES\git.release\OpenSim\Region\Application\OpenSimBase.cs:line 319 at OpenSim.ApplicationPlugins.LoadRegions.LoadRegionsPlugin.PostInitialise() in d:\OSGRID\OSGRID RELEASES\git.release\OpenSim\ApplicationPlugins\LoadRegions\LoadRegionsPlugin.cs:line 127 at OpenSim.OpenSimBase.StartupSpecific() in d:\OSGRID\OSGRID RELEASES\git.release\OpenSim\Region\Application\OpenSimBase.cs:line 208 at OpenSim.OpenSim.StartupSpecific() in d:\OSGRID\OSGRID RELEASES\git.release\OpenSim\Region\Application\OpenSim.cs:line 137 at OpenSim.Framework.Servers.BaseOpenSimServer.Startup() in d:\OSGRID\OSGRID RELEASES\git.release\OpenSim\Framework\Servers\BaseOpenSimServer.cs:line 295 at OpenSim.Application.Main(String[] args) in d:\OSGRID\OSGRID RELEASES\git.release\OpenSim\Region\Application\Application.cs:line 146 WRN: Assembly binding logging is turned OFF. To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1. Note: There is some performance penalty associated with assembly bind failure logging. To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog]. Application is terminating: True Please tell me how to fix this error? thank and best regards. -- Dau Huan ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] [realXtend] Re: 3Di Viewer Rei goes open source (BSD licensed in-browser viewer)
It works with vanilla but from my understanding not ModRex; the meshes are handled as Irrlicht meshes if I understand correctly. Synchronising these mesh standards (in both rex 3diov) might be a good idea methinks. ... then if we can get someone to adjust the full viewer, we'd have somewhat of a standard on our hands. Adam From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Mark Malewski Sent: Wednesday, 30 September 2009 9:02 AM To: realxt...@googlegroups.com; Opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] [realXtend] Re: 3Di Viewer Rei goes open source (BSD licensed in-browser viewer) Nlin, Does the Rei Viewer work with the OpenSim + ModRex (RealXtend) as well? Could you please explain the differences between a plain vanilla OpenSim Server, a OpenSim + ModRex (realXtend) server, and a 3di server? Thank-you for all that you do, Mark On Wed, Sep 30, 2009 at 8:36 AM, Anu Mishra anuranj...@gmail.commailto:anuranj...@gmail.com wrote: Nlin Do you know if this viewer works with Realxtend server as well? Anu On 9/30/09, Mark Malewski mark.malew...@gmail.commailto:mark.malew...@gmail.com wrote: RealXtend, Have any of the RealXtend core developer's had a chance to look at this OpenSource Rei viewer yet? It seems to be an OpenSource web-based viewer. It looks pretty cool. Would this OpenSource contribution help RealXtend's Viewer project in any way? Could this viewer be easily modified to work with BOTH the stock OpenSim AND also work with RealXtend ModRex? Mark On Wed, Sep 30, 2009 at 2:07 AM, Mark Malewski mark.malew...@gmail.commailto:mark.malew...@gmail.com wrote: Nlin, Thank-you very much for the post, that seems like an excellent contribution to the OpenSim Community! I'm wondering what type of effect this might have on RealXtend's project development of a new viewer? Will this Rei viewer work with the latest stock OpenSim server? Mark On Tue, Sep 29, 2009 at 8:24 PM, nlin nlin.mess...@gmail.commailto:nlin.mess...@gmail.com wrote: Hello, Today 3Di's in-browser viewer source code has been opened up, as the project 3Di Viewer Rei. The license is BSD. Please have a look if you are interested! Project home page: http://3di-rei.orghttp://3di-rei.org/ Press release: http://3di.jp/en/news/2009093001.html We're very interested in further development of this open source viewer with the community. Thanks to the IdealistViewer developers, as portions of Rei use source code from an early version of IdealistViewer. Rei uses no code from GPL-licensed viewers. The Rei source code is in git at github, with the main repository at: http://github.com/3di/3di-viewer-rei Thanks, -nlin --~--~-~--~~~---~--~~ http://groups.google.com/group/realxtend http://www.realxtend.org -~--~~~~--~~--~--~--- ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] [realXtend] Re: 3Di Viewer Rei goes open source (BSD licensed in-browser viewer)
various modules (like ModRex or a 3Di module, or a Tribal_Media module) that can be installed on top of OpenSim core? This would seem to make MUCH more sense, instead of all the various forks out there. I really do like the idea of standardization, and would really like to see Modules created instead of completely different OpenSim forks. Then it would be great to see the Viewers designed so that all the various viewers will work with all the different platform modules (ModRex, 3Di, Tribal Media Server, etc.) Mark On Wed, Sep 30, 2009 at 11:07 AM, Frisby, Adam a...@deepthink.com.aumailto:a...@deepthink.com.au mailto:a...@deepthink.com.aumailto:a...@deepthink.com.au wrote: It works with vanilla but from my understanding not ModRex; the meshes are handled as Irrlicht meshes if I understand correctly. Synchronising these mesh standards (in both rex 3diov) might be a good idea methinks. ... then if we can get someone to adjust the full viewer, we'd have somewhat of a standard on our hands. Adam *From:* opensim-dev-boun...@lists.berlios.demailto:opensim-dev-boun...@lists.berlios.de mailto:opensim-dev-boun...@lists.berlios.demailto:opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.demailto:opensim-dev-boun...@lists.berlios.de mailto:opensim-dev-boun...@lists.berlios.demailto:opensim-dev-boun...@lists.berlios.de] *On Behalf Of *Mark Malewski *Sent:* Wednesday, 30 September 2009 9:02 AM *To:* realxt...@googlegroups.commailto:realxt...@googlegroups.com mailto:realxt...@googlegroups.commailto:realxt...@googlegroups.com; Opensim-dev@lists.berlios.demailto:Opensim-dev@lists.berlios.de mailto:Opensim-dev@lists.berlios.demailto:Opensim-dev@lists.berlios.de *Subject:* Re: [Opensim-dev] [realXtend] Re: 3Di Viewer Rei goes open source (BSD licensed in-browser viewer) Nlin, Does the Rei Viewer work with the OpenSim + ModRex (RealXtend) as well? Could you please explain the differences between a plain vanilla OpenSim Server, a OpenSim + ModRex (realXtend) server, and a 3di server? Thank-you for all that you do, Mark On Wed, Sep 30, 2009 at 8:36 AM, Anu Mishra anuranj...@gmail.commailto:anuranj...@gmail.com mailto:anuranj...@gmail.commailto:anuranj...@gmail.com wrote: Nlin Do you know if this viewer works with Realxtend server as well? Anu On 9/30/09, *Mark Malewski* mark.malew...@gmail.commailto:mark.malew...@gmail.com mailto:mark.malew...@gmail.commailto:mark.malew...@gmail.com wrote: RealXtend, Have any of the RealXtend core developer's had a chance to look at this OpenSource Rei viewer yet? It seems to be an OpenSource web-based viewer. It looks pretty cool. Would this OpenSource contribution help RealXtend's Viewer project in any way? Could this viewer be easily modified to work with BOTH the stock OpenSim AND also work with RealXtend ModRex? Mark On Wed, Sep 30, 2009 at 2:07 AM, Mark Malewski mark.malew...@gmail.commailto:mark.malew...@gmail.com mailto:mark.malew...@gmail.commailto:mark.malew...@gmail.com wrote: Nlin, Thank-you very much for the post, that seems like an excellent contribution to the OpenSim Community! I'm wondering what type of effect this might have on RealXtend's project development of a new viewer? Will this Rei viewer work with the latest stock OpenSim server? Mark On Tue, Sep 29, 2009 at 8:24 PM, nlin nlin.mess...@gmail.commailto:nlin.mess...@gmail.com mailto:nlin.mess...@gmail.commailto:nlin.mess...@gmail.com wrote: Hello, Today 3Di's in-browser viewer source code has been opened up, as the project 3Di Viewer Rei. The license is BSD. Please have a look if you are interested! Project home page: http://3di-rei.org http://3di-rei.org/ Press release: http://3di.jp/en/news/2009093001.html We're very interested in further development of this open source viewer with the community. Thanks to the IdealistViewer developers, as portions of Rei use source code from an early version of IdealistViewer. Rei uses no code from GPL-licensed viewers. The Rei source code is in git at github, with the main repository at: http://github.com/3di/3di-viewer-rei Thanks, -nlin --~--~-~--~~~---~--~~ http://groups.google.com/group/realxtend http://www.realxtend.org
Re: [Opensim-dev] [realXtend] Re: 3Di Viewer Rei goes open source (BSD licensed in-browser viewer)
VRML suffers from filesize issues too however; and frankly I've never been impressed by what it can support as a format. Don't look to it if you want to do things like shader based materials; which are essential for the gaming/entertainment side. Adam From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Daniel Smith Sent: Wednesday, 30 September 2009 11:09 AM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] [realXtend] Re: 3Di Viewer Rei goes open source (BSD licensed in-browser viewer) On Wed, Sep 30, 2009 at 10:51 AM, Ryan McDougall sempu...@gmail.commailto:sempu...@gmail.com wrote: [1] I guess there is VRML/X3D, but they appear to have died for a reason? X3D + JavaScript is what drives Vivaty (as in Vivaty.com). I dont expect it's going to go very far (I did some work with it). The co-author of X3D (formerly VRML) is Tony Parisi, and he's at Vivaty. Daniel -- Daniel Smith - Sonoma County, California http://daniel.org/resume ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] OpenSim 0.7 Release Candidate with ALL working OpenSim Modules
tl; dr. Adam From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Mark Malewski Sent: Wednesday, 30 September 2009 3:45 PM To: d...@metaverseink.com; opensim-dev@lists.berlios.de Subject: [Opensim-dev] OpenSim 0.7 Release Candidate with ALL working OpenSim Modules Diva, It would just be nice to get everything integrated back into core (or as OpenSim modules). This would be terrible. Diva, please explain WHY would having a working OpenSim distro be terrible? Having something that actually works is terrible? In my opinion, just the opposite is true. You can spend your whole life developing things (that no one actually uses, and that don't actually work or do much of anything, and that no one will ever use) or you can make a WORKING product that is usable, and that is EASY to use, and that people will use. You seem to prefer the latter. I think you, and maybe others here, may need to understand better this concept of extensible systems. That's at the very core of OpenSim from the beginning, even before I started contributing -- OpenSim is not an application, it's a platform with which to build applications. I think you need to sit down and understand the concept of working product. You also need to stop confusing extensible system with not working product. PHP, and Apache are what I would consider extensible systems. PHP is easily downloaded, and it works (out of the box). Yet it comes with many different modules (as part of the default distro) and those modules have all been thoroughly tested, and can easily be enabled by simply uncommenting out the module name in the default.ini file. From an engineering standpoint, extensibility means the system is designed to include hooks and mechanisms for expanding/enhancing the system with new capabilities WITHOUT having to make major changes to the system infrastructure. OpenSim doesn't seem to be extensible. OpenSim seems to be broken. There is a big difference. Maybe your definition of extensible means that it requires a rocket scientist just to get the trunk to even compile (or even work), and takes hours and hours of debugging code, just to get a module to even work. That isn't my idea of extensible. I understand over the past few months, the server infrastructure (and architecture) has been changing quite a bit. It's hard to even tell if ModRex (or any other modules) even work with the current OpenSim trunk (or latest build) at this point. The average layperson doesn't want to spend hours and hours trying to compile from source, or debugging code, or searching for plugins/modules that may (or may not) exist, and even worse many of them may not be updated, or may not even work with the current OpenSim as core evolves. Often times many of these modules are not updated, and most have no clue how to even build from source, and for this reason it might be good to just have VERY simple turn-key distributions available for download. (Stable releases) Similar to how RealXtend has done in the past. I supposed I could sit down and begin working on creating a fully configured VMWare image of OpenSim with various modules installed and configured, that people could easily download, and be up and running in a few minutes (without having to hunt for various modules, or applications), or sifting through outdated wiki pages trying to figure out how to even get started or even get up and running, but to be honest most people just want something VERY easy to use, VERY easy to setup, and would love a nice GUI interface (like WixTD, etc.) that they can use to administer the server, add users, etc. Most laypeople don't want to hire a software engineer, or a programmer, just to get OpenSim to compile, or even get a module working, or just to get OpenSim running on a machine. If I want to use a plugin with Firefox, I've NEVER had to compile or debug code. If I want to enable a PHP module, I've NEVER had to debug any code. Most modules are included in the default distro, and modules can easily be turned on and off, by simply enabling them in the default ini (configuration) file. In my opinion, you may be confusing extensible system as an excuse as to why nothing should work properly. In my opinion, EVERY single working module that exists for OpenSim should be included in the default distro (in the modules directory), and these modules should ALL be disabled by default, but can be easily enabled by simply uncommenting out ONE single line in the default.ini configuration file. Include EVERY single working module with the default OpenSim distro, so users have a list of default working modules that are regularly updated so that they actually work (and are not broken), so that when a stable release comes out, a user can just enable or disable whatever modules they wish to use (by uncommenting out a line or two in the default .ini configuration file) and
Re: [Opensim-dev] OpenSim 0.7 Release Candidate with ALL working OpenSim Modules
There's only a handful of those at best (diva, osgrid, new world grid, realXtend,...). But it's probably really not a bad idea. I think what Diva is doing (the 'Diva Distribution') is exactly where things should be heading. Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Robert A. Knop Jr. Sent: Wednesday, 30 September 2009 4:12 PM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] OpenSim 0.7 Release Candidate with ALL working OpenSim Modules On Thu, Oct 01, 2009 at 12:51:49AM +0200, Melanie wrote: OpenSim Core is not a maker of distros. We are not a product company. We are a loose association of people who share an interest. We don't _want_ to make a product, because we can't support a product. We make bits and pieces and let those with support staff handle productizing it. It would be *great*, though, if the front page of opensimulator.org pointed folks to places where they could download and get a product. People come there looking to experiment with running opensimulator. If the page can point them to an easy as possible place to get and install a distribution, that'd be a benefit for all. -- --Rob Knop E-mail:rk...@pobox.com Home Page: http://www.pobox.com/~rknop/ Blog: http://www.sonic.net/~rknop/blog/ ___ 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] Mega Regions and PAL support in OpenSim?
There are four people I know of who have done fairly substantial work with OpenSim's physics engines: - MW (wrote the original interfaces) - Teravus (made ODE 'not suck' ... as much) - Jeff Ames (wrote the MICA one) - Leon Zhu (works for me, did some substantial work on the BulletX plugin, but is currently a bit busy to field questions on this list) Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Robert A. Knop Jr. Sent: Wednesday, 30 September 2009 6:36 PM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Mega Regions and PAL support in OpenSim? On Wed, Sep 30, 2009 at 06:23:56PM -0700, Dahlia Trimble wrote: We're watching PAL and may consider it when we find it to be sufficient for use with OpenSim. Another factor to consider is the majority of OpenSim developers are unpaid volunteers and it's difficult to find people who have the knowledge and expertise for implementing physics simulations and are willing to donate their time and services. If you have this expertise or know of someone else who would be willing to help implement PAL then please do consider creating a PAL module and donating it to the community. I fully understand (at this point) the MICASim Physics module and how it interacts; thanks to ter_afk (on IRC-- I wish I knew his real name!) for some pointers on getting the message back that the scene needs to get updated info from the physics sim. I have figured out a bunch of what needs to happen, but not all of it. Could somebody point me to where I'd look to understand what taints are all about WRT a physics engine? I have various interests in physics engines, what with being a physicist and the last one to hack the MICA code -- --Rob Knop E-mail:rk...@pobox.com Home Page: http://www.pobox.com/~rknop/ Blog: http://www.sonic.net/~rknop/blog/ ___ 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] Thoughts on adding a generic key-value storage system to OpenSim?
I think something that has emerged a lot in the last year is the scalability properties of key-value stores. You can get them up to gigantic sized databases fairly efficiently; definitely more so than a conventional DB. It would however be nice if we could get some kind of struct format for serialising/deserialising data and knowing how to decode it implicitly. (XML, JSON?) Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Stefan Andersson Sent: Monday, 21 September 2009 10:36 PM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Thoughts on adding a generic key-value storage system to OpenSim? John, I'm not a big fan of tall/skinny untyped string/string storage, as I believe that approach always come back to bite you in the ass in the end. Adam F did propose the same thing a year ago, and I was against it then as well. Since then, my stance has softened somewhat, as there hasn't really emerged any other option than nhibernate (but still, wouldn't that be an option?) If you can just turn string GetValue(string context, string key) into bool TryGetValue(string context, string key, out string value) embracing the Try pattern, I'm 0 on it. I'm presuming that you're going to implement a behind-the-scene module-unique identifier also, so modules don't clash on context? I would suggest having an IGenericDataStore factory that produces handlers that are private to the modules. /Stefan -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Hurliman, John Sent: den 21 september 2009 22:05 To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Thoughts on adding a generic key-value storage system to OpenSim? Formatting got messed up, that should have looked like this: // returns true if the key was found and data was updated, otherwise false if a new key row was added bool AddOrUpdateKeyValue(string context, string key, string value); // returns true if the key was found and deleted bool DeleteKeyValue(string context, string key); // returns the string value if the key was found, otherwise null string GetValue(string context, string key); -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Hurliman, John Sent: Monday, September 21, 2009 12:54 PM To: opensim-dev@lists.berlios.de Subject: [Opensim-dev] Thoughts on adding a generic key-value storage system to OpenSim? A lot of the work going into OpenSim recently has been modularizing the codebase and making it easy for third party developers to write plugins. One feature that I think would really complete the picture would be a (simple) generic data storage interface that leveraged the existing OpenSim storage framework. Most plugins I've seen (and wrote) currently tack on their own database tables, use a simple text file with a custom format, or use some other means of data storage that does not match up with the rest of OpenSim. Adding a new database table that had three columns: [context, key, value] would allow plugins to store key/value mappings (string to string) without worrying about data collisions between plugins or having to implement a custom data store every time. // returns true if the key was found and data was updated, otherwise false if a new key row was added bool AddOrUpdateKeyValue(string context, string key, string value); // returns true if the key was found and deleted bool DeleteKeyValue(string context, string key); // returns the string value if the key was found, otherwise null string GetValue(string context, string key); Although I've been writing extensions for the OpenSim codebase for quite a while, I'm still fairly new to the guts of the system. Does this seem like the correct solution? If so, where would this interface go? I'm happy to write the code to implement this, I just want feedback from the dev community first to see if I'm on track. John ___ 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] Prepackaged OpenSim installs
The OSGrid Binary Installs are generally pretty good - Neb does a good job with them. I generally use them whenever I need a quick region setup. Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Robert A. Knop Jr. Sent: Saturday, 19 September 2009 8:23 AM To: opensim-dev@lists.berlios.de Subject: [Opensim-dev] Prepackaged OpenSim installs On Sat, Sep 19, 2009 at 04:31:26AM -0500, Len Brown wrote: Surely, a single page step by step account of (at least) how to configure and run OpenSim is, in essence, MANDATORY. Otherwise all the hard work and effort on the project is absolutely worthless. If the average person cannot get a single stand-alone region running on their home computer within 5 or 10 minutes then it's all in vain. I'm entirely a Linux user myself, so I don't know the answer to this, but -- there are binary distros for windows available, are there not, for OpenSim? How friendly are they to get started? Next question : is there somebody in the OpenSim team who's taken on the mantle of providing binary distros and making it easy to install? I'll look into it, but I might be willing to try to take up the job of providing at least some of that for Linux builds. (Aside: I'm a n00b to opensim-dev. To those who haven't met me on IRC, I'm Rob Knop, itenerant astrophysicist computer engineer. I was a professor of Physics Astronomy at Vanderbilt until 2007, and from 2007 to 2009 was Prospero Linden, production operations engineer and later server release manager for Linden Lab. I currently don't have long-term employement, but am working with MICA (www.mica-vw.org) on N- body simulations, and using virtual worlds as both a collaboration platform and a visualization platform. This has naturally led me to OpenSim as an open source server that lets us do fun things you can't do without source code and your own servers running the code) -- --Rob Knop E-mail:rk...@pobox.com Home Page: http://www.pobox.com/~rknop/ Blog: http://www.sonic.net/~rknop/blog/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] The return of short version numbers (as tags)
Handy! -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Teravus Ovares Sent: Tuesday, 8 September 2009 7:18 AM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] The return of short version numbers (as tags) http://teravus.wmcv.com/googletester/GitLog.jpg Regards Teravus On Tue, Sep 8, 2009 at 10:10 AM, Frisby, Adama...@deepthink.com.au wrote: Where do we see this number? And is there any way to easily translate between the two? Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Sean Dague Sent: Tuesday, 8 September 2009 5:14 AM To: opensim-dev Subject: [Opensim-dev] The return of short version numbers (as tags) Late last week I found a script that tags each changeset that comes into the server with an increasing number. When you pull on master, you'll see these tags now flow down. Because the nature of distributed version control, this is only going to give you a rough idea of forward or backward in time. Commits are made locally, and only when merged into the master server do they get an id. http://github.com/opensim/opensim/network will give an idea of the complex dance of changesets and why this is never going to be fully linear. But, that being said, the lack of a short version number like that is the #1 issue (by vocalness) that people were having with git. Hopefully this helps that. This short version number only means anything if you are getting your tree from the main opensim archive. -Sean -- __ Sean Dague Mid-Hudson Valley sda...@gmail.com Linux Users Group http://dague.net http://mhvlug.org There is no silver bullet. Plus, werewolves make better neighbors than zombies, and they tend to keep the vampire population down. __ ___ 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] The return of short version numbers (as tags)
Where do we see this number? And is there any way to easily translate between the two? Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Sean Dague Sent: Tuesday, 8 September 2009 5:14 AM To: opensim-dev Subject: [Opensim-dev] The return of short version numbers (as tags) Late last week I found a script that tags each changeset that comes into the server with an increasing number. When you pull on master, you'll see these tags now flow down. Because the nature of distributed version control, this is only going to give you a rough idea of forward or backward in time. Commits are made locally, and only when merged into the master server do they get an id. http://github.com/opensim/opensim/network will give an idea of the complex dance of changesets and why this is never going to be fully linear. But, that being said, the lack of a short version number like that is the #1 issue (by vocalness) that people were having with git. Hopefully this helps that. This short version number only means anything if you are getting your tree from the main opensim archive. -Sean -- __ Sean Dague Mid-Hudson Valley sda...@gmail.com Linux Users Group http://dague.net http://mhvlug.org There is no silver bullet. Plus, werewolves make better neighbors than zombies, and they tend to keep the vampire population down. __ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] ConsoleClient -pass option
I have to second this motion - XMLRPC in my opinion is a lot better for remote programming than REST which doesn't really define the wire formats nor datatypes. The ICommander interface we are now using on the console really suits XMLRPC well - since we already have a list of defined arguments available, and can build nice remote-access documentation from them automatically. In addition, we can use the exact same format arguments as the console commands. Regards, Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Dickson, Mike (ISS Software) Sent: Friday, 4 September 2009 8:05 AM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] ConsoleClient -pass option Thanks for the pointer Melanie. No I wasn't aware of it. I'll have a look. I'm pretty sure I don't agree however that a simple GET/PUT interface is somehow just better than (dated!) XML/RPC (or some other protocol where the on the wire data types are actually defined). That's creeping towards a religious discussion however so I'll drop it. Having the console functionality packages separate like this is the important feature IMO. Mike -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Melanie Sent: Friday, September 04, 2009 9:59 AM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] ConsoleClient -pass option Have you ever looked at the REST console? That is precisely what it does, it removes the local console, enabling the process to run as a daemon, and allows remote connections from a console application. Only, it doesn't use the (dated) XMLRPC, it uses RESTful requests. XMLRPC admin is only available in region servers, and is too limited a tool even if beefed up to ever replace a console. Melanie Dickson, Mike (ISS Software) wrote: Right. That gets around the issue. BTW, if the server is running SNMP or something that gives access to the process list this problem can leak outside the local machine. I don't for sure but I'm guessing you could have the same issue in Windows with WMI. IMO, the right answer is to dump the consoles, beef up the XML/RPC admin interface and if desired do a separate console app that parses and sends the XML/RPC to the server. I've been noodling on that but still struggling with a stable config with the new BUST architecture. Mike -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Dr Scofield Sent: Friday, September 04, 2009 3:19 AM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] ConsoleClient -pass option Dickson, Mike (ISS Software) wrote: I'd agree with Dave on this one. Just a simple long ps listing gets you the password if its on cleartext on the command line. At least the file can be locked down via permissions. A password on the command line is pretty much insecure. Might as well not have one. ...unless you rewrite argv (which is standard practise for stuff like that). DrS/dirk Mike -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Melanie Sent: Thursday, September 03, 2009 10:02 PM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] ConsoleClient -pass option It's choosing the lesser evil. Melanie Dave Coyle wrote: On Thursday 03 September 2009 03:00:46 pm wrote: commit 6b70b5709913e9734f5864560e997b34dfd58b85 Author: Justin Clark-Casey (justincc) jjusti...@googlemail.com Date: Thu Sep 3 20:00:18 2009 +0100 * Add extra warning about using -pass in OpenSim.ConsoleClient.ini.example ... +; Please be aware that this is not secure since the password is in the clear +; we recommend the use of -pass wherever possible ;pass = secret Is the password not also in the clear, visible to any local user who does a 'ps', if you use the -pass switch? Access to OpenSim.ConsoleClient.ini can at least be restricted to specific user(s). I don't see how -pass is the lesser of the two evils. -coyled --- - ___ 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
Re: [Opensim-dev] OpenSim-Commits question
I think it's berlios that might be rejecting - nonetheless, I requested the subdomain get added, so it should be there soon. Adam -Original Message- From: Teravus Ovares [mailto:tera...@gmail.com] Sent: Monday, 31 August 2009 10:15 AM To: opensim-dev@lists.berlios.de Cc: Frisby, Adam Subject: Re: [Opensim-dev] OpenSim-Commits question Is this something that we can add an /etc/hosts entry in temporarily? Regards Teravus On Mon, Aug 31, 2009 at 12:00 PM, Sean Daguesda...@gmail.com wrote: Ursula MATOVA wrote: Hi All, Just a basic question ... :) Is it normal that I didn't receive any more messages on the opensim- commits mailing list ? Last I have received is from 2009/08/22 ( Git #1e4238af... ) Regards, Ursula. The email is all being held because the sending domain 'pinky.opensimulator.org' no longer exists. Adam, can you fix this when you get a chance? The email should flow after that point. -Sean -- __ Sean Dague Mid-Hudson Valley sda...@gmail.com Linux Users Group http://dague.net http://mhvlug.org There is no silver bullet. Plus, werewolves make better neighbors than zombies, and they tend to keep the vampire population down. __ ___ 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-Commits question
I think it's done via CIA actually automatically (don't quote me) Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Teravus Ovares Sent: Thursday, 27 August 2009 6:25 PM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] OpenSim-Commits question That might be a cron job that sdague setup. He's on vacation though, so, if it isn't working at the moment, then it may be down until he's back.I was able to get the svn mirror, mantisbot and panda builds running again but I didn't see one for the opensim-commits list yet. If I spot it, I'll get it running again. If not, it'll be running again shortly after sdague gets back. Regards Teravus On Thu, Aug 27, 2009 at 7:32 PM, Ursula MATOVAursula.mat...@klintcentral.net wrote: Hi All, Just a basic question ... :) Is it normal that I didn't receive any more messages on the opensim- commits mailing list ? Last I have received is from 2009/08/22 ( Git #1e4238af... ) Regards, Ursula. ___ 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] LookingGlass in Wright Plaza
Second suggestion - don't run debug builds. At stuff like geometry manipulation, the lack of inlining functions/etc causes a major major performance penalty. Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Mister Blue Sent: Tuesday, 25 August 2009 10:17 PM To: opensim-dev Subject: [Opensim-dev] LookingGlass in Wright Plaza The LookingGlass viewer forge project[1] reached a milestone last night of allowing me to walk and fly around Wright Plaza. If you ever see an avatar by the name of Charm DeSnoozle stumbling around OSGrid, that's me testing LookingGlass. I made a video of the experience [2]. You can see that the frame rate is very low and my overly aggressive object culling makes turning a reloading experience. My work so far has been getting correct prim representation and the framework in place. There are some texturing errors (some textures are upside down and the textures on the tree leaves are on the wrong sides of the prims) but, in general, the current display is pretty close. I hope to get the frame rate up and package this so there is a viewer framework for people to build on. More information is available at the LookingGlass web site[3]. -- ra [1] http://forge.opensimulator.org/gf/project/lookingglass/ [2] http://www.youtube.com/watch?v=88TZdYZTOkw [3] http://lookingglassviewer.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
Re: [Opensim-dev] DNS Notice
This has been transferred, however there is a glitch with the wildcard record - getting that fixed. Adam From: opensim-core-boun...@lists.berlios.de [mailto:opensim-core-boun...@lists.berlios.de] On Behalf Of Frisby, Adam Sent: Saturday, 22 August 2009 2:24 PM To: opensim-dev@lists.berlios.de; opensim-us...@lists.berlios.de; opensim-c...@lists.berlios.de Subject: [opensim-core] DNS Notice Hi everyone, We're going to be switching the nameservers for opensimulator.org and forge.opensimulator.org domains on Monday the 24th. (ie, this Monday). In theory there should be no disruption to the services; however the chance exists that sometime during Monday, the site will be inaccessible. (It's just going between different nameservers on the same ISP, so should be relatively safe) The IPs for the site should be: opensimulator.org 71.6.131.152 forge.opensimulator.org 66.240.236.69 If you have any trouble accessing the sites on Monday - you can put the above into your hosts file. Regards, Adam ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
[Opensim-dev] DNS Notice
Hi everyone, We're going to be switching the nameservers for opensimulator.org and forge.opensimulator.org domains on Monday the 24th. (ie, this Monday). In theory there should be no disruption to the services; however the chance exists that sometime during Monday, the site will be inaccessible. (It's just going between different nameservers on the same ISP, so should be relatively safe) The IPs for the site should be: opensimulator.org 71.6.131.152 forge.opensimulator.org 66.240.236.69 If you have any trouble accessing the sites on Monday - you can put the above into your hosts file. Regards, Adam ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] .NET 3.5 support
We're on the subset Mono 2.0.1 supports. As soon as 2.4 becomes standard, we may upgrade to 2.4 (which is fairly complete as far as 3.5 is concerned) I believe HashSet is safe to use however. The buildbot on Panda is the ultimate arbiter - if it compiles there, it's safe to use. Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Lake, Dan Sent: Tuesday, 18 August 2009 6:13 PM To: opensim-dev@lists.berlios.de Subject: [Opensim-dev] .NET 3.5 support It looks like the default build for OpenSim projects was recently changed to .NET 3.5. Can a submitted patch include features from .NET 3.5 such as HashSet? Are all 3.5 features supported by Mono? Thanks, Dan lake Software Engineer Visual Applications Research Microprocessor Programming Research Intel Labs 503.712.8318 dan.l...@intel.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] pruning reference servers in core
If OSGrid isn't already, we may begin doing testing on ROBUST. We have pretty decent stats on things such as memory leaks over time, so we can observe how it performs in a high usage environment. Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Melanie Sent: Thursday, 13 August 2009 12:43 PM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] pruning reference servers in core Thing is, that would make the new old servers actually be ROBUST. The concern that has been voiced is that ROBUST needs more testing and not all grids are willing to switch yet. What you propose would force them to switch, through the back door. While I'm all for that, it would achieve the same thing as simply removing A and I, namely, make people use ROBUST. Some don't want that yet. Melanie Fly Man wrote: Why wait until September when the solution is already on the Wiki: 1) Delete the old Grid.Asset and Grid.Inventory servers 2) Copy the new OpenSim.Server.exe to OpenSim.Grid.AssetServer.exe and OpenSim.Grid.InventoryServer.exe 3) Copy the .config files: OpenSim.Grid.AssetServer.exe.config and OpenSim.Grid.InventoryServer.exe.config and edit them so they'll use the same log file like they did before 4) Create the new OpenSim.Grid.AssetServer.ini and OpenSim.Grid.InventoryServer.ini like mentioned on the Wiki 5) Edit those like mentioned and run them I think the solution to this problem is easily fixed by doing this and commiting the whole bunch again then waiting until September 2009/8/13 d...@metaverseink.com: I'm fine with waiting until September before pruning reference implementations down to one of each. But someone needs to give love to Grid.Inventory, because I don't have time for loving so many servers :-) The current improvement I'm doing right now (eliminating the need to pass the entire inventory around) only works for the new-style inventory service. It can easily be made to work for the old one. Whoever wants Grid.Inventory to support the simulators' [much more reasonable] needs should make the necessary improvements to it. I'll be happy to explain what the server needs to do -- 2 additional service handlers. I still haven't pushed my local commits, and I can wait a little bit for a Grid.InventoryServer lover to step up and volunteer. But I don't think it's reasonable to hold this improvement until September; I already have it, and it's almost ready to be pushed out to grids out there. Passing thousands of inventory items upon region crossings and TPs is probably one of the worst things in OpenSim right now, and needs fixing. MW wrote: I'm fine with the AssetInventoryServer being removed as soon as possible because I don't think anyone uses it. But believe we should at least wait a couple of more weeks before the Grid.InventoryServer and Grid.AssetServer are removed, so that everyone gets a chance to have their say/vote. As a number of people are on vacation around this time. Personally as long as the ROBUST servers are fully tested on multiple grids that have a quite heavy load/userbase, then I'm okay with removing the old servers, as long as there is total agreement; I know a few people have said they don't want to swap to ROBUST. --- On *Tue, 11/8/09, Frisby, Adam /a...@deepthink.com.au/* wrote: From: Frisby, Adam a...@deepthink.com.au Subject: Re: [Opensim-dev] pruning reference servers in core To: opensim-dev@lists.berlios.de opensim- d...@lists.berlios.de Date: Tuesday, 11 August, 2009, 10:09 PM Please do. I'd like a 0.6.X release shortly after every networkinterface version change if possible - since it makes compat with the latest stable release always a headache. Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de /mc/compose?to=opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de /mc/compose?to=boun...@lists.berlios.de] On Behalf Of Justin Clark-Casey Sent: Tuesday, 11 August 2009 12:04 PM To: opensim-dev@lists.berlios.de /mc/compose?to=opensim-...@lists.berlios.de Subject: Re: [Opensim-dev] pruning reference servers in core d...@metaverseink.com /mc/compose?to=d...@metaverseink.com wrote: Dear devs, I'm finally changing the way the simulator caches inventory. This is all good, and it's the beginning of the much awaited user services refactoring. This requires a few small changes in the inventory services interface, as well as additions to the implementation(s). So... We now have 3 -- yes 3! -- different inventory servers in core. (and 3 asset
Re: [Opensim-dev] pruning reference servers in core
Update: apparently we're already running it - at least for Inventory. Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Frisby, Adam Sent: Thursday, 13 August 2009 8:06 PM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] pruning reference servers in core If OSGrid isn't already, we may begin doing testing on ROBUST. We have pretty decent stats on things such as memory leaks over time, so we can observe how it performs in a high usage environment. Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Melanie Sent: Thursday, 13 August 2009 12:43 PM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] pruning reference servers in core Thing is, that would make the new old servers actually be ROBUST. The concern that has been voiced is that ROBUST needs more testing and not all grids are willing to switch yet. What you propose would force them to switch, through the back door. While I'm all for that, it would achieve the same thing as simply removing A and I, namely, make people use ROBUST. Some don't want that yet. Melanie Fly Man wrote: Why wait until September when the solution is already on the Wiki: 1) Delete the old Grid.Asset and Grid.Inventory servers 2) Copy the new OpenSim.Server.exe to OpenSim.Grid.AssetServer.exe and OpenSim.Grid.InventoryServer.exe 3) Copy the .config files: OpenSim.Grid.AssetServer.exe.config and OpenSim.Grid.InventoryServer.exe.config and edit them so they'll use the same log file like they did before 4) Create the new OpenSim.Grid.AssetServer.ini and OpenSim.Grid.InventoryServer.ini like mentioned on the Wiki 5) Edit those like mentioned and run them I think the solution to this problem is easily fixed by doing this and commiting the whole bunch again then waiting until September 2009/8/13 d...@metaverseink.com: I'm fine with waiting until September before pruning reference implementations down to one of each. But someone needs to give love to Grid.Inventory, because I don't have time for loving so many servers :-) The current improvement I'm doing right now (eliminating the need to pass the entire inventory around) only works for the new-style inventory service. It can easily be made to work for the old one. Whoever wants Grid.Inventory to support the simulators' [much more reasonable] needs should make the necessary improvements to it. I'll be happy to explain what the server needs to do -- 2 additional service handlers. I still haven't pushed my local commits, and I can wait a little bit for a Grid.InventoryServer lover to step up and volunteer. But I don't think it's reasonable to hold this improvement until September; I already have it, and it's almost ready to be pushed out to grids out there. Passing thousands of inventory items upon region crossings and TPs is probably one of the worst things in OpenSim right now, and needs fixing. MW wrote: I'm fine with the AssetInventoryServer being removed as soon as possible because I don't think anyone uses it. But believe we should at least wait a couple of more weeks before the Grid.InventoryServer and Grid.AssetServer are removed, so that everyone gets a chance to have their say/vote. As a number of people are on vacation around this time. Personally as long as the ROBUST servers are fully tested on multiple grids that have a quite heavy load/userbase, then I'm okay with removing the old servers, as long as there is total agreement; I know a few people have said they don't want to swap to ROBUST. --- On *Tue, 11/8/09, Frisby, Adam /a...@deepthink.com.au/* wrote: From: Frisby, Adam a...@deepthink.com.au Subject: Re: [Opensim-dev] pruning reference servers in core To: opensim-dev@lists.berlios.de opensim- d...@lists.berlios.de Date: Tuesday, 11 August, 2009, 10:09 PM Please do. I'd like a 0.6.X release shortly after every networkinterface version change if possible - since it makes compat with the latest stable release always a headache. Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de /mc/compose?to=opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de /mc/compose?to=boun...@lists.berlios.de] On Behalf Of Justin Clark-Casey Sent: Tuesday, 11 August 2009 12:04 PM To: opensim-dev@lists.berlios.de /mc/compose?to=opensim-...@lists.berlios.de Subject: Re: [Opensim-dev] pruning reference servers in core d...@metaverseink.com /mc/compose?to=d
Re: [Opensim-dev] pruning reference servers in core
Release fairy is any core dev, but usually ckrinke lately. I hear r10108 was a decent release, but might be a little bit behind. Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of d...@metaverseink.com Sent: Tuesday, 11 August 2009 2:48 PM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] pruning reference servers in core I would really appreciate it if the release fairy would do her magic again! -- around now. Who is the release fairy? Frisby, Adam wrote: Please do. I'd like a 0.6.X release shortly after every networkinterface version change if possible - since it makes compat with the latest stable release always a headache. Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Justin Clark-Casey Sent: Tuesday, 11 August 2009 12:04 PM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] pruning reference servers in core d...@metaverseink.com wrote: Dear devs, I'm finally changing the way the simulator caches inventory. This is all good, and it's the beginning of the much awaited user services refactoring. This requires a few small changes in the inventory services interface, as well as additions to the implementation(s). So... We now have 3 -- yes 3! -- different inventory servers in core. (and 3 asset servers too). I think it's time to make a decision on what to keep and what to drop, because evolving this ecosystem of implementations in core is unscalable. With this, I'm proposing that we drop the old Grid.InventoryServer, the old Grid.AssetServer and the AssetInventoryServer (CB1). Some people may still be using the old servers, so it's time to switch everybody to ROBUST. Asking in the IRC, it looks like no one is using AssetInventoryServer. Comments? Objections? Might be an idea to knock out a 0.6.7 first before making that switch. -- justincc Justin Clark-Casey http://justincc.wordpress.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 ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] pruning reference servers in core
Please do. I'd like a 0.6.X release shortly after every networkinterface version change if possible - since it makes compat with the latest stable release always a headache. Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Justin Clark-Casey Sent: Tuesday, 11 August 2009 12:04 PM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] pruning reference servers in core d...@metaverseink.com wrote: Dear devs, I'm finally changing the way the simulator caches inventory. This is all good, and it's the beginning of the much awaited user services refactoring. This requires a few small changes in the inventory services interface, as well as additions to the implementation(s). So... We now have 3 -- yes 3! -- different inventory servers in core. (and 3 asset servers too). I think it's time to make a decision on what to keep and what to drop, because evolving this ecosystem of implementations in core is unscalable. With this, I'm proposing that we drop the old Grid.InventoryServer, the old Grid.AssetServer and the AssetInventoryServer (CB1). Some people may still be using the old servers, so it's time to switch everybody to ROBUST. Asking in the IRC, it looks like no one is using AssetInventoryServer. Comments? Objections? Might be an idea to knock out a 0.6.7 first before making that switch. -- justincc Justin Clark-Casey http://justincc.wordpress.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] Main Repository now in Git
Does that store the date of last 'commit' or current revision? If we're replacing the version number from 0.X.Y.SVNNUM - I think we should probably use: 0.X.DDMM.GITHASH - since the DDMM is going to be a lot easier to type. Adam From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of James Stallings II Sent: Thursday, 6 August 2009 4:39 PM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Main Repository now in Git Greetings List :) Just wanted to drop a line to the list and let you all know that we've (OSGrid Core Team) done a bit of research and determined the location of the file in the which git stores the hash for the the checked out tree (for lack of better terminology). I am personally finishing up a patch at the moment to replace the appearance of the svn revision number with the git hash where it has been present before (in the client, at region server startup and at in the region server's 'show version' command output). Please bear with me, I am not a core dev either and fumble a bit here and there with the tools, but I am rapidly improving my skills ;) I will notify the list as soon as I have the patch ready. ETA: sometime this evening CST. Hope this eases some concerns among you. Cheers! James On Thu, Aug 6, 2009 at 6:20 PM, Ursula MATOVA ursula.mat...@klintcentral.netmailto:ursula.mat...@klintcentral.net wrote: Hey Sean ... I know it's hard work ... My post was just comments/feeling about the migration from svn to git ... ` On my side ( I'm not a core-dev, just trying to be an active reporter ) I need to be able to migrate my OpenSim server to the latest current release to test some new feature/improvments and to be able to quick reverse to the previous release in case of problems ( it's normal when working with dev branch ) ... And all is based on the release number ... ... We were in SVN. #10115 ... Then what about now ? It's not clear at all, don't know the current release number ... ... do you know it ? What changes ? .../... When checking the git repository, I'm not sure to checkout the latest dev release ... is it ? or is it the stable branch ? Sorry, maybe my english is not good enough to follow the git/wiki instructions ... Could you provide a kind of digest for git noobs ( like me ) to keep track of the latest release ? or some specific release ? Anyway, I really appreciate everybody's work ... ( even 1st April jokes ) ... ... ... So, my feeling is not really important, I'll adapt myself, it'll be only a bit more difficult for us to report bugs ... Regards, Ursula. Le 6 août 09 à 13:42, Sean Dague a écrit : Ursula MATOVA wrote: Sure you're right ... let's go to git then :) But, is it possible to change the OpenSim Commits posts ? Really, it's un-useful and unreadable ... Yes, I'm working at changing that to something more readable, we'll need a few more commits going through before I figure out if I've fixed that. Also, there is an rss feed off of http://opensimulator.org/viewgit. I've found that to be a very useful way to keep up on things as well. -Sean -- __ Sean Dague Mid-Hudson Valley sda...@gmail.commailto:sda...@gmail.com Linux Users Group http://dague.net http://mhvlug.org There is no silver bullet. Plus, werewolves make better neighbors than zombies, and they tend to keep the vampire population down. __ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.demailto:Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.demailto:Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev -- === http://osgrid.org http://del.icio.us/SPQR 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] Temporary Assets now being pushed to grid
Hey folks, Myself and Nebadon have been curious about why OSGrid's asset server has been growing assets at a quadrupled rate in the last 2 weeks. It seems we're getting entries marked temporary being committed to the central server. (stats available at http://assets.osgrid.org/stats/ - look at Total Assets # on the year chart) Temporary assets should be being committed only to local asset caches, and not pushed upstream further - can someone take a look at this? Thanks Adam ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Inventory loss
It's worth also noting the clientside inventory skeleton can get corrupted - clearing cache will often restore supposedly missing inventory. Adam From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Nebadon Izumi Sent: Monday, 27 July 2009 10:39 PM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Inventory loss I don't recall OSgrid really getting many complaints about it either, infact i do not recall any, I am not saying its never occured, but its so minimal its not something i ever remember occuring, even when our whole asset table corrupted, we were able to get 100% recovery, i think we lost 1 asset. We run on MySQL, but run fragstore for blob storage, any grids still storing blobs inside the database is going to be in major trouble if they don't switch, storing blobs inside of any of the currently available database systems OpenSim's core is really a terrible idea and should not be done for anything that is considered a production level type grid. Neb On Mon, Jul 27, 2009 at 6:39 AM, Chris Hart ch...@codetorque.co.ukmailto:ch...@codetorque.co.uk wrote: From MSSQL side of the grid fence, I haven't had anyone complain of lost inventory to me - we did until recently have some lost assets after SI sessions due to asset server crashing - previously the code would attempt to store assets with descriptions bigger than database field length. This seemed to happen mostly with SI uploaded items but also was 100% reproducible if you had a sim with a long name and a parcel with a long name and attempted to create a landmark - there are checks now to stop this from happening that Justin kindly committed (and he was good enough to add similar checks for MySQL) and we've not had a crash since applying that patch over a week and a half ago. In terms of actual inventory, no-one has reported loss of specific items. Sometimes slow to load, but not loss. Is this something that has happened since 0.6.6 tag? Chris -Original Message- From: opensim-dev-boun...@lists.berlios.demailto:opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.demailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Melanie Sent: 27 July 2009 14:32 To: opensim-dev@lists.berlios.demailto:opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Inventory loss Those MySQL issues listed below and others like it are corner cases that OpenSim would never trigger. OpenSim is a very simplistic database user, it doesn't even really use any relational features of the database. So, I don't think that MySQL errors are something we need to concern ourselves with at this point. Especially, your suggestion would not help in those cases, as they are all about complete loss of rows. That is unaffected by a deleted type flag. That is neither here nor there anyway, since such a deleted flag would have to live under OpenSim.Data.. It has no business being in core at all. Melanie Colin B. Withers wrote: Reason I wondered is simply the number of websites dedicated to recovering from MYSQL database corruption, and offering tools for the same. Google returns over 250,000 sites for 'mysql database corruption'. MYSQL has had numerous bug fixes to fix database corruption, introduced by differing versions of MYSQL, eg Fixed in 4.0.18 INSERT DELAYED ... SELECT ... could cause table corruption because tables were not locked properly. This is now fixed by ignoring DELAYED in this context. (Bug #1983) Fixed in 4.0.16 Fixed bug in overrun check for BLOB values with compressed tables. This was a bug introduced in 4.0.14. It caused MySQL to regard some correct tables containing BLOB values as corrupted. (Bug #770, Bug #1304, and maybe Bug #1295) Fixed in 4.0.15 Fixed rare bug in MYISAM introduced in 4.0.3 where the index file header was not updated directly after an UPDATE of split dynamic rows. The symptom was that the table had a corrupted delete-link if mysqld was shut down or the table was checked directly after the update. Fixed in 4.0.14 Comparison/sorting for latin1_de character set was rewritten. The old algorithm could not handle cases like sä ßa. See section 5.6.1.1 German character set. In rare cases, it resulted in table corruption. and so on.. My own experience with Opensim is that in the last 12 months there has been three occasions where residents complained of stuff 'missing' (not a single resident, but several at once) and a roll-back to the last database backup cured the problems. Rock -Original Message- From: opensim-dev-boun...@lists.berlios.demailto:opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.demailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Melanie Sent: Monday, July 27, 2009 2:07 PM To: opensim-dev@lists.berlios.demailto:opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Inventory loss IMHO,
Re: [Opensim-dev] Very Good Git Book
I can tell you pretty safely; OpenSim’s SVN repository is probably several GB. Our standard distribution at several points in time was = 100mb. (a lot of binaries). So we’re going to be hosting ourselves for the foreseeable future I think. Adam From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Christophe, Jean-Charles Narbonne Sent: Tuesday, 28 July 2009 6:02 AM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Very Good Git Book GitHub allow 300MB, it as a bigger community, it has more feature and stats, a fork create a new branch but it cost no place because it's linked to the original project (only diff added is counted in the 300 Mo)... I'm not sure it would be limitant... but Git hub is probably today the best free GUI for git. (free as free bear) Sean Dague: There aren't any plans that this point, we'll have our own git tree hosted locally. I suppose once we turn to git, a branch would go on github/gitorious and one of you should have to pull from this branch... I agree with Mevlin gitorious have less limitation, and if you want to host it you can (but it will not increase the community power as much as go on gitorious or github) -- Thanx to free software. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Inventory loss
Sounds fine to me - however I would give pause before encouraging anyone to use 'no-copy' -- while this particular solution should work for routine issues; no-copy is fundamentally incompatible with the ideas of doing region backups (rollbacks, etc) and other similar issues. To solve that issue more effectively; I think some kind of 'serial number' system is probably preferred - so every legitimate copy produces a new serial number; and duplication efforts result in a serial number collision. Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Thomas Grimshaw Sent: Sunday, 26 July 2009 6:55 PM To: opensim-dev@lists.berlios.de Subject: [Opensim-dev] Inventory loss Hey folks. Been thinking a lot about inventory loss in OpenSim, something that I think we should really do as much as possible to avoid. We've been experiencing numerous cases of lost inventory in K-Grid recently. What i'd like to implement, is.. When an item is removed from inventory (deleted, or rezzed if it's no-copy), it is not actually deleted by instead an available flag is set in the inventory database. All inventory queries will check for the flag and thus it will appear as deleted to the user, but it can be restored easily by an admin if needed. A timestamp should also be set which indicates when the item was made unavailable, so that routine cleanup can be performed on items which were made unavailable a long time ago. I wanted to get people's opinons of this before I implemented it in code. Can anyone think of any drawbacks or possible issues? Any further room for improvement? Cheers Thomas Grimshaw (RemedyTomm) ___ 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] Bump GridComms Version Notice
D'oh. Wasn't moving to OMVTypes supposed to avoid breaks like this? Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Teravus Ovares Sent: Saturday, 25 July 2009 2:05 PM To: opensim-dev Subject: [Opensim-dev] Bump GridComms Version Notice Hey everyone After fighting with things for a bit, I'm going to recommend bumping the version of the gridcomms. It turns out that the json serialization of the UUID type was changed in libOMV revision r2588 to a plain string. This leaves older regions expecting a 'uuid::' prefix (as was the previous format) unable to decode UUIDs and return a UUID.Zero. This will break Hypergrid and some types of region to region comms between OpenSim revisions 10081 and 10082. Regions in versions 10082 cannot talk properly to regions 10081 and below. If you try, some regions will show, some won't, you'll have border crossing issues sometimes and you'll get weird console messages. For grids who want a consistent experience, you will need to upgrade regions together so organize the effort appropriately. Unfortunately, there isn't really anything that we can do besides this except roll back the LibOMV 0.7.0 commit and stay on an older version of libOMV. There isn't any way to programmatically change, without forking OpenMetaverse.StructureData, what should go over the wire serialization. Additionally, on the receiving side, there's no way to know what was a UUID and what was a string with UUID text in it's contents so converting it there is also out of the question. Additionally, any services that make use of the json serialization are affected (json stats come to mind). Be aware of these changes 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] World map - map doesnt load on large grids
Lame SL is lame. Is anyone able to patch Hippo to fix this issue? (tx?) Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Teravus Ovares Sent: Monday, 20 July 2009 9:27 AM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] World map - map doesnt load on large grids Normally, the client requests things as they are scrolled on to, however, in OSGrid's case, the regions are way outside the normal space that the client is used to. Remember that 4096m bug that causes regions to be a void space when you teleport? That also applies to the map. In fact, on OSGrid, without a hack I created for exactly that situation, the map doesn't display at all until you click on a region space. A couple of potential solutions: 1. Move all regions within 4096 region block spaces. 2. Expand the hack that I created so that it forces sending a significantly larger amount of regions. Regards Teravus On Mon, Jul 20, 2009 at 11:31 AM, Frisby, Adama...@deepthink.com.au wrote: Does anyone know what packets/messages the client requests as the map is scrolled zoomed - right now, only the initial area is shown when you load the map. On OSGrid this represents like 10% of the total world map being visible. Adam ___ 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] World map - map doesnt load on large grids
No, I was suggesting that -- make it so we alter world map related packets/caps to reflect a lower coordinate range. The median of the grid, could be used to determine the 'center of mass' for the world map. Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Teravus Ovares Sent: Monday, 20 July 2009 10:27 AM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] World map - map doesnt load on large grids Normally the client sends a post to one of the map CAPs, and then sends a bunch of UDP requests.On OSGrid, in the 10,000 range, the client just posts to the map CAP unless you click in an empty maptile space.Since no requests are made, no maptiles show. The hack is that when the client posts to the map cap, immediately send the map data for 10 spaces above and below the region the avatar is currently in. Regards Teravus On Mon, Jul 20, 2009 at 12:54 PM, Frisby, Adama...@deepthink.com.au wrote: hackSubtract 8,000 from all coordinates for the world map?/hack (derive 8,000 from the median position on the grid) Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Frisby, Adam Sent: Monday, 20 July 2009 9:34 AM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] World map - map doesnt load on large grids Lame SL is lame. Is anyone able to patch Hippo to fix this issue? (tx?) Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Teravus Ovares Sent: Monday, 20 July 2009 9:27 AM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] World map - map doesnt load on large grids Normally, the client requests things as they are scrolled on to, however, in OSGrid's case, the regions are way outside the normal space that the client is used to. Remember that 4096m bug that causes regions to be a void space when you teleport? That also applies to the map. In fact, on OSGrid, without a hack I created for exactly that situation, the map doesn't display at all until you click on a region space. A couple of potential solutions: 1. Move all regions within 4096 region block spaces. 2. Expand the hack that I created so that it forces sending a significantly larger amount of regions. Regards Teravus On Mon, Jul 20, 2009 at 11:31 AM, Frisby, Adama...@deepthink.com.au wrote: Does anyone know what packets/messages the client requests as the map is scrolled zoomed - right now, only the initial area is shown when you load the map. On OSGrid this represents like 10% of the total world map being visible. Adam ___ 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] ipv6? (was: STUN for OpenSim?)
IPv6 will work on non-UDP protocols. Eg; the IRCd clientstack supports IPv6. LLUDP will be IPv6 incompatible as long as it relies on circuits which depend on 32bit addresses. Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Kyle Hamilton Sent: Tuesday, 14 July 2009 3:44 PM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] ipv6? (was: STUN for OpenSim?) Speaking of... is there any IPv6 work going on at this point? -Kyle H On Tue, Jul 14, 2009 at 3:15 PM, Mojito Sorbetmojitot...@gmail.com wrote: If you are running OpenSim behind a NAT router, you are going to have to configure the routing in some way, regardless of whether STUN, or even TCP, is used. That is because the connection is originating outside of the firewall, and the whole purpose of firewalls is to not let that happen, except in carefully prescribed circumstances. Same thing applies to VOIP. The problem of people not being able to find your IP address has already been solved by services such as DynDNS. On Tue, 2009-07-14 at 07:57 +0200, Stefan Andersson wrote: One of the main shortcomings of the linden-legacy model is that OpenSim does not work well (as in simple and consistent) from behind NATs and several home routers. I was thinking, if something like STUN could help us overcome this? ___ 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] Request for documentation - InventoryItems.InvType
Thanks
-Original Message-
From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
boun...@lists.berlios.de] On Behalf Of jradford
Sent: Wednesday, 15 July 2009 8:31 PM
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Request for documentation -
InventoryItems.InvType
From Libomv:
/// summary
/// Inventory Item Types, eg Script, Notecard, Folder, etc
/// /summary
public enum InventoryType : sbyte
{
/// summaryUnknown/summary
Unknown = -1,
/// summaryTexture/summary
Texture = 0,
/// summarySound/summary
Sound = 1,
/// summaryCalling Card/summary
CallingCard = 2,
/// summaryLandmark/summary
Landmark = 3,
/*
/// summaryScript/summary
//[Obsolete(See LSL)] Script = 4,
/// summaryClothing/summary
//[Obsolete(See Wearable)] Clothing = 5,
/// summaryObject, both single and coalesced/summary
*/
Object = 6,
/// summaryNotecard/summary
Notecard = 7,
/// summary/summary
Category = 8,
/// summaryFolder/summary
Folder = 8,
/// summary/summary
RootCategory = 9,
/// summaryan LSL Script/summary
LSL = 10,
/*
/// summary/summary
//[Obsolete(See LSL)] LSLBytecode = 11,
/// summary/summary
//[Obsolete(See Texture)] TextureTGA = 12,
/// summary/summary
//[Obsolete] Bodypart = 13,
/// summary/summary
//[Obsolete] Trash = 14,
*/
/// summary/summary
Snapshot = 15,
/*
/// summary/summary
//[Obsolete] LostAndFound = 16,
*/
/// summary/summary
Attachment = 17,
/// summary/summary
Wearable = 18,
/// summary/summary
Animation = 19,
/// summary/summary
Gesture = 20
}
On Wed, 15 Jul 2009 22:56:07 -0400, Frisby, Adam
a...@deepthink.com.au
wrote:
Does anyone know what the values of InventoryItems.InvType represent?
It's
an integer and represents the type of inventory; but I cant seem to
find
any documentation (either in code, or externally) about what the
integers
correlate to.
Adam
-- Jim
!DSPAM:370,4a5e9ed719051028312470!
___
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: Change module interface to indicate replacable modules
Suggested change:
Some modules need to be configurable (eg, groups needs the groups URL) -
therefore, provide a standard way of entering configuration variables into a
module that can be set at runtime before the module is fully loaded.
As an upside, we could backport that to opensim core, so people can enter
opensim.ini settings at first startup. Load the more complicated ones from
opensim.ini as a default - but some like the defaultX/defaultY, HTTP port, etc.
My suggestion would be something that resembles this in the module code:
Public void prestart(IConfig defaults) {
IConfig myModuleConfig = new NiniConfig...
Configurator config = new Configurator(); // uses STDIO
int x;
if(!(x = myModuleConfig['MyModule'].GetInteger('foo'))) {
// Validation might require better handling...
while(x 0 x 100) {
x = config.GetInteger(Value of foo?:);
}
myModuleConfig['MyModule']['x'] = x;
}
... wash, rinse, repeat ...
myModuleConfig.Save('config/mymodule.ini');
}
Maybe we can simplify that down with a bit of cleverness and re-usable functions
(eg using a lambda or delegate to handle the validation callback)
Adam
-Original Message-
From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
boun...@lists.berlios.de] On Behalf Of Teravus Ovares
Sent: Friday, 10 July 2009 5:05 PM
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Proposal: Change module interface to
indicate replacable modules
Example:
Diva created a world map module, but the one in the OpenSimulator
distribution wouldn't let Diva's module run so she had to create a
configuration flag to turn the module in the OpenSimulator
distribution off. Now, there's a complicated configuration option
for the world map module where you have to type out the object
namespace.
The groups module in OpenSimulator's distribution is a stub. We do
not intend people to use it out of the box. Therefore it makes sense
to have an implicit way to ensure that it doesn't run when there is a
replacement loaded.
Melanie doesn't think the 'replaceable modules' architecture is
maintainable and so she proposed this idea to solve the 3 goals I had
for it;
1. Explicitly declare opensim core developer's intentions for the
module to be replaceable and that we intend on users replacing the
stub with a module that is more full featured
2. Be implicit so no configuration files or options need to be managed
by the end user. This makes packaging binaries easier. You tell the
user to download a dll, and put it in the bin folder. No need to
modify the opensim.ini or the config-include folder. This is a step
in the direction of a console module downloader and loader.
3. Be resource friendly. Currently even modules that are not running
are loaded in memory. The objects are. They may not be using much
memory.. but they're still there.
My method of reaching those goals was to create stub projects in
separate dlls where the dll contains only the module. The reason for
it being a single module in the dll is that it can be overwritten with
a dll provided by someone else. I called them the
ReplaceableModules.Melanie doesn't think this is maintainable
though with the number of modules that are stuck in various 'catch
all' dlls.I'm open to other solutions as long as they accomplish
the 3 goals :).Melanie's solution does accomplish those three
goals.
Regards
Teravus
On Fri, Jul 10, 2009 at 6:28 PM, Kyle Hamiltonaerow...@gmail.com
wrote:
money.
-Kyle H
On Fri, Jul 10, 2009 at 2:09 PM, Justin
Clark-Caseyjjusti...@googlemail.com wrote:
Melanie wrote:
The intent of this change is to let a module indicate that it
wishes
it's load to be deferred until all modules have been scanned and
initialized, and to indicate that it wishes to ot be initialized if
another module has already registered it's interface.
This will allow automatically disabling modules the developer has
marked as stub modules without full functionality, so that
replacement 3rd party modules can simply be dropped into the binary
distribution and get picked up and run instead of that stub.
Could you give an example of what kind of module we'd be talking
about here? Wouldn't this apply to all modules anyway
(since in principle it should be possible to replace anything)?
--
justincc
Justin Clark-Casey
http://justincc.wordpress.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
Re: [Opensim-dev] mono *.exe crashes if screen is smaller than created...
This sounds like a NLog bug actually -- all our console output is formatted by nlog (since it also does our logging, etc) Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Torrid Luna Sent: Friday, 10 July 2009 6:50 PM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] mono *.exe crashes if screen is smaller than created... Also sprach Mojito Sorbet (mojitot...@gmail.com): Why can't the consoles just use ReadLine and WriteLine? That would make it easier to interface with in a variety of ways? +1 Coming from Unix, I had these kind of problems only with Cisco Terminals, Windows Telnet emulations and Opensim so far. stdin/stdout is so much more convenient, and it would save a lot of screen sessions. Cheers, Torrid -- Excerpts of 1 Shell Scripts -- today: monkeytypewriter $ cat /dev/random | strings | fmt | less ___ 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: Changing Runprebuild.bat
Related question: Do we support .NET 3 now? There's a number of features such as lambda expressions I'd like to begin using (mono supports them). Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Sean Dague Sent: Thursday, 2 July 2009 3:40 AM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Proposal: Changing Runprebuild.bat Stefan Andersson wrote: Guys, As we officially no longer support Microsoft Visual Studio 2005 (neither Pro nor Express) I propose we get rid of either of the runprebuild bats. My vote is for the runprebuil2008.bat to go, and upgrade runprebuild to build the vs2008 target. +1 -Sean -- __ Sean Dague Mid-Hudson Valley sda...@gmail.com Linux Users Group http://dague.net http://mhvlug.org There is no silver bullet. Plus, werewolves make better neighbors than zombies, and they tend to keep the vampire population down. __ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Adding virtual to many methods on Region/Framework/* for experimentation
If you're interested in more dramatic SOG/SOP changes - please look at the MRM IObject interface - it would be awesome if we could get SOG/SOP to inherit that interface as it makes dealing with properties on objects a lot easier. Adam From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Cristina Videira Lopes Sent: Thursday, 2 July 2009 4:04 AM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Adding virtual to many methods on Region/Framework/* for experimentation Sean Dague wrote: Stefan Andersson wrote: I would argue that opening up for (reasonable) subclassing is a very core ideal of opensim-as-an-API. And on the subject; somewhere in 0.7 land, I would argue that we have to rethink the whole scene/SOG/SOP bit - right now, state and behavior is intermingled to the degree that we cannot do anything that requires reasonable decoupling of state and behavior. Not to mention if one were to start working with using these objects in a non-core context. While I firmly agree, I've looked at that problem a couple times before, and it's big. At the end of the day OpenSim is basically that scene, then lots of things bolted on to it. So nothing so grandious from me, but just some simple experimentation of if there is a good way to have some set of synthetic server side objects coexist with the user generated objects in the same scene, and not turn into total chaos. :) I've done this before (the traffic simulation). I love synthetic objects that extend SOG, and all applications I'm involved with use them heavily. Their only weakness right now is not being able to cross borders like the other ones, because the deserialization routine hardcodes the class. We should fix that at some point. Crista ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Proposal: Changing Runprebuild.bat
That would be a 'yes' then. Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Sean Dague Sent: Thursday, 2 July 2009 4:21 AM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Proposal: Changing Runprebuild.bat Frisby, Adam wrote: Related question: Do we support .NET 3 now? There's a number of features such as lambda expressions I'd like to begin using (mono supports them). If it works in mono 2.0.1, it's fair game. That seems to be our current minimum mono revision now. -Sean -- __ Sean Dague Mid-Hudson Valley sda...@gmail.com Linux Users Group http://dague.net http://mhvlug.org There is no silver bullet. Plus, werewolves make better neighbors than zombies, and they tend to keep the vampire population down. __ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] RFC/Proposal: Explicitly serializing SOP rather than relying on .NET automatic serialization.
Speak with Mikko - he wrote a manual parser that reads our formats. We needed it at the time for ModRex. Overall however +1 on a explicit serialisation. Please leave some room to allow us to tag metadata in too. Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Justin Clark-Casey Sent: Tuesday, 9 June 2009 9:04 AM To: opensim-dev@lists.berlios.de Subject: [Opensim-dev] RFC/Proposal: Explicitly serializing SOP rather than relying on .NET automatic serialization. Hi there, (For reference, I've reproduced this rfc at http://opensimulator.org/wiki/Explicit_Object_Serialization but any comments can be made here). Up until now, when we've needed to serialize scene objects (for storage in inventory, movement over region borders, etc.), we've done so using .NET's automatic XML serialization capabilities (XmlSerializer). .NET XML serialization is convenient when completely adding or removing properties - extraneous XML elements can be simply ignored and missing ones just result in the use of a default value. But if one wants to change an existing element then things get much more difficult. For instance, suppose that you want to change the existing UUID CreatorID of SceneObjectPart to be a string instead. Because the CreatorID uses OpenMetaverse's UUID object, .NET serialization of this produces the following CreatorIDGuida6dacf01-4636-4bb9-8a97- 30609438af9d/Guid/CreatorID Simply changing the CreatorID type to String in SceneObjectPart will cause .NET to look for CreatorIDa6dacf01-4636-4bb9-8a97-30609438af9d/CreatorID on deserialization, making older assets incompatible. The alternative approach of adding a string CreatorID property alongside the existing UUID one (e.g. have both CreatorID and CreatorIDFull in SceneObjectPart) quickly runs into very nasty problems with keeping the fields in sync. Therefore, I propose that for SceneObjectPart (and later TaskInventoryDictionary) we switch to explicit XML reading and writing rather than using .NET serialization. This will allow object serializations to evolve without adding increasingly odd code to keep automatic serialization working, if that's possible at all (we already have some nasty find and replace stuff in SceneObjectSerializer.FromOriginalXmlFormat()). Serialization formats will also gain explicit version numbers. Other parts of scene object serialization, such as script state, will remain as they are now. Being explicit about serialization may also promote interop and modularization. Explicit serialization can be moved away from core and into modules rather than requiring .NET XML serialization attributes on fields in SceneObjectPart. Naturally, I expect that OpenSim out of the box will always be compatible with older serialization formats - migrating existing scene object assets is not realistically possible. Also, I propose that the behaviour when adding or removing scene object elements (as opposed to changing them) remain the same as it does with .NET serialization. In other words, older region simulators will able to read newer object serializations simply by ignoring the extra elements. Only changes to existing elements will require a region simulator upgrade and these should be rare. Comments? -- justincc Justin Clark-Casey http://justincc.wordpress.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] Rethinking inventory
Infact, GetAllInventory could be detrimental to the server on a large inventory.
Personally, I would be in favour of some kind of 'automatic subdivision' of
folders. Eg, when you take an object to inventory, it gets default saved into a
folder for the week. (eg, 'Objects' - 'From 2009/15' - 'Object Name' [if the
folder doesn't exist, create it.])
This would reduce the size of the 'selects' and allow larger keys (which reduce
overall lookup times -- albeit clientside search does diminish a lot of the
gains here.)
Adam
-Original Message-
From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
boun...@lists.berlios.de] On Behalf Of Melanie
Sent: Sunday, 7 June 2009 11:23 PM
To: d...@metaverseink.com; opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Rethinking inventory
Hello Diva,
to answer your questions:
The inventory skeleton is fetched on login and sent to the client.
It contains (or SHOULD contain) the actual folder serial numbers. I
believe they may not currently be correct, though. The client
decides, on opening a folder, which are out of date (by the serial
number) and requests them.
I implemented the serial number thing not too long ago, before then,
inventory was always completely reloaded, the client cache was in
fact defeated. In part, that is still so (see above).
Inventory was implemented in a rather simplistic manner, sending the
entire inventory in a single transaction from the inventory server
to the client. This was never really necessary, and often not even
useful, since all inventory transactions depend on the root folder,
and it can't be loaded without loading all folders.
A better inventory service would load inventory to regions only when
it needs to be loaded, and the cases where that is necessary are
surprisingly few, and most could get away with just the folder
skeleton and individual items.
I believe that I could get away with a function that will fetch only
the user's root and system folders' UUIDs, since they are what is
needed for inventory gives.
For take and rez, the client already knows the folder IDs. So
dropping inventory on a user and scripted gives are the two things a
region does with client inventory.
About letting the client talk to the inventory server: It needs to
remain possible to do it through a region, as some grids are not
willing to expose their inventory (asset, grid, etc) server ports to
the internet. The region could, however, just verify the session and
pass the request on.
Session_lookup doesn't work. It was an attempt to secure the
inventory server that failed because of session caches. If the
inventory server needed to be restarted, it all currently logged in
users would lose inventory access until relog. It was found
architecturally flawed and not salvageable, so was turned off by
default and recommended to be kept off. New implementations don't
need to support the mechanism.
So, a possible interface could be:
class UserInventory
{
UUID RootFolder;
Dictionaryint, IventoryFolderBase SystemFolders; // System
folders by content type
List InventoryItemBase Items; // Cache for those items a region
actually uses
}
interface IInventoryService
{
UserInventory GetInventoryBase();
ListInventoryFolderBase GetInventorySkel(); // Used by
userserver
for logins
InventoryItemBase GetItem(UUID item);
ListInventoryItemBase GetFolderItems(UUID folderID);
bool StoreItem(InventoryItemBase item); // Will overwrite by UUID
}
GetItem() is needed to push newly acquired items to the client as
well as to verify that asset IDs given by the client on rez are
correct. We currently don't trust the IDs the client produces, and
we shouldn't.
GetInventoryBase is what the give class of functions would call on
users who are not logged into a region. We may want to call that
when a user enters the region, but possibly we can actually get away
with not obtaining any inventory information at all unless an object
gives something to the user, or another user does.
Note the distinct lack of a GetAllIventory type method... it's not
needed.
It may need a few more specialized methods, but this should be about
the size of it.
Melanie
d...@metaverseink.com wrote:
Also, are there any grid operators out there who run their inventory
servers with the configuration session_lookup = true ? (this is a
flag
in InventoryServer_Config.xml)
Just curious to know if this is being used.
___
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
Re: [Opensim-dev] HUGE ASSET CACHE (THANKS!!!)
If it works well, I think we should make this the default. Adam From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Brianna Sent: Friday, 5 June 2009 10:42 PM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] HUGE ASSET CACHE (THANKS!!!) +1 :) and thank you - Original Message - From: Danmailto:retro...@gmail.com To: opensim-dev@lists.berlios.demailto:opensim-dev@lists.berlios.de Sent: Friday, June 05, 2009 9:13 AM Subject: [Opensim-dev] HUGE ASSET CACHE (THANKS!!!) Mr. Cortez, let me thank you for your File Cache System; it is amazing! After only a few hours +95% of all assets are coming from the cache and not being pulled down from the internet. This had made regions run much faster and save a ton of bandwidth. If this were deployed grid-wide it would reduce the strain on any asset server by orders of magnitude. Thanks again, and I hope this becomes part of the main branch ASAP rather than just a patch. +++ AMAZING!!! Date: Sun, 31 May 2009 08:12:30 -0700 From: Michael Cortez mcor...@gmail.commailto:mcor...@gmail.com Subject: Re: [Opensim-dev] HUGE ASSET CACHE To: opensim-dev@lists.berlios.demailto:opensim-dev@lists.berlios.de Message-ID: 4a229e5e.2020...@gmail.commailto:4a229e5e.2020...@gmail.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Dan wrote: Is it possible to configure a huge disk asset-cache for region servers? A disk cache is currently being tested. No guarantees, warranties, express or implied but the test patch is available at http://code.google.com/p/flotsam/downloads/listhttp://code.google.com/p/flotsam/downloads/list This is just something I threw together 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 Date: Sat, 30 May 2009 20:54:21 -0400 From: Dan retro...@gmail.commailto:retro...@gmail.com Subject: [Opensim-dev] HUGE ASSET CACHE To: opensim-dev@lists.berlios.demailto:opensim-dev@lists.berlios.de Message-ID: 4ded3e640905301754g1277b055m7db78d48e4ccc...@mail.gmail.commailto:4ded3e640905301754g1277b055m7db78d48e4ccc...@mail.gmail.com is it possible to configure a huge disk asset-cache for region servers? Disk space is cheap these days and I'm sure most could devote a few gigabytes to store most if not all of its assets. This should speed up most simulators correct? Especially if it were to cache all those J2K decoded textures? Wouldn't it be better to cache those to a local harddrive rather than downloading and decoding them each and every time? Wouldn't this also drastically reduce the strain on the asset server if each simulator had cached all its assets on a local cache file? And also drastically reduce the bandwidth needed to run regions once the cache was full? -- Why is Common Sense so Uncommon? ___ 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] Using Grider to teleport SL - OpenSim
Well, what Stefan is suggesting bypasses that limit by having a libsl client logged into SL. Adam From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Gustavo Alberto Navarro Bilbao Sent: Tuesday, 2 June 2009 1:53 AM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Using Grider to teleport SL - OpenSim The main problem for the TP between SL and our grids is the SL side. Since the process requires authentication of the account in SL, some of us are using the realXtend viewer's ability to perform the pseudo TP between SL and our grids. Zonja made this funny video on the matter: http://www.flickr.com/photos/zonja/3573078853/ 2009/6/2 Stefan Andersson ste...@tribalmedia.semailto:ste...@tribalmedia.se Diva, I was reading the New World Notes on the grider teleports, and one thing occured to me; Given I have understood the grider concept, couldn't grider be one way to accomplish seamless sl-opensim teleports? (seamless in a very wide sense, of course) If I would set up an sl lightweight sim as a 'storefront' on SL, couldn't grider then intercept tp requests to that storefront and redirect it to my opensim region and vice versa? Best regards, Stefan Andersson ___ Opensim-dev mailing list Opensim-dev@lists.berlios.demailto: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] HUGE ASSET CACHE
I think the ideal disk cache needs to do things Async with a small memory cache. Probably a 5 minute mem cache with a long-term store on disk. All disk operations need to be done ideally async for storage. (obviously retrieval is another matter entirely). Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Brianna Sent: Sunday, 31 May 2009 11:50 PM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] HUGE ASSET CACHE No Cigar for me.. thrashed my HD a while, was filling my test (7000 prims) server disk fast and made lotsa noise. thanks though for the try so far .. the best cache is no cache :( - Original Message - From: Michael Cortez mcor...@gmail.com To: opensim-dev@lists.berlios.de Sent: Sunday, May 31, 2009 8:12 AM Subject: Re: [Opensim-dev] HUGE ASSET CACHE Dan wrote: Is it possible to configure a huge disk asset-cache for region servers? A disk cache is currently being tested. No guarantees, warranties, express or implied but the test patch is available at http://code.google.com/p/flotsam/downloads/list This is just something I threw together 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 ___ 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] HUGE ASSET CACHE
It will do that for you, to a degree. Remember that File.Close is synchronous; not Async. It will wait for flush before returning. Ergo, we need to do a little bit of additional caching I think. Adam From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Dahlia Trimble Sent: Monday, 1 June 2009 12:00 AM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] HUGE ASSET CACHE shouldn't the OS do that for you? or are you syncing the disk on writes? if the disk is thrashing, something else may be wrong On Sun, May 31, 2009 at 11:55 PM, Frisby, Adam a...@deepthink.com.aumailto:a...@deepthink.com.au wrote: I think the ideal disk cache needs to do things Async with a small memory cache. Probably a 5 minute mem cache with a long-term store on disk. All disk operations need to be done ideally async for storage. (obviously retrieval is another matter entirely). Adam -Original Message- From: opensim-dev-boun...@lists.berlios.demailto:opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-mailto:opensim-dev- boun...@lists.berlios.demailto:boun...@lists.berlios.de] On Behalf Of Brianna Sent: Sunday, 31 May 2009 11:50 PM To: opensim-dev@lists.berlios.demailto:opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] HUGE ASSET CACHE No Cigar for me.. thrashed my HD a while, was filling my test (7000 prims) server disk fast and made lotsa noise. thanks though for the try so far .. the best cache is no cache :( - Original Message - From: Michael Cortez mcor...@gmail.commailto:mcor...@gmail.com To: opensim-dev@lists.berlios.demailto:opensim-dev@lists.berlios.de Sent: Sunday, May 31, 2009 8:12 AM Subject: Re: [Opensim-dev] HUGE ASSET CACHE Dan wrote: Is it possible to configure a huge disk asset-cache for region servers? A disk cache is currently being tested. No guarantees, warranties, express or implied but the test patch is available at http://code.google.com/p/flotsam/downloads/list This is just something I threw together 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 ___ Opensim-dev mailing list Opensim-dev@lists.berlios.demailto:Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.demailto:Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.demailto: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] Removal of project on GForge
Fly-Man-, When you bring out the big guns, and you aren't on solid ground - people tend to look down at you - when you start a conversation out in confrontation, then confrontation you will get. Regarding, 'revoking' the license, you simply cannot do that legally (go check with a lawyer) - once you have placed code under one of the OSI licenses, there is simply no way to 'undo' that action down the road. If it were possible to undo an OSI license, then people would be setting up code, then charging people for it retroactively years later. It also means that a project cannot be killed by one angry developer. Likewise, you cannot change the license on an existing piece of code - you can release new versions, or co-release the old code under a new license (if you are the complete copyright owner and have no outside contributions), however the old license is still considered working and valid. Re: the forge itself - I am very, very loathe to remove any code or projects from the forge without an exceptionally good reason. A spat with other developers because they did something while you were gone, is not a good reason. Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Fly Man Sent: Sunday, 31 May 2009 7:54 PM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Removal of project on GForge Well, I can keep repeating myself but I won't ... If the 2 people that started this meaningless discussion just take up the glove and stop throwing dirt, then I have no problem with ending this discussion and reclaiming the projects and work on them like I did before. But as I have read for the past 6 hours, people tend to agree on one thing: There can only be losers in this discussion And maybe I need to explain why I am still argueing about this : When I develop things ( for the business that i make money with for a living since 5 months) and someone forgot to communicate with me and started this useless discussion, that those people know that they did something they shouldn't do a second time. We are all here to make OpenSim something to be proud of. And I enjoy working on the new technology just like every other developer. But when I need to call out the big guns just to get my point set, that disappoints me. 2009/6/1 Charles Krinke c...@pacbell.net: Dear Fly-Man: I would like to suggest we step back from a point of honor and try to figure out how to work together. There are times in this project when passions rise high and this is one of those times. I would really like to find a way to move forward without pushing anyone into a corner. Your enthusiasm, work ethic and code has been good for the grid deployments and all I can say is that I am sorry that you and others have gotten to the place where the need exists to make the statements said today. So, please, please, lets figure out how to just work together. Charles From: Fly Man fly.man.open...@gmail.com To: opensim-dev@lists.berlios.de Sent: Sunday, May 31, 2009 5:53:35 PM Subject: Re: [Opensim-dev] Removal of project on GForge Kyle, please read back what I posted earlier before you start to throw with words that I won't respond to: * There's 2 people that just need to apoligize and then we can all get back to what we're good in. Unless those people step up and take responsibilty about their actions, then it means that on the 2nd of June I need to consult with a lawyer about the further steps that need to be taken 2009/6/1 Kyle Hamilton aerow...@gmail.com: How about you check out the subversion tree at the last revision without the whole mess that it is now? That's what revision control systems are for, so you can check out old revisions. You can control your own experience -- while everyone else can cooperate as they want to. You should do this instead of bitching on the mailing list and essentially saying IT'S MY BALL AND I'M GOING HOME. You're thus making a huge deal out of, literally, nothing. Which means you're a drama whore at best, and a troll at worst. Get a grip. I will also point out that the main OpenSim project trunk isn't clean, and that branches are made to maintain specific milestones, and so your objection to as long as the main trunk is clean isn't even in line with what the community has (loosely) standardized on. Yes, this might fly in the face of other projects' conventions, but this is what we have to deal with and have to live with as a part of working with OpenSim. -Kyle H On Sun, May 31, 2009 at 3:26 PM, Fly Man fly.man.open...@gmail.com wrote: Ideia, this problem can easily be resolved by 2 people that just say sorry and revert back the things that they added to the OpenSimWiredux so I can take a clean copy of
Re: [Opensim-dev] Mac OS X OpenSim installer
+1 Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Jeff Ames Sent: Sunday, 31 May 2009 8:30 PM To: opensim-dev@lists.berlios.de Subject: [Opensim-dev] Mac OS X OpenSim installer Hello, I've started an OS X installer in http://forge.opensimulator.org/gf/project/osinstaller/, alongside the existing Windows one. It currently installs a binary version of 0.6.5-post-fixes (r9713), built with Mono 2.4. But it could still use a lot of work (dependency installation, creating opensim user/group, setting file permissions), so if anyone is interested in helping out, that'd be great! 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] Is the message Please wait 5 minutes still needed?
Make it standard. +1 Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Arthur Valadares Sent: Friday, 29 May 2009 2:59 PM To: OpenSim-Dev Subject: [Opensim-dev] Is the message Please wait 5 minutes still needed? Hi everyone, I wanted to consult you all about this matter, even though I have already committed some related code. I will gladly change it if we decide to do things differently. Once upon a time, there seemed to be a necessity that you had to wait 5 minutes if you crashed and tried to log back in. Those were the days before my time, tales that the elder tells us by the fireside. After these days, when I started messing around with OpenSim, there was a bug that would kick you after a few minutes if you tried to log back on without waiting. This was also fixed (thanks Crista!), which leads me to my question. Why are we still getting this message? Well, the only purpose I can think of is it warns you that you either crashed last time or that someone is using your account. Either way, something went wrong and the user might want to know that. So the code I committed puts an option in standalone that allows you to skip this message and just let OpenSim kick the old user and connect the new one, kind of like what happens in messengers if you logon from a different location. This is very useful when you have softwares that encapsulate the login process and doesn't want to leave the user looking at the viewer's login page with a failed message. So, should this become standard and just skip and kick, or should we leave it up to configuration? Opinions please.. -- Arthur Valadares arthu...@linux.vnet.ibm.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] Tag 0.6.6
Someone bumped NetworkVersion to 4 Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of d...@metaverseink.com Sent: Thursday, 28 May 2009 7:28 AM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Tag 0.6.6 What is incompatible? I thought your changes were still compatible with everything, no? Frisby, Adam wrote: Is it appropriate to tag 0.6.6 given that there was a network break in trunk and now post-fixes users are incompatible? (I don't think there is too much between the versions, so it would be a fairly minor upgrade) Adam - --- ___ 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] Memory cache
FS cache is pretty easy. In the simplest case, just dump it as a file in a
directory. (try keep the avg files per dir down to 3K or less though)
Adam
-Original Message-
From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
boun...@lists.berlios.de] On Behalf Of d...@metaverseink.com
Sent: Thursday, 28 May 2009 7:40 AM
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Memory cache
Imaze, I'll be looking forward to seeing your contribution coming on
mantis. Along with Melanie's improved Cache.cs, and the simplistic
GlynnTucker cache, we'll have a good set of mem cache options to
compare.
One thing I'd like to point out to everyone is that this particular
piece of functionality (the asset cache) is fairly isolated and well
modularized now. As such, this is a great entry point to programming
OpenSim, for those of you interested in doing that. Specifically, if
anyone wants to try implementing a file system cache, similar to that
used by the viewer, that'd be really great. Start by looking at the two
cache modules in OpenSim/Region/CoreModules/Asset, and take it from
there.
Imaze Rhiano wrote:
Hi Again!
Adding BSD compatible licence to the cache (CnmHashGenerationCache)
is
not problem (if I have understand right BSD licence still allows me
to
use it my closed source database project). I also have some ideas how
to
add time based expiration and how user could define to configuration
caches maxinium size in bytes instead of assets count. Basically this
is
just doing some optimization work for my own project. Importing
database
is still in long haul - maybe 6 months - before it is ready for
production. It would be just alternative for current Open SIM
database
implementations (SQLite/MySQL/...).
Before jumping to coding with CnmHashGenerationCache - anyone have
idea
what is IAsssetCache interface and why there isn't any implementation
for it? (Might also be result from bad trunk import) And why current
CoreCaches implementation class Cache is used directly in
FriendsModule and LandMaangementModule? I guess I could figure out
these
by staring code long enough, but this just might be faster way and
collect some extra requirements/knowledge... :)
Thanks!
- Imaze Rhiano
Melanie kirjoitti:
In fact, it must be a BSD compatible license for all parts to be
eligible for core. If any part is not licensed under a BSD
compatible
license, then it would have to live on Forge, which hosts other
licenses.
Melanie
d...@metaverseink.com wrote:
Imaze, this is awesome! Thank you so much for such extensive
testing
and for doing the extra cache module implementation. This is really
valuable.
If there are no objections from fellow committers, I will be more
than happy to take an improved version of your code and add it to
OpenSim as a 3rd alternative cache module that people can test out
there in the wild.
Technically, your code needs thread-safety, that's all.
Procedurally,
it also needs a license on top. If you want to give your code to
the
OpenSim project, it needs the OpenSim license text. Otherwise, the
cache itself (CnmHashGenerationCache) needs to be added as a 3rd
party dll, and only the module would be 100% OpenSim. In any case,
if
you want to do this, whichever way you want to do it, please do it
via a patch submitted in mantis, so we can have a record.
http://opensimulator.org/mantis
As for the more substantial contribution of the Cenome DB, I'll
leave
that to the people here who know more about DBs than I do.
Imaze Rhiano wrote:
Hi!
I have done some research about asset server. I used lates trunk
from this morning.
Here are my findings:
1. CoreAssetCache's CacheBuckets configuration is not working
properly. Cache's size is limited to 1024 buckets, because of bug
or
by design. So default configuration value 32768 - didn't never
happen.
See: private void SetSize(int newSize) in Cache.cs
lock (m_Index)
{
if (Count = Size)
return;
.
}
During initialization phase, Count is 0 - so initial size
value
1024 is used. (And Count never can't grow up bigger than Size)
2. GlynnTucker cache is basically Hashtable that contains all
assets they are never removed from cache unless assets is
exlusively removed by calling Expire method. It definately can
provide huge performance impact for short time - but eventually
your
server is going to run out of memory.
3. To evaluate different cache's performance I first tried to do
some testing in stand alone SIM. Unfortunately single client, just
didn't provide enough caching to really to measure performance, so
I
adopted different strategy. I did write simple Window$ console
application with 4 different test cases.
Test Case 1 EnumerateAllTest:
Re: [Opensim-dev] Conflicting revision numbers
Neither, state '0.6.5-postfixes' (but 9668 if you have to) Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Robert Dzikowski Sent: Monday, 25 May 2009 2:04 PM To: opensim-dev@lists.berlios.de Subject: [Opensim-dev] Conflicting revision numbers OpenSim 0.6.5-post-fixes according to subversion is revision 9668 but when I run it, it displays this: [STARTUP]: Version: OpenSimulator Server 0.6.5.9673 So what revision number should I write (9668 or 9673) when I find a bug in this version? ___ 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] Login tests failing in r9642+
Known issue - looks like something is at fault with the test construction, but I can't seem to work out exactly what. Tests run OK on my local system, but not opensim.org. Please do not revert the r9641-r9649 revisions as they contain important infrastructure work relating to our network assignment code. Adam ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Memory cache
We are using an external caching library I believe, it could be sitting in there. Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Melanie Sent: Wednesday, 20 May 2009 1:56 PM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Memory cache The surprise really is that the cache would be a performance loss instead of a performance gain. What is there that makes it so slow? Melanie Frisby, Adam wrote: As chief engineer aboard the USS OSgrid, I might want to recommend against this. Not having the sims cache assets will mean that every asset request will hit the core asset server which in turn will result in higher bandwidth requirements for it in the long run. It doesn't appear to have made a huge impact on our bandwidth charts for this week yet - however I wouldn't be surprised if it did if everyone did this. Adam From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Nebadon Izumi Sent: Wednesday, 20 May 2009 10:19 AM To: d...@metaverseink.com; opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Memory cache Yay for mistakes that end in gains!!! of course if anyone asks i planned this ;P anyway i thought people would like to see my ini changes.. this is what lead to the discovery: [OpenSim.ini] ; The following is the configuration section for the new style grid servers ; If you don't know what this is, don't enable it. It will eat your data, ; format your hard drive and make all meat in your fridge spoil. ; You have been warned. ; Some of this is starting to work! [Modules] ; Choose one ;AssetServices = LocalAssetServicesConnector AssetServices = RemoteAssetServicesConnector ;AssetServices = HGAssetBroker ; If you don't want asset caching in the regions, comment this AssetCaching = CoreAssetCache ;---*** SEE ERROR HERE ***--- - ; Choose one ;UserServices = LocalUserServicesConnector UserServices = RemoteUserServicesConnector [AssetService] ; Parameters for local assets, formerly known as standalone LocalServiceModule = OpenSim.Services.AssetService.dll:AssetService StorageProvider = OpenSim.Data.SQLite.dll ;StorageProvider = OpenSim.Data.MySQL.dll ;ConnectionString = Data Source=localhost;Database=opensim;User ID=opensim;Password=opensim; DefaultAssetLoader = OpenSim.Framework.AssetLoader.Filesystem.dll AssetLoaderArgs = assets/AssetSets.xml ; Parameters for remote assets, formerly known as grid AssetServerURI = http://assets.osgrid.org:8003/; ; Paremeters for the Hypergrid connector ;; Parameters for the HG Broker ; Use this one if you have a standalone grid ;LocalGridAssetService = OpenSim.Services.AssetService.dll:AssetService ; Use this one if this sim is connected to a grid-wide asset server ;LocalGridAssetService = OpenSim.Services.Connectors.dll:AssetServiceConnector ;HypergridAssetService = OpenSim.Services.AssetService.dll:HGAssetService [AssetCache] ; Number of buckets for assets CacheBuckets = 32768 [UserService] ;LocalServiceModule = OpenSim.Services.UserService.dll:UserService [/OpenSim.ini] Please test this out and see if you see gains too and let us know. Neb - --- ___ 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] Collada as Model Format
And to attach a demo object, the size shoots up to 1GB. Some things XML can't solve, 3D model storage is one of them. ;) Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Teravus Ovares Sent: Sunday, 17 May 2009 1:25 PM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Collada as Model Format The only thing that is frustrating about COLLADA.. is it's hard to support fully.For example..Bullet is a Physics engine that totals ~250kb.BUT if you build in COLLADA support, it becomes 6MB. :P On 5/16/09, Gustavo Alberto Navarro Bilbao alberto.navarro.bil...@gmail.com wrote: A silly question: ¿Can be compatible OGRE and COLLADA at the same time?. I say that because I suppose that there is a great time and effort spent by the realxtend and SIRIKATA' teams, working on, and many are expecting in July for the new RX-NG and SIRIKATA, and would be a pity not to make the already developed. Best regards 2009/5/16 Jani Pirkola jpirk...@gmail.com Immersive Education initiative (IEd) has decided in its Technical Working Group to support COLLADA as the format to transfer assets between different platforms. http://maxping.org/business/news/immersive-education-adds-support- for-realxtend.aspx To further support COLLADA, IEd and Khronos launched a contest for developing content using the format. http://maxping.org/business/real-life/champion-the-3d-web-using- collada.aspx Best regards, Jani 2009/5/16 Tommi Laukkanen tommi.s.e.laukka...@gmail.com Hello As custom viewers start to emerge I would like to point to Collada specification as one format which could be used to support freestyle models (meshes): This document describes the COLLADA schema. COLLADA is a COLLAborative Design Activity that defines an XML-based schema to enable 3-D authoring applications to freely exchange digital assets without loss of information, enabling multiple software packages to be combined into extremely powerful tool chains. The specification: http://www.khronos.org/files/collada_spec_1_4.pdf The schema: http://www.khronos.org/files/collada_schema_1_4 -tommi ___ 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] Feature Voting
Hi everyone, I would like to try a little experiment - as many developers have noticed, the Mantis has become somewhat crowded with both feature requests and bugs. To alleviate some of the load from feature requests, I have built a specialised feature voting site - it's still kind of primitive, but I have optimized it for quick reporting of feature suggestions. This is an experiment - I'll be tweaking the site periodically as the experiment progresses. The URL: http://www.opensimulator.org/features/ Please feel free to add feature suggestions, vote on them and otherwise use the site. If you find any bugs, let me know. Adam ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Standard Test region
OSGrid has a couple of test regions that are available. Neb's art OAR is a definite OpenSim stress test. Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Robert Martin Sent: Wednesday, 13 May 2009 6:55 PM To: opensim-dev Subject: [Opensim-dev] Standard Test region Just throwing an idea out what if we developed a Region that could be used to test the various bits and such. This way we can isolate stuff going funny because of new code or funny just because of the platform. Side note has anybody done a library of OAR files (more that like a half dozen)?? -- 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] MRM Loader
Hey Mike,
I’d just like to give you my personal thanks for this – this is a very cool bit
of technology.
Adam
From: opensim-dev-boun...@lists.berlios.de
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Mike Deem
Sent: Monday, 11 May 2009 11:55 PM
To: opensim-dev@lists.berlios.de
Subject: [Opensim-dev] MRM Loader
Hello, I would like to call your attention to a new forge project: MRM
Loaderhttp://forge.opensimulator.org/gf/project/mrmloader/.
MRM Loader is an experimental package based application model for virtual world
content. Packages will contain assemblies, textures, prims, and all the other
assets necessary to fully describe and implement a house, vehicle, attachment,
etc. They will be downloaded from web sites and run by OpenSim.
MRM Loader also allows MRM code to be edited, compiled, and debugged using
Visual C# Express, all without restarting OpenSim.
MRM Loader provides a region model that looks for scripts that contain
//MRM:Loader {package-path} and loads the indicated MRM package into an
application domain created just for it. The region module unloads these
application domains when the script is removed. Only package paths that
identify a directory on the local machine are currently supported. All of an
MRM's assemblies are loaded from this directory.
MRM Loader extends Adam's MRM
infrastructurehttp://www.adamfrisby.com/blog/tag/mrm/. The MRM region module
must enabled in order to use MRM Loader functionality. It is also currently
necessary to apply a patch to MRM module before it can be used with MRM Loader
(mantishttp://opensimulator.org/mantis/view.php?id=3630).
See this
threadhttp://forge.opensimulator.org/gf/project/mrmloader/forum/?action=ForumBrowseforum_id=501_forum_action=ForumMessageBrowsethread_id=120
for instructions.
Thanks,
== Mike ==
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] 23 LSL functions remaining
+1 From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Dahlia Trimble Sent: Tuesday, 12 May 2009 3:57 AM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] 23 LSL functions remaining I don't think 100% compatibility is possible given some of the quirks of the LSL language, and differences between the LSL2 and mono implementations that exist on the Linden grid. There will always be some differences. I also don't believe that many of the OpenSim developers see 100% SL compatibility as a goal for OpenSim. Rather, the SL viewer has been the first viewer used for development. As OpenSim continues to be developed and support for new viewers and protocols are added, there will likely be substantial divergence from the SL path. Of course if members of the user community submit acceptable patches which provide increased compatibility, they will likely be included into the code base. On Tue, May 12, 2009 at 3:13 AM, Colin B. Withers colin.with...@eumetsat.intmailto:colin.with...@eumetsat.int wrote: There is also the question of compatibility with LSL. Questions have been raised about whether Opensim can be used as a development tool for SL. Here is one thread that calls compatibility into question: http://www.sluniverse.com/php/vb/opensim-discussion/26340-opensim-compatibility-place-develop-secondlife.html Is the aim to have 100% compatibilty, so that scripts developed in Opensim will be guaranteed to work in SL, and vice versa? As the old saying goes, you cannot be a little bit pregnant, it is either 100% or nothing. Rock From: opensim-dev-boun...@lists.berlios.demailto:opensim-dev-boun...@lists.berlios.de [opensim-dev-boun...@lists.berlios.demailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Charles Krinke [...@pacbell.netmailto:c...@pacbell.net] Sent: 12 May 2009 04:25 To: opensim-dev Subject: [Opensim-dev] 23 LSL functions remaining I am asking for a few patches to complete the 23 LSL functions in our original project of more then 330. We are *almost* there, but need a little help with patches. Here is the remaining list that are still in the Not Implemented state. llRotTarget() llRotTargetRemove() llLoopSoundMaster() llLoopSoundSlave() llStopLookAt() llCollisionFilter() llAttachToAvatar() llDetachFromAvatar() llRotLookAt() llPointAt() llStopPointAt() llGodLikeRezObject() llPassTouches() llSetDamage() llTextBox() llCollisionSprite() llPassCollisions() llGetCenterOfMass() llSetSoundQueing() llTriggerSoundLimited() llGroundRepel() llSetVehicleFlags() llRemoveVehicleFlags() llRemoteDataSetRegion() llSetInventoryPermMask() Partial implementations are solicited. The goal here is to get all the LSL functions we have defined in LSL_Api.cs out of the not implemented state with at least *some* implementation. Charles ___ Opensim-dev mailing list Opensim-dev@lists.berlios.demailto: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] Standardizing OpenSim data formats
The parser needs to not barf if it sees an unknown element in there. Eg, ModRex mesh parameters, etc. Ideally the SaveToXYZ function should fire an event on the object called something like say 'OnSaveRequest(out List??? extraData)' which allows other modules to save additional data. On-load/On-construct should probably also fire an event which allows the data to be restored. Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Hurliman, John Sent: Tuesday, 28 April 2009 4:32 PM To: opensim-dev@lists.berlios.de Subject: [Opensim-dev] Standardizing OpenSim data formats Currently, OpenSim server-server communication is primarily made up of .NET XML serialization. As a side effect of this, I've seen the wire format between simulator and grid services or grid service to grid service change many times since I started working on backend services. The OAR file format has also changed at least once while retaining the same version number because the underlying prim XML format changed. I am working on a libomv OAR reader/writer at the moment, and trying to deal with hacks for supporting pre and post change OAR files. To increase compatibility between versions of OpenSim and with third party services I'd like to propose a standardization of (eventually) all over-the-wire communication in OpenSim. I started with an attempt at an LLIDL definition for primitives: http://opensimulator.org/wiki/PrimitiveFormatProposal Is anything missing? Does this look like a reasonable start? John ___ 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] Request for feedback: 0.6.5 Release Candidate Prospects
I think those j2k cache files are somewhat necessary - perhaps we can get those moved into a special subfolder so they don't clog up your bin directory, alternatively we could move them into our caching subsystem where assets go so they are part of a virtual file system. That being said, if there are no other major outstanding issues, it is probably a good time to tag 0.6.5; since there are a number of .NET 3.0 features I would like to begin utilizing (like lambda functions, etc). (This is assuming that Mono 1.9 is now the defacto standard with Ubuntu/etc, or that 1.2.X supports these.) Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Ai Austin Sent: Thursday, 23 April 2009 9:09 AM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Request for feedback: 0.6.5 Release Candidate Prospects Would this be a good time to look for the 0.6.5 release? Anyone know if the problem with massive numbers of small files benign created in the jkDecoderCache directory is fixed (Mantis 3288). It does cause the bin folder for Opensim to grow VERY large when you have been running a while. ___ 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] Request for feedback: 0.6.5Release Candidate 1Prospects
If we push MRM, please note - MRM is a security risk still. It's powerful as all heck, but that's a double edged sword. Adam From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Stefan Andersson Sent: Wednesday, 22 April 2009 11:22 AM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Request for feedback: 0.6.5Release Candidate 1Prospects Give me a rev, and I'll tag it, then let's take it for a drive, rev the rev, kick the wheels and see if we buy the car. Best regards, Stefan Andersson Date: Wed, 22 Apr 2009 11:16:32 -0700 From: cmick...@gmail.com To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Request for feedback: 0.6.5Release Candidate 1Prospects Would this be a good time to look for the 0.6.5 release? It will be a very good release with performance optimizations, MRM scripting, and VOICE (yeah!). I think the bugs that were discussed earlier have been fixed now. --mic On Sat, Apr 18, 2009 at 1:03 AM, Ralf Haifisch r...@ralf-haifisch.biz wrote: Does it ?? Is there a mantis ? I did use the libsl testclients on 9160 for some measurement yesterday... Cheers, Ralf -- Message: 3 Date: Fri, 17 Apr 2009 19:36:59 -0400 From: Frisby, Adam a...@deepthink.com.au Subject: Re: [Opensim-dev] Request for feedback: 0.6.5Release Candidate 1Prospects To: opensim-dev@lists.berlios.de opensim-dev@lists.berlios.de Message-ID: 63fad4f30a4ea79de9e8be66473519180...@winxbeus19.exchange.xchg Content-Type: text/plain; charset=us-ascii R9148 breaks support for libsl clients too - I'd rather not tag with that broken. Adam From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Stefan Andersson Sent: Friday, 17 April 2009 11:58 AM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Request for feedback: 0.6.5Release Candidate 1Prospects Is this fixed? Best regards, Stefan Andersson Tribal Media AB Date: Wed, 15 Apr 2009 12:42:45 +0100 From: ch...@codetorque.co.uk To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Request for feedback: 0.6.5Release Candidate 1Prospects Ah yes, this slipped through my tests yesterday - it's definitely there in 9137 too. Recommend we get that fixed before a tag. -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Melanie Sent: 15 April 2009 11:12 To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Request for feedback: 0.6.5Release Candidate 1Prospects That circular regioncross bug, where a region server will crash if an agent returns to it, needs to be squashed before we can tag a relaease. I didn't see that having been resolved, so it is probably present in 9140. Melanie Ralf Haifisch wrote: Agreed, maybe even 9140 after the cleanup... cheers, Ralf -- Date: Wed, 15 Apr 2009 07:52:57 +0100 From: Chris Hart ch...@codetorque.co.uk Subject: Re: [Opensim-dev] Request for feedback: 0.6.5 Release Candidate 1Prospects To: opensim-dev@lists.berlios.de Message-ID: 6abfbbbfa9738e47a00f30bc3c74171c1da...@kitt.ct.local Content-Type: text/plain; charset=us-ascii Very happy in tests yesterday with 9137 - 25 avatars on a sim for over an hour, no crashes. OSGrid office hours had Wright Plaza on 9136 and was also very stable, so I think around that point is a sweet spot... From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Stefan Andersson Sent: 15 April 2009 02:29 To: opensim-dev@lists.berlios.de Subject: [Opensim-dev] Request for feedback: 0.6.5 Release Candidate 1Prospects Esteemed Testers and Developers, As you may know, the current lean release cycle handling defines testers and developers as anybody feeding off trunk so if that's you, I have a favour to ask; it's time to gather round and try to nail down a good candidate revision for 0.6.5. Ideally, it should * Be (subjectively) as stable as the last version (0.6.4-post-fixes) * Be reasonably close to head (not more than two weeks off, I'd say) and * Be reasonably well tested (in a pragmatic sense) If you do have a revision that you feel particularly fond of, please speak up. With that, I leave the floor open. Best regards, Stefan Andersson Tribal Media AB No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.287 / Virus Database: 270.11.53/2054 - Release Date: 04/14/09 06:17:00 -- next part -- An HTML attachment was scrubbed... URL: https://lists.berlios.de/pipermail/opensim-dev
Re: [Opensim-dev] note: broken lenny stable apt-get install mono-devel
I wouldn't worry about us using Mono-only features, we've still got .NET to support. And yes, Mono 2.4s notoriety has already hit us - the Bamboo CI server we had ended up completely broken by Mono 2.4. We're in the process of switching to something else. Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Dzonatas Sent: Thursday, 16 April 2009 9:52 AM To: opensim-dev@lists.berlios.de Subject: [Opensim-dev] note: broken lenny stable apt-get install mono-devel Hello, We know that mono is currently at version 2.4 and there are many waited features of 2.0+ mono to hit stable branches, yet lenny got stuck at 1.9dfsg. If opensim starts to depend on 2.0+ features (hint: AOT, SIMD, partial references, .NET 3.5, etc), then opensim would be held back in unstable along with mono. Here is one reason why for the hold-up: http://wiki.debian.org/Teams/DebianMonoGroup/CSCNameClash Some bugzilla's for this event: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520862 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=509367 I know, given that last one you might think it is an April Fools joke, but however if you are on lenny stable and you don't allow unstable upgrades, you can test it yourself to see it is clearly broke: $ sudo apt-get install mono-devel Both apt-get and aptitude reports the package is broke, and it gives the only option to upgrade to unstable. That upgrade option for those that prefer lenny stable is not an option. Despite what happened on this list earlier, you can understand why people can't and won't upgrade to unstable to run opensim in a production environment: http://www.mail-archive.com/opensim- us...@lists.berlios.de/msg00818.html The best thing to do is get the word out about this, so people know why their .NET programs that run on fine under Microsoft Windows (with .NET 3.5 etc) won't run under stable lenny. This may be a case of playing chicken on the lenny roadmap, (two binaries fighting for one spot), and I think once you research this you'll also wonder if this is something devious rather than just a coincidence. I preach I don't know about the cause, but the facts are above, and it's no joke. Dzonatas ___ 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
