| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
circuitcode is already found in the first one
|
|
|
|
|
|
|
|
| |
could overwrite an existing endpoint that had not yet been used by the previous thread
* in practice these race conditions were probably pretty rare
|
|
|
|
|
|
|
| |
* This widened what I think is an existing race condition where asynchronous recieves could potentially stomp on each other's end points (though this must occur very rarely, if at
all, in reality)
|
|
|
|
|
|
|
|
| |
the existing one
* This requires copying details into a new endpoint when it needs to be stored in client/circuit code hashes
|
| |
|
|
|
|
|
|
|
|
|
| |
* This allows multiple user profile providers to be specified in OpenSim.ini separated by commas
* If multiple providers are specified then a request for a user profile will query each in turn until the profile is either found or all have been queried
* Unfortunately I don't believe this order can currently be specified, which if true is something that will need to be fixed.
* Thanks to smeans for the original patch.
|
| |
|
|
|
|
|
|
| |
* Hopefully this will resolve http://opensimulator.org/mantis/view.php?id=2383
|
|
|
|
|
|
|
| |
* I believe this is reasonable since code outside the Linden client stack shouldn't be aware of the packet format being used
* I would love to have made the method protected, but the LoadBalancerPlugin is still calling it and resolving that would require more work
|
| |
|
|
|
|
| |
there are some circumstances in which not finding a user is not an error
|
|
|
|
| |
LLClientView
|
|
|
|
| |
descriptive of its actual function
|
|
|
|
|
|
|
|
|
| |
when it moves
* This should fix a long standing issue where you often wouldn't see other people simply turn around without moving at all
* Arguably lastPhysRot (to mirror lastPhysPos) is not a good name, may change variable names later
|
| |
|
|
|
|
| |
descriptive of what it actually does
|
|
|
|
|
|
|
| |
* This may help http://opensimulator.org/mantis/view.php?id=2377 where large linksets do not always correctly delete - since a lost kill packet to the client could result in
the symptoms described
|