It appears that at least Singularity 1.8.5 (but probably others) rely on attachment FromItemIDs being different to display more than one.
This commit resolves this by generating random IDs instead of always using UUID.Zero for NPCs.
Resolves http://opensimulator.org/mantis/view.php?id=7110
objects in the world.
This was originally changed in an attempt to make vehicles work better
but the effect was not that large and it causes avatars to float
above the terrain.
udp texture throttle and move it to the task throttle. Since most
viewers are using http textures, the udp texture throttle is holding
onto bw that could be used for more responsive prims updates. See
the documentation for CannibalizeTextureRate in OpenSimDefaults.ini.
Option is disabled by default.
Conflicts:
OpenSim/Region/CoreModules/Framework/EntityTransfer/EntityTransferModule.cs
OpenSim/Region/Framework/Scenes/SceneBase.cs
OpenSim/Services/Interfaces/IGridService.cs
OpenSim/Services/LLLoginService/LLLoginResponse.cs
(conflicts were debug statements that are commented out in master branch)
Add new region crossing code to varregion
Conflicts:
OpenSim/Region/CoreModules/Framework/EntityTransfer/EntityTransferModule.cs
OpenSim/Region/Framework/Scenes/ScenePresence.cs
Rename 'RegionWorldLocX' to 'WorldLocX' and same for Y and Z.
This keeps the downward compatibility and follows the scheme of 'region'
and 'world' location naming that is happening in the Util module.
- Parts of region crossing code
- New bakes handling code
- Bakes now sent from sim to sim without central storage
- Appearance handling changes
- Some changes to sitting
- A number of unrelated fixes and improvements
It turns out that the x/y rot data in mouselook is needed to implement this and to push the avatar against the ground if walking in mouselook.
Doing this in the terse send so that we preserve mouselook rotation information
This records how many packets were indicated to be resends by clients
Not 100% reliable since clients can lie about resends, but usually would indicate if clients are not receiving UDP acks at all or in a manner they consider timely.
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.
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.
-- 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.
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.
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.
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
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.
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.
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
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
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.
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.
In this new protocol, and as committed before, the viewer is not sent EnableSimulator/EstablishChildCommunication for the destination. Instead, it is sent TeleportFinish directly. TeleportFinish, in turn, makes the viewer send a UserCircuitCode packet followed by CompleteMovementIntoRegion packet. These 2 packets tend to occur one after the other almost immediately to the point that when CMIR arrives the client is not even connected yet and that packet is ignored (there might have been some race conditions here before); then the viewer sends CMIR again within 5-8 secs. But the delay between them may be higher in busier regions, which may lead to race conditions.
This commit improves the process so there are are no race conditions at the destination. CompleteMovement (triggered by the viewer) waits until Update has been sent from the origin. Update, in turn, waits until there is a *root* scene presence -- so making sure CompleteMovement has run MakeRoot. In other words, there are two threadlets at the destination, one from the viewer and one from the origin region, waiting for each other to do the right thing. That makes it safe to close the agent at the origin upon return of the Update call without having to wait for callback, because we are absolutely sure that the viewer knows it is in th new region.
Note also that in the V1 protocol, the destination was getting UseCircuitCode from the viewer twice -- once on EstablishAgentCommunication and then again on TeleportFinish. The second UCC was being ignored, but it shows how we were not following the expected steps...
If this consistently increases then this is a problem since it means the simulator is receiving more requests than it can distribute to other parts of the code.
If we're not receiving packets with multiple threads (m_asyncPacketHandling) then this is critical since it will limit the number of incoming UDP requests that the region can handle and affects packet loss.
If m_asyncPacketHandling then this is less critical though a long process will increase the scope for threads to race.
This is an experimental stat which may be changed.
AgentUpdate packet. This fixes the problem with vehicles not moving forward
after the first up-arrow.
Code to fix a potential exception when using different IClientAPIs.
Justin Clark-Casey (justincc)