Beiträge von Klamann

Naja, vor allem würde ich gern die Module behalten und zusätzlich noch die Neigung/Biegung als Option haben. Ich werd mich bei Gelegenheit ein wenig durch die Dateien wühlen, zumindest bei der Neigung bin ich optimistisch (sofern man sie auf den ganzen Bahnhof anwendet, bei einzelnen Modulen wirds schon schwieriger).

Bei den Konfigurationsmöglichkeiten für Bahnhöfe hat sich bei TpF2 ja einiges zum Positiven hin geändert, aber die Grundstruktur der Bahnhöfe dürfte ja relativ ähnlich geblieben sein, wenn ich das richtig sehe. Hat sich hier schon jemand an Bahnhöfen mit Steigung oder gar an gebogenen Bahnhöfen versucht?

Ich spiele gern auf hügeligen Karten und die Einschränkung, nur ebene und gerade Bahnhöfe zu haben, zwingt mich zu sehr unschönen Konstruktionen...

Wirklich unglaublich, wie sich manche im Forum hier über andere auskotzen. Wer die Weisheit mit dem Löffel gegessen hat, kann ja problemlos alles alleine machen. Ich bin da raus.

Zitat von Transalpin

Der Übeltäter ist - zumindest in meinem Fall - der MOD Größere Bahnhöfe/Bigger Train Stations

Zitat von Tom

Keine Ahnung, was @Klamann da veranstaltet...

Nett, wie hier erstmal pauschal auf mich eingehackt wird, ohne die Ursache für eure Probleme zu kennen.

Tom, du veränderst in deiner Mod die platformConfig der Vanilla-Güterbahnhöfe, und zwar bevor die eigentliche Konfuguration des Bahnhofs (makeTrainStationConfig) ausgeführt wird. Das führt dazu, dass deine Mod keine der Änderungen berücksichtigt, die eine andere Mod durchgeführt haben könnte.

Hier ist der Patch für deine Mod:

updateFn = function(params)
  local trainStationConfig = railstationconfigutil.makeTrainStationConfig(params, stationConfig, stationBuilding, platformConfig)


  for i,part in ipairs(trainStationConfig.platformConfig.middlePlatformParts) do
    part.part = "station/train/cargo/tom_empty_double_stairs.mdl"
  end


  return makeTrainStationNew(trainStationConfig)
end

und schaut euch beim nächsten mal bitte erst euren eigenen Code an, ich mache mir Mühe mit meinen Mods und gehe jeder Meldung über Abstürze, die von mir verursacht sein könnten nach. In dem Fall habe ich eine Stunde lang fremden Code gelesen, um die Ursache zu finden. Da könnte ich meine Freizeit auch sinnvoller zubringen.

Das Problem gibt es übrigens schon lange, UG hat jetzt nur dieses "Terminal test" tool eingeführt, das den Fehler meldet. Richtig glücklich bin ich mit dem Tool auch nicht, sehr große Bahnhöfe will es nicht evaluieren, obwohl die Verbindungen korrekt sind. Hat wohl ein recht kleines Rekursionslimit...

@BILLYxx20xx du kannst "Größere Bahnhöfe" jederzeit deaktivieren, ohne dass das Savegame unbrauchbar wird. Alle deine Bahnhöfe bleiben auch so erhalten, wie sie sind.
Das liegt daran, dass Bahnhöfe in Transport Fever keine Objekte aus einem Guss sind, sondern aus Komponenten zusammengesetzt. Sobald ein Bahnhof gesetzt wurde, steht im Savegame nicht "da ist ein Vanilla-Bahnhof", sondern "hier ist ein Gebäude das aus dieser langen Liste von Komponenten besteht". Wenn jetzt eine Mod neue Komponenten hinzufügt, oder einen eigenen Bahnhof definiert, kannst du den nicht einfach entfernen. Meine Mod verändert aber nur den Bauplan der Vanilla-Bahnhöfe, und verwendet dafür auch nur Standardkomponenten. Deshalb kannst du "Größere Bahnhöfe" jederzeit problemlos entfernen.

@laedi du kannst in deine Mod einfach das paramsutil von UG reinkopieren, dann bist du nicht auf das Original angewiesen, das ja von anderen Mods verändert werden könnte. Auf die Art können auch beide Mods gleichzeitig funktionieren.

