* This should (hopefully) allow TestClient and stuff built on top of it to work again
* Will probably come back later and change variable names to stop this happening again
* Really this should be 1, but I think that this would be too slow compared to a Second Life server until we improve our ability to send textures of variable quality
* This may improve one aspect of sim performance where there are many avatars. However, there are still other performance problems that are unrelated to this change
* Value may be further tuned
* Removed temporary decals since the multipler setting will stick around now
* This should probably be 1, but currently by default it is 8, to reflect what was being eon3 in OpenSim before this revision. So if the client requested a maximum throttle
of 1500 kilobits per second, we would actually send out 1500 kilobytes per second
* Adjusting this multiplier down towards 1 may improve your OpenSim experience, though in other situations it may degrade (e.g. if you're using a standalone over high bandwidth
links)
* This is currently a user setting because adjusting it down may currently reveal other OpenSim bugs.
on-/offline updates, calling cards for friends.
This adds methods in the DB layer and changes the MessagingServer, so a full
update (incl. UGAIM) is necessary to get it working. Older regions shouldn't
break, nor should older UGAIM break newer regions, but friends/presence will
only work with all concerned parts (UGAIM, source region and destination
region) at this revision (or later).
I added the DB code for MSSQL, too, but couldn't test that.
BEWARE: May contain bugs.
* This may help us detect if mysterious UDP disconnects are happening because of this.
* Shouldn't be any functional change but I would appreciate a buddy check from Teravus if he has time (as for all client stack changes)
* Whilst this does automatically get the client to rebake, on crossing a region border the 'local' assets are left behind
* There may be a cunning solution (such as squirting the assets on region crossing, or having them fetched from the original region) but
instead I'm going to opt for the easy solution of keeping them in the asset database, for now
* And hopefully rebaking all the time should no longer be necessary now
* It turns out that when the client baked the texture, the uploaded asset had the Temporary flag to true (Temporary is actually deprecated).
* It also had the StoreLocal flag set to true, which signifies that the asset should be stored locally. If it disappears we should reply to the asset request with
ImageNotInDatabasePacket
* However, last time this was enabled some clients started crashing. This may well no longer be the case and needs to be tested, but in the mean time we will store
the asset instead.
* This needs to be resolved in a better way, possibly by starting to send the ImageNotInDatabase packet again instead
* This moves authentication from the client thread (where failure was difficult to detect) to the particular thread handling that packet
* I've kept the authentication outside of the crucial clientCircuits lock (though any delay here is probably swamped by the other delays associated with login)
* Also added more to the unit test to ensure this doesn't regress
* This checks that a client circuit is established when the udp server is given a use client circuit code packet
* And checks that other circuit codes do not exist
* Not sure why things still worked in the presence of this bug - possibly the problem is compensated for later on. If you are having udp session problems this bug fix may help
(though no guarantees).
