Re: [Opensim-dev] [Opensim-commits] r9339 - trunk/OpenSim/ApplicationPlugins/RemoteController

2009-04-29 Thread Sean Dague
drscofi...@opensimulator.org wrote: Author: drscofield Date: 2009-04-29 02:35:35 -0700 (Wed, 29 Apr 2009) New Revision: 9339 Modified: trunk/OpenSim/ApplicationPlugins/RemoteController/RemoteAdminPlugin.cs Log: From: Alan Webb alan_w...@us.ibm.com Added two new (optional)

Re: [Opensim-dev] moving away from grid vs. standalone

2009-04-29 Thread diva
Stefan Andersson wrote: How about --- [RegionResourceServices] ;GridService = OpenSim.Region.Communications.Hypergrid.dll, HGGridServices ;GridService = OpenSim.Region.Communications.Local.dll, LocalBackEndServices GridService = OpenSim.Region.Communications.OGS1.dll, OGS1GridServices

Re: [Opensim-dev] moving away from grid vs. standalone

2009-04-29 Thread diva
Maybe the right name for it is OpenSim.Region.ResourceServicesConnectors.dll d...@metaverseink.com wrote: Stefan Andersson wrote: How about --- [RegionResourceServices] ;GridService = OpenSim.Region.Communications.Hypergrid.dll, HGGridServices ;GridService =

Re: [Opensim-dev] Standardizing OpenSim data formats

2009-04-29 Thread Justin Clark-Casey
Hurliman, John wrote: 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

Re: [Opensim-dev] moving away from grid vs. standalone

2009-04-29 Thread Stefan Andersson
We could then have an method similar to the way we define/select physics engines; 2. On your previous suggested ini stuff, in my opinion something like UserService = { local | remote } would be clearer than LocalUserService = {True|False} So that each UserService module needs to

Re: [Opensim-dev] Opensim-dev Digest, Vol 20, Issue 75

2009-04-29 Thread Stefan Andersson
Just a heads up; I will probably not have time to champion the release cycle I have outlined in earlier posts - I hereby declare and underline it being a community effort. Best regards, Stefan Andersson From: r...@ralf-haifisch.biz To: opensim-dev@lists.berlios.de Date: Sat, 25 Apr 2009

Re: [Opensim-dev] moving away from grid vs. standalone

2009-04-29 Thread diva
Justin Clark-Casey wrote: I like this generally but I do have the following comments. 1. I'm not a huge fan of this since, like Stefan, I'd ideally like it to be possible to package an OpenSim that supports only a single architecture, with no trace of other architecture code in there at

Re: [Opensim-dev] moving away from grid vs. standalone

2009-04-29 Thread Melanie
I still think all that stuff can be put in region modules Melanie d...@metaverseink.com wrote: Maybe the right name for it is OpenSim.Region.ResourceServicesConnectors.dll d...@metaverseink.com wrote: Stefan Andersson wrote: How about --- [RegionResourceServices] ;GridService =

Re: [Opensim-dev] moving away from grid vs. standalone

2009-04-29 Thread diva
I think that there is a technical obstacle to doing that: the master avatar stuff, that happens early on in the application (OpenSimBase, line 688), needs to have the communication code in place. I think -- although I may be wrong -- that that happens before region modules are in place.

Re: [Opensim-dev] moving away from grid vs. standalone

2009-04-29 Thread Melanie
I have done a lot of stuff related to that. Master avatar should not even exist in the way it still does today, that is legacy. The very same thing can be done in another way (code-wise). So the existing master avatar stuff can be removed,if that is the only blocker, i'll think up some new

Re: [Opensim-dev] moving away from grid vs. standalone

2009-04-29 Thread Charles Krinke
I would urge us to make changes to the master avatar stuff with notice and encouragement of folks to write FAQ, wiki entries, mini-apnotes and anything else that will help cut down on confusion of those who have significant effort invested into builds on existing regions. Charles

Re: [Opensim-dev] Standardizing OpenSim data formats

2009-04-29 Thread Hurliman, John
Thank you for taking a look. Looks like I all of the ExtraData for prims, including sculpt/particles/flexi/etc. I'll see what OpenSim is doing for saving script state and add everything in a second pass. I'm hoping that this particular format captures everything needed to save simulator state

Re: [Opensim-dev] moving away from grid vs. standalone

2009-04-29 Thread diva
I'm also noticing that the region registration with the grid happens before the post-initialization of the region modules, at least as of now. In other words, the design has been that Comms would be in place very early on, so if we change that, it may break all sorts of random things. Melanie

Re: [Opensim-dev] Standardizing OpenSim data formats

2009-04-29 Thread Teravus Ovares
Sculpt/flexi/light are probably stored in the ExtraParams byte array. The routines for deserializing that are in PrimitiveBaseShape. Unfortunately this is one of those 'legacy' things that ended up that way.Someone, a long time ago, exposed these options as the ExtraParams byte array and

[Opensim-dev] Groups

2009-04-29 Thread Jason Fisher
Hi everybody! I found a group project, and I can't get it set up. Can anyone help me? I downloaded the SVN version, and have opensim 0.64 SVN. When it says Apply the patch, it says it is incompatible. I tried opensim 0.64, 0.63, and even 0.62. Can someone tell me what I'm doing wrong? Also, if

Re: [Opensim-dev] moving away from grid vs. standalone

2009-04-29 Thread Stefan Andersson
2. On your previous suggested ini stuff, in my opinion something like UserService = { local | remote } would be clearer than LocalUserService = {True|False} From what I remember, specifying remote is understandable even if the services are actually on the

Re: [Opensim-dev] moving away from grid vs. standalone

2009-04-29 Thread diva
OK, let me backtrack. There are really two separate issues going on. a) One issue is the means by which we specify different service connectors. The dlls + entry class is the right way. Unfortunately, that isn't in place yet, and I'm not sure I'm the right person to do it :-/ b) Another issue