Hi, was das Kompatibilitätsproblem betrifft: Es gibt im Moment keine Möglichkeit, diese Art von Konflikt aufzulösen, da wir beide die Zusammensetzung der Vanilla-Bahnhöfe verändern und damit unseren Code gegenseitig überschreiben. Du könntest die Abstürze verhindern, indem du den Wert "numTracks" von "railstationconfigutil.makeTrainStationConfig" nimmst, wenn "params.numTracksIndex" nicht verfügbar ist, aber letztendlich wird nur einer der Mods funktion, wahrscheinlich abhängig von der Ladereihenfolge der Mods. Oder du erstellst einen neuen Bahnhof (ohne die Vanilla-Bahnhöfe zu überschreiben), was in dem Fall wahrscheinlich sowieso sinnvoller wäre, weil es kaum jemanden geben wird, der auf seiner Karte nur Bahnhöfe ohne Bahnhofsgebäude bauen möchte.

Ich hab da mal einen Vorschlag gemacht, wie man das insgesamt besser lösen könnte, aber die Resonanz war recht verhalten, deshalb hat das im Moment keine hohe Priorität für mich.

@BILLYxx20xx du kannst "Größere Bahnhöfe" deaktivieren, ohne dein Savegame zu schrotten. D.h. du kannst die Bahnhöfe ohne Gebäude bauen, speichern, und die größeren Bahnhöfe wieder aktivieren. Ist ein hässlicher Workaround, aber sollte funktionieren. Aber bitte erstmal testen, ohne wichtige Savegames zu überschreiben

@Tom Nur damit wir uns richtig verstehen: Ich bin ein Fan von deinen Bahnhof-Mods und habe Respekt für die Arbeit, die du da reinsteckst.

Deine Lösung ist, möglichst alles in deine Mods zu integrieren, was man so braucht. Jetzt haben wir aber eine Menge großartiger Mods, wie sloped stations und die gebogenen Bahnhöfe, die verdammt schwer zu implementieren sind und die du nicht einfach so übernehmen kannst. Die werden also nie mit deinen Bahnhöfen zusammenarbeiten können, obwohl es technisch kein Problem wäre, weil die genannten Mods nichts neues definieren, sondern nur bestehende Strukturen transformieren.

Vielleicht gefallen dir die genannten Mods sowieso nicht und überhaupt willst du nur alleine entscheiden, was auf deinen Bahnhöfen geschieht - ist in Ordnung, kein Problem.
Aber auf einer abstrakteren Ebene: Wir haben mittlerweile ein paar sehr generische Lösungen für recht komplexe Probleme und es ist weder sinnvoll, noch nötig diese Funktionalität in jeder einzelnen Mod nachzuimplementieren. Warum nicht die Mods so bauen, dass sie grundsätzlich mit anderen kombiniert werden können? Und das ganz unabhängig von den Bahnhof-Beispielen, über die wir hier reden. Es gibt noch viele andere Stellen, an denen man sehr nützliche Funktionen problemlos miteinander kombinieren könnte, wenn es denn die technischen Voraussetzungen dafür gäbe. Daran würde ich gerne arbeiten.

@Tom deine Argumente kann ich allesamt verstehen. Es ist völlig klar, dass wir nicht jedes Problem mit einem Framework lösen können und ich sehe auch ein, dass es Leute gibt, die sich mit dem aktuellen Stand ganz wohl fühlen.

Aber du bietest auch keine Lösungen für die oben beschriebenen Probleme an. Beim Kompatibilitätsproblem geht es nicht um "one to rule them all", sondern um die Frage, warum ich nur Feature A oder B oder C nutzen kann, aber nicht alle zusammen, und der einzige Grund der dagegen spricht ist dass wir es als Entwickler untereinander nicht koordiniert bekommen. Wieso also gar nicht erst den Versuch wagen, das Problem zu lösen?

Zitat von Tom

Ich habe es für mich entschieden, in dem ich nach meinen ersten Mods den Beschluß gefasst habe,die Finger von dem UG-Code zu lassen. Er erfüllt in keinster Weise die von dir genannten Ansprüche...

es geht mir auch nicht um UG-Code vs. Eigenentwicklung. Wäre es nicht praktisch, wenn die Höchstgeschwindigkeits-Mod auch mit deinen Bahnhöfen funktionieren würde? Ohne dass du irgendwas an deinen Mods anpassen musst? Das meine ich mit Kompatibilität.

Zitat von EAT1963

Gegenseitiges Code-Überschreiben z.B. gehört nicht zum sauberen arbeiten. Da nützt auch keine API etwas, wenn derartige Basics vom Modder nicht bedacht werden.

Hmm, das wäre mir neu, ehrlich gesagt. Ein Beispiel aus der Bahnhofswelt (da kenne ich mich momentan am besten aus):

