Beiträge von eis_os

Erst wird wohl die bessere Unterstützung für mehr Mod Gleise kommen (und das bei allen meinen Mods) via CommonAPI, außerdem funktioniert das Kombinieren von verschiedenen Epochen in einem Bahnhof noch nicht so ganz. Auf der Todo Liste steht auch noch eine Gütervariante...

Status Update:

Ich versuche gerade ldoc zu überzeugen eine Dokumentation zu erstellen, aber es will irgendwie nicht. Die ersten Ergebnisse gibt es hier:
http://www.bytetransfer.de/pro…f/eis_os_commonapi_1/doc/

Mal schauen wie ich die Rückgabe Werte komplett dokumentiere.

Ein kurzer Test des UI Parameter Objekt scheint auch zu laufen, leider haben genügend Gleise immer den selben Namen.
t.name = _("Standard tracks")

Das ist natürlich überhaupt nicht förderlich für die UI.
Auch noch andere Sachen sind unschön, da zum Beispiel die High-Speed vor den normalen Gleisen erscheinen.

Aber es geht zumindest weiter...

It's debug.setHook, tracing a lot calls and to find the modid/mod.lua loading ones.
However every lua function call, including c lua runtime calls are going through this function.
This function is called a lot while loading and even while at the main menu/load game screen.

At least one good thing: if I have somewhere a syntax error the load game menu will crash, so faster testing

Neue Infos:

Ich hab gestern noch eine Idee umgesetzt, diese beruht auf der Lua Debug Hook Schnittstelle und dem Stacktrace. Also keine schöne Variante, sondern eher die Nutzung einer Brechstange.
Im ersten Test sieht es ganz gut aus, die Performance könnte aber besser sein. Damit sollte ich alle aktiven Mods herausfinden inkl. Pfad für Steam Mods.

Kombiniert sollte es mit popen (für dir/ls) und dem händischen Auslesen der Dateien zu einer kompletten Liste aller Ressourcen führen.
Sollte es gehen muss ich das ganze noch unter Linux testen und dann auch noch an der Performance schrauben.

Zumindest gibt es aber nun wieder eine Chance das ich eine brauchbare Lösung ohne UG hinbekomme.

Yep, currently this is not possible,
Snapping is currently only possible to use with with edgeLists.

Naja, große Engine bedeutet nicht besser (siehe CIM2, das war eine Katastrophe gegen CIM1).

Wie gesagt, ich hab meine Ideen ja hier geschrieben und suche mir ab jetzt einfach meine private Lösung wie auch für Cities Skylines.
Ich werde mich nicht weiter beteiligen...

This means when you are lucky you get this feature in an update for the next version of Transport Fever.
(TPF3.0 + Some Update around 2018/2019) They put fixed IDs for Resources to the their TODO List around release date of Transport Fever. I gave up in trusting UGs work for such things. Look at the construction ui mess, how many updates did it take so at least the buttons are reachable?

Ich sehe keinen Sinn drin eine halbgare Lösung anzubieten. Ich hab da zwar noch eine ganze Menge an Ideen wie man es trotzdem schafft. Aber wenn UG meint dann popen zu killen hab ich wieder Zeit für nichts verbraten.
Oder man findet alle Adressen der Lua Runtime Funktionen der exe/bin und kann Sie dann ansprechen von einer Lua Erweiterung.
Dabei wären aber alle Mac Nutzer außen vor und wenn UGs Compiler meint es müsse etwas inline machen, geht auch alles wieder kaputt.

Die andere Variante wäre alle Mod Autoren dazu zu bringen Ihre Mods anzupassen. Auch mit guten Argumenten hat so etwas damals nicht bei Cities in Motion funktioniert und ich werde es diesmal erst gar nicht versuchen.
Es gibt ja jetzt schon genügend Mods die Basisdateien überschreiben mit unangenehmen Auswirkungen, das scheint mir ein einziges Minenfeld.

Es wird eine Lib für meine eigenen Mods geben aber keine generelle Version, die wird dann auch Support beinhalten für Mods die ich selber nutze.

Ja, es ist eine Shell Lösung da LUA eben keine Möglichkeit bietet einen Verzeichnis auszulesen. Opendir oder ähnliches kennt LUA eben nicht.
Mit den anderen LUA Routinen kann man auch genügend Schaden anrichten.

