CommonAPI2 Entwicklungsdiskussion, Fragen & Antworten

Mit 1.8.20230808 (gerade hochgeladen) ssollten die Fahrzeuge nun beim Fahrgastwechsel schon das nächste Ziel zeigen...

Auch sollte das leidige Thema mit IsStationValid Geschichte sein.

Wenn man eine spezielle Straßen-Haltestelle in einer Einbahnstraße baut, die eine Fahrspur in der Mitte einer Straße auswählen sollte, kam ein Exception mit IsStationValid. Dies sollte nun behoben sein...

Damit wäre nun auch der Einstieg von Leuten auf einer Zweispurigen Einbahnstaße möglich...

pr.second Fehler können aber weiterhin nicht abgefangen werden....

Das Preview mit der Parcels ist auch drin und man kann auch Regionen auf der Karte auswählen... Und fragt mich nicht, wie Ihr links oder rechts der Straße erkennt. Die Änderungen wirken sich auch erst aus, wenn TPF2 Parcels erstellt. Ein Upgrade einer Straße führt meist nicht zu einem Neubau der Parcels, erst wenn die Straße wirklich breiter ist. Neue Parcels werden am Monatsanfang von Städten erstellt.

Ich tendiere daher weiterhin das Parcel Feature umzustellen... Ne Lösung für die Anzeige von Links&Rechts der Straße hab ich halt nicht...

Hallo,

für alle die sich mit pr.second Fehler herumschlagen (Nochmalig der Hinweis, CommonAPI2 ist daran nicht schuld!) hier eine DLL Datei.

CommonAPI2 1.8.20230808 installieren, dann die DLL Datei in eis_os_commonapi2_1/bin/CommonAPI2Native.dll durch diese hier im Anhang ersetzen.

Damit bekommt Ihr wieder wie früher Meldungen in der Form in der stdout.txt:

CommonAPI2 prevented a game crash:
ERROR: Reading params for mod: "Testing Mod Params", duplicate key "speedScaleTest" found!

Don't double activate mods! Please check for mod updates, if neither helps contact the mod author of "Testing Mod Params".

Alle Mods mit Fehlern/doppelten Installationen korrigieren...

PS: Auch wenn Sie im Spielstand deaktiviert sind, führt das Einlesen der mod.lua Dateien zum einlesen der Parameter. D.h. es genügt nicht, einfach nur den Mod in der Modliste im Spielstand zu deaktivieren.
Auch wenn Ihr meint das es funktioniert, ein Crash für die Zukunft kann weiterhin auftauchen... Also kümmert euch um das Problem...

Please upgrade C++ Runtime via Microsoft Visual C++ Redistributable: (Technical CommonAPI2 requires a recent X64 Runtime)

https://commonapi2.bytetransfe…requirements/requirements

Last point of the troubleshooting section in the handbook:

https://commonapi2.bytetransfer.de/#/troubleshooting

Transport Fever Linux Build 35720

geht mit / works with

buildoverwrite steam_35720_2

Windows 35720 Testing funktioniert nicht mit buildoverwrite

Da UG wohl einen neuen Compilerversion nutzt, ist der Binärcode nun anders.

Inwiefern ich dieses zeitnah reparieren kann, wird erst eine Analyse der exe zeigen. Das was ich aber sehe,

das stabile Fragmente über mehrere Versionen nun auch kaputt gegangen sind, betrübt mich sehr.

Entweder ich finde ne Lösung oder 20230808 für Windows Build 35716 wird die letzte Version werden.

Zitat von oberhausener68

... hat UG was gegen die commonAPI

Nein, auf das Endergebnis eines Compilerdurchgangs hat UG keinen bzw. kaum Einfluss.

Ich hab ja auch mal den Compiler erneuert um neue C++ Features zu nutzen, deswegen brauch es halt auch ne neue C++ Runtime.

Der selbe Build als Linux Binary mit gcc ist ja noch quasi identisch... wobei UG da ja auch auf die Idee kommen kann noch ein Update zu machen.

Ihr müsst mich auch verstehen, bei ner neuen TPF2 exe muss ich wirklich jede Funktion und Struktur wieder finden, das hab ich jetzt schon mehr als 3 mal durch bei TPF2 wo sich der Kern sehr stark geändert hat.

Vulkan Renderer, sol api Schnittstelle, nicht lineares ECS System, anderes Threading beim Laden/Speichern, UI Binding Updates.

Der letzten Punkt hat dazu geführt, das CommonAPI2 sogar in den changelogs drinsteht, obwohl ich versuche da ne Menge Abfragen einzubauen damit UG so wenig Bugreports bekommt.

(Wohlgemerkt, das war der Failback UI Code Pfad, der nur UGs LUA Runtime nutzt, da wird meine DLL nicht geladen)

Hier so mal ein Beispiel Windows, ich muss wissen wenn ein Spiel neu geladen wird um etwaige Zusatzdaten zu reseten.

CGame_LoadGame_Build35024:

48 89 44 24 20 4C 8B CB 4C 8D 44 24 50 48 8D 95 F0 01 00 00 48 8B CF

CGame_LoadGame_Build35126:

48 8D 45 00 48 89 44 24 20 4C 8B CB 4C 8D 44 24 50 48 8D 95 30 03 00 00 48 8B CF

CGame_LoadGame_Build35171:

48 8D 45 F8 48 89 44 24 20 4C 8B CB 4C 8D 44 24 38 48 8D 95 30 03 00 00 48 8B CF

Zwischen Build35024 und Build35126 hat sich viel getan. Zwischen 35126 zu 35171 gibt es kaum Unterschiede...

Türlich könnte ich Urban Games um ne Map Datei ( Funktionsnamen zu Adressen) oder gar Debug Symbole fragen.

Aber ich will Ihre Mitarbeiter nicht in irgendwelche Probleme manövrieren, nachher gibt es stress mit der Chefetage...

Meine Inbox hätte da natürlich trotzdem nix dagegen, nur so am Rande.

Sprich ich tüftele was aus und hab dann ggf. den Buschfunk und frage nach ob ich da total verkehrt liege.

Das hilft mir aber diesmal auch nicht wirklich. Sprich ich muss so eine halbes Gigabyte an Daten wieder finden (Das sind Strukturdaten, Funktionsnamen, Kommentare meinerseits zum Binärcode). Wieder mal

Andere Lösungen haben wir da noch nicht ausklügeln können, versucht hab ich es schon mit UG.

Um die Ecke sind unsere Standorte ja auch nicht...