Broken Netcode Demonstration -- A Bogus Kill

by **Drakona** » Tue Oct 29, 2013 11:49 am

Ok, here's a 58.1 build with Retrohomers. Remember to play with short packets DISABLED.

D1:
D2:

D1 version has been tested by Jeds & I, and Jeds & Mark, and we all approve.

D2 version has been tested by Mark & I, and it looks perfect. Also, watch out for that long packets gauss.

That doesn't solve the problem entirely, but should drastically reduce the pain.

by **Ryguy** » Tue Oct 29, 2013 12:04 pm

by **RiTides** » Tue Oct 29, 2013 1:45 pm

by **ryusei117** » Tue Oct 29, 2013 2:24 pm

by **Drakona** » Tue Oct 29, 2013 2:42 pm

by **ryusei117** » Tue Oct 29, 2013 4:20 pm

Thanks! They build with no issues; Linux uses pkg-config to automatically determine those include paths anyway. If I remember correctly, the miniDev is planned to receive this capability as well, or at least be updated for the new paths … but that hasn't been done yet.

by **Drakona** » Tue Oct 29, 2013 4:33 pm

Glad to hear Linux is covered.

As for Mac . . . I must say, my relationship with Mac has reached an all-time low, and that's saying something.

by **JinX** » Tue Oct 29, 2013 5:15 pm

Did you ever look into the rotational velocity interpolation in physics.c? It shouldn't be interpolated for players that are not you. It should, however, interpolate for absolutely everything else with rotational velocity.

EDIT: Sorry, I think I may be leading to some confusion when I call it interpolation; what it really is is the part of the code that applies air friction while you're spinning and slows you down. Players that are sending rotational velocity packets (large packets) shouldn't have their ships slowed down via air friction at all. Otherwise the engine should also apply normal vector velocity friction for the x, y, z axes, which it does not iirc.

by **Drakona** » Tue Oct 29, 2013 5:24 pm

I did look, and the math looked okay as far as I took it apart. Which admittedly wasn't very far. Once I discovered what was in the short packets I kinda raged out and stopped thinking about much else.

I'm not sure why you think interpolating rotation is a bad idea, though. At a 100ms / 10pps scale, rotational velocity should be pretty close to constant, so you should be able to do pretty accurate interpolation. Given that shot packets arrive independently of ship position packets and can arrive any time, you want that orientation as accurate as possible . . . and while there could be an error right when you change directions, I'm having a hard time seeing how not interpolating would be an improvement.

I mean, sending orientation data with each shot sounds like a pretty good idea when I put it that way, but I don't see how interpolating the ship orientation is a bad thing. Imperfect, sure, but it beats the alternative.

. . . am I missing something?

by **Drakona** » Tue Oct 29, 2013 5:41 pm

Oh, drag! Yeah, multiplayer ships have the same rotational drag as the player ship, per multi.c. That does seem a little odd, but it's been that way since the game was released, so I'm not inclined to mess with it lightly.

A quick test with a kb config shows that you stop moving within about 200 ms of releasing a turn key, which is alarmingly fast if this force is what's responsible. I don't think that's where the orientation errors are coming from, given that 0.55 (presumably) did it the same way and had such better performance. It might be worth testing whether turning that off improves overall accuracy, though.

Though I'm thinking if I want to improve on the original, I'm just going to send the darn orientation information with the shots.