CommonAPI2 does not work on Apple Systems:
Platform support
- Windows 10 1803 or higher (see windows requirements)
- Linux
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
CommonAPI2 does not work on Apple Systems:
Platform support
Had to reinstall windows, steam, tpf2 etc, cant remember how to resolve this, could you please remind me.
Many thanks
Jimbo
Please use the CommonAPI2 Manual at http://commonapi2.bytetransfer.de
The troubleshooting section exactly has an entry for this problem, telling you to upgrade C++ Runtime....
The requirements page has a link to the c++ runtime
I've downloaded the latest dev versions to have a look at the beta, turned all the required options on, I have all the street types, but the tram stops are missing. I'm assuming this must be a mod conflict of some kind. Is there any way to figure out what could be messing with these stops?
Maybe your game year isn't >1970 yet?
Oh dear. It hadn't occurred to me to check the availability date. They are most certainly there. My apologies for having bothered you ![]()
Hallo
wieder mal nur eine zwischen Version 1.8.20231104-beta :
Als neue Funktion gibt es nun einen mdl Datei Überprüfung (diese funktioniert auch ohne dll).
Dafür müsst Ihr in den Einstellungen checkmods aktivieren.
Da alle mdls überprüft werden und es daher etwas Ladezeit kostet ist es abgeschaltet.
Unter dem API Knopf gibt es dafür dann ein neues Fenster für Ladefehler:
Und ja, ich bin der Meinung das mein Prüfroutine laut UG Dokument richtig ist, und daher UG Dateien beanstandet werden! ![]()
Be aware that a mesh can't be used for multiple lighting purposes. Each mesh id may at most appear in one of the config lists. steht in der Doku unter:
https://www.transportfever2.co…p?id=modding:vehicletypes
Beispielhaft zeige ich mal ein Fehler der TPF2 sicher abstürzen lässt:
CommonAPI2 CheckModels ERROR: test/res/models/model/vehicle/bus/eis_os_crashvehicle.mdl: roadVehicle.configs[1].blinkLightsLeft[1] meshId = 110 bigger then last mesh id in lod = 25 lodid = 1 (LOD0):
roadVehicle = {
configs = {
{
blinkLightsLeft = { 110, },
blinkLightsRight = { 120, },
brakeLights = { 10, },
Hier ist also die meshId größer als die Anzahl der Meshes in LOD0, das ist ganz böse...
Bitte beachtet das der Tester wie bei LUA Tabellen üblich, mit 1 = erster Tabelleneintrag Arbeit.
Daher ist eine lod = 1 der erste Eintrag in der Lod Tabelle, sprich LOD0. (daher wird auch noch mal extra das LOD mitangeben).
Die meshIds werden wie auch im ModellEditor mit 0 = erster Knoten angeben, damit man dieses einfacher gegen prüfen kann.
Hura das LUA und TPF2 verschieden zählen ![]()
Sprich wer irgendwelche Probleme hat, wenn Autos blinken oder Bremsen.
Anschalten, und dann in der stdout.txt nach "bigger then last mesh" suchen...
Habe jetzt schon Angst vor hunderten von Fehlermeldungen, die einem das Wasser in die Augen treiben... 😏
Ist 'ne super Sache!
Aber vermutlich für Laien immer noch unverständlich zu interpretieren. Alleine anhand Deines Beispiels mit der Mesh-ID hätte ich schon nicht gewusst, wo ich hätte suchen und den Fehler finden sollen. ![]()
Noch ist die Funktion ja in der Beta Phase.
Für Verbesserungen in der Beschreibung der Fehler bin ich immer offen.
Zu jeder Datei wird der Pfad ausgegeben, sprich du hast dann die Möglichkeit problematische Mods mal abzuschalten... oder als Mod Ersteller mal den Modelleditor anzuwerfen und deine configs überprüfen..
In dem Kontext ist vielleicht interessant, dass in Advanced Camera Views auch eine Überprüfung von mdls notwendig wurde (durch eine Überarbeitung mithilfe EAT1963 ) RE: Triebwägen - Gelenke verhalten sich komisch
So haben wir eine ganze Reihe Mods (und ein Vanilla Modell) entdeckt, die fragwürdige Definitionen enthielten.
Diese Logik hatte mir bisher jedoch kein anderer Modder oder UG bestätigen können. Die dokumentation dazu hatte ich da nicht 100% verstanden.
Jedenfalls gibt es nun seit knapp 1 Jahr keine Beschwerden.
Demnach sind folgenden Vanilla Dateien fehlerhaft:
Advanced Camera Views - Delete invalid fakeBogie: 'configs[1].fakeBogies[1].' [res/models/model/vehicle/train/usa/speedance_express_front_v2.mdl]
Advanced Camera Views - Delete invalid fakeBogie: 'configs[1].fakeBogies[1].' [res/models/model/vehicle/train/usa/speedance_express_middle1_v2.mdl]
Advanced Camera Views - Delete 0 entry in 'configs[1].blinkingLights1' [mods/urbangames_legacy_vehicle_pack_1/res/models/model/vehicle/tram/usa/skoda_10t.mdl].
Hmm, fakeBogies Überprüfung hab ich auch, was verstehst du unter fehlerhaften fakeBogies?
Ich sehe da im ModellEditor für Speeddance Express Front V2:
Erster Eintrag:
fakeBogies = {
{
group = 0,
offset = 0,
position = 0,
upright = false,
},
},
Zweiter Eintrag:
speedance_express_front_v2.mdl
fakeBogies = {
{
group = 2,
offset = 0,
position = 5.3600001335144,
upright = false,
},
{
group = 6,
offset = 0,
position = -5.2800002098083,
upright = false,
},
},
Alles anzeigen
![]()
Skoda
Ok blinkingLights1 = { 0, }, der Skoda ist natürlich bescheuert. Dass dann der ganze Wagenkasten blinkt. Das rutscht bei mir durch, da das ganze Mesh ja auch valide ist. ![]()
-edit-
Bei der Skoda wird nun auch gemeckert. Sprich alle lightings dürfen nicht mehr 0 sein.
Bei backBackwardParts und co kann ich mir auch nicht vorstellen, das ganze Mesh abzuschalten richtig ist.
Aber es könnte ja sein das man ein Zugschluss baut und das ganze Modell abschalten will?
Schwierig.
Zitat von VacuumTube-edit-
-Der group Wert ist nicht nil,
-Der group Wert ist >0
-oder wenn group=0 ist, offset oder position ist nicht 0, oder die Anzahl von configs.axles =0
Also wenn group = 0:
Wenn Position = 0 und Offset = 0, muss #config.axles = 0 sein, sonst ist der Eintrag nicht valide?
Heute gibt es eine neue CommonAPI2 20231125 Version, wie bei Releases beschrieben:
CommonAPI2 - Neue Versionen und wichtige Informationen 20231125
Ich hab auch ein kleines Video auf Discord hochgeladen dazu, für Leute die nicht in Discord des Forums sind, hier mal ein Link dazu:
-edit-
Weil die Frage aufkam, ja das geht natürlich mit jedem Straßentyp...
Downloads:
Das neue Update ist WELTKLASSE!!! Vielen dank dafür mit den nodes ![]()
![]()
![]()
Fehlerdatei stdout bitte als Dateianhang hier hochladen. Die Experten brauchen dann weniger rätseln.
Speicherorte der Spieldateien, stdout.txt, Speicherstände, Mods (TPF2) --> punkt 2.
Deine Spielversion Build passt scheinbar nicht zur installierten CommonAPI2 Version. Ungewöhnlich, da technische Maßnahmen dieses verhindern.
CommonAPI2 doppelt installiert, bitte schaue in alle mods Ordner das dort keine CommonAPI2 liegt, es dürfen auch keine zip Dateien herumliegen. Am besten du entfernst alle Versionen. Dann einmal neu installieren.
stdout.txt anhängen...
DAS ist revolutionär, Leute!
Du hast das Unmögliche möglich gemacht...
Ich bin mir sicher, darüber wird im Hause UG nicht schlecht gestaunt werden.
Zunächst mal ein Klatschen, wenn auch momentan noch ein verhaltenes. Das ist DIE Funktion, die sich Tramfreunde schon immer gewünscht haben.
Allerdings funktioniert sie bei komplexeren Kreuzungen noch nicht einwandfrei, und da es manchmal Ruckler in der Grafik gibt, scheint es noch interne Instabilitäten zu geben. Aber immerhin lassen sich zumindest bei spitzwinkligen Tram-Abzweigungen schon mal die oft sinnlosen und viel zu engen Verbindungskurven eliminieren, was auf jeden Fall sensationell ist.
Und wieder einmal fragt man sich, warum UG noch nicht auf die Idee gekommen ist.
Bei mir gab es übrigens auch nach dem ersten Start mit CommonAPI einen Absturz, erst beim zweiten Versuch lief es dann.
Bedenke: Die Lanes gelten für alle Verkehrsteilnehmer...
Wenn es nicht funktioniert:
- Der Umbau wird durch UGs Streetbuilder gejagt für jede Änderung, sollte eine Konstruktion eine Node Verbindung haben funktioniert der Code nicht. Ein manuelles ändern einer Straße sollte dennoch den gewünschten Effekt haben.
- Manchmal wollen bestimmte Konstellationen nicht. Hab aber noch kein Testcase zum ausprobieren. Komischerweise kurz ein andere Verbindung zu ändern hilft.
- Wenn keine Lanes via Alt-Gr L angezeigt werden, sollten keine Grafikprobleme entstehen, da ist eine erweiterte Liste für neue Punkte dazugekommen... Sonst gibt es im Renderpfad keine Änderungen.
Ruckler? Beim Umbau oder wenn? Nunja, bei jeder Lane Änderung wird die Straße halt neu gebaut. Der Perfomance Effekt sollte sich genau so verhalten wie wenn Du Ampeln, Spielereigentum, Buslanes usw. auf einer Straße änderst.
- Man sollte den NodeEditor nicht offen lassen...
Komplexe Kreuzung, bitte Screenshot machen...
Technisch ist es so wenn TPF2 eine Straßennode neu baut schaut es in einer Liste nach XY Koordinaten, die dem Node nahe sind. Dort in der Liste werden dann die erweiterten Daten gespeichert. Hierfür gibt es ein Lese und Schreib Lock. D.h. das wird auch weiterhin parallel ablaufen wenn es nur liest.
Das liegt darin, das ich kein Daten durch den Konstruktionsprozess jagen kann. Bei Kreuzungen wird der Winkel der Abzweigung als Indiz genutzt, um die richtige Straße mit den richtigen Daten zu verknüpfen. Entity Ids sind nicht stabil und nach jedem Umbau anders...
Daher bei Screenshots auch die Debug Daten bitte mit anhängen.
Aber eigentlich sollte es keine weiteren Performance Auswirkungen haben.
Zum Crash:
Hast du checkmods aktiviert?
Dem kann ich mich nur anschließen. Das ist einfach Revolutionär.
Da kann man nur anerkennend den Hut ziehen.