Drop hacking -- solution?

So, I just spent 35 minutes in a tight game, I thought I was going to lose a couple times, but then I made a solid move that revealed I was going to win with my opponent having only 18 tickets left, or whenever he decided to quit but the game ended with him only having 18 tickets. Then, long random pause where nothing moves, "Waiting for match results." I figure he dropped, turns out I got the loss, must be drop hacking right? I have a lot of disputes, I live in a Chinese dormitory so I get a lot of disconnects, but I recently got a VPN and now I can play CoH2 lightning fast, FUCK YOU CHINA! Anyway, it seems odd to me that Relic hasn't made a simple, but probably complicated, algorithm that tests when there is a sync connection or some other form of disconnection late in the game. I figure this program would test if the game is below a certain amount of tickets, probably below 500 or 600 tickets, the game starts with 1000, then the program calculates total army value of both sides, and how many remaining tickets are on on each side. If you want to get advanced, all of this is already done in the post-game graphs available. The decline, or exponential decline, on one sides army value and also remaining ticket number should lower my chance of getting the win, as an example if I have a low army value and only have have 5 tickets and you own 2/3 of the VPs, with my low army value and low vp score the win should then reward the appropriate player the win. If the game is too close to call, or has not dropped below the decided, 600 or 500 ticket level, the game will be decided on the ELO system. I just think Relic should utilize a system it already has, determining army value, army-value-degradation and gain, into a much better system that can help prevent drop hacking. I typed this pretty quickly, out of my anger of being drop-hacked. But feel free to correct any little mistakes and/or add your thoughts. I'm not a programmer, but I'm just taking about Relic's already built post-game graphs into a usable algorithm, maybe.

I know my post was very long and covered a lot of issues, but this is my end goal.

SITUATION:

Two players battling, both have an army value of 2000 ( I don't know a proper army value off the top of my head)

suddenly one player goes from 2000 to 800 and the opponent goes from 2000 to 1800. Then a disconnect. This can probably be determined as a drop hack. So the game should then be determined by army value and Ticketvalue. Maybe calculate a time, like, 5 minutes, after that it's again up the algorithm or the ELO.

Example 2: two players, each with 2000 value army, one goes from 2000 to 1300, the other to 1500:, but the player with 1500 army values has 150 tickets, the other with only 18, sudden disconnection. Win goes to player with 150 tickets.

First off, considering you've had connection problems in the past and considering your geographic location, it's much more likely that either your connection, or a node on the path to the NY servers dropped and the server arbitrated correctly.

But let's say you were to introduce a more complex arbitration process that took vp's and army composition into account:

-You would still be able to abuse the system by temporarily stalling your connection at a moment when you're in the lead, thereby triggering the end of the game and eliminating any chance of a comeback from your opponent.

-Where would you draw the line on arbitration? What if you have an equal army value but one side had a 1vp advantage?

All in all, I think the current connection check + trust check setup is the best we can get with the current setup.

Your points are valid, I don't think I'm right, but I definitely think there is a better solution to this problem. I honestly just think this current, "trust," system has a lot of problems. One, I had no idea you could, "STALL," your connection to 'Drop hack," a game. New problem that has never be in CoH as far as I know.

2) I was going to draw the line of 'Total Army Value' decline. For example;

two players have equivalent armies, one goes from 2000 to 1500, the other goes from 2000 to 600. if there is a system error after that, use that fact as evidence to give the 2000 to 1500 player the win. Again, this is already covered by the current in-game coh2 post-game graph/algorithms.

Sorry big EDIT: but I read the last part of your post again, "All in all, I think the current connection check + trust check setup is the best we can get with the current setup."

I don't think the current trust system is, 'wrong or bad,'" I think that it can be improved on -- is the point of my post.

btw, stategos, you should really reread over this, I've made a lot of grammar and other mistakes my OP is probably a lot different then you first read, SORRY!

The only acceptable solution I can think of is to create a re-connection feature.

If one of the players loses his connection to the routing server:
1. The game pauses for the remaining player. This player maintains the current state of the game and is forced to wait.
2. Upon re-connection to the server, the game state is passed on to the reconnecting player and the game resumes.

I assume there's a good reason why this system isn't in place already though. It's probably too costly to create/maintain or opens the door to more security issues.

The only acceptable solution I can think of is to create a re-connection feature.

If one of the players loses his connection to the routing server:
1. The game pauses for the remaining player. This player maintains the current state of the game and is forced to wait.
2. Upon re-connection to the server, the game state is passed on to the reconnecting player and the game resumes.

