10 seconds is roughly the time between the region handshake completing and you being in world where you can see your avatar. So normally the terrain still should have loaded by time you get in the region, although it is possible that sometimes you might see the very end of the terrain load just after you arrive.
* Insert the very rough beginning stubs for a save/load OpenSim archive facility that will load/save prim assets (textures & inventory) as well as the prim details themselves
(our existing xml facilities).
* This won't be ready for even rough testing for quite some time.
* I'm doing this directly in the region server for now since this will be quicker to get something working (hence giving me the Serotonin boost that I need). However, there are
very good arguments for later also including it (or moving it entirely) to the separate export executable which Sean stubbed out some time ago.
i've added the OSHttpStatusCodes enumeration of HTTP status codes, have adapted
BaseHttpServer to use those.
then RestPlugin now has proper Failure handling returning proper HTTP status
codes. Regions/POSTHandler is work-in-progress.
* This is the same string as printed out on the opensim region console at startup, so it should now include the svn revision number (if available)
* This dialog box takes an awful long time to come up on my local system - no idea why that is. However, that also seems to have been the case before this revision.
* If a caller attempts to set PrimitiveBaseShape.ProfileCurve with a HollowShape or ProfileShape component which is not a valid enum, a warning is spat out and a default shape
subtituted
* This does not solve any underlying problem if we're missing some enum values (though it's not obvious what these are), but it should allow save-xml2/load-xml2 to be used
without causing invalid enum value related exceptions. The checks will also guard against badly behaved clients.
* This change alters the order of shape values in the xml, since it appears properties are serialized after fields (at least this is the case in mono). .net native
deserialization can cope with this it appears, though people manipulating xml manually may need to adapt (if there are any).
* This may be a good argument against relying on .net [de]serialization for our xml format.
* Concurrency issues are resolved because each object makes a memory-only copy of itself and backs up the copy.
* Because of the way this is done, the latest at the time of the backup gets backed up (no functionality change)
* You can move *thousands of objects at a time* and the sim doesn't freeze and wait for the backup to complete.
* This can be enhanced more by dedicating the thread as opposed to starting it when the backup process starts.
Fix RequestUpdateInventoryItem so that asset changes
generate a new asset, which is needed for editing
appearance to do the right thing. Persistant appearance
seems to work after this, except you need to rebake textures
some times.
provide OSHttpRequest and OSHttpResponse to our REST handler.
also, this adds proper RestPlugin.IsGod() checking against the X-OpenSim-Godkey
HTTP request header.
last, i added XML doc comments to RestPlugin.cs
the "if (request.UserAgent != null)" branch in the wrong place: as a result BaseHttpServer would not do
anything if the user agent header field was present....ARGH! BAAAAAAD.
You sure can. This change set restores pants (and the rest of the
default appearance) in grid mode. The
root issue had to do with serializing multi-faced textures to the
grid server. This also restores the lookup path through the avatar
factory module, as that seems the reasonable place to have it live.
Some clean up patches are coming later as well, plus testing on
standalone, but this should be in a good kicking around state for
grid users.
Justin Clarke Casey