Hallo,

Nach der Implementierung des trafficlight-Patches (r24357) von Hand, ist die Compilation fehlerfrei durchgelaufen.

Wenn ich aber auf "Einstellungen" klicke erscheint:

Assertion failed at line 951 of r27508/src/settings_gui.cpp: this->setting!= NULL

Kann mir jemand eventuell sagen woran dieser fehler liegen könnte, oder in welche Richtung ich suchen muss?
Dieser eintrag wurde nicht vom Patch vorgenommen.

Da hast du wohl "von Hand" irgendwas vergessen/falsch gemacht.

Da wirst du wohl mehr Details liefern müssen.

Ich habe diese Version von trafficlights r24357 in die r27508 eingebaut.

Das Spiel funktioniert auch mit Ampel, nur wenn ich bei Einstellungen auf "trafficlight" drücke kommt der Absturz.

Alle Abschnitte des Patches konnte ich wie angegeben einfügen, Problem macht nur die "settings_gui.cpp", hier wurden globale Script-Änderungen gemacht die nicht mehr zum Patch passen, ich habe das wie in Bild 1 gelöst, dass ist die einzige änderung.

Die änderung von trafficlights in traffic_lights hat nichts gebracht.

Sind die einzelteile des MinGW CompilierungsWiki noch aktuell?

und wie hast du diese Zeile eingefügt?

Hallo Eddi,

diese zwei Zeilen habe ich rausgenommen, hier kam beim Compilieren ständig eine fehlermeldung.
Ich bekomme diese zwei Zeilen nicht vernünftig in die settings_gui.cpp

Ich weiss auch nicht ob oder wie man diese Umschreiben kann, so das es passt.

Also ich bin mir ziemlich sicher, daß genau diese Unterlassung der Grund für deinen Fehler ist.

ja, dass wird es sein, nur weiss ich nicht wie ich die anscheinend 2 wichtigen Zeilen integrieren kann.

Das Spiel funktioniert ja, auch die Einstellungen funktionieren alle, ausser der klick auf "trafficlight", also wird es wohl an diesen beiden Zeilen scheitern, denn die gehören irgendwo in die settings_gui mit hinein.

Nimm doch diese fehlschlagende Assertion raus. Dann knallt es vielleicht an anderer Stelle wegen des Nullpointers, oder auch nicht.

Na das ist ja wohl die dämlichste Idee, die ich hier jemals gehört habe...

(14.02.2016, 20:12)Streckenläufer schrieb: ja, dass wird es sein, nur weiss ich nicht wie ich die anscheinend 2 wichtigen Zeilen integrieren kann.

versuch doch mal, das Commit zu verstehen, das die Struktur von settings_gui.cpp geändert hat.

Nachtrag: r26622

(14.02.2016, 17:57)Eddi schrieb: und wie hast du diese Zeile eingefügt?

Code:

static SettingEntry _settings_construction[] = { SettingEntry(&_settings_construction_signals_page, STR_CONFIG_SETTING_CONSTRUCTION_SIGNALS), + SettingEntry(&_settings_construction_trafficlights_page, STR_CONFIG_SETTING_CONSTRUCTION_TRAFFIC_LIGHTS), SettingEntry("construction.build_on_slopes"), SettingEntry("construction.autoslope"), SettingEntry("construction.extra_dynamite"),

mal versucht.... settings_construction_traffic_lights_page, STR_CONFIG_SETTING_CONSTRUCTION_TRAFFIC_LIGHTS) anstatt
settings_construction_trafficlights_page, STR_CONFIG_SETTING_CONSTRUCTION_TRAFFIC_LIGHTS)
??

klingt evtl. banal...aber... mal versuchen.

Eddi, ich versuche zu verstehen , der Nachtrag: r26622 ist eine große Hilfe, muss aber zwischendurch noch Arbeiten

Timeflyer, dass geht so nicht, habe ich rauf und runter probiert. Ich lese erst einmal den Commit in ruhe durch und versuche zu verstehen. Kann ein biss'l dauern.

Hallo

(15.02.2016, 14:36)Streckenläufer schrieb: der Nachtrag: r26622 ist eine große Hilfe, muss aber zwischendurch noch Arbeiten

Schaue dir besonders die veränderte Struktur der Menüeinträge an. Die ist sogar auf doppelte Weise anders. Anders als die Struktur, die dafür entfernt wurde, aber auch anders als die, die im Patch verwendet wird.

