Long time no see

[CBot]

Ich war grad zufaellig in der Naehe, und dachte, ich schneie mal herein. Schoen zu sehen, dass in den Jahren meiner Absenz so einiges passiert ist. Wie geht's so? Wer von der alten Garde ist noch aktiv? Was gibt's neues?

[Malle]

Hi CBot, schön dich wieder hier zu sehen. Ich denke allen von uns geht es gut. Von der alten Garde sind nur noch wenig übriggeblieben, Rautzebautze hab ich schon ewig nimmer hier gesehen, Mentat, Topper, Scav, Zunder und die anderen ebenso. Es hat sich ne neue Garde etabliert, allen voran Rainer mit seinem Wiki-Mammuth-Projekt und Anonymissimus mit den vielen Code-Löchern, die er gestopft hat. Aber auch andere machen gute Arbeit, Zechelon's 3D Grafiken sind echt cool und auf TrommlBomml's SFML-Implementierung bin ich schon gespannt.

Deine Netzwerk-lib funktioniert einwandfrei. Spielen schon seit einiger Zeit Samstags abends ne Runde BotE im Multiplayer und bisher gabs kaum bis keine Abstürze.

[Anonymissimus]

Hi CBot, hast du vielleicht irgendwie den source code von der lzma lib ? Den brauchen wir mal, um BotE auch mit VS2010+ kompilieren zu können. (Puste ist seit nem Jahr schon oder so zu beschäftigt )

[CBot]

Gruesse @Malle.

Cool. Respekt an alle, die das Projekt weiterpflegen. Sowas ist nicht immer ganz einfach und recht zeitaufwendig. Ausserdem war unsere anfaengliche Arbeit damit nicht umsonst.

Ich hab mal etwas im Wiki geblaettert. Das sieht mir recht umfangreich aus. Sehr eindrucksvoll. 3D-Graphiken im Spiel machen bestimmt auch nochmal was her. Aus eigener Erfahrung weiss ich, wie schwierig das Ausfindigmachen und Fixen von Bugs sein kann, insbesondere wenn der Code heutigen Qualitaetskriterien nicht mehr entspricht. Also vielen Dank an alle fleissigen Mitstreiter.

Freut mich, dass die Netzwerk-Bibliothek noch im Einsatz ist. Dann hat sie ja doch was getaugt. Dabei hatte ich noch so viel mit ihr vor. Da waren aber keine Code-Loecher, oder?

@Anonymissimus: Ich hab bestimmt noch Source Code in meinem Archiv herumliegen. Lass mich mal etwas kramen. Ich will aber nicht zu viel vorweg versprechen.

[CBot]

Success!

Ich hab mir mal das aktuelle Repo von Github gezogen. Mit dem MD5-Hash der lib fand ich tatsaechlich einige Treffer in meinem Archiv, datiert auf 2007-01-03. Und, siehe da, ebenso ein Source-Verzeichnis mit selbem Datum.

Wenn ich das richtig sehe, handelt es sich um die original LZMA Sources (genauer: ein Unterverzeichnis namens "LZMA_Alone"). Ich kann nicht ganz ausschliessen, dass wir hier und da leichte Veraenderungen vorgenommen haben, wenn ueberhaupt. Siehe auch Kommentar in LZMA_BotE.h:

* Die folgenden Funktionen stammen ursprünglich aus LzmaRam und LzmaRamDecode des Projektes
* LZMA_Alone. Der Quellcode wurde übernommen und für unsere Zwecke angepasst. Die notwendigen
* übersetzten Objekte wurden statisch zur Bibliothek BotE_LZMA.lib gelinkt. Sämtliche
* Headerdateien wurden mit ihrer ursprünglichen Ordnerstruktur unverändert übernommen.

Das Paket enthaelt sogar noch die VS-Projekt-Dateien. Die Compiler-Settings sind wohl eher zufaellig. Alles im Unterverzeichnis:

Code: Alles auswählen

C/7zip/Compress/LZMA_Alone/

