The encodings are thread-safe and already used in such a manner in other places.
This isn't done where Byte Order Mark output is suppressed, since Encoding.UTF8 is constructed to output the BOM.
* Removed two redundant parameters from SceneObjectPart
* Changed some code in terse update sending that was meant to work with references to work with value types (since Vector3 and Quaternion are structs)
* Committing a preview of a new method for sending object updates efficiently (all commented out for now)
* Added permissionLevel attribute to [MRM] section in OpenSim.ini. Default is 'Internet', however may be any of the following (case sensitive), FullTrust, SkipVerification, Execution, Nothing, LocalIntranet, Internet, Everything. For previous functionality, set to FullTrust or Execution.
Date: Wed, 5 Aug 2009 12:45:56 +0200
Subject: [PATCH] A few minor tweaks to the MRM API's in order to make it possible for MRM's to run in a separate AppDomain without poluting the primary appdomain of OpenSim
Specifically:
Added an explicit method for getting the "globals" of the MRM, removing the need to have the MRM script code loaded into the primary domain, in order to set up proxies
Added a [Serializable] attribute to TouchEventArgs, again in order to remove the need to have MRM script code loaded into the primary domain.
---------
Applied with whitespace changes
* MRM Scripts should do appropriate cleanup within this event, to allow for clean shutdowns and script updates. This means unbinding from events you are listening to, and releasing any resources.
This add a configuration option to the MRM module called "hidden".
if MRM is marked as enabled, the module will additionally check for
the "Hidden" flag, before registering for client side scriping events.
When MRM is running hidden, it will not respond to client side
scripting events, giving serverside scripting modules, like MRMLoader
and MRMAddin the ability to leverage the MRM engine. This way, even
a possible clientside exploit will not be possible, while still
allowing the MRM engine to run.
* Example in region module:
Scene.GetModuleInterface<IMRMModule>.RegisterExtension<IMyInterface>(this);
* In the MRM:
//@DEPENDS:MyExtensionModule.dll
...
Host.Extensions<IMyInterface>.DoStuff();
* This allows you to utilize System.Drawing tools on textures within the region.
* Example: use System.Drawing.Bitmap to make your texture, then use Host.Graphics.SaveBitmap to make an asset from it in JPEG2K. You can edit (but not overwrite) existing textures using Host.Graphics.LoadBitmap.
* This makes MRM scripting ever so slightly more secure. If you have enforced Object Permissions enabled, it may be acceptable to enable MRM within your regions.
* Security bug reports on this feature are much appreciated (eg: anyone finding ways around this to execute a MRM as a basic user).
* Corrected issue with MRMs where it would attempt to overwrite an already loaded DLL. (and thus fail with cryptic UnauthorizedAccessException.)
* Made DrunkenTextAppreciationModule.cs MRM not crash with StackOverflowException
* Added some temporary logging to MRM World.*
* Renames MiniRegionModule to MRMModule to make it more distinct from the actual Mini Region Module[s] executed in Scene.
* Renames MiniRegionModuleBase to MRMBase for convenience. MRM's need to be adjusted to inherit from MRMBase.
