| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| |
| |
| |
| | |
Conflicts:
OpenSim/Data/MySQL/Resources/RegionStore.migrations
OpenSim/Region/Framework/Scenes/Scene.Inventory.cs
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
http://opensimulator.org/mantis/view.php?id=5869
Signed-off-by: BlueWall <jamesh@bluewallgroup.com>
|
| | |
| |
| |
| |
| |
| | |
accurately reflects the data sent by the viewer. Add times bans and the
expiration of timed bans.
Warning: Contains a Migration (and nuts)
|
| |\ \
| |/
| |
| |
| | |
Conflicts:
OpenSim/Data/MySQL/MySQLSimulationData.cs
|
| | |
| |
| |
| |
| | |
Warning: Contains a Migration.
Warning: May contain nuts.
|
| |\ \
| |/
| |
| |
| |
| | |
Conflicts:
OpenSim/Data/MySQL/MySQLSimulationData.cs
OpenSim/Framework/RegionSettings.cs
|
| | |
| |
| |
| |
| |
| | |
Telehub commits! They will eat your babies and corrupt your database while
they munch. DO NOT use anything from the first Telehub commit to this one.
FIRST GOOD COMMIT is the one FOLLOWING this one. You have been warned.
|
| |\ \
| |/
| |
| |
| | |
Conflicts:
OpenSim/Framework/RegionSettings.cs
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is damage control es EstateSettings is not the place this can be put.
EstateSettings is nt unique to a region and therefore would introduce
a hard limit of one telehub per estate, completely shutting off the
option of having SL style telehubs, e.g. one per region. Whole
estate teleport routing can still be implemented id desiresd, this
way all options are open while the other way most options get closed
off.
|
| |\ \
| |/ |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Using MyISAM proves vastly faster for persisting scene objects.
For instance, a scene object that took 9 seconds to persist before now takes 1. This also improves the experience of loading large OARs.
We don't use any of the transactional features of InnoDB.
The only thing that may have an impact is that InnoDB does row locking on inserts while MyISAM does table locking.
However, field reports say there is no noticeable difference.
|
| |\ \
| |/ |
|
| | |
| |
| |
| |
| |
| | |
themselves. Tested. Seems to be working, main tests pass. Nothing done for IARs or HG transfers yet -- this only works for OARs for the time being.
New migration in inventory table in order to make CreatorID varchar(255).
|
| | |
| |
| |
| |
| |
| |
| | |
Creator name properly shown on the viewer as first.last @authority.
New option added to save oar -profile=url. Migration on RegionStore making CreatorID be 255 chars.
Moved Handling of user UUID -> name requests to a new module UserManagement/UserManagementModule.
|
| |\ \
| |/ |
|
| | |
| |
| |
| |
| |
| | |
properly for the new media settings.
Signed-off-by: Melanie <melanie@t-data.com>
|
| |\ \
| |/ |
|
| | | |
|
| |\ \
| |/ |
|
| | |
| |
| |
| | |
* Added an error message in initial estate owner creation that makes it clear what needs to happen.
|
| | | |
|
| | | |
|
| |\ \
| |/ |
|
| | |
| |
| |
| | |
better
|
| |\ \
| |/ |
|
| | |
| |
| |
| | |
(some Estate SQL left behind in the Region migration)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
ok, so the estate stores now want their own migration files, but as it
happened the SQL definition were inside the Region migrations.
It seems better/cleaner to keep each 'store' separately updatable.
WARNING: any editing in the middle of the migration scripts (as opposite
to just appending to them) has the potential of messing up updates of
existing databases. As far as I can see, this one is (probably) safe,
the worst that could happen is the EstateStore migration silently fail
if the estate the tables are already there.
|
| |/ |
|
| |
|
|
| |
files. Restored Presence table to its taboo-breaking form.
|
|
|
Replaced all NNN_StoreName.sql migration resources with a more
readable, single-file-per-store
|
