OpenSim.32BitLaunch.exe is a 32-bit application that loads OpenSim.exe using .Net framework, hence it is JIT-compiled to 32-bit.
Use this app to start OpenSim on 64-bit systems (works great on Vista 64 :))
Added VISUAL BASIC.NET-support
//cs, //lsl and //vb as first characters of script will determine what compiler is used.
Compile warnings are no longer treated as errors. Script will still run.
Added a few useless and useful config options:
Write script source to harddisk for debug, Default compile language, Allowed compilers (languages), compile in release or debug mode, clean up old scripts on startup
Loads of warnings for incorrect config
Added comments and regions, restructured code
Changed a lot of AppDomain junk from console from using Console.Write to Log.Verbose and set it to #if DEBUG
All modules should now refresh their configuration runtime
Made all logging in ScriptEngine.Common get script name from actual engine
Renamed LSLLongCmdHandler to AsyncLSLCommandManager
Added auto-recover with 5 sec throttle for new MaintenanceThread
Bugfix: Scripts exceeding max and set to be killed were not killed, only removed.
Added ability to re-read configuration while OpenSim is running
All regions now sharing one MaintenanceThread
New MaintenanceThread:
- checks for script execution timeout
- re-reads config
- starts/stops threads if thread active count becomes too high/low compared to config
Speed increase on event execution:
- Reuse of try{}catch{} blocks
- Time calculation on event execution
* We still need to set the 'default particle' texture as, a particle system with no texture set doesn't work.
* The particle System Flags don't seem to be quite right yet as some flags don't seem to have an effect. So no alpha in/out, color change, affected by the wind, etc.. yet
* Thanks to Alondria for some massive work here. This update just tweaks a few things that she did.
* You can type 'stats' at the REGION# prompt to get this information in grid or standalone mode
* Don't take these numbers as gospel yet, since for some reason textures displayed from inventory which require downloading from the server are being recorded as assets
rather than textures
* But I don't have any reason to believe they aren't broadly accurate.
* I've put these in so I can tell whether the high memory usage on regions is down to the asset/texture cache
* This will require a prebuild
* DEV: Only adds needed to be implemented since, as far as I can tell, assets cached are currently never released. For my part, seeing large cache memory numbers will
provoke me to think about doing something about this.
* DEV: Now switched to using a singleton to get the stats reporters rather than threading the object through various layers
* DEV: Will refactor the other server stats reporters to do this in one of the next commits
Tedd Hansen