I assume there's a good reason why this system isn't in place already though. It's probably too costly to create/maintain or opens the door to more security issues.

I think what you just stated was the, "Battle Sever," solution. Which was covered a couple patches ago. The problem is, what if the other player does no reconnect? That's when ELO, Trust, or whatever, comes into play.

I don't think you understand what a drophack is. There really isn't an easy way to drophack in CoH2 thanks to battle servers; even before they were implemented, it wasn't trivial.

The way battle servers work is, every player is connected to the server. The server acts as a relay between players; players send information to the server and the server relays that information to all the other players. This means one player with a bad connection won't lag all the other players, since all that matters now is a good connection to the server, not a good connection to the other players. It also means the server knows which players are connected to it.

This second point is the most important when it comes to discussing drophacking. If the server knows which players are connected, it also knows when a player disconnects. Therefore, pulling the plug doesn't work, because the server will detect it, realize the other player is still connected, and award the connected player the victory. Lagging out won't work either, because the server will know which client is lagging, and will grant the other player the win. Blocking the server IP won't work either, because again, the server will know which player isn't connected.

Those are the traditional means of drophacking. None of them work, because the server has enough information to make a correct decision. The only way to get "drophacked" these days is to get denial-of-service attacked to the point where you are unable to communicate with the server anymore. That's the only way your opponent can cause a drop and get the win short of hacking the server or finding a serious exploit in the game's communication with its server, and it requires your opponent to know your IP address, which you can't get through the game.

Of course, plenty of situations can result in lost connection. Drops in your internet connection, drops in the server's internet connection, server crashes, natural disasters, planned maintenance, all sorts of things can cause all of the players on a server to be disconnected. When that happens, the trust system takes over. It's not practical to judge a game's outcome based on game data because game data is largely inconclusive; in those rare instances of mutual lost connection, the trust system is more than adequate.

So to summarize, you aren't getting drophacked. Please stop complaining about drophacking. Networks are imperfect, expect them to have issues.

I think what you just stated was the, "Battle Sever," solution. Which was covered a couple patches ago. The problem is, what if the other player does no reconnect? That's when ELO, Trust, or whatever comes into play.

The battle server does not allow re-connections at all. If one player drops out, it's over.

The point of a re-connection system would be to give the disconnecting player the option and time to reconnect, if he doesn't want to, he concedes.

Dota2 and Cs:Go do this pretty well but in their case, the true game state actually runs on the server and I guess that makes things much easier. Mimicking that on a p2p system probably creates a load of other issues.

First person who loses connection to relic's relay servers ("battle servers") loses. It's plenty fair in my opinion, just because you have internet issues does not mean you should get a win for a game you drop out of no matter how far ahead you were.

Also, reconnecting isn't possible because the servers don't have any knowledge of the game state; they only relay messages between players. In order for reconnecting to be possible, the server needs to store a history of player actions so that the reconnecting client can simulate the parts of the game it missed and catch up in the gameplay simulation. This adds a ton of overhead and isn't all that feasible for an RTS.

The only reconnect feature we might see in the future is resuming from replays, which is entirely useless in a matchmaking environment.

Also, reconnecting isn't possible because the servers don't have any knowledge of the game state; they only relay messages between players. In order for reconnecting to be possible, the server needs to store a history of player actions so that the reconnecting client can simulate the parts of the game it missed and catch up in the gameplay simulation. This adds a ton of overhead and isn't all that feasible for an RTS.

The only reconnect feature we might see in the future is resuming from replays, which is entirely useless in a matchmaking environment.

But assuming one player remains connected to the server, couldn't he send his game state to the re-connecting player(s)?

Forcing the opponent to wait after a disconnect just opens the door for tons of low-life players to grief their enemies when they are losing.

Forcing the opponent to wait after a disconnect just opens the door for tons of low-life players to grief their enemies when they are losing.

Penalties could be added to discourage such behaviour.

RTS games have no means of conveying a singular game state. They just execute commands in a deterministic manner. What you're proposing is possible, but extremely impractical, because it would mean having to completely rewrite how the game engine runs. RTS games aren't designed to be "picked up" from a random point in the action. Resume from replay functionality works by running through the replay file and pausing the simulation at a set time, then giving players control at that point. It's a pretty big leap to somehow package up the game data, send it to a disconnected player, and be confident that the simulation will proceed without issue from that point. It's a lot of work for something with relatively little utility.

Try test you connection, see if they lost packages on a long connection, from a site in other country, need fix the internet, sometimes the modem, you move, sometimes not to doo...

Good luck...

Yes