Questions regarding Retro features

by **Jediluke** » Fri Jul 11, 2014 9:43 pm

In a way....I take full credit for retromod's existence!

oh...and the DCL!

by **karx11erx** » Sat Jul 12, 2014 7:05 am

Lothar,

I perfectly understand where Drak is coming from; Particularly when she didn't even know D2X-XL.

My point about Rebirth is clear enough I think, so I will not bore you with it anymore.

XL could certainly need some solid multiplayer testing, but then you are perfectly satisfied with the Rebirth mod, so what.

Anyway, I have learned enough from the issues Drak has identified, and it was refreshing to talk with someone who I felt was on the same technical level as I.

I wish you good times with whatever Descent mod you chose.

karx

by **RiTides** » Sat Jul 12, 2014 12:05 pm

I did not realize D2X-XL allowed Descent 1 play. The name is a little misleading!

Very cool seeing all the code discussion here, even though it's over my head.

by **karx11erx** » Sat Jul 12, 2014 12:49 pm

I know. Originally it was a Descent 2 source mod and the name has just stuck. Besides the D2 collision physics code (which should be identical to D1's minus a few bugs maybe) it also uses the D2 netcode, meaning it doesn't have the problems with misaligned shots among others. The D1 support uses D1 data particularly for the weapon physics (damage etc.) in D1 missions, and the D1 AI for robots in D1 missions. Ofc it also uses the D1 textures and sounds there.

by **karx11erx** » Mon Jul 14, 2014 7:08 am

Drakona,

how exactly did you implement your message handshake mechanism? Did you consider the possibility that a handshake didn't reach the intended client and that client keeps resending the related message?

by **Drakona** » Mon Jul 14, 2014 10:58 am

Message handshake . . . I'm not quite sure what you mean by that. You mean the process of joining the game?

by **karx11erx** » Mon Jul 14, 2014 11:18 am

You wrote that you are making sure that important messages reach all clients by them sending a confirmation back. That's what I am referring to.

by **Drakona** » Mon Jul 14, 2014 11:46 am

Ah! I didn't write that. I inherited it from Rebirth. I considered taking it out entirely, due to it's not being original D1 behavior . . . but it's kind of nice, even if it is sometimes prone to misbehavior.

But yes, the system does take loss into account. Messages that require acknowledgement are given serial numbers, which are used to track them. When one is sent, the sender waits for an ack and resends the message if it doesn't get one within 1000 ms. It will try up to 14 times (used to be 4, I raised it) before concluding that the connection has been lost.

For things like chat messages, kills/deaths, game control (kicks), and score updates, this is perfect. For things like powerup pickups and ship explosions, it's got some quirks (sometimes a pickup message arrives pretty late, and you see the object vanish into thin air), but is better than the alternative. For things like door openings, it does more harm than good, and I've taken those off the system.

One of the things I didn't like about the Rebirth implementation is that if you failed to ack one of these messages, you wouldget disconnected from the game. With a resend limit of 4, this could happen over a (playably) lossy connection if you just had a run of bad luck. This seemed unnecessarily harsh to me, and has been removed; disconnects now happen if there are no position updates over a 15 second period. (The 15 seconds is intended to give you time to plug a cable back in or something).

I am not completely happy with the system, as the guaranteed delivery packets are still managed by the game host and have to go through them. I would like to keep the ack mechanism while still sending these messages peer to peer. We have occasionally noticed desync issues caused by the different latencies in the peer-to-peer position updates and the through-the-host powerup pickups. It normally isn't an issue at latencies considered 'playable', but if there's some loss and the message has to be resent a time or two, the delay and hence the desync can be considerable. As a future improvement, it might be worth shortening the delay before resending the message, or even going with the Doom/Quake strategy of simply sending everything three times in the first place.

by **karx11erx** » Mon Jul 14, 2014 5:25 pm

I am just done adding a similar system to D2X-XL. My system works P2P: The client originating (causing) an event will ask all other clients to confirm receipt of the event's message and will resend the message every 300 ms for 3 seconds to all clients who haven't acknowledged them. I was mostly considering coop when chosing these values.

D2X-XL relies on a different timeout detection by checking whether it did not receive any data at all from a client and will disconnect such a player after 3 seconds. He will be kicked after 30 seconds; until then, he can reconnect and pick up where he timed out. I may make these values and timeout conditions selectable via the game hosts multiplayer setup menu, should the need arise.

14 resends in 1000 ms seems a bit fast because that means a packet round trip time of only 70 ms for a client's confirmation to arrive in time.

What problems do you see with resending e.g. door activatuon messages?

by **LotharBot** » Mon Jul 14, 2014 5:53 pm