Why do you some of you guys do this?

What is the fun of ché@ting?
Sign this petition to help get Supercell off their @sses and do something about it.

Hurry up cause supercell will probably close this because im exposing flaws in their game.

https://www.change.org/p/supercell-acknowledge-the-rampant-♥♥♥♥♥ing-in-clash-of-clans-and-provide-transparency-in-your-efforts-to-fix-the-the-problem

Quote:

---

Originally Posted by Clashmasterxhhfsdvnm

Hurry up cause supercell will probably close this because im exposing flaws in their game.

---

That part made me laugh. They have a section in the forums about bugs and problems. I understand that this isn't a bug but still, it's a problem. They obviously care about "flaws in their game" somewhat. So don't go saying that they'll close a thread exposing problems in the game. Just move this stuff there! Also, I know this problem has been brought up to them and they are aware of this already. I think they don't like ♥♥♥♥♥ers as much as we do.

Title says it all

Way to be part of the solution. Keep this up and it'll be fixed in no time.

Quote:

---

Originally Posted by Duude

don't go saying that they'll close a thread exposing problems in the game.

---

wont be the first time

Attacking is done on the client software. No matter what, h@ckers will always be able to h@ck the client software.

While attacking, the client communicates with the server. The server makes sure all of the data from the client is valid. Otherwise someone could h@ck the client, make it pass false data to the server, and automatically win every attack.

The problem is, the client can't communicate with the server 100% of the time. The quality of mobile devices' internet connections is very unreliable. This means, the client software has to has to be able to run the attacking algorithms itself, in absence of the server.

Since the attacking algorithms exist on the client software, h@cks can prevent the client from communicating with the server, resulting in the ability to perform "sandbox" attacks.

To prevent sandbox attacks, they would need to remove the attacking algorithms from the client. This means, the client would have to have a solid and fast connection to the server 100% of the time, and there would be lots of issues with lag.

Basically, there are two options. Have smooth gameplay for everyone, but allow some people to che@t. Or prevent people from che@ting, but have laggy gameplay for everyone.

Quote:

---

Originally Posted by Janz

Attacking is done on the client software. No matter what, h@ckers will always be able to h@ck the client software.

While attacking, the client communicates with the server. The server makes sure all of the data from the client is valid. Otherwise someone could h@ck the client, make it pass false data to the server, and automatically win every attack.

The problem is, the client can't communicate with the server 100% of the time. The quality of mobile devices' internet connections is very unreliable. This means, the client software has to has to be able to run the attacking algorithms itself, in absence of the server.

Since the attacking algorithms exist on the client software, h@cks can prevent the client from communicating with the server, resulting in the ability to perform "sandbox" attacks.

To prevent sandbox attacks, they would need to remove the attacking algorithms from the client. This means, the client would have to have a solid and fast connection to the server 100% of the time, and there would be lots of issues with lag.

Basically, there are two options. Have smooth gameplay for everyone, but allow some people to che@t. Or prevent people from che@ting, but have laggy gameplay for everyone.

---

This is not true, running attacks on client isn't the culprit. The root problem here is that h@ckers intentionally disconnect connections to servers during the 30 second preparation period. After the first troop is dropped, it doesn't matter afterward since disconnections then would still make it a done attack.

Thus, a fix doesn't need to "remove the attacking algorithms from the client". Servers currently already handle disconnections after the first troop is deployed. The question is to whether count the disconnections before first troop is deployed as a real attack. One simple solution is to add a pop-up after clicking "Attack" button to confirm it, once it's confirmed, it's treated as a real attack even when a disconnection happens during the 30-second preparation period.

Another way to make it more flexible and affects normal users less is to only treat disconnections for long period of time as failed/complete attacks.

For example, allow clients to queue and re-transmit network packages after servers detect disconnections and send back requests for retransmission. During this time, attack still continues on the client side but the data is saved and queued. If the client never re-transmits after certain time (let's say 5 minuets), server only then determines it's an actual disconnection and a failed attack. This way, losing network connection for a short period of time doesn't cause problems to normal users.

Of course, all these network transfers are secure and encrypted like currently are.

I don't agree with this posters particular rhetoric, but I would love an even playing field

How I feel reading about redditors talking about their loot filter mods
http://i.imgur.com/RTPbb8D.jpg

Quote:

---

Originally Posted by Janz

Attacking is done on the client software. No matter what, h@ckers will always be able to h@ck the client software.

While attacking, the client communicates with the server. The server makes sure all of the data from the client is valid. Otherwise someone could h@ck the client, make it pass false data to the server, and automatically win every attack.

The problem is, the client can't communicate with the server 100% of the time. The quality of mobile devices' internet connections is very unreliable. This means, the client software has to has to be able to run the attacking algorithms itself, in absence of the server.

Since the attacking algorithms exist on the client software, h@cks can prevent the client from communicating with the server, resulting in the ability to perform "sandbox" attacks.

To prevent sandbox attacks, they would need to remove the attacking algorithms from the client. This means, the client would have to have a solid and fast connection to the server 100% of the time, and there would be lots of issues with lag.

Basically, there are two options. Have smooth gameplay for everyone, but allow some people to che@t. Or prevent people from che@ting, but have laggy gameplay for everyone.

---

Ban all people who use jailbroken or rooted devices?

Quote:

---

Originally Posted by buffaloes

...
Of course, all these network transfers are secure and encrypted like currently are.

---

This part is funny :)