Am Saturday 28 January 2012 00:37:44 schrieb Jonathan Welch:
> Yes, because the coarseupdate packet holds many positions, it is not
> just 1 packet per avatar, but as many as can be packed into the
> coarseupdate packet as will fit. So it is not possible to alter this
> packets' format in any way.
Dan took it into SH as SH-2918. Guess its gonna be fixed :)
On 1/25/2012 8:46 PM, Dave Booth wrote:
> reverified with todays build, VWR-28207 created.
>
> On 1/24/2012 4:02 PM, Dave Booth wrote:
>> Somewhere between the branch for the current beta and the tip is a
>> mistake leading to an instant
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/27/2012 6:21 PM, Argent Stonecutter wrote:
> How about reducing the vertical resolution of the packet by 4?
This was also brought up several times during the various discussions.
It would break old/existing clients more than the current change, a
How about reducing the vertical resolution of the packet by 4?
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges
On 1/27/12, Jonathan Welch wrote:
> This has been discussed several times at the server group meetings.
> Fixing this just to have a fully correct map display is more trouble
> than it is worth; having to run two packet formatters in parallel
> forever, having to query the viewer what packet form
> PS: I really want to be able to get rid of my lag-creating Sensor-based HUD
> for a pure client-side system. Hence my active commentary.
The server team is not going to be making changes to the current
system; they have said the cost of doing that, the additional load on
the servers, etc. is no
It just means that having a proper clientside radar system is now truly
stuck.
And I did mean a finite time period for the deprecation: I agree that such
things are unmaintainable in the long term. However the current state of
affairs isn't viable for long either, so a plan has to be readied.
Ka
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/27/2012 3:37 PM, Jonathan Welch wrote:
>> Would the client have a problem if another word was added to the
>> message giving - duplicating the data, but allowing newer clients
>> to choose to use the new word while older clients use the old
>> b
> Would the client have a problem if another word was added to the message
> giving - duplicating the data, but allowing newer clients to choose to use
> the new word while older clients use the old byte?
Yes, because the coarseupdate packet holds many positions, it is not
just 1 packet per avatar
A couple of questions Oz:
1. Would the client have a problem if another word was added to the
message giving - duplicating the data, but allowing newer clients to choose
to use the new word while older clients use the old byte?
2. Would the client have any problems if the CoarseLocatio
On 2012-01-06 16:15 , Oz Linden (Scott Lawrence) wrote:
We're going to deploying changes to the inventory backend soon that
improve robustness and performance, but in testing those changes we
found that existing viewers relied on certain things being strictly
ordered. With the new backend, tha
On 2012-01-27 13:45 , Zi Ree wrote:
> Am Freitag, 27. Januar 2012, 14:40:01 schrieb Jonathan Yap:
>
>> The SL simulator has recently been fixed so that the CoarseLocationUpdate
>> message properly returns 255 for all altitudes above 1020 meters.
> "Properly" is a very ... unusual term for this kind
Am Freitag, 27. Januar 2012, 14:40:01 schrieb Jonathan Yap:
> The SL simulator has recently been fixed so that the CoarseLocationUpdate
> message properly returns 255 for all altitudes above 1020 meters.
"Properly" is a very ... unusual term for this kind of behavior. It still
returns a wrong va
---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/545/
---
Review request for Viewer.
Description
---
The SL simulator has recent
14 matches
Mail list logo