Die meisten der anderen Unterverzeichnisse sind wahrscheinlich ungenutzt.

Et voilà!

[CBot]

BTW typo in README.md:

For improvement suggestions we are >>am<< very grateful.

Ich wuerde den ganzen Satz gleich austauschen:

We highly appreciate your suggestions for improvement.

Aber das sollte ich wohl eher im Bug Tracker unterbringen. Ich vermute, dass ich mir dafuer allerdings einen Github Account zulegen muesste.

EDIT: I'd change the language in a couple more spots, if I may be so bold.

[Anonymissimus]

lzma: ausgezeichnet, danke
Dann kann ich das demnächst genauso einbinden wie den code der Netzwerklib, der sich mittlerweile auch im Repository befindet und auch verwendet wird. Das heißt, es gibt keine kompilierte Version mehr, die beim Linken von BotE verwendet wird, sondern das muss man vorher selbst machen. Und da danach kann man womöglich endlich mit neueren VS Versionen kompilieren.

Da waren aber keine Code-Loecher, oder?

Um ehrlich zu sein - was Malle oben sagt stimmt, aber ich fürchte, da sind schon welche. Commit 4a0c819c0a442e23e40df3590fd4d267f3fdc7e5 behebt zB einen Fehler, der laut Doku Speicherkorruption verursacht. (delete/delete[]) (Du kannst dir das commit mal anchauen, da ich dabei weitgehend DrMemory vertraut hatte, welches so freundlich war mir das anzuzeigen)
Nun, die NetzwerkLib strotzt leider vor manuellem Speichermanagement, und es ist realistisch anzunehmen, dass sich da noch mehr schwere Fehler befinden.
Man schaue sich zB commit c3fc65e5945c5493f4bfcabe71fc975bef8ed634 an: In dem commit verändere ich die Reihenfolge wann was serialisiert wird. Dieses commit solte keinerlei Auswirkungen haben, (abgesehen davon, dass es alte savegames inkompatibel macht), da unsere Codelogik nicht von der Serialisierungsreihenfolge abhängt (es war zwischendrin mal so, aber das hab ich wieder verbessert). Wenn man dieses commit rückgängig macht, sollten sich zufällige Abstürze beim Laden von Spielständen zeigen, und es gibt keinerlei Möglichkeit festzustellen, woran das liegt. Zurzeit der primäre Grund, warum ich sage, dass BotE unter schwerer Speicherkorruption leidet...
Aber wenn wir den code der Bibliotheken jetzt haben, ist es auch möglich mit solchen tools weitere Fehler zu finden. DrMemory hatte sich wesentlich verbessert, seit ich ihn das letzte Mal ausprobiert hatte.

[Vuto]

Hallo CBot, schön mal wieder einen weiteren der BotE-Founding-Fathers zu sehen.

Aber das sollte ich wohl eher im Bug Tracker unterbringen. Ich vermute, dass ich mir dafuer allerdings einen Github Account zulegen muesste.

Den Github-Bugtracker benutzen wir nicht, dafür muss der Bugbereich im Forum herhalten.

Also entweder im Forum posten oder doch einen Githubaccount erstellen und direkt selbst ändern.

[Anonymissimus]

Rainer oder ich müsste den Schreibzugriff gewähren.
Aber ich glaube, wir können CBot nicht animieren einzusteigen. Das Dateiformat von seinem Archiv ist .tar.gz, wer sowas postet ist sehr wahrscheinlich unter einem Linux System und hat sich von Visual Studio entfernt. (Ich bin da ne große Ausnahme als regelmäßiger OS Wechsler)

[Vuto]

Richtig, auf Schreibzugriff muss man noch warten, mit "direkt" meinte ich "ohne Umweg", nicht "sofort".

Ich benutze Visual Studio auch nur in einer virtuellen Maschine, also an der Linuxnutzung liegt es nicht.
Keine Angst CBot, ich will dich nicht direkt wieder einspannen, ich wollte nur alle Optionen zur Bugkorrektur nennen.

