instead of the 130s timeout somewhere. Additionally, mark the map-tile as
offline. This partly fixes the TP problems of Mantis 2332; the rest is a viewer
problem (just relogin).
- Added lookup in the data-layer
- MySQL works
- SQLite doesn't have a grid-db, so it won't work there
- I added MSSQL-code to the best of my knowledge; but I don't know MSSQL :-)
- Added the plumbing up to OGS1GridServices. This speaks with the grid-server
via XMLRPC.
- Modified MapSearchModule to use the new data. It's backward compatible; if
used with an old grid-server, it just returns one found region instead of a
list.
- Refactored a bit.
Note: This updates data, grid-server and region code. No new files.
old way: each region module interested in chat from client had to
- subscribe to scene.EventManager.OnNewClient
- then in its OnNewClient delegate it would subscribe to
client.OnChatFromViewer to capture chat messages coming
new way: ChatModule is the only region module that uses the "old
way" approach but is now forwarding all client chat via
scene.EventManager.OnChatFromClient
- each region module interested in chat from client now only
subscribes to scene.EventManager.OnChatFromClient
this not only simplifies code, but also allows us to substitute
ChatModule with derived classes (ConciergeModule is going to be one
example).
Also, this changeset changes ChatFromViewer to ChatFromClient as it
doesn't necessarily have to be a viewer that is a chat source.
i've taken great care to only comment out those OnNewClient delegates
that were only used for getting at the client chat --- hope it's not
breaking anything.
* Switched it on by default
* Updated OpenSim.ini.example to reflect this
* Caught a UDP Server issue that occurs when the network pipe is saturated
* Still experimental :D
regions in the in-world map. It currently only returns the first region that
matches the search string; in a future version it will return more search
results.
Note: File added; run runprebuild.
* This is a HUGE update.. and should be considered fraut with peril.
* SSL Mode isn't available *yet* but I'll work on that next.
* DrScofld is still working on a radical new thread pump scheme for this which will be implemented soon.
* This could break the Build! This could break your Grid!
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.
