| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
that it can be overwritten in subclasses. That way extensions can decide in which assembly migration resources should be looked up. This is a refactor similar to commit 9923a2ff1002d722ccebea8bf4d71718ed4e2a03 for MySQL -- no functional changes.
|
| |
|
|
|
|
|
|
| |
changes to all the estates that the user owns).
This applies to adding/removing estate users, groups, managers and bans.
This is the application of the AllEstates_0.5.patch from http://opensimulator.org/mantis/view.php?id=5420
Thanks very much, Snoopy!
|
| |
|
|
| |
region part of an existing estate, then list the existing region names.
|
| |
|
|
|
|
|
| |
* Hopefully this will enable mac people to use SQLite again
* Someone cooler then me will need to figure out how to define CSharpSqlite with Mono so the conditional will pick up.
* There's also an error that occurs when you first load OpenSimulator under CSharpSQLite that goes away after.
* The databases are not byte for byte compatible. Mono.Data.Sqlite is able to read CSharpSqlite made databases but not the reverse way.
|
| |
|
|
|
|
|
|
|
|
| |
* Use a conditional define to determine whether we're using CSharpSqlite or Mono.Data.Sqlite
#if CSharpSqlite
using Community.CsharpSqlite.Sqlite;
#else
using Mono.Data.Sqlite;
#endif
* Hopefully, this will restore sqlite functionality on a Mac. In visual studio, you can edit the OpenSim.Data.SQLite project, go to the Build tab and enter CSharpSqlite in the box. I'm not sure how to define CSharpSqlite in Mono, someone better at it then me will have to take the job of figuring out the best way to define it in Mono.
|
| |
|
|
|
| |
* Removed StorageManager
* CONFIG CHANGE: There are no more database settings in OpenSim.ini. Check the config-include configuration files for region store and estate store database settings
|
| | |
|
| |
|
|
|
|
|
| |
this seems the least evil way forward since mono 2.6 and later will see increasing usage, and this only works with what was SQLiteNG
MAC USERS WILL NEED TO CHANGE REFERENCES TO "OpenSim.Data.SQLite.dll" to "OpenSim.Data.SQLiteLegacy.dll" in OpenSim.ini and config-include/StandaloneCommon.ini (if using standalone)
See the OpenSim.ini.example and StandaloneCommon.ini.example files for more details
This commit also temporarily changes unsigned ParentEstateID values in the OpenSim.Data.Tests to signed temporarily, since the new plugin enforces creation of signed fields in the database (which is what the SQL actually specifies). And change data columns in sqlite is a pita.
|
| | |
|
| |
|
|
|
|
|
| |
of a region and joining it to an existing estate or creating a new estate,
as well as creating an estate owner if in standalone, and assigning estate
owners. In Grid mode, existing users must be used. MySQL ONLY!!!! so far, as
I can't develop or test for either SQLite or MSSQL.
|
| |
|
|
|
| |
defaults. Adding code to facilitate estate creation / managemment as part of
first time start up
|
| |
|
|
| |
LICENSE.txt.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
nhibernate mapping. Refactored property getters and setters for estate ban object to support NHibernate.
* Added estate ban table to migration scripts of all supported databases.
* Added nhibernate mapping for EstateBans property of EstateSettings
* Refactored property accessors for EstateBan object.
* Added comments for EstateBan properties.
* Ensured that NHibernate tests pass with NUnitGUI.
* Ensured that nant test target passes.
This fixes mantis #3210. Thank you, tlaukkan!
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
OpenSim.Region.Environment into a "framework" part and a modules only
part. This first changeset refactors OpenSim.Region.Environment.Scenes,
OpenSim.Region.Environment.Interfaces, and OpenSim.Region.Interfaces
into OpenSim.Region.Framework.{Interfaces,Scenes} leaving only region
modules in OpenSim.Region.Environment.
The next step will be to move region modules up from
OpenSim.Region.Environment.Modules to OpenSim.Region.CoreModules and
then sort out which modules are really core modules and which should
move out to forge.
I've been very careful to NOT BREAK anything. i hope i've
succeeded. as this is the work of a whole week i hope i managed to
keep track with the applied patches of the last week --- could any of
you that did check in stuff have a look at whether it survived? thx!
|
| | |
|
| |
|
|
|
|
|
| |
* This is a HUGE OMG update and will definitely have unknown side effects.. so this is really only for the strong hearted at this point. Regular people should let the dust settle.
* This has been tested to work with most basic functions. However.. make sure you back up 'everything' before using this. It's that big!
* Essentially we're back at square 1 in the testing phase.. so lets identify things that broke.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
owner (alongside the master avatar) and provides storage fo the
abuse email address. No user functionality yet.
This patch includes a migration.
|
| | |
|
| |
|
|
|
|
| |
but earlier versions of the SQLite dll
|
| |
|
|
|
|
|
| |
No longer teleports an agent home unless their root agent is being banned.
Visual blocking is still in effect.
|
| | |
|
| | |
|
|
|
Makes the estate dialog fully functional. Implements all client facing functionality. Moves estate data from estate_settings.xml, which is used to provide defaults, to the region data store. Creates one estate for each region, and places the region in it. Converts all region bans to estate bans.
|