Ich möchte aber nicht alle Mods auslesen, sondern wirklich nur die aktiven Mods.

Hab schon viel zu viel Zeit darauf verbraten um die Fehler oder Designentscheidungen im Spiel zu umgehen.
somit ist das mein letzter Beitrag hier.

The English translation sounds horrible, so now English Versions too:

Yes, it's a shell solution. Lua has no built-in way to get a folder list. Opendir or something similar is not known by LUA.
With other lua functions you can create enough harm too.

I don't want to read all mods but only the active ones.

Did already spend to much time on TPF to avoid bugs and workaround design decisions, so this will be my last post.

-Old Post translation-
I got a solution to find files when loadConstruction haven't run yet. However it was a dead end after all.

As not all mods have res/scripts thus won't be registered in package.searchpath. For Steam Mods I need to resolve the whole path. I searched the complete LUA variables but found no evidence of the mods, so I can't search the mod path for ressource files.

Without some help of UG I can't seem to find a cross platform solution.

A lua extension can't be programmed because the lua runtime isn't exposed by the exe/bin (no export)

Status Report:

Ich hab eine Lösung um Dateien zu finden bevor die loadConstrunction durchlaufen, aber nach weiteren Test war dies schon wieder eine Sackgasse.
Grund hierfür, nur wenn ein Mod auch einen res/script Ordner hat wird dieser in package.searchpath registriert.
Gerade für Steam Mods benötige ich den kompletten Pfad zum Mod, ich hab die ganzen Lua Variablen abgesucht, auch die debug.luaregistry und finde leider die Pfade nicht.

Daher kann ich den Pfad nicht durchsuchen.

Ohne etwas einlenken von UG scheine ich da keine Plattform übergreifende Lösung zu finden.
Auch eine Lua Erweiterung ist aussichtslos, da die Lua Runtime in der Exe/bin steckt und die Lua Runtime nicht exportiert wird.

Auch wenn Ihr wegen Kompatibilität die Lade Reihenfolge nicht ändert, wäre es schön wenn es eine Info über alle Mods und deren Pfade liefern könntet. Und auch Lua LFS (LuaFileSystem) einbinden, dann kann ich mir die Infos per LUA Script selbst zusammenbauen. Diese Info könntet Ihr vielleicht im settings Parameter der RunFn übergeben, dann bräuchtet Ihr noch nicht mal eine neue Funktion oder Variable definieren.

I guess you use:
"steamapps\common\Transport Fever\res\strings\de\LC_MESSAGES"

Under Steam -> Right Click TPF -> Properties -> Language -> Select Language -> English

Steam will download the English LC_MESSAGES and create (important):
"steamapps\common\Transport Fever\res\strings\en\LC_MESSAGES"

This English res.mo File is around 293 KB.

Again as I said, the German res.mo is useless as the language is already German so there is no translation in it.
msgunfmt from gnu getext-tools.

(A reason I prefer the GOG Version)

-edit-
Changing Language will remove the other language folder, so you may want to create a backup!

TTDPatch, sure, I worked on stuff like canals or higher resolution for the windows version.

I did a short test on an older GOG Version, looked into Transport Fever\res\campaign\eu\04\script.lua

"Betreibe eine Fluglinie zwischen".....

Found in res.mo (converted to po)

msgid ""
"Betreibe eine Fluglinie zwischen [link=${planeTown0}][/link] und [link="
"${planeTown1}][/link] sowie eine Bahnlinie zwischen [link=${trainTown0}][/"
"link], [link=${trainTown1}][/link] und [link=${trainTown2}][/link]"
msgstr ""
"Operate an airline between [link=${planeTown0}][/link] and [link="
"${planeTown1}][/link] as well as a rail line between [link=${trainTown0}][/"
"link], [link=${trainTown1}][/link] and [link=${trainTown2}][/link]"

Or can you give me an sample string?
Otherwise do a filesearch, it's either in the translation files or exe file.

Technical in res.mo.

However the base language is German (as seen in the campaign text), so while the base game translates from English to German,
you should be able to find German to English translation in res/strings/en/LC_MESSAGES/res.mo

Note: There are some strings hard coded in the exe, but the mission descriptions should be in res.mo.

