welcomes = /path/to/welcome/files/directory
a directory in which you can place welcome templates for concierged
regions (those regions that match the "regions" regexp). you can use
format substitution:
0: will be replaced by avatar name of the avatar entering the region
1: will be replaced by region name
2: will be replaced the name of the concierge
MemberwiseClone() also clones the "already backed up" flag, preventing prims
created by drag-copying from being persisted. If such a prim is made the root
prims of a link set, the entire set will not be persisted. Fixed now.
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.
* Guys, there's an endless loop there *ON PURPOSE*. Please don't try to *fix* it. We must continue to process the UDP stream buffer on clients that disconnected nastily until it ends or the UDP server accept thread will die a horrible death.
* Unix epoch starts at midnight, not at 8:00am
* All date/time handling should be done in UTC in the server, not in
the local timezone.
* Refactor out repeated computation of a constant value
- Added setting of CreationTime to some places where inventoryitems
are created
This fixes Mantis#2390.
Add rezzing time to objects. Add Object return and traffic fields to land
database. Add plumbing for auto return. Implement auto return.
Contains a migration. May contain nuts.
* Implement the linear impulse portion of llPushObject. We should have a lsl compatible implementation of that portion of the push. Angular.. well. still have yet to implement a torque accumulator.
* llPushObject respects the region and parcel settings for Restrict Push, it also respects GodMode as is defined in the LSL spec.
* Regarding an earlier change, I think it would be possible to eliminate the creation of new IPEndPoints on every end receive if we did the client circuit lookup before starting
the next receive. However, this would be a performance trade off and hence not worth trying without performance testing
* This widened what I think is an existing race condition where asynchronous recieves could potentially stomp on each other's end points (though this must occur very rarely, if at
all, in reality)
Melanie Thielker