• Mod A will alle Vanilla-Bahnhöfe so anpassen, dass mehr Bahnsteige gebaut werden können und überschreibt zu dem Zweck die Funktion paramsutil.makeTrainStationParams.
• Mod B will ebenfalls die Vanilla-Bahnhöfe so anpassen, dass eine Höchstgeschwindigkeit im Bahnhofsbereich definiert werden kann und überschreibt zu dem Zweck die Funktion paramsutil.makeTrainStationParams.

Wie lösen das die Modder jetzt, ohne ein gemeinsames Framework zu verwenden?

• Sie können einen eigenen Bahnhof erstellen, dann kann man aber keinen Bahnhof haben, der mehr Bahnsteige und das Geschwindigkeitslimit gleichzeitig hat
• Sie können eine darauf folgende Funktion überschreiben, z.B. railstationconfigutil.makeTrainStationConfig, aber auch hier ist die Anzahl der verfügbaren Funktionen stark begrenzt und eine Koordination ist trotzdem nötig

Wie würdest du das lösen?

Zitat von Tom

https://xkcd.com/927/

Das Problem kenne ich, aber in diesem Fall haben wir genau 0 Standards.
Ob dieser Vorschlag hier der eine Standard wird, ist mir relativ egal. Ich bitte hier um Input, damit wir schon in der Designphase möglichst viele Probleme berücksichtigen, aber jeder der möchte kann natürlich weiter sein eigenes Ding machen. Ein paar der beschriebenen Probleme kann man einzelner Modder nicht lösen (insb. das Kompatibilitätsproblem), allein schon deshalb wäre es vielleicht sinnvoll, überhaupt mal ein Framework zu definieren.

ich habe mich in letzter Zeit ein wenig mit Bahnhof-Mods beschäftigt und mir sind dabei ein paar grundsätzliche Probleme aufgefallen, die ich gerne lösen würde

• Kompatibilität zwischen Mods: Skript-Mods überschreiben entweder einzelne Funktionen oder ganze Dateien. Wenn zwei Mods die gleiche Funktion überschreiben, geht eine Änderung verloren, obwohl die beiden Mods prinzipiell kompatibel sein könnten.
  Viele Modder lagern deswegen ihre Funktionalität in separate Objekte aus, was aber schade ist, weil es durchaus erwünscht sein kann, verschiedene Mods zu kombinieren (z.B. gebogene Bahnhöfe mit mehr Gleisen und Geschwindigkeitsbegrenzungen - 3 verschiedene Mods)
• keine Standardmethoden: es gibt häufig wiederkehrende Aufgaben, die jeder Modder selbst lösen muss, z.B. Optionen im Baumenü hinzufügen/verändern. Eine erweiterte Modding-API würde Entwicklungsaufwand sparen, Kompatibilität zwischen Mods erhöhen und Standardaufgaben robust und sicher lösen.
• Ladereihenfolge: beim Laden von Mods gilt first come first serve, und das obwohl es im Spiel nicht mal eine einfache Möglichkeit gibt, die Ladereihenfolge von Mods zu verändern. Das Problem mit der Ladereihenfolge auf den einzelnen Anwender auszulagern halte ich nicht für sinnvoll.
• Lokale Funktionen: Etliche Funktionen in den Lua-Skripten von TpF sind als lokal deklariert. Das bedeutet, dass man für kleinste Änderungen oft hunderte Zeilen Code kopieren muss und damit das Kompatibilitätsproblem noch verschärft.

welche Anforderungen sollte eine erweiterte Modding API erfüllen?

• 100% Kompatibilität mit allen Mods, die nicht die erweiterte API benutzen wollen (sonst macht man nur den Code von Anderen kaputt und die sind dann berechtigterweise sauer)
• Standardmethoden, um alle bestehenden Funktionen (auch lokale Funktionen) beliebig oft zu erweitern (nicht einfach überschreiben)
• die Reihenfolge, in der Erweiterungen definiert werden, kann für jede Funktion neu bestimmt werden und wird im Code der Mod festgelegt (unabhängig von der Ladereihenfolge im Spiel)
• eine kleine Standardbibliothek, die robuste Lösungen für häufig verwendete Aufgaben anbietet
• umfassende und verständliche Dokumentation für Modder, mit Codebeispielen

über die Umsetzbarkeit habe ich mir schon einige Gedanken gemacht und ich glaube, dass es machbar wäre, eine Modding API zu bauen, die diesen Ansprüchen genügt.

Was mich aber jetzt interessieren würde: Was haltet ihr überhaupt von der Idee? Würdet ihr als Modder eine solche API nutzen? Welche Features vermisst ihr, welche möchtet ihr auf keinen Fall haben? Brauchen wir sowas überhaupt?