You may want to contact Urban Games directly, maybe the like to add Dutch as translation.

@tomdotio Dutch people like to play transport games too

Ja, ich möchte eine Vorab Version veröffentlichen sobald ich etwas funktionierendes ohne grobe Fehler habe. Ich hab noch ne ganze Menge TODOs zu lösen.

Zum Cache habe ich noch keine Idee wie man das Savegame spezifisch machen kann, Ideen sind wie immer willkommen.
Ich hab mir den interne Taskmanager für Missionen angesehen, aber ohne Mission ist das alles recht nutzlos, außerdem ist das auch wieder zu spät. Da die Konstruktionen zu dieser Zeit schon geladen sind.

Mein altes System hatte eine Datei in mods Ordner wo der Nutzer die Gleis/Brücken Dateien angeben konnte und es gab eine sortierte Liste mit Default Werten.
Wenn es beim Bauen einen Type nicht gegeben hat wurde ein Fallbacktyp genutzt, der Rest war mit M1,M2 Buttons erreichbar. Aber das ist weder ModManager kompatibel noch nutzerfreundlich.

Das angedachte Cache System:

Lade Dateien, Nutzer klickt ein Konstruktion auf.
Die Repo Liste ist an dieser Stelle komplett und kann abgespeichert werden. Beim nächsten Laden wird diese als Basis für die UI genutzt.
Das zerstört aber immer die ID Zuordnungen der UI bei verschiedenen Savegames.

Zwischenstand meiner internen Entwicklung:

Der Vorteil für Mods wird sein, das man komplett ohne require auskommen kann um die Komponenten zu nutzen.
Somit kann man Mods schreiben die Kompatibel sind aber nicht erst selbst irgendwie herausfinden müssen ob den CommonAPI geladen ist um dann ein require auszuführen,

Im Mod Code kann man dann einfach commonapi bzw eine Komponente per ~= nil testen.
if (commonapi ~= nil) then
-- Mehr Gleise und co

else
-- Normaler Code

end

Dies funktioniert auch wenn commonapi als letztes Mod geladen wird (solange UG nicht die Strings anders lädt, ja wieder mal ein Hack)

Die einfache Version dieses Loaders funktioniert, dh. commonapi.repos lädt die Repository Komponente, commonapi.uiparameter usw.
Die erweiterte Version des Loaders, der auch bestimmte API Versionen Laden soll ist nicht fertig, ob ich Ihn verwende ist auch noch nicht sicher, die Parameter Erstellung ist jetzt erst mal wichtiger.

Repositories:
Die Repositories geben nicht einfach die Daten wieder sondern eine Tabelle mit ID, Filename und Data.
Damit ist es einfacher die Daten zu Filtern und wieder in der Repository zu finden.

Die API der Repositories sehen zurzeit so aus:
getByName(filename)
getById(id)
getEntries()
getFilteredEntries(filter)

Die Filter sind wie Filefilter aufgebaut (d.h. Sie können kombiniert werden), diese Funktion wird dann durch die UI genutzt um Strassen bzw. Eisenbahnbrücken zu erhalten.

Bei den UIParameter für Gleise versuche ich gekapselte Version per Objekt anzubieten
D.h. man erhält ein Objekt mit Funktionen zu Erstellung der Parameter und deren Abfrage.
Der Parameter Key und Beschreibung kann dabei natürlich überschrieben werden, auch hier gibt es die Möglichkeit per Filter unerwünschte Daten auszufiltern.
(Für verschiedene Gleistypen in einem Objekt)

Sinn der ganzen Sache soll eine sehr einfache Handhabe in der updateFn und beim Parameter bauen sein.
Für Strassen/Gleise möchte ich damit auch die Tram bzw. Oberleitung einbeziehen.

Sollte UG doch noch UI Elemente wie DropDown Felder anbieten kann das Zentral geändert werden ohne wieder alle Mods anzupassen.

Mir macht noch immer die Ladereihenfolge von Konstruktionen und der anderen Komponenten wie Gleismaterial, Straßen und co. Probleme. M1, M2 usw. sehen nicht schön aus.
Ich hab dazu noch eine Idee über einen Cache d.h. man muss ggf. sein Savegame nochmalig laden.
Bis UG das dann endlich sinnvoll löst, aber solche Sachen dauern eben immer sehr lang oder kommen erst in einem neuen Spiel.

