| Commit message (Collapse) | Author | Files | Lines |
|
BSPrim.Incomplete flag based on rebuild flags to say when an object is being rebuilt.
|
|
calling ZeroMotion in SetPhysicalProperties() at all
SetPhysicalProperties is only called when adding a new character so it looks like there is no existing data to reset anyway.
|
|
convert the m_log.DebugFormat() call back to the original DetailLog call
|
|
when avatar enters the new region.
This commit addresses the following issues were causing velocity to be set to 0 on the new region, disrupting flight in particular
* Full avatar updates contained no velocity information, which does appear to have some effect in testing.
* BulletSim was always setting the velocity to 0 for the new BSCharacter. Now, physics engines take a velocity parameter when setting up characters so we can avoid this.
This patch applies to both Bullet and ODE.
|
|
thread and run work in the jobengine from Watchdog to a WorkManager class.
This is to achieve a clean separation of concerns - the watchdog is an inappropriate place for work management.
Also adds a WorkManager.RunInThreadPool() class which feeds through to Util.FireAndForget.
Also switches around the name and obj arguments to the new RunInThread() and RunJob() methods so that the callback obj comes after the callback as seen in the SDK and elsewhere
|
|
avatars collide. This is true by default.
This is implemented with a new collision type (PhantomToOthersAvatar) to potentially allow colliding and non-colliding avatars to be present in the same scene.
So there is no provision yet for giving avatars different collision types.
This commit replaces the temporary change in commit f3eaa6d8 where avatars would never collide when using BulletSim
This is equivalent to the av_av_collisions_off option in ODE.
|
|
problem diagnosis.
"show threadpool calls" now also returns named (labelled), anonymous (unlabelled) and total call stats.
|
|
rather than a sleep.
In theory, there should be no difference between these mechanisms.
However, on at least Mono 3.2.8 waiting via an event appears to be much more accurate.
|
|
Will only effect Windows or mono with a patch such as https://gist.github.com/justincc/31e52218d098529b4696 applied
For test purposes
|
|
Need to do this for a test. Final implementation will be properly controlled through a property.
|
|
unnecessary object update if the prim was not moving to target.
This involves making PhysicsActor.PIDActive get as well as set.
On physics components that don't implement this (all characters and some phys engines) we return false.
|
|
|
|
checked, specially on portals
|
|
|
|
|
|
|
|
|
|
|
|
method is only run for an indepndent thread anyway.
Also remove bulletsim monitored thread from watchdog on shutdown.
|
|
The cost is minimal (also done for scene loop) at the benefit of telling us if this thread simply stops for some reason.
|
|
|
|
watchdog.
This allows us to see the presence of the permanent thread via the "show threads" console comand.
Also adds the region name to the thread name.
|
|
BulletSim fixed constraint to not be confused with the native version.
|
|
Fix for 7284 which is an enumeration exception when starting up a region.
|
|
bulletsim physics is running in a separate thread.
This will also allow the "disable physics" setting in the region debug viewer dialog to work in this circumstance.
|
|
constructed.
Add routine to check for failed and use that method rather than
checking individual state.
|
|
|
|
|
|
|
|
This is related to http://opensimulator.org/mantis/view.php?id=7067 .
But that bug complains about BulletSim, and this fix is for ODE.
|
|
|
|
|
|
complete with use of the Limit Roll Only Flag.
Signed-off-by: Robert Adams <misterblue@misterblue.com>
|
|
condition check without changing the logic
|
|
forward when moving south or west.
Addresses http://opensimulator.org/mantis/view.php?id=5003
Thanks to UbitUmarov for this fix.
|
|
|
|
child mesh is not available when building a linkset.
|
|
has. Before this falling from really high caused the avatar to fall faster then the veiwer can handle and cause camera issues.
|
|
from locking up when running BulletSim on a separate thread.
|
|
child doesn't have a physical shape. Another attempt at fixing Mantis 7191.
|
|
AvatarFlyingGroundMargin and AvatarFlyingGroundUpForce set to 5.0 and
2.0 respectively which seems to give about the same action as in SL.
Also moved force addition to before the velocity to force computation
so the upward velocity is properly applied to the avatar mass.
|
|
(swimming)
Signed-off-by: Michael Cerquoni <nebadon2025@gmail.com>
|
|
flop to the floor when flying with bullet physics and acts more like ODE and SL flight.
Signed-off-by: Michael Cerquoni <nebadon2025@gmail.com>
|
|
|
|
This should get around the exception reported in Mantis 7191 and 7204
by checking for the unbuilt child and rebuilding the linkset the next tick.
A warning message is output when this rebuild happens and this message is
clamped to 10 times in case there is a problem with a loop.
|
|
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.
|
|
step updates and collisions. This is an attempt to fix a crash reported
by Justin when doing high velocity teleports.
|
|
to west.
|
|
staircases. This change is required because of the change in the
avatar default shape from the capsule to the rectangle.
|
|
Extends basic physics to allow av movement on a varregion (basic physics is only really useful for regression test purposes).
|