ich habe heute einen Bug im Zusammenhang mit den Gebogenen Bahnhöfen von UG gefixt, und bei der Recherche ist dieses "Kunstwerk" entstanden ;D

Heute ist Weihnachten

Das Problem mit den nicht funktionierenden Bahnhofs-Upgrades konnte ich lösen. Danke für den Hinweis @Gordon Dry

--> Download 1.0-beta2

Falls durch das Update neue Probleme entstehen, schreibt mir bitte!

Ich hab mal deine Logdatei durchgeschaut.. du hast über 300 Mods aktiv wird nicht einfach das Problem zu identifizieren...
Hast du die 400m-Bahnhöfe noch aktiv? Sonst irgendwelche Mods, die die Vanilla-Bahnhöfe verändern?

edit:
Ok, hab gerade festgestellt, das bereits bestehende Bahnhöfe nicht aufgerüstet werden können (also alte Bahnhöfe aus Savegames). Du musst den Bahnhof leider abreißen und neu bauen. Danach kannst du ihn aber aufrüsten. Ich muss mal rausfinden, woran das liegen könnte...

Zitat von Enzojz

It's terrainAlignmentList who deforms the terrain.

Take attention of the vertex you declared in each list, its CW or CCW sensitive, depending where it starts, if you did it in wrong direction(seems be x > 0 or x < 0), your terrain will be very sharp.

I don't actually change anything about the terrain alignment, just fixed the bugs in the original code. From what I can see, this get's overwritten by sloped stations anyways, so there's not much I can break here. I tested it ingame, all waypoints connect corretly, when bigger stations + sloped stations are both active

Zitat von Enzojz

In Lua you can readout a function from a file then hack into it (by hijacking its return and modify it), in this way you don't need to copy-paste all the codes.

Yeah, I actually store functions I override in a "super" object so I just have to change the parts I need and then call the super function, like so: store, call.

The issue with the bug in the constructionutil code is that makeTrainStationNew calls lots of functions that have been declared as local and makeTrainStationNew is the function that gets called by the game, so the only way to hook in there is to redeclare this function, which forces me to copy all the local functions. Modifying just the returned object would be pretty complicated (and error-prone) in this case, so I decided to copy-paste it and wait for UG to fix the bug (already sent them an email, I hope they'll read it)

Zitat von Gordon Dry

Hallo, könnte es sein, dass dieses Mod sich mit 400m lange Bahnhöfe beißt?

sieht ganz danach aus, die Mod scheint auch eine ähnliche Methode wie meine zu benutzen und weil ich nett bin und im Zweifel lieber anderen den Vortritt lasse als Crashes zu provozieren, wird meine Mod deaktiviert.
Kannst du "400m lange Bahnhöfe" entfernen, ohne dass dein Savegame kaputt geht? Falls nicht, kann ich dir leider nicht helfen. Beim nächsten Spiel kannst du meine Mod benutzen, und die kannst du auch jederzeit problemlos entfernen.

Zitat von Nordwestexpress

In der Beschreibung steht:

"Mod kann jederzeit gefahrlos hinzugefügt und entfernt werden"...

genau so ist es. Ich habe keine neuen Elemente eingefügt oder sonst etwas, das den Spielzustand verändern würde, das war mir sehr wichtig.

Ich werde das mal an UG melden, vielleicht wird das ja mit dem nächsten Patch repariert. Bis dahin baue ich den bugfix in die Mod ein (dafür muss man ja nur 800 zeilen code kopieren, weil sich jemand dachte, es wäre sinnvoll, möglichst viele funktionen als local zu deklarieren...)

Ich habe mir das Problem mit dem nicht ordentlich planierten Untergrund einmal genauer angesehen, da mir das im Spiel (ohne Mods) auch schon öfter aufgefallen ist. Die Beobachtung war, dass der Fehler nur auftritt, wenn man einen Bahnhof mit zweitem Straßenanschluss baut. Ein einfacher Workaround war demnach, erst den Bahnhof ohne zweiten Anschluss zu platzieren und danach aufzurüsten.

Jetzt habe ich auch die Ursache dafür im Code gefunden:

result.terrainAlignmentLists[#result.terrainAlignmentLists] =

Hier müsste natürlich result.terrainAlignmentLists[#result.terrainAlignmentLists + 1] stehen. Der Fehler tritt in den Zeilen 709, 773, 819 und 871 auf. Wenn man das repariert, funktioniert die Terrain-Begradigung für alle Vanilla-Bahnhöfe, egal welcher Größe (also auch mit Mod-Größen).

@Tom werd ich probieren, vielen Dank!