| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
|
|
| |
display total frame time, not just non-spare time.
This makes it easier to see when components of frame time exceed normal permitted frame time.
Currently reflect scene frame times.
|
| |\ |
|
| | | |
|
| | | |
|
| | |\ |
|
| | | |
| | |
| | |
| | | |
Looks like the wrong one was cut and pasted.
|
| | |/ |
|
| |/
|
|
|
|
|
| |
time taken per second.
This is to make these statistics actually match their names (and also be more accurate as number of frames can vary under heavy load)
Currently using scene frames (11.23 every second) instead of physics frames (56.18 per second)
|
| |
|
|
| |
inv.Folders.Count in a minor change.
|
| | |
|
| |
|
|
|
|
|
|
| |
1) The return messages were being wrongly populated with the names of asset, inventory and sale types when their corresponding integers should have been used instead.
2) Folders with links were including the linked items in the descendents figure, when only the links should be included.
3) Links and linked items in link folders were not being included in the return data, and not in the correct order.
Now that these issues have been addressed, outfits and attachments appear to work consistently when HTTP inventory is enabled (as is now the default).
|
| |
|
|
| |
accounts every single scene frame, update in the once every 3 seconds SimStatsReporter run
|
| |
|
|
|
| |
These will act as a sanity check with the main scene stats, to show that physics scene entities are being managed properly.
Total prims will not match scene total prims since physics total does not include phantom prims
|
| |
|
|
| |
possible. All subsequent code is only relevant if there are contacts.
|
| |
|
|
| |
native spaces or geom collision code
|
| |
|
|
| |
millisecond optional stats
|
| | |
|
| |
|
|
| |
Unnecessary since this has now been broken down into space collisions and geom collisions
|
| |
|
|
| |
listeners in physics frames
|
| | |
|
| | |
|
| |
|
|
| |
physics stat
|
| |
|
|
| |
and geom collision stats
|
| |
|
|
| |
contacts per collision and this is what is actually being measured.
|
| |
|
|
|
|
| |
standing on a prim.
This has already been added earlier on in the method.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
the first 25 that had non-zero collision scores.
Also zeros collisions scores on all prims after report collection, not just the top 25.
As before, this collision scores are only reset after a report is requested, which may give unrealistic numbers on the first request.
So to see more realistic scores, ignore the first report and then refresh the request after a couple of seconds or so.
|
| |
|
|
|
|
|
|
|
|
|
| |
arbitrary stats.
If active, the physics module can return arbitrary stat counters that can be seen via the MonitoringModule
(http://opensimulator.org/wiki/Monitoring_Module)
This is only active in OdeScene if collect_stats = true in [ODEPhysicsSettings].
This patch allows OdeScene to collect elapsed time information for calls to the ODE native collision methods to assess what proportion of time this takes compared to total physics processing.
This data is returned as ODENativeCollisionFrameMS in the monitoring module, updated every 3 seconds.
The performance effect of collecting stats is probably extremely minor, dwarfed by the rest of the physics code.
|
| |
|
|
| |
See "help teleport user" on the console for more details
|
| | |
|
| |
|
|
| |
make code more analyzable
|
| |
|
|
|
|
| |
start the handling.
Also fixes the log warning from ResetInTransit() if the state is cleared direct from Transferring or ReceiveAtDestination, as pointed out in mantis 5426
|
| | |
|
| |
|
|
|
|
| |
If the script requesting permissions is owned by either the NPC or
the NPCs owner (if the NPC is created as owned) then grant any
permissions automatically.
|
| |
|
|
|
|
|
|
| |
been closed not before.
If this is done before then on ODE agent update calls still incoming can fail as they try to use a raycastmanager that has been disposed.
Bullet plugin does nothing on Dispose()
However, I wouldn't be at all surprised if individual region restarting was buggy in lots of other areas.
|
| | |
|
| | |
|
| |
|
|
| |
Also removes small bug where calling this method would add 1 to LPS, evne though all callers already did this.
|
| |
|
|
| |
instead of searching the task inventory manually.
|
| |
|
|
|
|
| |
SceneObjectPartInventory.GetInventoryItem(string)
Also gets llStopAnimation() to call KeyOrName rather than duplicating logic.
|
| |
|
|
|
| |
Corrected to stop animations using the animation UUID similar to llStopAnimation.
See http://opensimulator.org/wiki/OsAvatarStopAnimation
|
| | |
|
| |
|
|
| |
not before.
|
| |
|
|
| |
return earlier to simplify method
|
| |
|
|
| |
at SceneObjectPartInventory.ApplyNextOwnerPermissions().
|
| |
|
|
| |
reason "Communications failure" no matter what the destination region actually returned
|
| |
|
|
|
|
|
|
|
| |
before the source region has finished cleaning up old agent data and structures.
If this is allowed, then the client usually gets forcibly logged out and data structures might be put into bad states.
To prevent this, the binary state machine of EMT.m_agentsInTransit is replaced with a 4 state machine (Preparing, Transferring, ReceivedAtDestination, CleaningUp).
This is necessary because the source region needs to know when the destination region has received the user but a teleport back cannot happen until the source region has cleaned up.
Tested on standalone, grid and with v1 and v3 clients.
|
| |
|
|
|
|
|
|
|
|
| |
of always true no matter what the callee actually returned.
This was due to two things
1) SimulationServiceConnector.QueryAccess was always looking to the outer result["success"].
But if a "_Result" map is returned (which is certainly the case right now), then the true success is _Result["success"], result["success"] is always true no matter what
2) If QueryAccess was false at the destination, then AgentHandlers.DoQueryAccess() was never putting this in the result.
The default action of SerializeJsonString() is not to put false booleans in the JSON!!!, so this has to be explicitly set.
|
| |
|
|
|
|
| |
taking place, rather than just (falsely) logging that we're not going to proceed.
An oversight from recent commit 9ab0c81
|