Soviel erst mal zum Zwischenstand der Entwicklung.

Versprechen kann ich da nix genaues, aber als Beispiel für eine einheitliche Mod API kann es gut möglich sein das ich alle UG Sachen wie Bahnhöfe und Depots ändere damit man alle Mod-Gleise auswählen kann.

Vielleicht wäre es eine Möglichkeit wenn man bestimmte Teile als nur für die UI Phase markieren könnte. (also dem Modell nicht nur die id und matrix mitgeben sondern auch noch ein UI Flag)

Zusammengefasst wäre es das Du eine UI haben möchtest die gar nichts mehr mit dem jeweiligen Daten der Konstruktion zu tun hat.
Dann kann man auf ein Teil der Konstruktion klicken und dafür eine (gesonderte) UI Anzeigen.

Wie sollen alte Konstruktionen/Mods funktionieren?
Wenn kein Datenpaket im result set ist, weiterhin die params Einstellungen der UI speichern? Es wird von UG kein Update geben das alle Mods unbrauchbar macht, einfach die alten Informationen Verwerfen geht ja nicht, es muss ja auch noch mit "alten" Mods laufen.

Du möchtest also die UI Funktionen mit in die updateFn packen? Dies kann man natürlich auch so lösen. Ich will das für UG aber so einfach wie möglich gestalten

Darf ich fragen was Du mit "schließen des Fensters (durch Abbruch)" und "schließen des Fensters (mit ausführen des Umbaus)" vor hast?

Yeah, I do think it would be better to have a API from UG for this, technical it should sample the terrain the same (even wrong) way that UG uses. So the results are consistent.

Freakh:

Natürlich würde ich gerne auf die Hidden Elements verzichten und eine lua table speichern, dann sind auch floats und strings möglich.
Hier ging es mir um die Kompatibilität zum vorhanden Code und Savegames.

Technisch gesehen sind alle Element immer noch einfache Parameter und zu TPF und updateFn kompatibel.
Einzelnen Einträgen in einer Value Liste hat den selben Grund, da man ja nur einen Integer Wert speichern kann.

Die Bedeutung der ID<->Gleis/Brückenart Mappings soll sich während der Zeit nicht ändern, das fehlt auch noch in der API Beschreibung zu den Repositories.

Eine alte Konstruktion kann ja auch vorhanden sein, die der Spieler upgraden möchte. Da soll ja nicht auf einmal ein ganz andere Straßentyp oder ein Gleistyp auftauchen.

Darüber hinaus sind da auch noch ein paar andere Dinge die unsere Aufmerksamkeit benötigen: Zurzeit schreibt UG einfach die Parameter Liste um um ein Gleisupgrade zu machen.
Auch hier müsste es ein Callback geben, der den neuen Gleistyp sowie Edge ID mitgeteilt bekommt und die "uisettings" dann ändert.

So sollten die Repository IDs im ganzen Spiel das selbe Darstellen und daher ist eine reine Modifer Lua Lösung nur ein temporärer Ersatz.
Trotzdem werde ich wohl das komplette API als LUA Version ausarbeiten damit man schon mal damit experimentieren kann.

Wenn es UG dann nicht umsetzten will, kann zumindest keiner behaupten wir haben es nicht versucht.

Hmm, die Idee finde ich nicht schlecht.
Ich kann aber sagen das Konstruktionen in TPF ein Spezialfall sind und für andere Sachen so nicht existieren, aber das kann man für TPF3 natürlich aufgreifen. Ich hoffe ich hab die UI Parameter Erweiterungen verständlich rüberbringen können.

Enzojs: Your code is a bit hard to follow. My code is even worse to follow, so no problem If I am right you calculate the arc of a new track and the store this for later reusage.
My station script is dump compared to your approach, I do have a virtual coordinate system and bend it to the curve.
Reminds me I should release update to my mods.

Ich frage mich ob ich meine API als shared mod veröffentlichen soll, ich mag es eher das ein Mod ohne externe Abhängigkeiten sind und nicht jeder wäre wohl mit meinen Ideen bzw. deren Ausführung glücklich. Anderseits die API und modifer nicht in jedem Mod mitzuliefern wäre auch ne schöne Sache.