[Sven]

Ich denk es gibt zwei mögliche Szenarien:
EALA geht entschlossen dagegen vor in dem sie einen 'Wachhund' - vermutlich würde der dann wieder Apoc heissen - einsetzen der alle, die derlei Cheats einsetzen, rigoros bannt.
EALA arbeitet mit den Entwicklern dieser Cheats zusammen um die Löcher zu stopfen.

Zu Szenario #1:
Das würde bedeuten, daß die Spiele bleiben wie sie sind: Offen wie Scheunentore für Angriffe dieser Art, es würde lediglich ein gewisses Abschreckungspotential entstehen. Ich kann mich altuell nur an einen historischen Fakt erinnern bei dem eine solche Abschreckung ernsthafte Wirkung gezeigt hat: Das Ende des kalten Krieges.
Mal ehrlich: Nur weil es verboten ist? Das reizt doch erst recht. Serial-Ban? Und wie lange...?

Zu Szenario #2:
EALA müsste eingestehen, daß der Code recht buggy und damit halt aktuell offen wie ein Scheunentor ist. Danach aber bestünde eine echte Chance auf einigermaßen sicheren Code. Das Problem hierbei ist eher ethischer Natur: Auf Hacker eingehen die Cheats für Games entwickeln?
Im sonstigen Softwarebereich, vor allem bei sicherheitskritischen Lücken ist das eigentlich recht verbreitet. Nur nennt man das dann nicht Cheat sondern Exploit.

Für mich denkbares Szenario #3:
Ich frage mich schon seit Generals warum EALA sich so standhaft weigert einfach ACETON als offizielles Anti-Cheat-Tool einzusetzen. Ein einfaches 'No Aceton? No Laddergame!' würde das Problem weitgehend aus der Welt schaffen und EALA hätt satt Ressourcen gespart die sich anderweitig gut einsetzen lassen.

Im Hintergrund der ganzen Sache steht allerdings vor allem Eines:
Warum existieren diese Schnittstellen, an die sich solche Cheats anhängen können, seit min. Generals und zogen sich über ZH und die beiden SuME bis hin zu TW? Hatte da einfach nur jemand die Idee mal eben eine Speicheradresse zu ändern und das dann als Fortschritt gegen Cheatfähigkeit zu preisen ohne mal einen Stresstest zu machen?

Manchmal frage ich mich, ob EALA den Code der den ganzen RTS Games zu Grunde liegt - und der ja prinzipiell immer noch der TD Code sein dürfte - überhaupt versteht, ob da genügend Leute sind die noch von WS kommen und am grundlegenden Code mitgearbeitet haben.
Hat schonmal jemand versucht Fremdcode weiterzuentwickeln? Der weiß was da für Probleme auftreten und wenn man keine Zeit hat dann kann man eigentlich keine Hand dafür ins Feuer legen.