Estate/ Manager Owner Uses the Region/Estate Menu Region TAB,
and uses "Teleport Home All Users..." (Action Button), the
action will complete but no one will be teleported and all
users still function in the region ok.
- Added TeleportFinish event to the event-queue. It works better than
before (you can teleport), but it doesn't work quite right yet (you
start TPing after the TP again).
Beware: Still experimental and non-working.
* If EventQueueGet is enabled, use that instead of a few UDP packets, if it's disabled use the UDP packets like normal.
* We *really* suggest users do not turn on EventQueueGet yet.. as it's highly experimental, broken, and resource intensive
* Updated OpenSim.ini.example
* Testers of EventQueueGet.. in OpenSim.ini, it's in the [Startup] Section.. change EventQueue = false, to EventQueue = true.
* returns FAKEEVENT instead of the connection returning a 502. It doesn't like our 502's for some reason.. so, in leau of this.. send it a fake event.
* Once again, this is still 'really early' code, so please don't blame us if you have no more threads left.
* This won't function yet as far as the client can tell.. because it doesn't respond to the first query with a 200 message.
* We have to figure out how to encode those binary values in the example code in the module...
* Committing this so we have a start point. Will continue to work on this more today.
* This means that saving notecards in prim inventories should now work.
* Not the nicest code in the world - the transactions system is pretty fugly right now
* PLEASE NOTE: Currently, the prim will not repersist until up to 15 seconds after it is unselected.
* What we really need is a proper mechanism so that any prim updates still waiting when the simulator is quit are performed before exit.
* It seems kind of silly to be building a 256x256 array just to use two 16 float blocks.. but for now the layerdata routine requires it so we'll go along with that.
* We only fill a 32x16 area of the 256x256 float array with data.
* We use patches 0,0 and 0,1 for the first and second patch to determine the direction and magnitude of the wind.
* A little wind wouldn't hurt anyone, right? This is the 'slightly breezy' setting.. hopefully you won't notice 'much' of a difference.
* It turns out the terrain patch routine is similar enough to the wind version that it can be used to hack together a breeze generator with a few mods.
* Not much configuration.. yet. You only get breeze updates in the general vicinity of your camera now to keep bandwidth usage down.. and we're not talking about 'much' movement at the moment.
* initial version... could use improvement I'm sure.
all methods needed outside the API ststic. Async command processing
is now wholly internal to the API. This sets the stage for the next
convergence step.
ordinary region modules and are able to coexist in one instance.
See http://opensimulator.org/wiki/ScriptEngines for details. There were
changes to OpenSim.ini.example, please note DefaultScriptEngine.
Also see the User docs and FAQ on the Wiki. Default is DotNetEngine.
* you'd think from all this that I was one of those fanatically tidy people. I can assure you from looking around my bedroom/study that this is not the case :)
* Monitors / for getting the seed cap for rez_avatar/request on application/llsd+xml && application/xml+llsd && !application/xml
* Experimental, this might break LibOMV temporarily.
New patch (terrainedit2.patch) is attached that passes unit tests (
and in fact supplies the new unit test to pass..:) The previous
failure was due to the change of the brush size to be linear instead
of exponential, and the fact that the test parameters were assuming
the exponentional brush size.
This patch also removes dependency on 'duration' argument for
adjustment step size. This should address the widely differing reports
of instability with terrain editing.
Note: 'doing this right' implies ultimately reading the parameters
from the ini file, which this patch does not do.
* the methods were identical except that the Properties one did a check for the user profile beforehand. However, every caller was doing this already anyway.
fixes the terrain spikes, and is the result of mostly a tuning
operation on the smooth and flatten tools. I dug in and found that the
spikes apparently result from smooth's overly aggressive iteration
steps toward the average curvature, which leads to an instability that
blows up the heights. I introduced a scaling factor to dampen the
'duration' parameter which tames progress and seems to keep things
stable.
