It is true - the server could use improvements and they could both do with
working better together. And this is something we want to do, eventually.
However these specific changes are about addressing some of the worst
offenders - the blatently horrible cases where you fly off into the sunset
beca
Yeah, that is true. It should be able to detect the very source that causes
most movements. There might be issues on scripts that influence an avatars
movements via control events though, while that could be avoided by checking
if control events have been taken, it might misidentify scripts that ta
Could checking to see if a user is still pressing a movement key fit into
the algorithm? It seems it could be a useful input to help determine if the
user really wants to continue along a dead-reckoning path.
On Tue, Oct 12, 2010 at 2:51 PM, Dale Innis wrote:
> On Tue, Oct 12, 2010 at 5:38 PM, Si
On Tue, Oct 12, 2010 at 5:38 PM, Simon Linden wrote:
> Some of my changes should help, however. The viewer will check the edge of
> the region, and if there is no neighbor region, stops the object motion.
> Predicted object motion is also pinned to the
> allowable underground distance and top
Hi -
Yes, I updated that repository with my first attempt at improving the viewer
prediction code. The changes are:
* Configurable settings for tapering off viewer-side motion prediction
* Limit predicted motion at region edges based on adjacent regions
* Bug fixes around region crossing timers
If anyone is interested his code is here:
http://bitbucket.org/simon_linden/viewer-dev
cc'ing the opensource-dev list as this seems appropriate for that list at
this point.
- Kelly
On Tue, Oct 12, 2010 at 8:27 AM, Kelly Linden wrote:
> Actually one of my coworkers has been working on some fea
