997R, it sounds like you're doing client-side prediction with dead-reckoning, which probably isn't the best way unless you need absolute time synchronization with all displays showing the exact identical scene (or as close as the system can get, for example if they are side-by-side networked displays which the user can easily detect are out of sync -- although in that case you're probably on a LAN and can just increase the update rate from the server to 10ms instead of 100).
If you do need that precise time synchronization, client side prediction will give you the closest result, but you will also have mispredictions from the dead reckoning you will need to store and smoothly correct over time instead of just jumping the object to the newly-updated position (which sounds like what you're doing now). For example, at time 0.0(ms) you get an object update from the server, and it's velocity vector (let's say for example, "straight ahead") and you start stepping that object straight ahead along the vector every 10ms. At 20ms, the object on the server starts to turn right, but you won't know that until the next update, so you keep showing it stepping "straight ahead." At time 100.0ms, you get the new update which says the object is to the right of where you've been stepping it along. The difference between your stepped-along (dead-reckoned) position and the new "actual" position you would save as the error delta. The next "step" would continue from the last dead-reckoned position (not the new updated position), but along the newly updated velocity vector, PLUS you add a fraction of the saved error delta (e.g. half the remaining error delta each step, then halving that saved value so you get a continuous, smooth "correction" curve the user hopefully won't notice).
If it's okay for the client to be slightly behind the server, you can avoid all that by caching one of the updates and extrapolating from the 2nd previous update to the last update. You won't have any mispredictions or "sliding" as objects correct their update errors, but in your case the client will be seeing the scene 100ms behind the server. That might not matter though to your users.
0xC00000B0 is a Windows kernel "disconnected pipe" error. I'm pretty sure SimConnect uses named pipes internally, and it probably automatically reconnects so I bet you can just ignore it. .
Capn_Geoff, the sliding and stuttering of a remote object that you're showing locally can happen if you're not freezing physics processing by sending the FREEZE_LAT_LONG / ALTITUDE / ATTIDUE events for that object. I think the FSX physics loop happens at some sparse rate (4HZ? 1HZ?) where it determines new velocity and accelerations, but it's drawn more frequently of course, and I think the drawing loop extrapolates positions and orientations like above, based on those stored velocity and acceleration values. If you're just updating position and orientation, I found it will keep "extrapolating" the object toward the previous position while you keep trying to move it the other way. Freezing lat/long/altitude/attitude solves that kind of stuttering, anyway.
Other jittering can happen if you're switching between 64 bit position variables and 32 bit. FSX does store position internally as 64 bit values (double precision float). If you are calculating in 32 bits, you lose the precision when it casts back to 64 bits and objects will seem to jump instead of move more smoothly.
Another frustrating problem with floating point underflow can happen if you're updating positions too frequently and the velocity is really small. It can be noticeable with slow taxiing aircraft like at 1 or 2 knots -- a very small time interval times very small angular velocity relative to earth underflows even the 64 bit value and it will round to 0.0 and not move at all. I don't get those problems with 60HZ position updates, but started to at 100 or 120HZ.
I hope one of these ideas might fix your problem or give you some other ideas.
into the rotation. Solved that by making sure that the value is between 0 and 2 pi for heading, and -pi and +pi for pitch and bank.
