| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |\ \ \ \ \ \ \ \ \ \
| | |_|_|_|_|_|_|_|/
| |/| | | | | | | |
| | | | | | | | | | |
Also prevent god takes from ending up in Lost and Found
|
| | | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
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.
|
| | | |_|_|_|_|_|_|/
| |/| | | | | | | |
|
| | | | | | | | | | |
|
| | | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
prevent overflow
|
| |\ \ \ \ \ \ \ \ \
| |/ / / / / / / / |
|
| | | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
This should show the number of bytes sent to the client that it has not yet acknowledged.
|
| | | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
For each agent, this command shows how many packets have been sent/received and how many bytes remain in each of the send queues (resend, land, texture, etc.)
Sometimes useful for diagnostics
|
| | | |_|_|_|_|_|/
| |/| | | | | | |
|
| | | | | | | | | |
|
| |\ \ \ \ \ \ \ \
| |/ / / / / / / |
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
packet processing stack
|
| |\ \ \ \ \ \ \ \
| |/ / / / / / / |
|
| | | |_|_|_|_|/
| |/| | | | | |
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
up the LLUDPServer (and therefore the entire scene)"
This reverts commit 40e05f41098bdedac7296d84c9aa8d915c5c9ede.
Conflicts:
OpenSim/Region/ClientStack/LindenUDP/LLUDPServer.cs
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
processed before the presence has bound to receive events. Fixed this by adding packets to a queue and then processing them when the presence is ready."
This reverts commit 91b1d17e5bd3ff6ed006744bc529b53a67af1a64.
Conflicts:
OpenSim/Client/Sirikata/ClientStack/SirikataClientView.cs
OpenSim/Region/ClientStack/LindenUDP/LLClientView.cs
OpenSim/Region/Framework/Scenes/ScenePresence.cs
|
| |\ \ \ \ \ \ \
| |/ / / / / / |
|
| | | |_|_|_|/
| |/| | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
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.
|
| | |\ \ \ \ \ |
|
| | | | |_|_|/
| | |/| | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Setting this to true avoids a 500ms or so client freeze when the LLUDP server thread is taken up with processing a UseCircuitCode packet synchronously.
Extensive testing on Wright Plaza appeared to show no bad effects and this seems to reduce login lag considerably.
Of course, a lot of login lag is still coming from other sources.
|
| | |\ \ \ \ \
| | |/ / / / |
|
| | | |\ \ \ \ |
|
| | | | | |_|/
| | | |/| |
| | | | | |
| | | | | | |
for diagnostics
|
| | |/ / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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.
|
| | | |/
| |/|
| | |
| | |
| | | |
This reverts commit 21187f459ea2ae590dda4249fa15ebf116d04fe0, reversing
changes made to 8f34e46d7449be1c29419a232a8f7f1e5918f03c.
|
| | |\ \ |
|
| | | |/ |
|
| |\ \ \
| |/ / |
|
| | |/ |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
halting visual behavior of large group deletes and eliminates the packet flood
|
| | | |
|
| | | |
|
| |\ \
| |/ |
|
| | | |
|
| |\ \
| |/
| |
| |
| |
| | |
Integrate the next large patch.
Don't use this version, it has a ghost avatar issue. Next push
will fix it.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| | |
| |
| |
| | |
informative
|
| |\ \
| |/
| |
| |
| | |
The modules will need to be updated for this to compile and run again. Please
don't use until I do the companion commit to modules later on.
|
| | |\ |
|
| | | | |
|
