| Commit message (Collapse) | Author | Age | Files | Lines |
|\ |
|
| |
| |
| |
| | |
first added a few commits ago
|
| |
| |
| |
| | |
UploadBakedTextureModule
|
| |
| |
| |
| |
| |
| | |
This allows one to monitor the total number of messages resent to clients over time.
A constantly increasing stat may indicate a general server network or overloading issue if a fairly high proportion of packets sent
A smaller constantly increasing stat may indicate a problem with a particular client-server connection, would need to check "show queues" in this case.
|
| |
| |
| |
| |
| |
| | |
physics engine.
Older physics engines will default to the legacy region size.
Update BulletSim to use the new region size information.
|
| |
| |
| |
| | |
Add some debugging logs on region creation to report region size.
|
| |
| |
| |
| |
| | |
compression base computation.
Complete replacement of float[] for terrain heightmap with TerrainData instance.
|
|\ \
| |/ |
|
| |
| |
| |
| |
| |
| |
| | |
ObjectProperties UDP replies to viewer
Not yet shown that this is used or resolves a bug where not all textures appear on objects with an "XML with textures" upload from singularity 1.8.3
Proper texture entries are actually present and appear properly on relog, but not on select from viewer until at least one face texture is changed.
|
| |
| |
| |
| | |
Appears to be a never used method.
|
| |
| |
| |
| | |
if we sent immediately)
|
|\ \
| |/ |
|
| | |
|
| |
| |
| |
| | |
LLClientView to use same. This passes a terrain info class around rather than passing a one dimensional array thus allowing variable regions. Update the database storage for variable region sizes. This should be downward compatible (same format for 256x256 regions).
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
-- addition of varaible region size in X and Y
-- internal storage of heightmap changed from double[] to short[]
-- helper routines for handling internal structure while keeping existing API
-- to and from XML that adds region size information (for downward compatibility,
output in the legacy XML format if X and Y are 256)
Updated and commented Constants.RegionSize but didn't change the name for compatibility.
|
|/
|
|
|
|
|
|
| |
count number to integer world coordinates.
Added new methods RegionWorldLoc[XY].
Refactored name of 'RegionLoc*' to 'LegacyRegionLoc*' throughout OpenSim.
Kept old 'RegionLoc*' entrypoint to RegionInfo for downward compatability
of external region management packages.
|
|
|
|
| |
the code that this is symmetric with CloseAgent()
|
|
|
|
|
|
| |
it clear that all non-clientstack callers should be using this rather than RemoveClient() in order to step through the ScenePresence state machine properly.
Adds IScene.CloseAgent() to replace RemoveClient()
|
|
|
|
|
|
|
|
| |
LLUDPServer.HandleCompleteMovementIntoRegion() to fix race condition regression in commit 7dbc93c (Wed Sep 18 21:41:51 2013 +0100)
This check is necessary to close a race condition where the CompleteAgentMovement processing could proceed when the UseCircuitCode thread had added the client to the client manager but before the ScenePresence had registered to process the CompleteAgentMovement message.
This is most probably why the message appeared to get lost on a proportion of entity transfers.
A better long term solution may be to set the IClientAPI.SceneAgent property before the client is added to the manager.
|
|
|
|
| |
21:41:51 2013 +0100)
|
|
|
|
|
|
| |
debugging purposes.
This may reveal why on some teleports with current code, the UseCircuitCode message gets through but CompleteMovement disappears into the ether.
|
|
|
|
|
|
|
|
|
|
| |
Patch taken from
http://opensimulator.org/mantis/view.php?id=4905
originally by Greg C.
Fixed to apply to r/23314 commit
ba9daf849e7c8db48e7c03e7cdedb77776b2052f
(cherry picked from commit 4ff9fbca441110cc2b93edc7286e0e9339e61cbe)
|
|
|
|
|
|
|
|
|
| |
LLUDPServer.HandleCompleteMovementIntoRegion()
This is to deal with one aspect of http://opensimulator.org/mantis/view.php?id=6755
With the V2 teleport arrangements, viewers appear to send the single UseCircuitCode and CompleteAgentMovement packets immediately after each other
Possibly, on occasion a poor network might drop the initial UseCircuitCode packet and by the time it retries, the CompleteAgementMovement has timed out and the teleport fails.
There's no apparant harm in doubling the wait time (most times only one wait will be performed) so trying this.
|
|
|
|
|
|
|
| |
LLUDPServer.HandleCompleteMovementIntoRegion()
Add more information on which endpoint sent the packet when we have to wait and if we end up dropping the packet
Only check if the client is active - other checks are redundant since they can only failed if IsActve = false
|
|
|
|
|
|
| |
to allow
for external handlers.
|
|
|
|
|
|
|
|
| |
hear chat from their source region for some time after teleport completion.
This occurs on v2 teleport since the source region now waits 15 secs before closing the old child agent, which could still receive chat.
This commit introduces a ScenePresenceState.PreClose which is set before the wait, so that ChatModule can check for ScenePresenceState.Running.
This was theoretically also an issue on v1 teleport but since the pause before close was only 2 secs there, it was not noticed.
|
| |
|
|
|
|
|
|
|
| |
going to that region first.
If this is attempted, they get a "Try moving closer. Can't sit on object because it is not in the same region as you." message instead, which is the same as current ll grid.
Sitting on ground is okay, since viewer navigates avatar to required region first before sitting.
|
|
|
|
|
|
|
|
| |
PacketPool.GetType()
Instead adjusts code with that from Packet.BuildHeader(byte[], ref int, ref int):Header in libomv
This stops packet decoding failures with agent UUIDs that contain 00 in their earlier parts (e.g. b0b0b0b0-0000-0000-0000-000000000211)
Thanks to lkalif for pointing this out.
|
|
|
|
| |
occuring on every login and entity transfer
|
|
|
|
| |
well-formed packets that were not initial connection packets and could not be associated with a connected viewer.
|
|
|
|
|
|
|
| |
a malformed packet. Record this as stat clientstack.<scene>.IncomingPacketsMalformedCount
Used to detect if a simulator is receiving significant junk UDP
Decimates the number of packets between which a warning is logged and prints the IP source of the last malformed packet when logging
|
|
|
|
| |
client without a queue to include the event message name.
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
an line from A->B->C would not close region A when reaching C
The root cause was that v2 was only closing neighbour agents if the root connection also needed a close.
However, fixing this requires the neighbour regions also detect when they should not close due to re-teleports re-establishing the child connection.
This involves restructuring the code to introduce a scene presence state machine that can serialize the different add and remove client calls that are now possible with the late close of the
This commit appears to fix these issues and improve teleport, but still has holes on at least quick reteleporting (and possibly occasionally on ordinary teleports).
Also, has not been completely tested yet in scenarios where regions are running on different simulators
|
|/
|
|
| |
change only affects the editing user's experience. Non-editing users will see nothing different from the current 'slow' result. See comments for the thought process and how the issues surrounding terrain editing, cache, bandwidth, threading, terrain patch reliability and throttling were balanced.
|
|
|
|
|
|
| |
forget conditions.
I generally prefer this approach for regression tests because of the complexity of accounting for different threading conditions.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
immediately if any data was sent, rather than waiting.
What I believe is happening is that on initial terrain send, this is done one packet at a time.
With WaitOne, the outbound loop has enough time to loop and wait again after the first packet before the second, leading to a slower send.
This approach instead does not wait if a packet was just sent but instead loops again, which appears to lead to a quicker send without losing the cpu benefit of not continually looping when there is no outbound data.
|
|
|
|
|
|
| |
d9d995914c5fba00d4ccaf66b899384c8ea3d5eb (r/23185) -- the WaitOne on the UDPServer. Putting it back to how it was done solves the issue. But this may impact CPU usage, so I'm pushing it to test if it does."
This reverts commit 59b461ac0eaae1cc34bb82431106fdf0476037f3.
|
|
|
|
| |
d9d995914c5fba00d4ccaf66b899384c8ea3d5eb (r/23185) -- the WaitOne on the UDPServer. Putting it back to how it was done solves the issue. But this may impact CPU usage, so I'm pushing it to test if it does.
|
|
|
|
|
|
|
| |
cap is something other than "localhost". A new interface for handling
external caps is supported with an example implemented for Simian. The
only linden cap supporting this interface right now is the GetTexture
cap.
|
|
|
|
|
|
|
| |
HGMapModule, hooking on to SimulatorFeatures.OnSimulatorFeaturesRequest event (similar to what the DynamicMenuModule does).
Only HG Visitors get this var, to avoid spamming local users.
The config var is now called MapTileURL, to be consistent with the login one, and its being picked up from either [LoginService], [HGWorldMap] or [SimulatorFeatures], just because I have a bad memory.
|
|\ |
|
| |
| |
| |
| | |
reflect it is a timeout due to no data received rather than an ack issue.
|
| |
| |
| |
| | |
I accidentally left in a test line to force very quick client unack
|
| |
| |
| |
| |
| |
| |
| | |
add this to the StatsManager
This reflects the actual use of this stat - it hasn't recorded general exceptions for some time.
Make the sim extra stats collector draw the data from the stats manager rather than maintaing this data itself.
|
|/
|
|
|
|
| |
OSDMap GridServices to OpenSimExtras, normalized the url keys under it, and moved ExportEnabled to under it too. Melanie: change your viewer code accordingly.
Documentation at http://opensimulator.org/wiki/SimulatorFeatures_Extras
|
|
|
|
|
|
| |
join/drop appropriately, invitechatboxes.
The major departure from flotsam is to send only one message per destination region, as opposed to one message per group member. This reduces messaging considerably in large groups that have clusters of members in certain regions.
|