| Commit message (Collapse) | Author | Age | Files | Lines |
|\ |
|
| | |
|
|\ \
| |/ |
|
| |
| |
| |
| | |
reporting login issues.
|
| |
| |
| |
| | |
it is needed again. Mantis #5365
|
| |
| |
| |
| | |
This reverts commit 585473aade100c3ffeef27e0c8e6b6c8c09d0109.
|
| | |
|
| |
| |
| |
| | |
race condition happen, and got very similar results to those described in mantis #5365 -- no prims/avie sent back.
|
| | |
|
| | |
|
| |
| |
| |
| | |
"emergency-monitoring on/off"
|
|\ \
| |/
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
OpenSim/Region/CoreModules/Avatar/Inventory/Archiver/InventoryArchiverModule.cs
OpenSim/Region/ScriptEngine/Shared/Api/Implementation/LSL_Api.cs
OpenSim/Server/Handlers/Simulation/AgentHandlers.cs
OpenSim/Services/Connectors/SimianGrid/SimianGridMaptileModule.cs
OpenSim/Services/GridService/HypergridLinker.cs
|
| | |
|
|\ \
| |/ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
|\ \
| |/ |
|
| |
| |
| |
| | |
Didn't touch the appearance related stuff.
|
| |
| |
| |
| | |
Bytes were being wrongly added again on a resend
|
|\ \
| |/ |
|
| |
| |
| |
| | |
some point.
|
|\ \
| |/ |
|
| |\ |
|
| |\ \
| | | |
| | | |
| | | |
| | | | |
Conflicts:
OpenSim/Region/Framework/Scenes/Scene.cs
|
| |\ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Conflicts:
OpenSim/Region/CoreModules/Framework/EntityTransfer/EntityTransferModule.cs
OpenSim/Services/Connectors/Simulation/SimulationServiceConnector.cs
|
| |\ \ \ \ |
|
|\ \ \ \ \ \
| | |_|_|_|/
| |/| | | |
| | | | | | |
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.
|
| | |_|_|/
| |/| | | |
|
| | | | | |
|
|\ \ \ \ \
| |/ / / / |
|
| | |_|/
| |/| | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
up the LLUDPServer (and therefore the entire scene)"
This reverts commit 40e05f41098bdedac7296d84c9aa8d915c5c9ede.
Conflicts:
OpenSim/Region/ClientStack/LindenUDP/LLUDPServer.cs
|
|\ \ \ \
| |/ / / |
|
| | |/
| |/|
| | |
| | |
| | |
| | | |
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
|
| |/
| |
| |
| |
| | |
This reverts commit 21187f459ea2ae590dda4249fa15ebf116d04fe0, reversing
changes made to 8f34e46d7449be1c29419a232a8f7f1e5918f03c.
|
| | |
|
|\ \
| |/
| |
| |
| |
| | |
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.
|
|\ \
| |/ |
|
| |
| |
| |
| | |
informative
|
|\ \
| |/ |
|
| |
| |
| |
| |
| |
| | |
DisableFacelights option to OpenSim.ini to finally kill those immersion-
breaking, silly vanity lights that destroy nighttime RP. Girls, you look
just fine without them. Guys, you too. Thank you. Melanie has left the building.
|
| |
| |
| |
| |
| |
| | |
DisableFacelights option to OpenSim.ini to finally kill those immersion-
breaking, silly vanity lights that destroy nighttime RP. Girls, you look
just fine without them. Guys, you too. Thank you. Melanie has left the building.
|
| |
| |
| |
| | |
can deal with the client's response have finished loading.
|
| |
| |
| |
| | |
avoids some stuttering", pending fix for the core issue
|
| |
| |
| |
| | |
when people log in, but fatally screws up money.
|
|\ \
| |/ |
|
| |
| |
| |
| | |
original behavior of avatar update sending and has a simplified set of IClientAPI methods for sending avatar/prim updates
|
| |
| |
| |
| | |
sent when the user logs out. This eliminates the annoying "crash on log out" bug, and allows the client to commit important information at the last moment (attachment data!)
|