| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
OSChatMessage coming from client.
|
|
|
|
|
|
|
| |
again. need to investigate why chat position is catastrophically off.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
chat relaying via private channels, and old IRCBridgeModule
behaviour. also cleaning up IRCBridgeModule's OpenSim.ini
configuration variable names (still supporting "old" variable
names). refactored IRCChatModule into IRCConnector and incorporating
watchdog from IRCBridgeModule into IRCConnector.
enabling ChatModule to be used as a super-class and utilizing it in
ConciergeModule.
|
|
|
|
|
|
| |
See mantis #2379 for some useful scripts that work with this.
Note that I added another configuration parameter in addition to the patch to allow for legacy behavior in the absence of new configuration settings.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Remove some old dead code.
|
|
|
|
|
|
|
| |
* This is a HUGE OMG update and will definitely have unknown side effects.. so this is really only for the strong hearted at this point. Regular people should let the dust settle.
* This has been tested to work with most basic functions. However.. make sure you back up 'everything' before using this. It's that big!
* Essentially we're back at square 1 in the testing phase.. so lets identify things that broke.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The following is a patch that causes the ensuing http_response event (after
an llHTTPRequest) to include the HTTP status code returned from the server
(if available). The patch also sets the body parameter for the
http_response event to be set as the status description returned by the
server.
|
|
|
|
|
|
|
| |
The following is a patch that causes HTTP connections made by llHTTPRequest
to be closed once the response is read.
|
| |
|
| |
|
|
|
|
|
| |
Implements X-SecondLife-* HTTP Headers for llHTTPRequest
|
| |
|
|
|
|
|
| |
Adds additional support for llEmail().
|
|
|
|
|
| |
Addresses HTTP_METHOD parameter does not work for POST requests.
|
| |
|
|
|
|
|
| |
Adds IEmailModule and a module skelaton
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
never display
on the client.
|
|
|
|
|
|
| |
32bit images and changed them to 24bit images.
|
|
|
|
|
|
|
|
| |
san serif fonts are a bit easier on the eyes on textures.
Add a new "FontName" attribute that can be used to override
the font type.
|
|
|
|
|
|
|
| |
now preserve the bulk of the texture attributes, and force on full
bright. Not tested yet, but shouldn't bother most people.
|
|
|
|
|
|
|
|
| |
I'm getting an unhandled exception in openxmlrpcchannel during simulator initialization.
I have two objects in different regions that open remote data channels in the state_entry event.
It appears that the state_entry call is executing before the postinitialize method is called in
xmlrpcmodule (the exception occurs because m_openChannels is not initialized).
|
|
|
|
|
|
| |
small patch to encode and send the outbound_body parameter
in an http request. this enables post messages to send a body
|
| |
|
|
|
|
|
|
|
| |
This patch proposes a new function : osOpenRemoteDataChannel(key channeID)
that allow to open an XMLRPC channel for remote_data event. The difference
is that the channelID can be customized instead of being randomly generated.
|
|
|
|
|
| |
GetSerializationData() and CreateFromData() methods
|
|
|
|
|
| |
XMLRPCModule.cs: RemoteDataReply() and XMLRpcResponse()
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
* Converted a large number of read-only fields to be actually, readonly.
* Reformatted code sections.
* Removed redundant code.
|
| |
|
| |
|
| |
|
|
directory with any associated module-specific classes.
* Each module directory is currently inside one of the following category folders: Agent (Anything relating to do with Client<->Server communications.), Avatar (Anything to do with the avatar or presence inworld), Framework (Classes modules can use), Grid (Grid traffic, new OGS2 grid comms), Scripting (Scripting functions, etc), World (The enrivonment/scene, IE Sun/Tree modules.)
* This should be moved into a seperate project file.
|