| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
| |
SceneGraph.ForEachSOG(). This will be corrected soon.
Also adds lots of temproarily debug logging
|
| |
|
|
|
|
|
| |
counts populated by LandManagementModule.
In order to pass ILandObject into IClientAPI.SendLandProperties(), had to push ILandObject and IPrimCounts into OpenSim.Framework from OpenSim.Region.Framework.Interfaces, in order to avoid ci
Counts are showing odd behaviour at the moment, this will be addressed shortly.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
the server settings.
This is in a very crude state, currently.
The LindenUDPModule was renamed LindenUDPInfoModule and moved to OptionalModules
OptionalModules was given a direct reference to OpenSim.Region.ClientStack.LindenUDP so that it can inspect specific LindenUDP settings without having to generalize those to all client views (some of which may have no concept of the settings involved).
This might be ess messy if OpenSim.Region.ClientStack.LindenUDP were a region module instead, like MXP, IRC and NPC
|
| |
|
|
| |
packet
|
| |
|
|
| |
animations
|
| | |
|
| |\ |
|
| | |
| |
| |
| |
| |
| | |
* Added Calculating Time Dilation in the OdePlubin
* When multiple object updates are stuffed into one packet, average the time dilation between them as a compromise.
* Time Dilation on the update is calculated when the EntityUpdate object is created. The pre-calc-ed TD is stored in the Entity update and used when it goes out on the wire. Previously, it was 1.0 all the time. The time dilation is tied to when the update is created, not when the update is sent.
|
| |/
|
|
| |
which now lives entirely in LindenUDP space.
|
| |
|
|
|
|
| |
* Adds an item that checks to see if the top request has been there for longer then 30 seconds without an update and sends an AbortXfer if it encounters one. This allows the client to cancel the Xfer on it's side so you can re-select the prim and get the inventory when it fails the first time.
* Some interesting locking... Using NewFiles to lock the rest of them. We'll see how that goes.
* The goal of this is to ensure that Xfers are restartable when they fail. The client will not do that on it's own.
|
| |
|
|
| |
ImprovedTerseObjectUpdate messages
|
| |
|
|
|
|
|
| |
m_entityUpdates.SyncRoot
These locks are necessary to avoid a delete/update race condition for scene objects.
However, since we're now locking on m_killRecord this shouldn't cause delays to m_entityUpdates reprioritization
|
| |
|
|
| |
updates for self movement as absolute top priority, going in to the unthrottled category. Self only, not other avies.
|
| |
|
|
| |
reprioritizations from actually happening. #LoginLag
|
| |
|
|
|
|
|
| |
Remove the too coarse CanEditParcel method in favor of a CanEditParcelProperties
method that takes a GroupPowers argument to specify what action is to be
taken. Also, make the method to set parcel data much more granular. Permissions
in a deeded setting should now work.
|
| |
|
|
| |
This reverts commit ccb4f958c0dbb2daad4249a6b97d1c0b008b6a47.
|
| | |
|
| |
|
|
|
|
| |
SceneObject updates, and place them in different queues."
This reverts commit f84905e2949d61239c8bff815f8061a9435c124c.
|
| |
|
|
| |
updates, and place them in different queues.
|
| |
|
|
|
|
|
|
| |
If an LL 1.23.5 client (and possibly earlier and later) receives an object update after a kill object packet, it leaves the deleted prim in the scene until client relog
This is possible in LLUDPServer if an object update packet is queued but a kill packet sent immediately.
Beyond invasive tracking of kill sending, most expedient solution is to always queue kills, so that they always arrive after updates.
In tests, this doesn't appear to affect performance.
There is probably still an issue present where an update packet might not be acked and then resent after the kill packet.
|
| | |
|
| |
|
|
| |
packet processing stack
|
| |
|
|
|
|
| |
This will cause visual params to be persisted along with worn items. With
this, alpha and tattoo laters will be saved. Multiple layers MAY work, but
not tested because I don't use Viewer 2.
|
| |
|
|
|
|
|
|
|
| |
It contains a major interface version bump and will NOT work with earlier grid
services. This is preliminary work that will lead to layers support.
Rest appearance services are commented out completely, they will have to be
adapted by someone who actually uses them. Remote admin is working, but has
no layers support. There is no layers support in the database. Login likely
won't work. You have been warned.
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
AvatarService -- add two new methods, GetAppearance and SetAppearance
to get around the lossy encoding in AvatarData. Preseve the old
functions to avoid changing the behavior for ROBUST services.
AvatarAppearance -- major refactor, moved the various encoding
methods used by AgentCircuitData, ClientAgentUpdate and
ScenePresence into one location. Changed initialization.
AvatarAttachments -- added a class specifically to handle
attachments in preparation for additional functionality
that will be needed for viewer 2.
AvatarFactory -- removed a number of unused or methods duplicated
in other locations. Moved in all appearance event handling from
ScenePresence. Required a change to IClientAPI that propogated
throughout all the IClientAPI implementations.
|
| |/ |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Object updates are sent on the task queue. It's possible for an object update to be placed on the client queue before a kill packet comes along.
The kill packet would then be placed on the state queue and possibly get sent before the update
If the update gets sent afterwards then client get undeletable no owner objects until relog
Placing the kills in the task queue should mean that they are received after updates. The kill record prevents subsequent updates getting on the queue
Comments state that updates are sent via the state queue but this isn't true. If this was the case this problem might not exist.
|
| |
|
|
|
|
|
|
|
| |
to reduce scope for kill/update race conditions
This is necessary because it was still possible for an entity update packet to be constructed, the thread to pause, a kill to be sent on another thread, and then the original thread to resume and send the update
This would result in an update being received after a kill, which results in undeletable ghost objects until the viewer is relogged
Extending the lock looks okay since its only taken by kill, update and reprioritize, and both kill and update do not take further locks
However, evidence suggests that there is still a kill/update race somewhere
|
| |
|
|
| |
unhandled GenericMessages
|
| | |
|
| | |
|
| |
|
|
| |
(as much as is possible). There was a report of non-finite avatar positions after the update
|
| |
|
|
|
|
| |
avoid repeated requests for missing avatar IDs
* Updated to OpenMetaverse r3442 to fix a timezone issue with ExpiringCache
|
| |
|
|
| |
on IDwellModule
|
| |
|
|
| |
\to display avatars
|
| |
|
|
|
|
|
| |
client protocol packets
These levels correspond to packets that one isn't usually interested in when debugging (e.g. regular outgoing SimStats packets)
This is equivalent to what we had a year ago before it was removed. It's extremely crude since it doesn't allow one to pick individual clients or packets. However, it can still be useful when debugging packet race conditions.
|
| |
|
|
|
|
| |
properly for the new media settings.
Signed-off-by: Melanie <melanie@t-data.com>
|
| |
|
|
| |
This finally completes http://opensimulator.org/mantis/view.php?id=4356 where this change had been accidentally removed. Thanks Revolution.
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| | |
client after it has been told that the entity has been deleted.
On Linden Lab clients and some derivatives, receiving an entity update after an entity deletion notice results in an undeleteable prim that disappears upon client relog.
This check was dropped in 0.7 for unknown reasons but renewed testing demonstrates that queued updates can still be present after a scene object has been deleted.
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
to fix the build
|
| |
|
|
| |
TeleportStart, and now sending this upon all teleports, not just some, and in the right place (EntityTransferModule).
|
