Was aber jetzt gar nicht mehr funktioniert, ist die mit BwC konstruierte Kreuzung. Da kann ich den zweiten Node nicht mehr markieren. Was spricht dagegen, den Kollisionscheck beim Proposal generell abzuschalten, statt die Markierung zu sperren? Oder ist sie gar nicht gesperrt, und es ist nur ein gewöhnlicher Bug?
Es ist kein Code drin, der etwas abschaltet, umschaltet oder verhindert. Ist das die Testkreuzung in einem Testspielstand, den du mir schon geschickt hast?
Beide Umbauten im Code werden via nodedata.rebuildNode(pos, callback, ignoreCollision) abgewickelt.
In Zeile 854, wird nd.rebuildNode(statedata.nodeData.pos, fn, true) aufgerufen, d.h. ich verstehe nicht warum du mir immer wieder sagst, ich würde etwas verhindern?
Ggf. ist dein BaseNode und NodeData nicht mehr zueinander ausgerichtet. Blaue Markierung und Rote Markierung liegen nicht mehr aufeinander?
Gerade wegen deinen Beschwerden hab ich im Code die NodeDaten Umkreissuche von 3m auf 1m reduziert...
Der Button "Wähle ein BaseNode" ist selektiv Blau, sprich nur wenn du da drauf klicken sollst. Wenn er nicht mehr genutzt werden soll, ist er nicht mehr hervorgehoben.
Steht aber auch im Hilfetext, das man via rechter Maustaste wieder zurückkehren soll.
Ggf in Zukunft werden bestimmte Einstellungen nicht direkt gespeichert/umgesetzt.
Wenn du da auf "Wähle ein BaseNode" klickst, machst halt ein reset ohne etwas zu Speichern.
Verbindungen via transportModes selektiv abschalten geht nicht, nochmalig, das was ich dir auch schon per Nachricht geschrieben habe:
TPF2 will die Verbindungen errechnen, ruft eine Funktion auf, die eine Liste mit Einträgen aus:
{ QuellstraßeIndex, QuellLaneIdx, ZielStraßemIndex, ZielLaneIdx} erstellt. Da gibt es keine transportModes.
Genau das Ergebnis dieser Funktion manipuliere ich. Etwaige andere Änderungen bedürften ein neu schreiben von 7 Funktionen, da diese unter Linux alle zu einer optimiert wurden. Dafür müsste ich dann auch noch Menge mehr wissen anhäufen wie lanes, transportModes in das TransportNetworkSystem gespeichert werden. X Winkelberechnungen und noch ne Menge andere Sachen.
Bitte sei mir nicht Böse, aber das ist kein Vergleich zu irgendwelchen Änderungen von Lua oder con Dateien.
Da kannst im Binärcode nicht einfach was ändern. Da TPF2 regen Gebrauch von Exceptions macht, gibt es nur bestimmte stellen im Code, x86_64 long jmps, calls wo Du wirklich neuen Code aufrufen kannst. Wenn da Stackmanipulationen wie push/pop drin sind oder du eine Grenze eines try / catch Blocks überschreitet wird dein Spiel definitiv abstürzen.
Auch wenn ich etwas in LUA errechnen kann, heißt das nicht nicht das ich da Zugriff genau an der Stelle habe, wo ich Code im Binärcode einfüge. Das kann wegen Unwissenheit von Strukturen/Speicherlayout sein oder weil die Funktion die Daten einfach nicht geliefert bekommt, da sie nur einen Teilaspekt abdeckt.
Mit der Einführung der Änderung der Nutzung eines Vektors, hatte ich mal Debug Ausgaben eingebaut.
Bei einer Kreuzungsänderungen via api.cmd gab es gleichzeitig zwei nebenläufige Threads, noch nicht mal diese hatten die selben Straßen zu StraßenIndex Mapping.
Also nochmalig, ich versuche viel umzusetzen und auch alle Bugs auszumerzen.
Es gibt in meinem Code nie stellen wo ich aktiv etwas verhindere ohne Grund.
Wenn ein Code Teil etwas aktiv verhindert, wird der Grund meisten sein, dass das Spiel abstürzt oder das Gameplay sehr stark negativ beeinflusst.
Beispiel, der NodeWindow Code lässt es nicht zu das du zwei Lanes so verbindest, das nachher Verkehr in die falsche Richtung einen Deadlock verursachen. Das ist der abgeschaltete Advance Modus...
Warum die Kreuzung sich also nicht mehr umbauen lässt, keine Ahnung.
Es kann kann halt sein das die Änderung der Behandlung der Kurven dieses Problem auslösen... ich danke dir für deine Tests, wenn etwas nicht mehr läuft, müssen wir halt den Grund herausfinden...