Tschö, Auge

(14.02.2016, 23:52)Eddi schrieb: Na das ist ja wohl die dämlichste Idee, die ich hier jemals gehört habe...

Da scheint aber jemand besonders starke Grundprinzipien zu haben.

Diese Beschreibung mit Links hat mir schon weitergeholfen um festzustellen, dass es nicht an der Settings_gui.cpp liegt.

Irgendwo ist noch ein Teufelchen drin. Habe mich schon mit Rujin in verbindung gesetzt, warte noch auf Antwort, solange werde ich weiter probieren.

Was auch sein könnte: in settings.ini wurde irgendwann noch ein Eintrag für die Beschreibung hinzugefügt, und die Struktur der Einträge für die Auswahl der Einstellung wurde geändert.

(16.02.2016, 15:43)RK schrieb:

(14.02.2016, 23:52)Eddi schrieb: Na das ist ja wohl die dämlichste Idee, die ich hier jemals gehört habe...

Da scheint aber jemand besonders starke Grundprinzipien zu haben.

Ne, da hat der Eddi vollkommen Recht; das hat nix mit Prinzipien zu tun sondern mit zielgerichteten Arbeiten. Die Assertions sind an den Stellen, wo sie sind, weil nachfolgender Code zwingend die da abgefragte Bedingung voraussetzt. Klar, kann man sie rausnehmen und dann schauen wo's kracht. Aber es wird krachen, 100%ig, die Frage ist nur wie und wo. Nur wird man dann nicht mehr einfach nachvollziehen können warum, weil man die Überprüfung an der Stelle, wo es klar ist, rausgenommen hat.

Das ist als wenn Du beim Auto die leuchtenden Lämpchen für Öldruck und Kühlwasser ausschaltest und behauptest, der Fehler sei behoben, weil die Lämpchen nicht mehr leuchten...

Da muss man nun keine Autovergleiche heranziehen. Man kann mir ruhig vertrauen, denn ich bin Wissenschaftler.
Wer garantiert denn dass diese Variable benötigt wird? Vielleicht stürzt es dann nur in einem Untermenü ab, dass man nicht benötigt und dann kann man damit leben.
Wer alles nur als Gott-gegeben betrachtet und sich kein Trial&Error traut, der wird nie ein guter Entwickler, Jungs.

(17.02.2016, 11:02)RK schrieb: Wer alles nur als Gott-gegeben betrachtet

damit unterstellst du, daß sich weder der Entwickler, der diese Assertion da reingeschrieben hat, noch ich als ich die Antwort geschrieben hab, sich Gedanken gemacht haben, ob das da nu wirklich nötig ist, oder auch durch einen halbherzigen Hack umgangen werden kann.

Zitat:und sich kein Trial&Error traut, der wird nie ein guter Entwickler, Jungs.

Das ist nu wirklich kompletter Unsinn. Klar hilft ein gewisser Spieltrieb beim Verstehen von Problemen, aber zu nem "guten" Entwickler gehört auch, daß man sich ernsthafte Gedanken macht, bevor man was tut.

Man muss erstmal hinterfragen was der Zweck dieser Anweisung ist. Der Entwickler versucht damit an einer gewissen Stelle einen Nullzeiger auszuschließen und hofft dadurch Fehler etwas früher zu entdecken. Ob das nun einen relevanten Nutzen kommt auf den Fall an. Da gibt es heutzutage wohl aber coolere Konzepte (Stichwort für Neugierige: Option type).
Jedenfalls ist die Intention des Entwicklers die Codequalität für den Endnutzer hoch zu halten. Aber auf der Schiene bewegen wir uns ja gar nicht. Der Captain will nur ein Programm für sich selbst kompilieren und das schlimmste was beim experimentieren schief gehen kann ist, dass das Programm abstürzt.

habe heute meinen Trunk von Revision r27506 auf r27508 erneuert, wollte neu Compilieren und erhalte folgende Fehler ohne eingegriffen zu haben (siehe Bild). Der Trunk 27506 hat einwandfrei funktioniert und ich konnte damit spielen.

Habe mir die r27506 noch einmal gezogen und fehlerfrei Compiliert, sowie ich die Revision auf r27508 steigere und Compiliere erhalte ich gleiche fehler.

Die Liste ist noch länger und betrifft die settings.h aus /objs