17.04.2021, 11:23
(Dieser Beitrag wurde zuletzt bearbeitet: 17.04.2021, 13:08 von siebenstreich.)
Nach wie vor bin ich immer wieder mal an meinem BrightEyes-Fork zu Gange. Meine Hauptmotivation ist das Reparieren von Bugs (von denen es leider furchtbar viele gibt). Gerne hätte ich auch die ganzen Bugfixes aus dem Patch von NRS mit drin. Ich stelle mir vor, nach Lust und Laune Listen von bekannten Bugs durchzugehen und zu reparieren; dabei ergibt sich dann auch gerne, dass der umliegende Code verstanden werden muss, den ich dann gleich kommentieren kann und Variablen umbenennen (falls noch nicht geschehen).
Teilweise betreffen die Bugs ja auch die Daten in der SCHICK.DAT. Momentan werden Daten "on the fly" im Quellcode repariert, z.B. diese Reparatur eines Rechtschreibfehlers.
Denkbar wäre es aber auch, sich einen Patch-Mechanismus für die SCHICK.DAT zu überlegen und das ganze als Diff-Dateien in BrightEyes zu verwalten, siehe z.B. diesen Beitrag und die darauf folgenden. Ich möchte hier also eine Diskussion darüber anstoßen, wie das ganze am bsten in BrightEyes umgesetzt werden sollte und was es dabei zu beachten gilt, damit man es hoffentlich gleich von Anfang an "richtig" macht
Persönlich tendiere ich zur gepatchten SCHICK.DAT, weil es sich sauberer anfühlt. Aber der Mechanismus muss erstmal aufgesetzt werden. Er dürfte grob aus den folgenden Teilen bestehen dürfte:
Über die folgenden Punkte muss man sich wohl auch Gedanken machen:
@gaor: Nachdem Henne ja nicht mehr mitmacht, geht meine Hoffnung zuerst in deine Richtung. Du hast ja auch das schlaue Tool schick-data-gui geschrieben, das ja auch die SCHICK.DAT ausliest.
Teilweise betreffen die Bugs ja auch die Daten in der SCHICK.DAT. Momentan werden Daten "on the fly" im Quellcode repariert, z.B. diese Reparatur eines Rechtschreibfehlers.
Denkbar wäre es aber auch, sich einen Patch-Mechanismus für die SCHICK.DAT zu überlegen und das ganze als Diff-Dateien in BrightEyes zu verwalten, siehe z.B. diesen Beitrag und die darauf folgenden. Ich möchte hier also eine Diskussion darüber anstoßen, wie das ganze am bsten in BrightEyes umgesetzt werden sollte und was es dabei zu beachten gilt, damit man es hoffentlich gleich von Anfang an "richtig" macht
Persönlich tendiere ich zur gepatchten SCHICK.DAT, weil es sich sauberer anfühlt. Aber der Mechanismus muss erstmal aufgesetzt werden. Er dürfte grob aus den folgenden Teilen bestehen dürfte:
- Entpacken und Zerlegen der SCHICK.DAT
- Anwenden der Patches auf die Einzelteile
- anschließendes Packen und Zusammenbauen zu der gepatchten SCHICK.DAT
Über die folgenden Punkte muss man sich wohl auch Gedanken machen:
- Das Patchen muss abhängig von Präprozessor-Flags gestaltet sein, so dass die angewendeten Patches passend zu den im Quellcode aktivierten Modifikationen vorgenommen werden.
- Momentan wird ja auf Textblöcke der SCHICK.DAT durch Befehle der Art get_tx(<nummer>) zugegriffen. Wenn das Reparieren eines Bugs das Erstellen weiterer Textblöcke erforderlich macht, dann verschiebt sich evtl. die <nummer>. Wie geht man damit am besten um? Fügt man die neuen Textblöcke immer hinten an, damit sich die Nummern davor nicht verschieben? (Aber was macht man, wenn durch Präprozessor-Flags nur eine Auswahl der neuen Textblöcke aktiviert wurde?) Gibt es eine Möglichkeit, hier eine vernünftige Zwischenebene einzufügen? Letztlich sind die <nummer>n ja auch wieder nur "magic numbers", die idR besser durch Konstanten-Bezeichner ersetzt werden sollten.
@gaor: Nachdem Henne ja nicht mehr mitmacht, geht meine Hoffnung zuerst in deine Richtung. Du hast ja auch das schlaue Tool schick-data-gui geschrieben, das ja auch die SCHICK.DAT ausliest.