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.
I know this is tough on Mac OSX users (since SQLiteNG requires the export of the sqlite3_column_origin_name symbol and this isn't present for the Mac OSX sqlite3 system library)
Unfortunately, I need to shaft somebody (as it were)
Include the library so that Windows builds correctly
It appears that Windows is okay with either SQLite or SQLiteNG
Incorporate the latest fixes made by Diva to OpenSim.Data.SQLite
This means moving the alert up to a place where the IClientAPI is available.
One can also argue that such client messages shouldn't be sent directly from the scene data model
This implements the 'share with group' flag for notecards and scripts in prim inventory since the PermissionsModule checks group membership and permissions.
Other than that, the code in PermissionsModule duplicates the checks in LLClientView so there should be no change other than allowing group members to edit embedded notecards and scripts.
For all other asset types, the permission checking code in LLClientView continues to be used, pending refactoring of suitable permissions code
This means that 'share with group' will not yet work for prim inventory items other than notecards and scripts
is fully rezzed and all scripts in it are instantiated. This ensures that link
messages will not be lost on rez/region crossing and makes heavily scripted
objects reliable.
This allows you to load an oar without loading its assets. This is useful if you know that the required assets are already in the asset service, since loading without assets is quicker.
This option will become more useful when the ability to save oars without assets is added, which should happen fairly soon. At this point there will also be better documentation.
the lack of this caused me a NullReferenceException when calling some groups methods directly though in principle it would also fail in other situations
probably appears to occur because mono 2.4.2.3 (and possibly later) erroneously returns a value of 0 for BufferWidth and BufferHeight in some circumstances
Justin Clark-Casey (justincc)