| Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
of existing fields
* 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
|
|
by the client throttle setting does not
* Old behaviour was to throw an exception on startup
* Print out client stack setting temporarly for debug purposes
|
|
See OpenSim.ini.example for details as to what this means
* 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
|
|
multiplier is applied to all the client throttle settings received by the client
* 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.
|
|
adjustable setting yet (and then only for debug purposes)
|
|
since this is always non null
|
|
ClientStackUserSettings class
* This conforms better to other module usage
|
|
initialisers, etc.
|
|
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.
|
|
* Don't save attachments on saving oar, which stops them coming back as ghost prims
|
|
print this out to the log once
* 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)
|
|
get through after the malformed ones have been sent
|
|
passes it malformed data
|
|
first place
|
|
|
|
|
|
|
|
sending ImageNotFound to clients if avatar textures are missing
* 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
|
|
logging messages
|
|
|
|
|
|
signature
|
|
|
|
|
|
|
|
|
|
|
|
region server wasn't told that it was coming)
* 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
|
|
* The fact that the assert passed even when authentication failed reveals a bug in the code that will be corrected soonish
|
|
|
|
|
|
|
|
* If this was important to you please reinsert and we can put it in a recognized interface.
|
|
* 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).
|
|
|
|
* Temporarily disabled assert because it just picked up an existing bug. Yay for tests!
|
|
synchronously. Shouldn't be any functional change
|
|
real groups module can even be implemented.
|
|
|
|
* Guys, there's an endless loop there *ON PURPOSE*. Please don't try to *fix* it. We must continue to process the UDP stream buffer on clients that disconnected nastily until it ends or the UDP server accept thread will die a horrible death.
|
|
|
|
|
|
Add rezzing time to objects. Add Object return and traffic fields to land
database. Add plumbing for auto return. Implement auto return.
Contains a migration. May contain nuts.
|
|
|
|
if we are adding a client
* Regarding an earlier change, I think it would be possible to eliminate the creation of new IPEndPoints on every end receive if we did the client circuit lookup before starting
the next receive. However, this would be a performance trade off and hence not worth trying without performance testing
|