[rainer]

Ich wuerde den ganzen Satz gleich austauschen:

We highly appreciate your suggestions for improvement.

Aber das sollte ich wohl eher im Bug Tracker unterbringen. Ich vermute, dass ich mir dafuer allerdings einen Github Account zulegen muesste.

EDIT: I'd change the language in a couple more spots, if I may be so bold.

den Satz habe ich schonmal reingeschrieben... (EDIT: wobei es hier AUCH um Puste's readme.txt geht, aus dem das ganze genommen ist...aber Puste hat sicher auch nicht gegen "improvement suggestions")

...eigentlich fehlt es nur am Deinem Github-Account, damit Du Schreibzugriff kriegst ....schön, dass Du mal wieder reinschaust

..bist herzlich eingeladen
- BotE mal wieder zu spielen
- vll. auch Multiplayer (Samstags immer so um 18.00 Uhr...Skype Audio oder BotE-interner Chat)
- im Gegensatz zu Vuto würde ich Dich schon einspannen bzw. zumindest Dich nicht daran hindern, wenn Du an BotE etwas arbeiten willst

[CBot]

Da waren aber keine Code-Loecher, oder?

Da fehlt der < > im Zitat. Klar gibt's Bugs; es gibt sicher auch einige Stellen, die ich mir heute nur kopfschuettelnd ansehen wuerde. Aber so ist das immer.

Hab mir die Fixes in der Network-Lib schonmal ein wenig angesehen. So tief steck ich da nicht mehr drin, sehen aber plausibel aus. Man sollte eigentlich eine Belohnung fuer jeden Fix ausgeben, hmm... Auf jeden Fall werd ich die im Auge behalten - es ist immer interessant zu sehen, wo die Fehler lagen.

Zur Serialisierungsreihenfolge: Solange man die Reihenfolge der Deserialisierung ebenfalls anpasst, sollte das okay sein. (Davon ausgehend, dass die Serialisierung nicht nur zufaellig funktioniert.) Sonst kann es natuerlich zu Abstuerzen beim Laden kommen, da hier jegliche Pruefungen fehlen. Ich waere nicht ueberrascht, wenn man durch manipulierte Spielstaende buffer overflows erzeugen koennte... Noch eine Bemerkung: Wenn ich mich recht erinnere, wird dieselbe Serialisierung auch fuer die Netzwerkkommunikation verwendet. D. h., sobald man die Reihenfolge aendert, sind verschiedene Versionen auch im Netzwerk inkompatibel. Ich glaub, wir haben eine Versionsnummer mit drin, die beide Endpunkte zu Beginn aushandeln; damit koennte man die Kommunikation kompatibel halten, ist allerdings ein ganzes Stueck mehr Aufwand im Code. D. h., wenn es keine wirklich dringenden Gruende gibt, wuerde ich die Reihenfolge so beibehalten, wie sie ist.

Ich kann sehr empfehlen, das static code analysis tool staendig zu verwenden. Alles, was hilft Bugs frueher zu erkennen, ist sehr sinnvoll und spart enorm viel Zeit spaeter.

[CBot]

Das Dateiformat von seinem Archiv ist .tar.gz, wer sowas postet ist sehr wahrscheinlich unter einem Linux System und hat sich von Visual Studio entfernt.

Ich nehm alles mit einer vernuenftigen bash. Keine Ahnung, warum Windows nicht von Haus aus mit einer benutzbaren Standard-Shell kommt. Mein "grosser Rechner" (ja, sowas gibt's noch) hat tatsaechlich Windows.

Die alten Visual Studios haben fuer mich nie wirklich funktioniert, insbesondere die Refactoring-Funktionen, die beim Sauberhalten von Code eine sehr grosse Rolle spielen. Von daher hab ich mich von VS sehr weit entfernt.

Keine Angst CBot, ich will dich nicht direkt wieder einspannen, ich wollte nur alle Optionen zur Bugkorrektur nennen.

..bist herzlich eingeladen
- BotE mal wieder zu spielen
- vll. auch Multiplayer (Samstags immer so um 18.00 Uhr...Skype Audio oder BotE-interner Chat)
- im Gegensatz zu Vuto würde ich Dich schon einspannen bzw. zumindest Dich nicht daran hindern, wenn Du an BotE etwas arbeiten willst

Danke fuer die Einladung. Allerdings bin ich absolut unfit, was das Spiel selbst angeht. Ich hab mich immer auf die Programm-Infrastruktur konzentriert, wie Netzwerk, effiziente Darstellung, diverse Spielalgorithmen, etc. Ausserdem lebe ich in den USA (Westkueste), von daher ist meine Zeitzone besonders inkompatibel mit Deutschland (sowie mein Tastatur-Layout - haeufiges Wechseln hat mich nur verrueckt gemacht ).

Naturgemaess ist meine Zeit auch relativ knapp, und ich bin total aus C/C++ raus. Von daher werd ich wohl nicht direkt am Code arbeiten; allerdings will ich das auch nicht grundsaetzlich ausschliessen. Ich kann aber beratend zur Seite stehen, sofern es die Zeit zulaesst: im Bereich Softwareentwicklung hab ich einiges an Erfahrung (Senior Software/Java Architect), und das Englische (genauer: Amerikanische) geht mir auch leichter von der Hand.

[Anonymissimus]

Zur Serialisierungsreihenfolge: Solange man die Reihenfolge der Deserialisierung ebenfalls anpasst, sollte das okay sein. (Davon ausgehend, dass die Serialisierung nicht nur zufaellig funktioniert.) Sonst kann es natuerlich zu Abstuerzen beim Laden kommen, da hier jegliche Pruefungen fehlen. Ich waere nicht ueberrascht, wenn man durch manipulierte Spielstaende buffer overflows erzeugen koennte... Noch eine Bemerkung: Wenn ich mich recht erinnere, wird dieselbe Serialisierung auch fuer die Netzwerkkommunikation verwendet.

Richtig, aber darum gehts nicht. Die Reihenfolge war zwischendrin wichtig, da ich Zeiger auf die Rassen in den Sytemen hatte; da die Rassen bei jeder Serialisierung neu allokiert wurden, hätte ich dann hängende Zeiger oder doch zumindest veraltete Objekte gehabt; und hatte deshalb den RaceController vor den Systemen (de)serialisiert. Aber die Rassenobjekte werden mittlerweile nur einmal allokiert zu Beginn, da konnte ichs wieder umstellen. Diese hin- und zurück sollte eben nix ausmachen, aber das tut es. Und die Abstürze treten zufällig auf, also nicht mit nem bestimmten Speicherstand immer, wie das der Fall sein sollte, wenn dieser manipuliert wurde, oder die Deserialisierung nicht zur Serialisierung passt. Da sind mittlerweile so viele assertions drin, dass es dann sicher irgendwo abstürzt, weil ein Wert unzulässig wird.

Ich kann sehr empfehlen, das static code analysis tool staendig zu verwenden. Alles, was hilft Bugs frueher zu erkennen, ist sehr sinnvoll und spart enorm viel Zeit spaeter.

Wird sind fast cppcheck-clean, aber leider scheint's auch nicht viel gebracht zu haben...

[rainer]

ich bin zwar nicht auf dem aktuellsten Stand -sondern mit Paul Samstags immer noch DevBotE2014-01-22-339d25c33b7ace37dba5b1e19b3fe37a9d5466e5.exe-,
...aber Abstürze sind sehr sehr selten bzw. eigentlich gleich NULL - nur um es mal zu sagen
-> insofern ist es für mich wenig schlimm, wenn unter der Motorhaube etwas nicht tausendprozentig sauber läuft.

Danke hier nochmal an Anonymissimus , der uns in ? 2012 ? sehr half, um BotE die vorübergehend verlorene Stabilität (=regelmäßige Abstürze) zurückzugeben