Wir begrüßen euch in der Fan-Community zu den Spielen Transport Fever und Train Fever, den Wirtschaftssimulatoren von Urban Games. Die Community steht euch kostenlos zur Verfügung damit ihr euch über das Spiel austauschen und informieren könnt. Wir pflegen hier einen freundlichen und sachlichen Umgang untereinander und unser Team steht euch in allen Fragen gerne beiseite.
Die Registrierung und Nutzung ist selbstverständlich kostenlos.
Wir wünschen euch viel Spaß und hoffen auf rege Beteiligung.
Das Team der Transport-Fever Community
stdout.txt nach dem laden eines Spielstands hochladen, und oder nach dem Laden unten den API Knopf drücken "Ladefehler" aufrufen, dann hast du eine UI mit Fehlern... (Und ja, TPF2 hat da ein paar Fehler ab Werk)
Wenn da was mit 100 am Ende steht, wird TPF2 bei Nutzung des Models in 35720 und älter crashen. Es soll wohl in der testing Version nun nicht mehr crashen...
CommonAPI2 ist leider nicht im Spielstand aktiv. Lade mal mit checkMods aktiv und aktivierten CommonAPI2 im Spielstand. Das sollte ggf. allgemeine Fehler in mdl Dateien aufdecken.
Alternativ versuch es halt mit der testing version...
Ggf. hast du dein TPF2 auf eine neue Testing Version geupdated?
Die neuen Testing Versionen haben ein paar mehr checks drin, damit TPF2 eben nicht mehr crasht.
CommonAPI2 ändert da eigentlich nichts. checkMods sollte bei fehlerhaften Ids aber etwas in der stdout.txt hinterlassen:
"CommonAPI2 CheckModels ERROR: " "seatProvider.seats" bzw. "bigger then last mesh id in lod"
Was sein kann, das ein Seatprovider fehlerhaft ist. Das sollte aber dann bei mehr Nutzern Probleme geben.
Wenn ich mir die Dateien anschaue. haben die in der Webdisk auch capacity = 150, darin wird es wohl nicht liegen.
Werden denn die Fahrzeuge bzw. das Fahrzeug nun auch voll ausgelastet?
Nochmals es wäre hilfreich das du uns das Mod und Bus nennst und die Anzahl der Busse zum testen reduzierst bzw. nur jeweils eine Art von Bus nutzt-
Damit sollte dann ganz sicher crashen wenn die Busse "volllaufen" um den Fehler genau einzugrenzen. (Einen Test Spielstand musst du ja nicht weiter nutzen)
Vielleicht hat der Busmod schon ein Update erhalten? Auch dann ist die Info hilfreich
Nicht nur du willst Hilfe, alle anderen Nutzer auch. Sprich das mindeste was du leisten musst ist ggf. ein paar Minuten Zeit investieren um Fehler genauer einzugrenzen, nicht für dich sondern eben auch für andere Spieler.
Antworten wie: "Funktioniert nun" sind extrem egoistisch, denk mal an deine Mitmenschen die ggf. auch so ein Problem haben.
Und das gilt für alle Nutzer hier im Forum, das Forum lebt von gegenseitiger Hilfestellung!
PS: Und nein mit der hier gezeigten Infos kann ich nicht herausfinden welches Fahrzeug bzw. Busmodell genutzt wird... außerdem müsste ich dann wieder Zeit investieren um das einzugrenzen...
Das steht modelIdCar = -1, sprich Frau Schwarz hat nach der Info gar kein Auto...
Schau mal was das für ein Fahrzeug da bei Entity Id 190875 sein könnte und tausche das mal aus, bzw. lass es voll laufen durch Reduzierung von anderen Fahrzeugen auf der Linie.
Ich würde sagen, da ist ein Fahrzeug mit zu wenig Sitzen unterwegs: vehiclePartInfo.seats.size() und sobald du nahe an der Kapazitätsgrenze kommst gibt es dann einen Crash wenn da ein Sim sein Plätzchen sucht...
Warum testen, du willst ja in Zukunft und auch für andere das Problem lösen...
Tramgleise sind in Straßen nichts anderes als Texturen, die Modell bzw. Erstellung der Dreiecke läuft automatisch im Binärcode ab. Das ist aber alles flache Geometrie. 3D Effekte erhältst du via Normalmap und co...
Ich sehe natürlich keinen großen Sinn drin irgendwelche Features zu bauen oder komplettieren die nachher sowieso keiner Nutzen wird.
Frag mich nun seit gestern warum ich mir die ganze Zeit mit Winkelberechnungen, Nodes und co "verschwendet" habe für grenzwertigen Straßenbau via Build on Collision, wenn mir nun gesagt wird es wird sowieso nicht genutzt. Ich für meinen Teil nutze keine schmalen Straßen.
Und bis jetzt hab ich euch immer mit neuen Windows Builds für die CommonAPI2 versorgt für UGs Testversionen und das in der Regel auch immer sehr zeitnah.
Sprich ich werde mir das ganze nochmal sehr stark überdenken wie viel Zeit ich da wirklich noch investieren möchte.
Mir reichen auch sehr spezielle Features um meine Stadtbastelwut auszulasten und die UI muss auch nicht schön sein oder mit Hilfetexte vollgestopft werden. Das macht nur Arbeit.
Um zurück zum Thema zu kommen:
Ja, ich würde an manchen Stellen es begrüßen den Tragseil und Co Bau selbst zu übernehmen oder zu beeinflussen.
Mir würde da ein Oberleitungswerkzeug vorschweben. Wenn mir ein Mast nicht gefällt kann ich den dann entfernen, bzw. an einer neuen Stelle einen neuen Hinstellen.
Auch die Tragseilkonstruktion würde ich gerne beeinflussen können. Da ich TPF2 als Spiel ansehe, will ich halt nicht wie bei eine Modellbahn, jeden einzelnen Mast selber kleben 
Und mit meinem bescheidenen Wissen der interne sollte so etwas sogar möglich sein zu speichern.
Das größte Problem das ich sehe ist der Konstruktions und Straßenbauer. Technisch muss jede Änderungen durch ein Proposal, sprich eine Anweisung was entfernt und neu gebaut wird.
Wenn du eine Busspur auf eine Straße aktivierst, wird da nicht einfach nur ein Bit geändert, nein die ganze Straße inkl. Nebenstraßen wird neu gebaut.
TPF2 hat da kein Platz für Extradaten und es ist an vielen stellen gar nicht vorgesehen.
CommonAPI2 umgeht das komplett mit eine eigenen internen Struktur.
Das kann man sich eher so vorstellen, das man an stellen der Karte die physikalischen Gesetze ändert und so mit ein anderes Ergebnis beim Bauen von Sachen herauskommt.
Hmm, Oberleitung komplett verschwinden, das hatte ich mal als Fehler in der CommonAPi2 in der Entwicklung, und dann Oberleitung auch bei nicht elektrifizierten Tramgleisen. 
Ich hab mir als Ziel für 2024 gesetzt, zu schauen das ich Normalspur und 1000mm gleichzeitig in CommonAPI2 Straßen rein bekomme.
Meine Idee wäre ja Straßen, Tramgleise bzw. Texturen und Oberleitungen zu trennen und die via Nodewerkzeug bzw. Regionswerkzeug änderbar zu machen.
Das Endziel ist, jede Spur einer Straße individuell bearbeitbar zu machen.Tram, Busspur... aber das ist so ein Todolist Eintrag der schon seit Jahren drin ist.
Ob ich da irgendwann hin komme außerdem wenn ich Fertig bin hat UG wohl schon TPF3 am Start...
Du hat selber irgendwann mal deine Version auf b35716 gesetzt in Steam (in deinem Screenshot) Dort musst du bei Betateilnahme im Dropdown (rechts oben im Fenster) eine leere Zeile / keine/ stabil bzw. testing auswählen, wo zurzeit "b35716 - Build 35716" steht.
Du musst das aktiv selber eingeben und festgelegt haben, das geht nicht ohne eigenes Handeln...
Newevents eingeschaltet?
Das ist eine Fehlermeldung, diese zeigt auf:
- Du hast eine zu alte Spielversion (TPF2 Build kleiner 35320) und eine neue NEP2 Version installiert. Also eine Inkompatibilität.
oder
- Du hast ein altes Color Paletten Mod installiert, dass das Spiel durcheinanderbringt und game.config.gui.layers zerstört...
Die Fehlermeldung hab ich vorgeschlagen, damit man NEP2 nicht als fehlerhaften Mod darstellt bzw. es einen Crash herausgibt.
Meist ist dieser Mod hier installiert und sollte entfernt werden
Noch ne sache:
FileName[params.dh106_CitroenH_1 + 1]
gäbe es noch als sichere Variante:
FileName[ (params.dh106_CitroenH_1 or 0 ) + 1]
warum? TPF2 hat zumindest früher schon mal "vergessen" einen Parameter mitanzugeben.
Oder du hast ein "altes" Asset ohne den Parameter auf der Karte und bei einem Mod Update gibt es neue Parameter.
Die Idee dahinter: Wenn ein Parameter nil ist, kann man damit nicht rechnen und es gibt einen LUA Fehler, mit dem "or" hast du dann 0. Sprich nicht gesetzte Parameter sind dann 0 + 1, also immer den erste Eintrag.
Eigentlich müsste man noch schauen ob der Index außerhalb der Tabelle ist... Aber Ihr erweitert eure Mods ja immer, kleiner werden die nicht
Beta? Ich rede nicht von Beta? 
35720 ist die letzte stabile Version:
https://www.transportfever2.co…/doku.php?id=releasenotes
35731 bzw. 35731 sind die testing Versionen. 35720 wäre also die Version die GOG und Steam als Stabil herunterlädt...
Sprich CommonAPI2 läuft mit 35720 und 35731 direkt, 35732 via buildoverwrite
Also mit allen aktuellen TPF2 Versionen... für andere alte TPF2 Versionen gibt es keine Unterstützung meinerseits...
Da ich gerade die internen Code für Modlisten ändere wird es die nächste Version wohl erst im nächsten Jahr geben...
Wenn ein Bahnhof vor und danach ist, kann man das via CommonAPI2 umbauen lassen...
So das ist aber das letzte mal, nun auch in Bildern:
Steam:
GOG Galaxy:
Kann man das "Türchen" Tor via Scriptparameter auch aufmachen?
*Glaskugel auspacken*
ws_sizex ist wohl nicht definiert, also nil
Daher wird es dir sagen, mit der transf für das Modell kann man nix anfangen. Korrigiere das mal, dann wird es wohl gehen..
-edit-
terrainface ist auch noch so ein Kandidat, das solltest du ggf auch reparieren...
Kurz überflogen
function data()
local function makeParams()
Was denn nun? Ne lokale Funktion in der Funktion Data? Einfach so geraten,
local function makeParams() willst du gar nicht haben, da es nicht aufgerufen wird...
Wenn doch, sollte es wohl vor dem return enden?
Am Ende der Datei hast du:
} -- Ende von Tabelle gestartet bei return {
end -- Das eigentliche Ende von function data() da nichts mehr weiter kommt.
Ergebnis:
Der Interpreter sieht die function data gestartet, dann die lokale Funktion makeParams,
dann wird ganz unten mit end nun die lokale Funktion beendet, aber die data ist immer noch nicht fertig: Du siehst den end Fehler in der Fehlermeldung mit einer nicht geschlossen Funktion aus Zeile 6.
Nutze mal Texteditor der dir den Code formatiert. Das sieht grauenhaft aus...
Das hilft beim Code "Schachteln" ungemein 
"starting up build version: 35716"
Wie ich schon mehrmals geschrieben habe, man kann nicht einfach eine CommoAPI2 Version mit einer beliebigen Build Version verwenden. CommmonAPI2 muss die genauen Interna von TPF2 kennen und kann die Fragmente in der exe Datei nicht finden. In anderen Worten:
Jedes mal wenn UG eine neue Version herausbringt ist die EXE Datei anders - der Byte Code und die Instruktionen und das Speicherlayout ändern sich.
Du brauchst die GOG Version Build 35720, die Testing Version 35731 oder via buildoverwrite 35732 zusammen mit CommonAPI2 20231215.
Das steht aber auch so in jeweils in den Changelogs drin, wie in deinem Fall:
1.8.20231206
- BUILD 35720 Version Steam windows and linux support
-----
As I said numerous times you can't simply use a random ComonnAPI2 Version with a random TPF2 Build Version. CommonAPI2 does need to know the exact inner workings of TPF2 and technical can't load because it can't find all code pieces in the exe. Or in other words. Every time UG releases a new build the release binary has a different byte stream, instruction encoding and or memory layout.
You need tpf2 gog version Build 35720 stable, 35731 or ( 35732 via buildoverwrite to use the last CommonAPI2 20231215
The changelog of the installed version says:
1.8.20231206
- BUILD 35720 Version Steam windows and linux support
Zäune Mod nicht geladen (Abhängigkeit)
