Questions regarding Retro features

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

You are talking several seconds now, while you previously mentioned a timeout of 1000 ms ...

A delay of one second seems acceptable to me even under competitve conditions. The alternative would in your example be not to get any audio feedback of a player's position at all. How is that fairer?

You could also use a shorter timeout for such messages, like 300 - 500 ms. On a halfway reliable connection that would suffice. A worse connection would render the idea of playing competitively absurd. I think a door not opening at all would block more shots than one opening a bit late, wouldn't it?

by **LotharBot** » Mon Jul 14, 2014 6:05 pm

by **karx11erx** » Mon Jul 14, 2014 6:09 pm

I cannot quite follow that, but then I am not playing Descent competitively. My focus is more on coop and anarchy for fun.

by **LotharBot** » Mon Jul 14, 2014 6:16 pm

exactly. In coop you want the door to open even if it's late. In less-structured anarchy either approach works. In 1v1 and competitive scored anarchy (DCL and Rangers games) the misleading aspects of having a door open late are worse than having it simply not open. Remember, it's not just the blocked shots. It's the false information. Or the second player being able to go through the door after it's closed on the first player's screen. The errors propagate into the future if the door opens late.

Also remember, this isn't something decided by debate, but by playtesting. It bothered players more to have late-opening doors than not-opening doors for the above reasons.

by **RiTides** » Mon Jul 14, 2014 8:56 pm

Did players actually observe late opening doors in multiplayer games (or at least, more than just a one-off?). It seems like that's pretty significant... and likewise, if now they could regularly have a door an opponent went through not be open, seems significant. I didn't realize this was happening, so knowing it's frequency / likelihood seems useful.

by **LotharBot** » Mon Jul 14, 2014 9:06 pm

It was observed on occasion in lossy games. Think of it as happening in the same scenarios where you might get occasional bursting.

by **Drakona** » Mon Jul 14, 2014 11:00 pm

It still happens in 1.3, and more than I'd like. Once or twice since 1.3 came out, I've seen someone come through a closed door.

Diedel's suggestion of a fast resend for that particular packet is a good one. I'll probably do that in 1.4. I'd probably use an aggressive 50 ms resend and similarly aggressive discarding of duplicate packets. For 1.3, I basically didn't touch the existing ack mechanism, not wanting to disturb any more code than I already had.

I haven't had it happen in a ladder match, yet, and you have to be on a pretty lossy connection (or have terrible luck) for the door packet to be the one that gets dropped. On a 30 PPS game, you're sending 30 position packets every second, and the loss of any of them will make the loss meter light up at 1% for a few seconds. If your loss meter is staying at zero -- typical for most games -- thousands of packets are going by every minute without one being dropped. The odds of dropping one of the handful of door packets in that scenario are pretty darn low.

by **karx11erx** » Tue Jul 15, 2014 2:19 am

Understood. One thing you could do is resend the packet very fast - too fast even for the confirmation message to arrive (edit: Just noticed you had mentioned that). The mechanism preventing such a message to be processed twice (D2X-XL's clients remember important messages they have received and drop duplicates of them - does Rebirth do that, too?) could handle duplicate messages being processed, and you would have some delay between the two data packets reducing the chance of both getting lost, unlike two packets being sent right one after the other. Maybe resend 50 - 100 ms after the initial message. Might alleviate the problem w/o introducing much lag.

by **karx11erx** » Thu Jul 17, 2014 5:35 am

If I have understood you right, Rebirth's important message handling routes all such messages from the clients originating them to the game host. Am I right with this? If so, that would of course add to the message travel time to the other clients. It would also introduce a chance of packet loss between the originating clients and the game host. Understandably, this would create problems particularly in competitive multiplayer matches with their need for short message travel time.

by **DKH** » Tue Jul 22, 2014 11:39 pm

Interesting...