The problem with logging at warn is that these aren't actually warnings, and so are false positives to scripts that monitor for problems.
Ideally, log4net would have a separate "status" logging level, but currently we will compromise by putting them to console, as they are user-oriented
These stopped working because current code calculates sit heights based on avatar physics rather than appearance data.
Also changed BasicPhysics to not divide Z param of all set sizes by 2 - there's no obvious good reason for this and basicphysics is only used in tests
- 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
the RegionReady module to be warn so that the message will show up in the
log for simulators running in a more production mode (knowing when logins
are functional is useful).
Instead, "show client stats" now prints "Off!" so that exception is not thrown and we know which entries in ClientManager are in this state.
There's a race condition which could trigger this, but the window is extremely short and exceptions would not be thrown consistently (which is the behaviour observed).
It should otherwise be impossible for this condition to occur, so there may be a weakness in client manager IClientAPI removal.
Currently, first name and last name are input separate but are concatenated with a space in the middle to form a regex.
So to sit all bots with the first name "ima", for instance, the command is "sit user name --regex ima .*"
"sit user name" will currently only sit the given avatar on prims which have a sit target set and are not already sat upon.
Chiefly for debug purposes.
I think there is an argument for sending this information to NPCs anyway since in some cases it appears a lot easier to write server-side bots by hooking into such internal events.
However, would need to stop event messages building up on NPC queues if they are never retrieved.
These were genuine failures caused by ScenePresence.CompleteMovement() waiting for an UpdateAgent from NPC introduction that would never come.
Instead, we do not wait if the agent is an NPC.
- The existing event to scene has been split into 2: OnAgentUpdate and OnAgentCameraUpdate, to better reflect the two types of updates that the viewer sends. We can run one without the other, which is what happens when the avie is still but the user is camming around
- Added thresholds (as opposed to equality) to determine whether the update is significant or not. I thin these thresholds are ok, but we can play with them later
- Ignore updates of HeadRotation, which were problematic and aren't being used up stream
Added here since it was the most convenient place
Number is in the last column, "Sig. AgentUpdates" along with percentage of all AgentUpdates
Percentage largely falls over time, most cpu for processing AgentUpdates may be in UDP processing as turning this off even earlier (with "debug lludp toggle agentupdate" results in a big cpu fall
Also tidies up display.
This was probably the mistake.
The other handlers are named RenderMaterials as well but this actully has no affect apart from on stats, due to a (counterintuitive) disconnect between the registration name and the name of the request handler.
Will be tested very soon and reverted if this still does not work.
