- Yes, everything is fine with the font.
- https://pastebin.com/4sDB6Dvg a small text correction for the Workshop.
Namely:
103. … для настройки свойств железнодорожных путей, дорог, мостов и …
Common API
Willkommen in der Transport Fever Community
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
-
-
Ich habe aktuell ein Problem, wo mir das Crash Debug Log etwas sagt, dass schon beim Laden was schief geht, die Symptome, weshalb den Debug Log überhaupt angeworfen habe, aber ein anderer ist.
Das Symptom war, dass ich die Gleis- und Straßen Toolbox nicht mehr nutzen konnte, sobald ich die Damm einstellungen ändern wollte, crashte TPF.
Mit dem Crash Debug Log bin ich aber dem Problem nicht zu 100% auf die Spur gekommen. Zumal er schon beim Laden des Saves sofort wieder crasht.Die stdout hab ich angehängt.
-
Windows Steam Version.
Straßen entfernt?
Ich habe in dem Save Autobahn 2.5 gegen 3.0 ersetzt. Ich hatte bis dato aber keine Autobahnen gebaut und daher da eigentlich keine Probleme erwartet.Auch ein Rücktausch gegeneinander hat nicht geholfen.
Tante Edit sagt:
Ich hab einen älteren Save geladen, mit 51 Mods und aktivem Crash Debug Log, auch er crashte mit beim Cargo. -
Es scheint einen Crash mit der common API unter Linux in Verbindung mit TPFMM (Linux Version) zu geben. Von der aktuellen TPFMM Version gibt es keinen Linux built, falls ich die dafür nötigen Veränderungen für Linux geportet bekomme, würde ich ein auslesen der mod.lua der common API verhindern - ansonsten kannst Du da evtl mal draufschauen @eis_os
-
-
Hallo. Ich habe das Problem das beim Erstellen einer neuen Karte das Spiel bei 41% (Initialisiere Städte) abstürzt. Aber ohne Fehlermeldung. Ich habe die Common API Mod auf aktuellster Version, aber es hilft nix.
-
Hallo
Es gibt mal wieder eine neue Testversion:
Fix: CrashDebug sollte nun keine Cargo Fehler verursachen.
Es gibt nun einen Ringbuffer, somit werden die letzten 20 Dateien bei einem Crash ausgegeben. (Das verkürzt das Log enorm)Für vehicle_cargo_util::MakeVehicleCargoInfo Crashes:
Der Eintrag "Last seen ecs::TransportVehicleSystem::EntityAdded" via CrashDebug sollte sehr hilfreich sein:CommonAPI ermittelt nun mit CrashDebug bei Eintritt der Funktion den Transport Vehicle Namen, da ich mittlerweile zumindest in der Windows Version eine guten Überblick habe, wie das ganze ecs::Entity Geraffel funktioniert und wo ich einen Hebel ansetzen kann. In dieser Funktion wird dann später vehicle_cargo_util::MakeVehicleCargoInfo aufgerufen.
Ich kann so einen Crash reproduzieren, wenn ich in der .mdl Datei die Cargo Capacities ändere. Das sollte jetzt also richtig funktionieren. *Technisch gesehen könnte ich das bestimmt noch für andere Fehlerarten einbauen. Wobei dann die Frage wäre, welcher Art von Fehler speziell am lukrativsten wäre...
Um Probleme mit TPFMM nun endlich für immer auszuschließen, wird in Zukunft die Initialisierung der CommonAPI nicht mehr unter TPFMM von @Xanos erfolgen.
Dafür wird ein Update des TPFMM benötigt, Xanos wird das dann wohl sicher in seiner Änderungsliste aufführen.* Vielleicht kann ich UG via @tomdotio überzeugen, das so eine Art Funktion für TPF2 schon ab Werk eingebaut wird. Das TPF2 das ohne Crash hinbekommt wäre natürlich mir noch lieber
-
Ich kann so einen Crash reproduzieren, wenn ich in der .mdl Datei die Cargo Capacities ändere. Das sollte jetzt also richtig funktionieren.
Siehst du da evtl. eine Möglichkeit das Spiel davon zu "überzeugen" das Ändern der Capacities gescheit zu verarbeiten und eben keinen Crash zu verursachen?
-
Moin moin @eis_os,
also ich finde deine commonAPI großartig auch wenn ich wahrscheinlich erst einen Bruchteil der Funktionen kenne oder verstehe. Und da ist der
Knackpunkt: Ich würde zum Beispiel gerne auch deine Straßentyp-Liste bei meiner Mod mit einbinden, aber ich weiß nicht wie. Ich habe versucht die mitgelieferte Dokumentation zu Hilfe zu nehmen, aber ich als Programmieranfänger gucke da wie ein Schwein ins Uhrwerk. Nur dass mir nicht die Programmiersprache große Probleme macht, sondern eher die Schnittstellen zwischen Mod, Spiel und commonAPI.
Bei meinem Straßenproblem frag ich mich zum Beispiel wie ich auf die Straßenliste zugreifen kann, oder muss ich die erst erstellen (eigentlich ja nicht, da ich sie ja in deinem UI einsehen kann oder?)?
Das nächste Problem wäre wo ich die entsprechenden Befehle einfügen muss. Ich habs mit dem StreetSelector in params={} versucht, aber da schmiert mir das Spiel schneller ab als ich gucken kann.
Weiterhin muss ich zwingend auf die Breite der zu verwendeten Straße zugreifen, da ich ja damit rechnen muss. Mit zum Beispiel var=loadfile("old_medium.lua") bekomme ich nicht das gewünschte Ergebnis, oder besser gar kein Ergebnis. Oder hat UG da irgendwie eine Sperre eingebaut?
Kurzgefasst würde ich mir wünschen das die Dokumentation etwas anfängergeeigneter wird, ähnlich wie dein Lexikoneintrag über die Einbindung der commonAPI mit Beispielen und Erklärungen.
Ich bin davon überzeugt das viele Hobby-Modder davon profitieren könnten, und du hast weniger Mails mit dummen Fragen wie die die Anfrage von mir
-
Das liegt daran das ich nie Zeit finde, das alles sehr gut aufzuschreiben bzw. auch selbst in einem Mod zu nutzen.
Im Gegensatz zu Gleisen gibt es leider keine einfache Möglichkeit Strassen Selektoren zu bauen.
Eine Variable im Modul / bzw. Con (Du brauchst das selbe Objekt für die UI Parameter und in der updateFn)
local streetSelectorObj = commonapi.uiparameter.createStreet({ key = name, caption = "" })Wenn man die Liste filtern möchte:
streetSelectorObj:addFilter(filterfn)Fügt einer Liste mit UI Buttons (params) dieses Objekt hinzu:
streetSelectorObj:createUIParams(params)In der updateFn kann man dann dieses Objekt abfragen:
local userSelectedStreet = streetSelectorObj:getSelection(params)
Ein Objekt::getSelection gibt ein commonapi.repos.repoentry zurück, d.h. Du kannst dann auch die Daten der config auslesen:
userSelectedStreet.filename für den Dateinamen
userSelectedStreet.data beinhaltet die Daten.Es gibt von UG dafür keine Funktionen, daher muss die CommonAPI auch alle Dateien bei Spielbeginn preloaden...
Ich möchte noch irgendwann mal einen Modularen Beispielbahnhof bauen, der das alles Live zeigt. Ich habe aber die Befürchtung, dass dann schon TPF2 draußen ist
-
Irgendwie krieg ich das nicht gebacken.
Ich glaube ich hab " local streetSelectorObj = commonapi.uiparameter.createStreet({ key = name, caption = "" }) " an der
falschen Stelle und das was ich in den Klammern stehen habe ist vermutlich grundlegend falsch.
Bei dem Rest glaube ich es richtig eingesetzt zu haben.Ich pack ma den Code hier rein, und die stdouts hab ich auch angehängt. Die eine mit commonAPI 20190331, da meckert das Spiel das 'params' leer ist und die zweite mit commonAPI 20190522-dev, da wird gemeckert das 'commonapi' leer ist. Anscheinend bin ich doch zu blöd für das ganze
Lua
Alles anzeigenlocal transf = require "transf" function data() local paramfn = function(params) return params end local streetSelectorObj = commonapi.uiparameter.createStreet({ key = "streetT", name = "Straßentyp" }) return { type = "ASSET_DEFAULT", description = { name = _("Miscellaneous"), description = _("Teststrasse") }, availability = { }, categories = { "misc" }, order = 1, skipCollision = true, autoRemovable = false, params = paramfn ({ streetSelectorObj:createUIParams(params) }), updateFn = function(params) local result = {} local userSelectedStreet = streetSelectorObj:getSelection(params) local streetedges = {} result.models = {{ id = "asset/bumper.mdl", transf = { 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1 } }} result.edgeLists = { { type ="STREET", alignTerrain = true, params = { type = userSelectedStreet.filename }, edges = streetedges, snapNodes = { 0, 1 } }, } streetedges[#streetedges + 1] = {{ 0.0, 0.0, 0.0 }, { 0.0, 0.0, 0.0 }} streetedges[#streetedges + 1] = {{ 0.0, 0.0, 0.0 }, { 0.0, 0.0, 0.0 }} return result end } end -
Wenn ich meine MOdliste Exportiere und dann ein neues Spiel auswähle, die Modliste Importiere, nimmt die API nur ein bruchteil der Mods, warum ist das so ?
Was mich noch irritiert, wenn ich die Settingslua die Reihenfolge änder, der Mods, wird es nicht übernommen sondern wieder zurück gesetzt, dabei macht man doch ingame im Modmanager nichts anderes...
-
Ich hab etwas mehr als 600 mods aktiv. Teilweise übernimmt dann die api nur 16 mods oder 133, es varririert. Mit dem tf mods, okay. Wie gesagt, da gibt es keine feste Zahl also.
Das mit dee settings.lia ist so gemeint: mods a, B und C sind in Reihenfolge 3.1.2,sollen aber durch crash Verhinderung in Position 1.2.3 geladen werden. Tpf speichert aber nicht die richtige Reihenfolge, sondern die Reihenfolge der Aktivierung. Dies wollte ich, per settings.lua ändern, da es schneller geht als wie im tpf mod Manager. Aber tpf übernimmt nicht die manuellen Änderungen in der settings.lua. Heißt tpf müssten sich das ganze noch wo anders merken.
