This should not currently be used in any circumstances except for experimentation.
Database tables used by this plugin can still change at any time with no migration path.
This is to deal with the hundred lines of command splurge when one previously typed "help"
Modelled somewhat on the mysql console
One can still type help <command> to get per command help at any point.
Categories capitalized to avoid conflict with the all-lowercase commands (except for commander system, as of yet).
Does not affect command parsing or any other aspects of the console apart from the help system.
Backwards compatible with existing modules.
We can now do this since the entire scene and all objects within it are now successfully gc'd at the end of these tests.
This greatly improves the time taken to run each test (by reducing teardown time, not the time to actually do the test work that we're interested in).
Slightly simplifies config read in Scene constructor to help facilitate this.
OnNewScript fires when a script is added to a scene
OnRezScript fires when the script actually runs (i.e. after permission checks, state retrieval, etc.)
I believe this was originally required back when there could be two LocalGridServiceConnectors but this is no longer the case.
Having such statics makes performance testing much more difficult since they prevent GC of objects unless static references are explicitly nulled.
They were all failing assertions but the exceptions these threw were caught as expected Exceptions.
I don't think we can easily distinguish these from the Exceptions that we're expecting.
So for now we'll do some messy manually checking with boolean setting instead.
This patch also corrects the assertions themselves.
The part reverted is from commit 2ebb421.
Unfortunately, IAvatarFactoryModule.SetAppearance() does not transfer attachments.
I'm not sure how to do this separately, unfortunately I'll need to leave it to Dan :)
Regression test added for this case.
Mantis ref: http://opensimulator.org/mantis/view.php?id=5914
Some successful collision attacks have been carried out on sha1 with speculation that more are possible.
http://en.wikipedia.org/wiki/Cryptographic_hash_function#Cryptographic_hash_algorithms
No successful attacks have been shown on sha256, which makes it less likely that anybody will be able to engineer an asset hash collision in the future.
Tradeoff is more storage required for hashes, and more cpu to hash, though this is neglible compared to db operations and network access.
Melanie