Sean Dague wrote:
> Dahlia Trimble wrote:
>> When a module moves out of core and to forge, what process would be in place
>> to make sure these modules remain compatible when possibly breaking changes
>> are made to core? I use the IRC module in some of my regions and I wouldn't
>> want to see it b
ould be argued that bringing that active module, which is
>> one small C# file into SVN might be to our advantage for the same reasons we
>> are discussing here.Charles
>>
>>
>> From: Sean Dague To: opensim-...@lists.berlios.desent:
>> Monday, February 9, 2009 11:3
set of forge module sources
> into that directory - which prebuild would then just bundle together into one
> big fat glorious module dll, custom to your environment.
> Best regards,Stefan AnderssonTribal Media AB
>
>
>
> Date: Mon, 9 Feb 2009 11:42:31 -0800From: c...
Sean Dague wrote:
> Dahlia Trimble wrote:
>> When a module moves out of core and to forge, what process would be in place
>> to make sure these modules remain compatible when possibly breaking changes
>> are made to core? I use the IRC module in some of my regions and I wouldn't
>> want to see it b
n AnderssonTribal Media AB
Date: Mon, 9 Feb 2009 11:42:31 -0800From: c...@pacbell.netto:
opensim-...@lists.berlios.desubject: Re: [Opensim-dev] what are the core region
modules? which are not?
SDague has a good point. And it gets a bit more interesting when one considers
the OSSearch module, which
is one small C# file
into SVN might be to our advantage for the same reasons we are discussing here.
Charles
From: Sean Dague
To: opensim-dev@lists.berlios.de
Sent: Monday, February 9, 2009 11:30:59 AM
Subject: Re: [Opensim-dev] what are the core region modules
Dahlia Trimble wrote:
> When a module moves out of core and to forge, what process would be in place
> to make sure these modules remain compatible when possibly breaking changes
> are made to core? I use the IRC module in some of my regions and I wouldn't
> want to see it broken, and I like to sta
What I was trying to say was taking a region module out core would allow
core to deviate in compatibility from those modules and not provide any
feedback to core developers that a deviation had occurred, nor would it
enforce any responsibility to maintain compatibility. In my case I would
have to d
When a module moves out of core and to forge, what process would be in place
to make sure these modules remain compatible when possibly breaking changes
are made to core? I use the IRC module in some of my regions and I wouldn't
want to see it broken, and I like to stay close to head in all of my r
Melanie wrote:
> Hi,
>
> I believe TreePopulator should be an optional module.
k.
> Conversely,
> Combat is required to be present for the llSetDamage() and related
> functions as well as the damage setting in the viewer to work
> properly and should therefore be core.
ah. ok, makes sense.
u
Dr Scofield wrote:
> Justin Clark-Casey wrote:
>> Dr Scofield wrote:
>>> i'm now working on step 2 of the OpenSim.Region.Environment refactor.
>>> here is a list of CoreModules and OptionalModules. clearly the later
>>> ones are candidates for moving to forge. any comments on the contents of
>>> th
Melanie wrote:
> Two chat modules? The chat module should certainly be core.
sorry. typo. one ChatModule in Core and IRC stuff (which lived in Chat module
subdir) which i'd like to move to Optional.
DrS/dirk
>
> Melanie
>
>
> Dr Scofield wrote:
>> Dr Scofield wrote:
>>> i'm now workin
Two chat modules? The chat module should certainly be core.
Melanie
Dr Scofield wrote:
> Dr Scofield wrote:
>> i'm now working on step 2 of the OpenSim.Region.Environment refactor.
>> here is a list of CoreModules and OptionalModules. clearly the later
>> ones are candidates for moving to forge.
Hi,
I believe TreePopulator should be an optional module. Conversely,
Combat is required to be present for the llSetDamage() and related
functions as well as the damage setting in the viewer to work
properly and should therefore be core.
Melanie
Dr Scofield wrote:
> i'm now working on step 2
Justin Clark-Casey wrote:
> Dr Scofield wrote:
>> i'm now working on step 2 of the OpenSim.Region.Environment refactor.
>> here is a list of CoreModules and OptionalModules. clearly the later
>> ones are candidates for moving to forge. any comments on the contents of
>> these two lists? any modules
Dr Scofield wrote:
> i'm now working on step 2 of the OpenSim.Region.Environment refactor.
> here is a list of CoreModules and OptionalModules. clearly the later
> ones are candidates for moving to forge. any comments on the contents of
> these two lists? any modules that should not be in CoreModul
Dr Scofield wrote:
> i'm now working on step 2 of the OpenSim.Region.Environment refactor.
> here is a list of CoreModules and OptionalModules. clearly the later
> ones are candidates for moving to forge. any comments on the contents of
> these two lists? any modules that should not be in CoreModul
i'm now working on step 2 of the OpenSim.Region.Environment refactor.
here is a list of CoreModules and OptionalModules. clearly the later
ones are candidates for moving to forge. any comments on the contents of
these two lists? any modules that should not be in CoreModules (and any
modules that sh
18 matches
Mail list logo