Steamproblem. Workshop war down.
Sowas hat nie nie nie mit der commonapi zutun.
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
Steamproblem. Workshop war down.
Sowas hat nie nie nie mit der commonapi zutun.
Mich wundert aber die plötzliche Änderung meiner Build-Version welche die Api wieder für mich unbrauchbar macht.
UG hat ein Update herausgebracht, damit Spieler ohne Vulkan das Spiel nutzen können. Deswegen haben wir nun eine neue Build. Release war ein paar Minuten her...
Steam scheint bei einigen Spieler die models.zip kaputt zu updaten:
stdout.txt hat dann den Eintrag gzip error invalid distance too far back, das hatten wir hier:
Spiel läuft jetzt wieder. Trotz veränderten Build.
Bei mir gibt es folgende Fehlermeldung:
your Transport Fever 2 version 31921 isn't listed as good version, native functionality disabled.
kann man die Überprüfung irgendwo abstellen, damit man die commonApi benutzen kann?
Sobald ich an nem Windows Rechner bin, werde ich erst testen bevor ich irgendwas freigeben kann...
-edit-
Im Hauptmenü unten auf die rote Nachricht bezüglich falscher Version klicken, unter build overwrite (ggf. runterscrollen ) eingeben:
steam_31921_1
Dann auf "Save" klicken -> Danach das Spiel neu starten...
Danke, allerdings muss man dann auch in der settings.lua die disablenative = true, auf false stellen, erst dann ist die commonApi wieder betriebsbereit.
disablenative wird vom Code nicht angefasst. Das musst du selber mal umgeschaltet haben.
Build 31921 funktioniert direkt mit CommonAPI2 1.7.20210223-dev:
Auf Windows Systemen wird nun 7-Zip Intern aufgerufen, ob die Version stimmt. Darüber hinaus wird nach dem Entpacken geschaut, ob das Verzeichnis auch wirklich existiert bevor es versucht wird an die neue Stelle zu verschieben...
1.7.20210223-dev
- support TPF2 Windows Build 31921 OpenGL & Vulkan Renderer
- add 7zip version check
- add check, does modid directory exist after running 7zip?
- show error if 7zip is missing
- download and extract 7zip to local/commonapi/7zip
Das mit den Ladereinfolgen verstehe ich nicht so wirklich. Commonapi2 verlangt Ladereinfolgen bei einigen Mods. Sonst war das immer egal.
Screenshot? / stdout.txt Die Ladereihenfolgen werden durch die Mods bestimmt. Wenn du zum Beispiel ein Repaint hast, sollte die Basis Datei vorher geladen werden...
Egal welcher Mod es war. Egal ob Basis oder Repaint, danach wurde nie gefragt.
Seid ich die Api nutze , wird immer bei einigen Mods an gezeigt , Ladereihenfolge beachten . Ich finde es gut , das es diese Funktion gibt . Oller Mann vergisst schon mal etwas .
Natürlich hat das die CommonAPI2 schon immer gemacht, siehe hier:
CommonAPI2 Entwicklungsdiskussion, Fragen & Antworten
Es kann natürlich sein, das Mod Autoren bei Updates Ihrer Pakete nun die benötigen Informationen hinzufügen.
Es kann auch irgendwo ein Fehler in der CommonAPI2 sein, der fehlerhafte Abhängigkeiten zeigt, aber die Funktion ist gewollt und soll verhindern das ein Mod crasht, weil eine Abhängigkeit noch nicht geladen wurde oder eben ganz fehlt. Wie gesagt, Screenshot des Fensters zeigen, dann lade ich mir die Mods runter und kann das testen...
eis_os : Auch die Version 31921 inkl. der neuen CommonAPI funktionieren bei mir ohne Fehlermeldungen. Auf den ersten Blick habe ich festgestellt, dass UG wohl bei den Grafikeinstellungen Felder gesperrt und jetzt wieder entsperrt hat. Die Umstellung von Vulkan auf OpenGL war bei mir in der Version 31895 nämlich nicht möglich. Probleme mit der Modreihenfolge gab es auch keine, da ich die "Basis-Mods" grundsätzlich immer zuerst lade.
Ich habe eine Frage und zwar wenn mir die Api die Modliste an zeigt , dann ist eine Datei rot . Ich habe diese Datei schon einmal aus dem Ordner gelöscht und neu installiert , in der Annahme das es eine TPF1 Datei war . Aber es ändert sich leider nicht . Datei von Blanki , Desiro ML der DB . Mache ich etwas falsch ?
Auch bei mir Api , ohne Probleme . Danke dafür
eis_os : Auch die Version 31921 inkl. der neuen CommonAPI funktionieren bei mir ohne Fehlermeldungen. Auf den ersten Blick habe ich festgestellt, dass UG wohl bei den Grafikeinstellungen Felder gesperrt und jetzt wieder entsperrt hat. Die Umstellung von Vulkan auf OpenGL war bei mir in der Version 31895 nämlich nicht möglich.
Die Umstellung geht nur im Hauptmenü, nicht im laufenden Spiel. Da gab es keine Änderungen zwischen den beiden Versionen.
Hmm, mehre ungünstige Sachen kommen da gerade zusammen, bei Mod Installation fehlt der Error Tab, ups.
Leider scheint in der mod.lua die Abhängigkeit nicht zu stimmen, also ein mod mit der modId kann es so nicht geben: vienna_fever_addon_oebb_cityjet_gysev_ventus_odeg
Sprich temporär
vienna_fever_addon_oebb_cityjet_gysev_ventus_odeg durch vienna_fever_s_bahn_cityjet_addon_1 in der mod.lua ändern?, sollte den Fehler beheben.
Ich werde es morgen nach der Frühschicht beheben. Nobodys perfekt, ist mir wohl ein Fehler unterlaufen.
Die Frage ist wo Ich das genau korrigieren kann. Möchte nicht der Übeltäter für Gecrashte Savegames sein. Also verzeiht mir Bitte. Ich selber nutze die CommonApi garnicht.
Mfg BlanKi
Da gibt es doch nichts zu verzeihen . Wenn ich einem Mod erstellen würde, den würde ich nicht einmal zum laufen bringen . Passiert nun mal , das sich Fehler einschleichen .
Wer sich beschwert bei umsonst erhaltenen Mods , hat das Spiel nicht verdient.