| Commit message (Collapse) | Author | Files | Lines |
|
the kill work
|
|
BestAvatarResp scheme. Attachments cannot be sent on imediate queues,
since they will block everything. Changed distance to priority math,
keeping identical result, shifted to start at queue 3.
|
|
nonimediate queues. Imediate queues where not taken into account so it
was unused.
|
|
|
|
selected priority (by distance being the one that makes sense(?). So called fairness serves no usefull purpose. If a region is lagged or user has bad comms, and far objects updates don't arrive, at least nearby thinks do have a chance to keep ticking. Just test on a big region and observe rez order on arrival. lower viewer bandwith helps seeing the diference. No use to put in core since cmic loves the priority scrambling code i comented out."
This reverts commit 68981d01f024f8a46949127e1cc23c81282f5220.
|
|
priority (by distance being the one that makes sense(?). So called fairness serves no usefull purpose. If a region is lagged or user has bad comms, and far objects updates don't arrive, at least nearby thinks do have a chance to keep ticking. Just test on a big region and observe rez order on arrival. lower viewer bandwith helps seeing the diference. No use to put in core since cmic loves the priority scrambling code i comented out.
|
|
|
|
of not all prims being sent without reprioritization.
|
|
and currently used for all of an avatars attachments by the other
policies. Also changed the way items are pulled from the update queues
to bias close objects even more.
|
|
command to look at the entity update priority queue. Added a "name" parameter
to show queues, show pqueues and show throttles to look at data for a specific
user.
|
|
per Melanie's very good suggestion. The immediate queue is
serviced completely before all others, making it a very good
place to put avatar updates & attachments.
Moved the priority queue out of the LLUDP directory and
into the framework. It is now a fairly general utility.
|
|
types of property updates to be specified. Not sure if one form
of property update should supercede another. But for now the old
OpenSim behavior is preserved by sending both.
|
|
to the entity update queue. The number of property packets can
become significant when selecting/deselecting large numbers of
objects.
This is experimental code.
|
|
types of property updates to be specified. Not sure if one form
of property update should supercede another. But for now the old
OpenSim behavior is preserved by sending both.
|
|
to the entity update queue. The number of property packets can
become significant when selecting/deselecting large numbers of
objects.
This is experimental code.
|
|
types of property updates to be specified. Not sure if one form
of property update should supercede another. But for now the old
OpenSim behavior is preserved by sending both.
|
|
to the entity update queue. The number of property packets can
become significant when selecting/deselecting large numbers of
objects.
This is experimental code.
|
|
is big enough.
|