Hell0,
Zuerst möchte ich mit einer Nachricht direkt für alle Flamer starten: ICH HABE NIEMALS TO VERLASSEN. Ich habe lediglich aufgehört das TO-Forum zu besuchen.
Für die Ignoranten unter euch, die noch behaupten "du hast uns nie eine Warnung gegeben", die sollten meinen letzten Beitrag im ACC Forum lesen, worin ich schrieb, dass wenn das geflame gegen ESE, CB, TOST und ACC nicht aufhört, ich die TO-Community verlassen werde. Die Flamereien haben nicht aufgehört, so ...
Ok, ich habe mein Versprechen gebrochen und habe die Community nicht verlassen, sondern habe mich in den Hintergrund zurück gezogen, könnte man sagen.
Eine weiter Frage, die jedem normalen Verstand entspringen könnte ist, was ich in meiner 'Abwesenheit' getan habe: Prüfungen, Jobsuche und ESE.
Unglücklicherweise musste ich mich dann zwischen ESE und TO entscheiden. ESE war meine Wahl, da Coly und BugBunny zu dem Zeitpunkt wenig Zeit hatten und MadMax noch nicht im Team war, dachte ich mir, dass ich mir damit weiterhelfe.
Nachdem MadMax ins Team kam, zusammen mit Coly, kam wieder etwas mehr Coderaktivität in ESE und Bugfixing, da BugBunny inactiv wurde. Später kam ich dazu und übernahm einen größeren teil vom ESE-Client, einschließlich den TOST-Teil. TO 3.5.5.wurde für unbestimmte Zeit eingestellt, was nicht bedeutet, dass es nie erscheinen wird. Es ist nur so, dass ESE im Moment wichtiger ist. An alle, die mich während der 'Abwesenheit' unterstützt haben ein Danke und für die, die mich angeflamet haben ... denkt euch was ich euch zu sagen habe
Als nächstes möchte ich mit einigen Worten zu den bisherigen ESE-News, sowie dem ESE-Releasedatum fortfahren.
Viele Menschen bemängeln (im IRC, Forum oder anderen Medien), wie es sein kann, dass in fast jeder ESE News "wir fanden einige neue Bugs" stehen kann. Viele von euch wundern sich, wie ein 3+ Jahre altes Projekt immer noch Bugs haben kann - immer noch nicht released ist und nichts Konkretes außer ein paar Screenshoots vorweisen kann.
An dieser Stelle sollte man anfangen nachzudenken: Wann ist es besser Bugs zu finden? Während internen Releases und internen Betatests oder nach einem Public Release. Natürlich wird es immer Bugs geben, egal wie gut wir suchen, aber die Wahrheit ist, dass wir die größten und kritische Bugs gefixt haben (von false positives über Crashs hinweg) und die sind wichtiger als irgendwelche Tippfehler oder Bugs die nur einmal bei Vollmond passieren.
Das bringt mich zum Releasedatum: Vor 4 Monaten hatte ich eine schwere Entscheidung zu treffen: Release der Beta, die eigentlich eine Alpha war im Vergleich zu heute, oder noch mehr Bugs fixen und ein besseres Endprodukt anbieten können. Die Wahl fiel auf das Letztere. Es gab einige Checks, die gar nicht funktionierten, nur manchmal funktionierten, schlecht funktionierten, laggy waren, ungenau arbeiteten oder einfach unnötig waren und nur Ressourcen gefressen haben.
Natürlich ist die erste Frage, wie kann so was bislang übersehen geworden sein. Naja, wenn ein stück beschädigter Code eine Prüfroutine von der Arbeit abhält, kann man sich das so vorstellen, dass eine folgende Routinen gar nicht erst startet, womit es unmöglich war Bugs in der zweiten Routine zu finden. Ich habe einen Haufen an Bugs gefundne und gefixt in den letzten 4 Monaten, sowie das einfügen von neueren und besseren Checks.
Die zweite Frage dürfte dann sein, warum braucht man dazu mehr als 3 Jahre? Das ist einfach zu beantworten. ESE ist NICHT TOST. Es ist kein kleines Tool, welches nur 2-3 Klassen prüft, unbekannte Actors checkt und zu guter letzt für ein falsches Render Setting kickt. ESE ist viel weiter entwickelt und wir müssen sicherstellen, dass der U-Script Teil, der C++ Teil , der API Teil, sowie alles als Ganzes, das Erstellen des Frameworks sowie Funktionen auf jeden Umstand vorbereitet sind. Als Beispiel: Vor einem Monat, ein eigentlich bugfreier Algorithmus hatte ein Problem auf meinem System. Coly stellte später fest, dass das Problem durch den Einfluss verschiedener API-calls entstand, die später gefixt wurden, womit keine false positives mehr auftreten sollten (hoffen wir zumindest). Des Weiteren sollte man beim ersten Blick auf UScript bedenken, dass U-Script keinen Zugriff auf C++ oder API Funktionen hat, bedenke, dass selbst mit C++ es nahezu unmöglich ist auf U-Script Klassen zuzugreifen. Deswegen arbeiten wir immer wieder an Ideen bezüglich des Problems. Man sollte immer bedenken, dass alles bypassed werden kann, aber ich verspreche, dass wir es den Cheatern nicht einfach machen werden ESE zu umgehen.
Die letzte Frage, die sich wohl einige stellen ist das "wann?". "Wann" ist noch kein festgelegtes Datum bis jetzt, ABER wir hoffen, dass es noch vor Weihnachten dieses Jahr passieren wird.
Am 22.09.2007 berichteten wir über einen geplanten internen Betatest, welcher für den 23.09.2007 geplant war. Der Betatest wurde verschoben auf den 01.10.2007, da während eines 'Vortests' der Client bei jedem Mapswitch crashte, was gefixt werden musste.
Als der Test endlich abgehalten erden konnte, wurden einige für eine 'false positive' Cheaterkennung gekickt. Dieser Bug wurde aber auch schon behoben. Ein anderes Problem welchem wir kürzlich gegenüber standen war, dass mein PC nicht richtig funktionierte. Angefangen bei Festplatten die sich überhitzten, gab nun mein CPU-Kühler die Geister auf. Währendessen ich versuchte die Probleme zu lösen, fand ich eine Möglichkeit die Probleme temporär zu lösen (danke an einigen Freunde), damit ich weitere Bugs in ESE beheben kann, was dazu führt, dass der nächste große Betatest erst am nächsten Wochenende sein wird.
Zum Abschluss möchte ich gerne noch einige Sachen anmerken. Einige von euch bemerkten TOST v4.4.
Bevor einige für einen Download-Link fragen, TOST44 ist noch in arbeit, da letzte Woche Kagome einen Bug bei der Demoaufnahme und MadMax einen Fehler in einigen INIs von unseren Betatester fand, muss beides auch noch hardcode gefixt werden. Des Weiteren ist diese Version nicht für ein jetziges Release vorgesehen. Diese TOSTVersion ist exclusiv für ESE erstellt worden und wird nicht mit anderen Anticheats zusammenarbeiten. ( wie z.B. TOSTProtect, XProtect, TO Protect, ACP oder B][O-Protect)
Zusammenfassend: Wir hoffen die erste Version vor Weihnachten zu releasen, zusammen mit TOST4400. Seid gespannt auf weitere Erfolgsberichte.
more
0 
