First, figure out the units used by this FS MP packet.  Then, allow the user to
turn it on in the multiplayer options.  This would let the user have a low
update MP update rate (say, 4 Hz) to save on CPU, but still get smooth plane
drawing.

This also causes groundspeed to be shown as zero in apps like FSNav.

*** Bug 171 has been marked as a duplicate of this bug. ***

Also, ground speed should be transmitted correctly in the position packets if
it's not already.  It is expressed as an integer in knots and is the speed
relative to the ground.  Not sending this correctly can cause tracking problems
in ASRC.

*** Bug 277 has been marked as a duplicate of this bug. ***

Just a sec.  Ground speed is actually already being sent in the position packets.

When flying from Denver to ABQ - ABQ had a fly in going on... I loaded FSNAV 
and was able to see all the ground traffic on FSNAV and hear the multiple 
aircraft that approach was talking too, but did not see any on the ground... 

So... When using multiplayer with FSNAV - it takes the planes out of the sky 
for you to see... 

 

FYI - Just loaded new build... FSNAV is working with multiplayer and I can see 
a/c outside my windows... 

The airspeed indicator remains inop in FSNAV

Build 4803

*** Bug 425 has been marked as a duplicate of this bug. ***

When this gets fixed, test if it fixes bug 118.

The lack of speed data could also be causing the Project Magenta TCAS to not
display planes at all.

This could also be causing bug 157.  Not sure.

Consider changing default updating plane position rate to 5Hz.

The code for this has been written.  The last groundspeed transmitted from the
network (in knots) is saved for each plane.  This is then added to the
POSITION_VELOCITY packet after being converted to feet per second and into
whole/fractional format.  The values for lat_velocity, lon_velocity and
alt_velocity are computed based on the difference of the last two latitude,
longitude and altitude samples for each plane.  The values are converted into
feet per second and into whole/fractional format.

SB3 then sends POSITION_VELOCITY whenever any of those 4 velocity values are
non-zero.  Otherwise it sends POSITION_LLAPBH.

The problem is that the plane drifts quite undesirably when sending velocity
packets.  For instance, when moving straight ahead, the plane will drift left or
right.  As soon as SB3 starts using POSITION_LLAPBH packets instead of
POSITION_VELOCITY, the plane pops back into the correct position.  This doesn't
appear to be due to inappropriate values or units, because sending a value of
zero for all velocity values has exactly the same effect.

I'm perplexed.

Joel,
Velocity packet are kind of mad bull to handle.
FS will tend to generate eratic mvt as soon as you dont send enought velocity 
packet frequently enought.
in FSInn i user a formula based on plane distance and speed to know what 
refreshment rate i have to use to get the plane smooth.
For exemple a plane flying at 80kts will be extremly smooth with 4Hz 
refreshement, 250kts plane often need up to 20Hz refreshment to be smooth.

In my opinion you have 2 options :
- implement fully velocity packets, with a adaptative rate depending on display 
distance and speed, 
- play with LLAPBH and VELOCITY just enought to trick PM and FSNav....
let say you send LLAPBH, except 2HZ you send VELOCITY immiedatly followed by 
LLAPBH.

The choice you must make is : spend quite some time on VELOCITY to do it well, 
or make a trick and postpone modification to a futur patch.
IMO, i ll choose the second, i know where i went thru with VELOCITY packets.

This makes me want to weep.

Thanks for the feedback though Ben!  This is helpful.

Anyway, I think the next strategy should be to snoop the DP packets on a real
FS-to-FS session and see what FS sends when the plane moves around.

Joel, i think your prob isnt due tu incorrect values or protocol, but due to 
the refreshment rates as i described before, snoop if you want, from what you 
shown me, your packet are correct.

MP speed still shows 000 in FSNav with Beta 4

Confirmed, FSNAV still shows ground speed of ZERO, whilst using SB3 Beta 4.

I'm going to wait until the new timer implementation is done (to address bug
431) so that if I need to up the frequency of these things a good deal, I'll at
least know they're coming through accurately and consistently.

These are still quite problematic.  And the regular LLAPBH packets are working
just fine.  I think we'll go with that for SB3.0 for now.

Talked to Russell about this a bit....  Am going to try to use appropriate
values of metres / second and only send these 4 times per second.  I'm going to
get these to work if it kills me.  It appears that sending LLAPBH only at very
high frequencies causes some sessions to get totally bogged down.  So sending
these would seem to be a must.

Well they seem to work now.  All velocities are in fact in feet per second
EXCEPT groundspeed which is in metres per second.

It's in and can be activated in advanced options.

Released in RC3 build (March 3 2005; 5315)