| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|\
| |
| |
| | |
into presence-refactor
|
| | |
|
|/
|
|
| |
CreatorID, it doesn't modify database backends or OAR files to support storing/loading it
|
|
|
|
|
|
|
| |
This resolves the problem where eyes and hair would turn white on standalone configurations
When a client receives body part information, for some insane reason or other it always ends up uploading this back to the server and then immediately re-requesting it.
This should have been okay since we stored that asset in cache. However, the standalone asset service connector was not checking this cache properly, so every time the client made the request for the asset it has just loaded it would get a big fat null back in the face, causing it to make clothes and hair white.
This bug did not affect grids since they use a different service connector.
|
|
|
|
| |
unknown asset type, and log an error if it ever does happen
|
| |
|
|
|
|
| |
retrieval was not synchronous.
|
| |
|
|
|
|
| |
cache at all)
|
| |
|
| |
|
| |
|
|
|
|
| |
LICENSE.txt.
|
|
|
|
|
|
| |
https://lists.berlios.de/pipermail/opensim-dev/2009-May/006673.html
|
|
|
|
| |
Them being synchronous in certain cases (asset in cache, for example) may account for slowness reported by folks in osgrid when they have the cache module on. Turns out that some of the provided handlers do non-trivial processing (the ones coming from J2KImage, for example), which means that the several asset requests that hit the cache end up being synchronous. The jury is still out on this.
|
|
|
|
|
|
|
|
| |
whatever reason, but it won't crash the sim.
Addresses mantis #3707, mantis #3713, mantis #3686.
|
|
the user server skeleton in preparation for introducing a generic server
|