| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
| |
Signed-off-by: Michael Cerquoni <nebadon2025@gmail.com>
|
| | |
|
| |
|
|
| |
ScenePresence.SendTerseUpdateToAllClients() which is extremely helpful when investigating presence update triggers.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
RawVelocity update threshold for now in BSCharacter.UpdateProperties().
For some reason as yet unidentified (feedback?) a threshold above 0.4 here causes the RawVelocity to move between a lower and upper bound rather than remaining constant.
The RawVelocity increased until it triggered the threshold update, at which point it started to decrease until it again triggered the threshhold update.
This delta-v was enough to exceed the checks in ScenePresence.SendTerseUpdateToAllClients() and produce jittery avatar flight because of the fluctuating velocity.
With a threshold of 0.4 (or 0, as with ODE), the RawVelocity remains constant in BulletSim and so avatar flight becomes mostly smooth - remaining occasional glitches appear to be a result of errors in distance extraploation.
There are no obvious problems with commenting out the threshold.
Misterblue, if this is wrong or I've missed some subtlety here, please feel free to revert and/or correct.
The same considerations may or may not apply to object velocity updates.
|
| | |
|
| |
|
|
|
|
| |
bitmap generation in WorldMapModule throw an exception on next startup.
This commit replaces the hardcoded region sizes in WorldMapModule.GenerateOverlay() with numbers pulled from m_scene.RegionInfo
|
| |
|
|
|
|
| |
messages instead of a warning message.
Same justification as earlier commit 996a6c2. These are not warnings but should still be visible to the user at any log level.
|
| | |
|
| |
|
|
| |
the issue with different AppDomain BaseDirectory in local and Jenkins test runs
|
| |
|
|
|
|
| |
out to console to get a handle on what's going wrong.
Does not fail for me locally and I failed to notice this test was failing on Jenkins.
|
| |
|
|
|
|
| |
commit 1fa3a6f
This was hidden in continuous integration because of another regression test issue.
|
| |\ |
|
| | |
| |
| |
| |
| | |
step updates and collisions. This is an attempt to fix a crash reported
by Justin when doing high velocity teleports.
|
| |/
|
|
| |
send the SW-most corner of the varregions; the other areas, when clicked, would result a blue circle, meaning that the viewer didn't know about those areas. This is still not quite right, as all the areas appear to be in the same coordinates, but it's good enough for now.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
permissions according to the permissions of the items in the object
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| | |
script.
This is probably due to changes in the layout of the generated script preamble (using statements etc, ) in c8afc852 (Jan 17 2013).
Re-enabled existing regression test that exercises at least one case of this.
|
| | |
| |
| |
| |
| |
| | |
yet enabled.
This reveals the position map problems and will make the fix (and subsequent continual checking) easier.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
MessageTransferModule.SendGridInstantMessageViaXMLRPCAsync() whilst preserving retry lookup behaviour.
This is based on heavily mikemig's original patch in http://opensimulator.org/mantis/view.php?id=7149
but instead of exiting after the first IM delivery failure to presence information retrieved from the presence service
it will retry the lookup until the result matches the previous lookup.
This is to deal with the case where the agent is sent an IM whilst they are teleporting.
|
| | |
| |
| |
| |
| |
| | |
in a root prim, the focus should remain on the root prim.
Matches behaviour just tested on the Linden grid.
|
| | |
| |
| |
| | |
camera-at value, rather than replace.
|
| | |
| |
| |
| | |
child prim with camera-eye set
|
| | |
| |
| |
| |
| |
| | |
prim and the root prim has no corresponding value set, then also set the root prim.
This matches behaviour just tested on the Linden Lab grid.
|
| | |
| |
| |
| |
| |
| | |
prim does not, use the root prim offsets.
This matches behaviour just tested on the Linden Lab grid.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
prims moved camera/focus to wrong position.
For non-root prim, eye offsets now need to be made relative to root prim if either camera-at or camera-eye are set.
Probably a regression since November 2013 when all sits were made relative to root prim to match viewer expections (and fix other bugs).
Addresses http://opensimulator.org/mantis/view.php?id=7176
|
| | | |
|
| | |
| |
| |
| | |
chat
|
| | |
| |
| |
| | |
chat both ways.
|
| | |
| |
| |
| |
| |
| | |
child presence connection directly rather than routing through TestClient.
This code isn't relevant to this test and is already exercised by other tests.
|
| | |
| |
| |
| | |
to west.
|
| |/ |
|
| |\ |
|
| | |
| |
| |
| | |
These characters are used as placeholders for other characters: ": /". But we should search first for the exact string the user entered, and only if that fails then replace the characters and search again.
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
anywhere in neighbouring regions.
This was due to a silent uint overflow in ScenePresence.UpdateChildAgent() corrupting child agent positions
when the child agent was in a region with a greater x or y map co-ord than the root agent region
Probably introduced in beeec1c.
This still will not function properly with very high region map co-ords (in the millions) but other parts of the code don't handle this properly anyway.
Looks to address http://opensimulator.org/mantis/view.php?id=7163
|
| | |
| |
| |
| | |
when sending group messages, not just those after get group members and get presence status, as applicable
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
that of the groups module.
This is to allow us to get useful information on messaging without being overwhelmed by the rest of groups debug.
Enabled with [Groups] DebugMessagingEnabled = true in config (default false)
Or "debug groups messaging verbose true|false on the console" (similar to existing groups setting).
Done for both xmlrpc and V2 groups.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
notice with XmlRpcGroups messaging did not appear in the user's inventory.
This was because the "session ID" when the message template was copied was always replaced with the group ID, whereas a notice requires this to be the notice ID.
Instead just copy the "session ID" as is - other callers already have this set properly so replacing with group ID was redundant anyway.
Relates to http://opensimulator.org/mantis/view.php?id=7037
|
| | |
| |
| |
| |
| |
| | |
Cross, because the permission checks are different.
Previously we used a heuristic of checking if the entry position is 0 to differentiate between Teleport and Cross, but that doesn't work anymore since we've started providing the precise entry position for cross, too. That's required in order to ensure that the user is allowed to enter the parcel that he's walking into.
|
| | |
| |
| |
| | |
due to permissions (in QueryAccess and IsAuthorizedForRegion)
|
| | | |
|
| | |
| |
| |
| | |
error messages.
|
