, 2009, 7:11 PM
TribalServer fell into disrepair I believe, but MW LBSA
donated their unique features into a Forge project at least 6 months ago. (look
for ‘Tribal’ in the projects list).
3Di is just OpenSim + a support contract + some extra modules
for the 3D models and analytics
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
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.
Both SceneObjectGroup and Part are growing beyond manageable sizes (with both
of them over 3000 lines long), and are not very easy to change when trying to
make custom classes bassed on them (as I think Sean found out recently during
his attempts).
Ideally I think we would all like to see the
I believe that each region is still loading and using the library in all modes.
As you said it certainly used to be like this, and from a quick look just now,
it still looks like it is the case.
So yes the LibrariesXMLFile should move to the Startup section. And in the
longer term we really
Well apart from wondering if the basic option will be a bit confusing, and if
there is any other more meaningful description for that option. I'm +1 on the
changes.
--- On Fri, 10/7/09, Melanie mela...@t-data.com wrote:
From: Melanie mela...@t-data.com
Subject: [Opensim-dev] Proposal: change
@lists.berlios.de
Date: Friday, 10 July, 2009, 4:44 PM
Dear Mw:
Thank you for sharing your technical thoughts as you work through them. It is
my fervent hope that others will share similarly so that some of us 'lesser
wizards' may learn a bit more by reading how OpenSim is evolving.
Charles
From: MW
Well as Justin said, there needs to be plans/documents detailing all the
details of the replacement protocols before the process of replacing them is
began.
--- On Wed, 8/7/09, Melanie mela...@t-data.com wrote:
From: Melanie mela...@t-data.com
Subject: Re: [Opensim-dev] Deprecate
will evolve as
they are coded.
Finally, the new protocols will replace the old, after they have
been tested and used in production by early adopters.
Melanie
MW wrote:
Well as Justin said, there needs to be plans/documents detailing all the
details of the replacement protocols before
, the new protocols will replace the old, after they have
been tested and used in production by early adopters.
Melanie
MW wrote:
Well as Justin said, there needs to be plans/documents detailing all the
details of the replacement protocols before the process of replacing them
is began
--- On Mon, 8/6/09, Frisby, Adam a...@deepthink.com.au wrote:
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
I'm not sure how realistic it is to try to do a feature freeze, as some of our
developers mainly do their work outside the main core (and work in modules
etc). So a feature freeze might just see them not doing any commits during that
time.
But in general I'm a +1 to focusing on bug fixing. A
If you submit a patch and no one has looked at it after a couple of days, I
think its a good idea to post a small note about it on here. As its very easy
to miss patches on the mantis.
--- On Mon, 1/6/09, Robert Dzikowski rdzikow...@gmail.com wrote:
From: Robert Dzikowski rdzikow...@gmail.com
In standalone mode there is a annoymous mode which basically means that there
isn't any checks of passwords done, and if someone tries to sign on using a
account (user name) that doesn't exist, then a new account is automatically
created for it.
But there currently isn't any support for
This is just the region side stuff that is changing? Just wondering if anything
will conflict with the generic grid server work in the branch.
Alos on a side note, it would be good if we could tag a new stable release from
before these changes. From what feedback I have seen, it seems that a
.
Melanie
MW wrote:
This is just the region side stuff that is changing? Just wondering if
anything will conflict with the generic grid server work in the branch.
Alos on a side note, it would be good if we could tag a new stable release
from before these changes. From what feedback I have seen
UGAIM
ServiceConnectorIn's for standalone grids that let the users go out.
Does this make sense?
MW wrote:
So can we have some idea of what is being done for the new grid servers,
all the talk I saw was about region side dlls /config setting etc.
I was already in the middle of making
So maybe to start with we should analyze what the features of a group is and
how the protocol and client supports those features. Then maybe we could work
out what improvements we could make to the base group functions
--- On Fri, 3/4/09, Charles Krinke c...@pacbell.net wrote:
From: Charles
Myself and Stefan did a Facebook/opensim integration application about a year
and a bit ago (http://www.youtube.com/watch?v=qkiilgjs0Rg) but we never took
it to deployment.
Apart from that I don't know of any opensim based integration with facebook. I
think there are some sl/facebook things
Good questions.
While OpenSim.Framework should be a general framework/library that can be used
in other programs, it has very much turned out to be more of a internal
framework for building the various opensim servers.
Also there is a question of if opensim.framework should actually have
Last week, I added the ability for opensim to search a folder for ini files and
load (and merge together) all of those files.
By default it will look for the folder 'bin\config' and search that for .ini
files. The folder it searches can be changed by using the command line argument
I don't know about the snapshot one because I haven't actually looked to see
what CAPS the client is requesting lately. But the others are caps services
that the client requests (or at least used to).
As you know when the client first connects it makes a request to the caps seed
that it was
in
region modules. So do most other comms I'm aware of. Take users, fir
instance. The application never talks about users, regions do. The
user server comms really should be a shared region module.
Modularisation is the key here, not centralisation.
Melanie
MW wrote:
More and more
or Global/comms modules is a different
question. I just think we should have more specialisation in the modules so we
can easily change the network protocols without replacing the whole sub system
of a feature.
--- On Thu, 26/2/09, MW michaelwr...@yahoo.co.uk wrote:
From: MW michaelwr...@yahoo.co.uk
, 26/2/09, MW michaelwr...@yahoo.co.uk wrote:
From: MW
michaelwr...@yahoo.co.uk
Subject: Re: [Opensim-dev] Comms Manager
To: opensim-dev@lists.berlios.de
Date: Thursday, 26 February, 2009, 9:44 AM
Well I agree
the name CommsManager is a bad choice and I'm all
easily change the network protocols without replacing the whole sub system
of a feature.
--- On Thu, 26/2/09, MW michaelwr...@yahoo.co.uk wrote:
From: MW michaelwr...@yahoo.co.uk
Subject: Re: [Opensim-dev] Comms Manager
To: opensim-dev@lists.berlios.de
Date: Thursday, 26 February, 2009, 9:44
easily access these interfaces, too.
Application modules that expose no services to Scenes at all can
skip that step completely.
Melanie
MW wrote:
I was never suggesting that we keep CommsManager as it is. I was suggesting
baby steps so for now there would be a commsManager
sub system of a feature.
--- On Thu, 26/2/09, MW michaelwr...@yahoo.co.uk wrote:
From: MW michaelwr...@yahoo.co.uk
Subject: Re: [Opensim-dev] Comms Manager
To: opensim-dev@lists.berlios.de
Date: Thursday, 26 February, 2009, 9:44 AM
Well I agree the name CommsManager
Just a though,t but maybe we are trying to be too generic in finding a single
interface that meets all needs. We have a plugin loader (Mono.addins) that can
quite easily load different plugin types. So by using the IApplicationPlugin
system, we can have them also loading other plugin types.
To: michaelwr...@yahoo.co.uk, opensim-dev@lists.berlios.de
Date: Thursday, 26 February, 2009, 12:50 PM
I'd have to see that, but it sounds good.
Can you illustrate?
Melanie
MW wrote:
Just a though,t but maybe we are trying to be too generic in finding a
single interface that meets all needs. We have
on the region, and
the region modules uses it.
That is much cleaner.
Melanie
MW wrote:
Well I hadn't really thought out all the details but what I meant is
we
can have a IApplicationPlugin that can load other plugin types itself.
So if we look at the code in OpenSimBase that loads
to start on the process of cleaning the
whole system up. Maybe at a later date we might decide to remove the access to
the global registry from the scenes (but at this time, I'm against that)
--- On Thu, 26/2/09, MW michaelwr...@yahoo.co.uk wrote:
From: MW michaelwr...@yahoo.co.uk
Subject: Re
in a
callback, and that would actually let them register only to specific
scenes if they wanted to. More flexibility yet.
Melanie
MW wrote:
Hmm, I never suggested anything that would mean one scene be able to
directly access another.
I see the GlobalRegistry as a very basic interface
scenes/regions. And then the current
Registry in Scene.
Then its upto the modules/components/plugins to which registries they want to
register.
And certain plugin types might only get references allowing them to register to
certain registeries.
--- On Thu, 26/2/09, MW michaelwr...@yahoo.co.uk
in core, where i think that
complexity (e.g. registering to scenes) s better off distributed inside the
modules that actually need it. Keep it simple. I believe my approach is what
will work with the least amount of core code, and provide the greatest
flexibility.
Melanie
MW wrote:
I know I said we
, and has no
automagic that is hard to understand or brittle.
Melanie
MW wrote:
I still think we should have a SharedRegistry that all Scenes have access
to. Some of the current shared RegionModules could move to using it as well. And
I know some of the other devs want one to; Adam and Stefan were
();
loader.OnNewScene += NewScene;
}
private void NewScene(IScene scene)
{
}
and that will solve it.
I am objecting only to the attempts to create a complex solution for
a simple problem, when the above is the simple solution we already
mostly have.
Melanie
MW wrote:
Well I still want to be able to have
, Melanie mela...@t-data.com wrote:
From: Melanie mela...@t-data.com
Subject: Re: [Opensim-dev] Comms Manager
To: michaelwr...@yahoo.co.uk, opensim-dev@lists.berlios.de
Date: Thursday, 26 February, 2009, 6:00 PM
Well, here goes
MW wrote:
I'm not actually bothered about the interface per se. What I
: Thursday, 26 February, 2009, 7:07 PM
MW wrote:
I'm not actually bothered about the interface per se. What I require
is
to be able to dynamically load generic modules that no where in that
module does it know about IScene/Scene.
I actually see your approach as complex because it demands
is another question.
But, +1
Melanie
MW wrote:
Well I think the compromise we basically agreed on is that we go with
IApplicationPlugins being able to register to the ApplicationRegistry and also
(via OnRegionCreated events) to the scenes.
And then for the service modules, we can have
a
ApplicationPlugin that is a loader of IService modules. So these ideas are just
about how that loader handles things.
--- On Thu, 26/2/09, MW michaelwr...@yahoo.co.uk wrote:
From: MW michaelwr...@yahoo.co.uk
Subject: Re: [Opensim-dev] Comms Manager
To: opensim-dev@lists.berlios.de
Date: Thursday, 26
what we ended up with was fine and agreeable to all, and now here you
come again with region modules/regions accessing the core directly. I think that
is a BadIdea(tm) to allow calls from regions into base directly.
Melanie
MW wrote:
Or a slightly different approach would be to add a security
More and more of the Region to UGAIM comms and Region to Region comms, is being
moved out of the Comms Manager and into region modules. Is this a process we
should continue and move everything out of there and into Region modules?
I'm a bit torn on that issue, and I think a few other people
wrote:
Hi,
On Sat, Feb 21 2009 10:41:28 -0800
m...@opensimulator.org wrote:
Author: mw
Date: 2009-02-21 10:41:28 -0800 (Sat, 21 Feb 2009)
New Revision: 8554
Added:
trunk/OpenSim/Grid/GridServer/IUGAIMCore.cs
Removed:
trunk/OpenSim/Grid/GridServer/IGridCore.cs
To me
Typo Correction:
*Maybe a name change on that module is needed as well, so its clear its about
Messaging servers registering with it and
provides a inteface so other modules can request the data about those
registered messaging servers.
--- On Mon, 23/2/09, MW michaelwr...@yahoo.co.uk wrote
the way, we might end up with just one single
GenericServer, which, when configured with running all services, would
be the equivalent of the standalone mode.
Probably not something that can be done overnight, but just a thought...
MW wrote:
Well the name changed came
: [Opensim-dev] MXPClient?
To: opensim-dev@lists.berlios.de
Date: Sunday, 22 February, 2009, 6:28 PM
OK. I guess new projects don't load when VS is already running. Had to
exit and restart.
MW wrote:
After running prebuild it should be in the VS (2008)
solution
.
I think this is an extension beyond what the Express editions support and we
might want to consider making our build a tiny bit more 'vanilla'.
Charles
From: MW michaelwr...@yahoo.co.uk
To: opensim-dev@lists.berlios.de
Sent: Sunday, February 22, 2009 10:30:00 AM
Subject: Re: [Opensim-dev
Yeah, I don't think we should just remove the option to set what sort of asset
system is used. As although I'm not sure if anyone does it, I think a important
part of our system is that we allow modes in between full standalone and full
grid, like someone could have a mostly standalone system
I don't think this is really practical, different users will want things
running on different ports. And we need to allow all ports to be changed.
Also some people might be running multiple grids (servers) on one physical
server. So they all couldn't be running their discovery service on the
+1, lets not make things even more complicated. A lot of people aren't sure
what state to set already. So if we made some changes my vote would be more for
removing some of the states, rather than adding more.
Jeff Ames jeffa...@gmail.com wrote: Hello,
I was originally thinking that we might
I think with a bit of trickery its also possible to have multiple region
servers managing a 256X256 area. As apart from terrain, a region can tell a
client that objects are outside its own 256X256 area.
So if you had 9 regions set up in a 3X3 array. With the centre 256x256 area
being where
There is also IClientFileTransfer (and LLFileTransfer) that I moving all the
err client file transfer code. But thats still a work in progress.
Charles Krinke c...@pacbell.net wrote: This seems like a capital idea to me
and will allow OpenSim to more easily have modules added for other,
My preference is that we modulariSe the whole avatar creation, its much more
flexible.
Also on that subject I suggest we move the server side avatar data from the
user server to one of the other servers (most likely the inventory server). I
don't think it should be in the user server for a
This is more to do with how we use Mono.Addins, but we really should make it a
lot easier to separate the various UGAIM servers, so that each one can be in
its own directory without needing the other UGAIM exe's to be in there.
By default we have the loading of plugins referencing all the
of common
standards, professionalism, code quality, and cooperation.
Cheers,
On Sun, Jan 25, 2009 at 12:35 PM, MW wrote:
Yeah I wasn't really being serious that we should try to get as many
spelling systems or langauges as we can.
So I do agree that it would be best to have one
type the correct ones, they go to a phishing site.
On 1/25/09, MW wrote:
+1000, that sounds like a good compromise. Then everyone has to make a
effect to make sure their spellings are correct.
Frisby, Adam wrote:
I can get our Shanghai office to translate our comments into Cantonese
actually should we wait a while and get more reaction. As this is going to
effect anyone who has a module that isn't in trunk. Seems a lot of hasle for
such a small thing.
Would seem better to wait and make the change when/if we change to homer's new
module interface.
MW michaelwr
I've just added some very initial support for reading Hypergrid link data from
xml files, that includes support for the xml files being on a webserver.
The xml file has a format like:
Nini
Section Name=Region1
Key Name=xloc Value=1002/
Key Name=yloc Value=1006 /
Key
59 matches
Mail list logo
