| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | |
| | |
| | |
| | | |
other way because SOG doesn't technically exist in the DB
|
|\ \ \
| |/ /
|/| /
| |/
| |
| |
| | |
Conflicts:
OpenSim/Framework/Servers/VersionInfo.cs
OpenSim/Region/CoreModules/World/WorldMap/WorldMapModule.cs
OpenSim/Region/Framework/Scenes/ScenePresence.cs
|
| |
| |
| |
| |
| |
| | |
MySQL and MSSQL have it as Sandbox, sqlite as sandbox.
In various different places in every plugin the wrong casing is used...
Consistency, who needs it? Or one day sqlite can change to Sandbox.
|
|\ \
| |/
| |
| |
| |
| | |
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)
|
| | |
|
|\ \
| |/ |
|
| |
| |
| |
| |
| | |
Warning: Contains a Migration
Warning: Cannot guarantee nut free
|
|\ \
| |/
| |
| |
| | |
Conflicts:
OpenSim/Data/MySQL/MySQLSimulationData.cs
|
| |
| |
| |
| |
| | |
Warning: Contains a Migration.
Warning: May contain nuts.
|
| | |
|
| | |
|
| | |
|
| | |
|
|\ \
| |/
| |
| |
| |
| | |
Conflicts:
OpenSim/Data/MySQL/MySQLSimulationData.cs
OpenSim/Framework/RegionSettings.cs
|
| |
| |
| |
| | |
additional redundant information.
|
| |
| |
| |
| |
| |
| | |
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/Data/MySQL/MySQLSimulationData.cs
|
| | |
|
| | |
|
| | |
|
|\ \
| |/
| |
| |
| | |
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.
|
| |
| |
| |
| | |
Telehub settings now persist to the database and are saved across sim restarts. So-far this only works on MySQL. this is a work in progress, teleport routing is not yet implemented.
|
| | |
|
| |
| |
| |
| | |
values for places where NaN are found.
|
| |
| |
| |
| | |
replace it with
|
| | |
|
|\ \
| |/ |
|
| |
| |
| |
| | |
like they've been active for at least 2 and a half years
|
|\ \
| |/ |
|
| |
| |
| |
| |
| |
| | |
5035).
Using the RemoteAdmin API to close then recreate a region would fail if the estate name had not changed. If the estate name /was/ changed then the existing estate would be renamed rather than a new one being created. The problem really arose from a lack of distinction in the data storage layer between creating new estates and loading existing ones.
|
|\ \
| |/ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
them as UUID.Zero.
Leaving them at UUID.Zero meant that when a viewer 2 logged into a region that had been freshly created, it received UUID.Zero for these textures, and hence display the land as plain white.
On a simulator restart, the problem would go away since when the database adapators loaded the new region settings, RegionSettings itself has code to use default textures instead of UUID.Zero.
This commit resolves the problem by saving the default texture UUIDs instead of Zero.
However, we currently have to do this in a roundabout way by resaving once the RegionSettings have been created by the database for the first time. This needless complexity should be addressed.
This change will also have the effect of replacing any existing UUID.Zero terrain textures with the default ones.
However, this shouldn't have any effect since the UUID.Zeros were already being replaced in memory with those same UUIDs.
|
|\ \
| |/ |
|
| |
| |
| |
| |
| |
| |
| | |
objects that had previous been attachments.
Looks like this code was accidentally uncommented in e1b5c612 from feb 2010.
Appears to resolve the rest of http://opensimulator.org/mantis/view.php?id=5664
|
| | |
|
| | |
|
| |
| |
| |
| | |
set on the default profile and hopefully finally fix day and night
|
|\ \
| | |
| | |
| | | |
ssh://3dhosting.de/var/git/careminster into careminster-presence-refactor
|
| |\ \
| | |/ |
|
| | |
| | |
| | |
| | | |
wrong key
|
| |\ \
| | |/ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| |\ \
| | |/ |
|
| | |
| | |
| | |
| | | |
characters of each field -- that's the UUIDs. Thanks coyled. WARNING: Again, people who have gone through this migration and failed need to run it manually.
|
| | |
| | |
| | |
| | |
| | |
| | | |
Revert "Changed Friends table to have 165-sized varchars on PrincipalID and FriendID. The reason for this number is the following: there is a combined key of these 2 fields; apparently MySql can't handle keys larger than 1000 bytes; when the table is created with utf8 encoding, this combined key is bigger than 1000 bytes, and the migration fails. WARNING: this is not a new migration! People who have gone through this migration and failed should update the sizes of these fields manually."
This reverts commit 3fa54a156a83e498a7d5d0949a5f848fe82fe86f.
|