Beiträge von Freahk

@Enzojz thanks, but there should be a native version if we want to pass the spline to the updateFn and let the user himself handle the terrain alignment.
Otherwise there will be many implementations of the same alignment and some users that don't know how to properly align the terrain.
btw. I also implemented some spline to polygon approximation so I can use splines for terrain alignment.
I should have looked at your code BEFORE implementing the whole spline stuff On the other hand it was just ported from some js code I had written some years ago to display some spline stuff in the browser, so it was not too much work.
Btw. it is possible to calculate the exact length of a spline by (numerical) integration. However, in many cases an approximation is just fine and faster.

Zitat von Enzojz

in general, tracks should be decomposed as tracks, tunnel, portail, catenary etc, I think this will not be done until TPF2

Yeah that would be great. Anyways, for now it would already be a huge advantage to move the wall over from the track to the tunnel.

@eis_os
Ich habe ehrlich gesagt keine Lust echsen oder elfen zu analysieren und glaube dir das einfach mal. Analysieren kann man halt machen, möchte man (also zumindest ich) aber nicht...
Wenn es im code schon etsprechend vorhanden ist, sollte man die api tatsächich einfach an die lua Umgebung weiter geben, falls nicht wäre es aber auch nicht so wild dies auf einen späteren Zeitpunkt zu verschieben.

Zitat von eis_os

Außerdem kann es ja sein, das ein späterer Modifer die Werte ändert

ja das stimmt, ist allerdings nur dann ein Problem, wenn der modifier eine neue table erzeugt und zurückgibt anstatt einfach das übergebene Objekt zu modifizieren und wieder zurückzugeben.
Die meisten Mods modifizieren einfach die übergebene table. Es gibt natürlich auch manche die dies nicht machen und damit den workarround aushebeln, weshalb ich die forderung nach zumindest einer Liste und der geänderten Ladereihenfolge vonn und ganz zustimme. Die gesamte API wäre natürlich schön und wenn das ganze intern eh schon vorhanden ist, sollte diese auch zur Verfügung gestellt werden, allerdings nicht unbedingt notwendig.

"Wie kannst Du nach Dateien in LUA suchen" naja ich kann für so ziemlich alles bis auf meshes und scripts einen modifier registrieren und mir merken was alles geladen wurde. Für scripts kann ich per pcall versuchen ein Script zu laden und weiß dann auch, ob es existiert oder nicht.

Die die erwähnten workarounds sind auch eher nicht an dicht gereichtet, da ich davon ausgehe, dass du du meisten oder alle davon schon kennst, sondern stehen hier eher für die die diese noch nicht kennen.

So jetzt zu meinen Ergänzungen:
Ich hatte ja bereits ergänzt, dass in den Zugriff auf die UI wünsche.
Dadurch ergeben sich folgende weitere (teils dazu notwendige) API Wünsche:

- neuer törö alignment und face modus "fromSpline".

- callbacks, ähnlich der updateFn einer construction für Straßen, Gleise, Tunnel und Brücken

- Straßen Schnittstelle bezüglich der lanes modbarer gestalten:

- Straßen und Gleis API zu Verkehrswegen generalisieren.

Erstmal zu deinen Punkten:

Bei der Dokumentation und der Fehlerbehandlung stimme ich dir vollkommen zu. Da sollte etwas getan werden.

Zitat von eis_os

- Snappoints für Konstruktionen

Steht auf meiner Wunschliste ganz Oben. Die Unterführung macht sowas zwar bereits, nutzt aber einen ziemlich hässlichen workarround den man auch nicht in allen Situationen nutzen kann.
Weitere ähnliche workarrounds hatten wir dabei ebenfalls ausprobiert. Teilweise sind die in bestimmten Situationen nützlich, teilweise crashen die unter manchen Systemen (lustigerweise nicht unter allen) das Spiel.
Die "stable" workarrounds arbeiten alle mit einer Kombination aus rail und road snaps und eben dies ist nicht in allen Situationen ohne weiteres möglich. Da muss eine Lösung her die snapping der lanes direkt ohne den Umweg über die edges (Straßen und Gleise) erlaubt.

- Kontrolle über das Konstruktions und, hier ergänze ich, allgemein alle Parameter Fenster, steht bei mir auch ganz Oben auf der Wunschliste mit dabei.
Mit "allgemein alle parameter Fenster" meine ich die der Gleise, Straßen und Signale (mag sein, dass ich noch was vergessen habe)
Gleise haben so viele unterschiedliche Werte für die man Parameter verwenden könnte, um das Menü etwas aufzuräumen. Gleiches gilt für Straßen.

- bessere API für das Laden von neuen Ressourcen (Gleise, Straßen, Tunnel):
stimme ich dir prinzipiell zu. Fürs Erste sollte es dort aber reichen die Straßen zu laden bevor man die construction läd und deren Parameter Fenster initialisiert. Die ID to name Umwandlung könnte man dann notfalls per lua lib umsetzen, wenn man beliebige tables an eine entity kleben kann.
Zusätzlich sollte das Spiel eine Liste aller geladenen Ressourcen dieser Art zur Verfügung stellen, damit man sich diese Liste nicht, wie aktuell, selbst über einen modifier zusammensammeln muss (ja, man kommt an diese Informationen bereits ran aber leider zu einen Zeitpunkt an dem es schon zu spät ist und es ist auch keine gute API, wenn man sich die Liste erst zusammen sammeln muss...)
Dennoch muss ich dir zustimmen, dass eine solche API natürlich noch etwas besser wäre, mit Sicherheit aber auch mit einer Menge Aufwand verbunden wäre den UG imho lieber in andere API Verbesserungen investieren kann.

- Möglichkeit im Virtuellen Res Ordner nach Dateien zu suchen:
Auch hier stimme ich dir aber zu, dass es dazu eine Funktion geben sollte. Es gibt bereits einen Weg für mods eine solche Funktion im lua zu implementieren (außer für meshes) aber auch das ist eher ein nicht schöner workarround und unter Umständen, auf die man selbst keinen Einfluss hat funktioniert der workarround nicht.

- Pfad Auslesen/Speichern von Mod spezifischen Einstellungen:
Mir ist nicht ganz klar was du damit meinst? So etwas in der Art wie die config von Merk im Zusammenspiel mit dem MM von Xanos?
Wenn ja stimme ich dir zu, dass das Spiel sowas direkt handlen können sollte, zumal es so scheint, dass dies mal angedacht war, es aber nicht ins Spiel geschafft hat.
Allerdings würde ich das von der Priorität her ziemlich weit Unten ansiedeln.

- Bessere Kontrolle über die Bodentätigkeiten eines Gleis. (Und auch keine Änderung Textur bei alignTerrain = false):
Bei dem Punkt in Klammern stimme ich dir voll und ganz zu.
Den anderen Teil davon verstehe ich auch nicht so recht. Was möchtest du da genau kontrollieren?

- Abschalten von Tunnelwänden (Ich will nicht jedes Modgleis duplizieren um die Wände zu ändern):
Tunnelwände komplett abzuschalten ist imho nur bedingt sinnvoll. Die Tunnelwände sollten meiner Meinung nach allerdings zum Tunnel und nicht zum Gleis gehören.
Zusätzlich sollten diese optional sein, damit man keine transparente Textur verwenden muss, wenn man mal keine Wand haben möchte.

So weit zu deinen Punkten.
Meine Ergänzungen kommen Heute Abend oder Morgen, ich muss jetzt weg meinen Geburtstag feiern.

Ich habe vor einiger Zeit mal damit angefangen den Wertebereich aller Attribute von denen ich diesen zu kennen meine zu dokumentieren, weil UG dies eben nicht macht und ich der Meinung bin, dass es schon ziemlich wichtig ist, dass es eine solche Dokumentation gibt.
An der Sache gibt es aber natürlich mindestens 3 Probleme, die beide in der Aussage
"aller Attribute von denen ich diesen zu kennen meine" versteckt sind.
1. Kann ich wie wir alle nur die Spieldaten nach Attributen durchwühlen. Wenn es weitere Attribute gibt die UG nicht selbst nutzt, werde ich dies wohl auch nicht dokumentieren können und
2. Für jedes Attribut kann ich den Wertebereich nur erraten und dann stichprobenartig testen, ob das Spiel mit solchen Werten tatsächlich klar kmmt. Für diese enum-artigen Strings wie "RAIL_STATION" etc. ist das noch recht einfach, da gehe ich einfach davon aus, dass die Werte die in den Originaldateien verwendet sich auch gültig sind und es keine weiteren gibt. Bei Strings die recht eindeutig Pfade sind ist dies auch noch recht einfach aber bei Zahlen ist ist es häufig mit viel Raterei verbunden.
3. hängt recht eng mit 2. zusammen. Selbst wenn ich herausfinde, dass zum Beispiel 0 eine besondere Bedeutung hat, weiß ich noch längst nicht, ob dies nur rein zufällig so ist oder, ob es tatsächlich ein so vorgesehenes feature ist. Ich kann nicht garantieren, dass das was ich dort dokumentiere auch nach dem nächsten und Übernächsten patch noch so ist, weshalb ich grundsätzlich in der Dokumentation als Wertebereich erstmal nur den Bereich bezeichne den UG tatsächlich nutzt und zusätzlich erwähne welche Bereiche außerhalb dieses Bereiches noch akzeptiert werden.

Und genau diese Probleme führen dann dazu, dass man 0 als speziellen Wert verwendet, sich 3 patches weiter herausstellt, dass dies garnicht so vorgesehen war und viele Leute ihre mods anpassen dürfen weil das Spiel sonst crasht...

Ehm, genau es gibt den lua stack trace aus, der prinzipiell vollkommen ausreicht.
Aber wo siehst du in dieser Ausgabe auf welche konkrete Datei im Dateisystem sich das bezieht? Also ich sehe da nur Pfade die relativ zu irgend einem der zig res Verzeichnisse steht und um genau diese Information geht es mir.

Das kann man sich zwar zusammensuchen, führt dann aber dazu:

Zitat von tomdotio

Für den durchschnittlichen User sonst unmöglich, die passende Mod zu finden und zu deaktivieren.

Bei den besagten anderen Problemen die erst deutlich später auftreten, also meistens bei denen die gar keinen lua Fehler erzeugen, stimme ich dir nach wie vor zu, dass es da schweirig wird die richtigen Fehlermeldungen auszugeben, ergänze allerdings nach wie vor, dass man trotzdem versuchen Sollte an Stelle oder zusätzlich zur Ausgabe der failed assertion eine Meldung auszugeben, die das ganze nochmal in etwas lesbarer beschreibt.
Außerdem sollte es möglich sein auszugeben aus welcher Datei die updateFn stammt die aufgerufen wurde um die Daten einer construction zusammenzusetzendurch die das Spiel mit einer failed assertion abgebrochen ist.

Das würde schon sehr viel weiter helfen als die aktuelle Situation.

Viel mehr wird tatsächlich technisch schwer machbar sein.

Ich erwarte mit nichten, dass lua für jede Tabelle die Herkunft kennt. Ich wünsche mir nur, dass an Stelle des Pfaded relativ zu irgendeinem res dem res Verzeichnis übergeordneten Verzeichnis im stack trace der Absolute Pfad, oder zumindest ein Pfad aus dem man direkt die genaue Herkunft dieser Dateien ablesen kann ausgegeben wird.
und um Missverständnisse auszuschließen, ich beziehe micht auf den von dir verlinkten Fehler bei dem es tatsächlich relativ wenig bringen würde mitgeteilt zu bekommen, dass es eine originaldatei ist, sondern betrachte das Fenster nur als Beispiel eines lua stack traces wie er von TpF eben mit ziemlich unpräziser Pfadangabe, ausgegeben wird.
Nicht selten gab es in der Vergangenheit (und gibt es noch immer) das Problem, dass Mods sich untereinander nicht vertragen haben weil sie gegenseitig Dateien überschrieben haben.

Das Ergebnis ist dann sehr aussagekräftig in etwa "stack trace... attempt to call function in res/scripts/file.lua" und an eben diesem Punkt sollte es die Information geben um welche res/scripts/file.lua es sich genau handelt und für den Fall, dass es sich bei der table in der nach der nicht existierenden Datei um eine modul handelt (auf gut Deutsch, genau diese Table existiert in modules.loaded), sollte zu dieser table eben auch der genaue Pfad der Datei angegeben werden.

Das ist bei weitem keine Perfekte Lösung aber einfach durch einer kleinen Anpasung der require Funktion umzusetzen und in vielen Fällen hilfreich.
Sehr Häufig, wenn wieder jemand im Discord Probleme mid Mods hatte die sich gegenseitig beißen lag es daran, dass eine der Mod (oder beide) Originaldateien überschrieben haben und dadurch das eine Modul Funktionen hatte die das andere nicht anbieten konnte.

Viel mehr ist dann aber tatsächlich technisch nicht drin, ohne so pauschal für jede lua table ihre Herkunft zu verfolgen.

@eis_os naja wenn es zu einem crash kommt könnte man aber auf jeden Fall feststellen welches Modul mit dem bestimmten Namen nun geladen wurde, sowohl für das Modul aus dem der Aufruf stammt als auch das Modul an den der Aufruf gerichtet war (z.B. mods/<modname>/scripts/constructionutil.lua z.B.). Am besten wäre diese Information gar für den gesamten Stack.
Das wäre schon eine enorme Bereicherung. Selbst der normale Spieler würde damit zumindest den Hinweis bekommen "versuch mal eine der mods zu deaktivieren vielleicht gehts dann".

Ob es weitere Dateien gab die auf den Selben Modulnamen hören und "überschrieben" wurden wäre zusätzlich auch sehr nützlich zu wissen und technisch machbar. Das kann man ansonsten aber auch "von Hand" herausfinden.

Schwieriger wird es da schon, wenn ein Original Script überschrieben wird und der Funktionsaufruf erstmal korrekt ist, dadurch allerdings die zusammengeklebte lua table nicht der vom Spiel erwarteten Struktur entspricht. An dieser Stelle stimme ich dir voll und ganz zu, dass es technisch sehr schwierig sein wird die richtige Fehlermeldung herzustellen, allerdings kann man auch hier deutlich besseres feedback als diese aktuellen failed assertions geben, indem man einfach mal dazu schreibt welche lua Datei die Daten erzeugt hat die zu dieser failed assertion geführt haben und, als so richtiges premium feedback, die Fehlermeldung zumindest etwas lasbaerer z.B. erwähnt, dass sich an einer bestimmten Position eine rail node auf einer street node liegt und ähnliches für die ganzen anderen Fehlerquellen sie das Spiel zu Abstürzen mit kryptische Fehlermeldung bewegen.

Da könnte es im allgemeinen aber schon helfen im Log eine Information auszugeben, wenn an Stelle einer Original Datei eine Datei aus einer mod verwendet wird. Auch das ist technisch machbar.

Um Probleme durch überschriebene Scripts zukünftig grundsätzlich zu minimieren wäre es hilfreich eine Datei zusätzlich zum Modulnamen über 2 lazy module, ich taufe sie jetzt einfach mal valilla und mods.modname erreichen zu können. Nu für steam mods wird das dann schwierig aber da afaik vor dem upload die steam ID der mod nicht bekannt ist und man diese in den Modulnamen angeben müsste.

Deiner Anregung kann ich voll zustimmen: Das wäre schlicht nützlich.

Nein das geht nicht.
Aber du kannst es, wie du bereits festgestellt hast durch die Richtung beim bauen festlegen. Sollte doch reichen oder nicht?

zum Beispiel. Oder den erweiterten Depots die für jede Richtung ein eigenes Depot haben.
Du kannst pro mdl ein Depot haben, kannst mit dem construction alleskleber dann aber beliebig viele Depots zusammen kleben.
Am einfachsten dürfte es wohl sein strikt das Modell mit den Gebäude meshes vom Modell mit der Depot Funktionalität (einschließlich lanes im Depot und und Türen) zu trennen.
Dann kannst du auch ohne weiteres neben der Doppel Version eine reine Tram und eine reine Bus Version anbieten.

Bisher hat UG es immer hinbekommen, dass saves durch einen patch nicht zerlegt wurden.
Entweder bis zum release sind alle mods so angepasst, dass es keine Probleme gibt oder UG bastelt es so zusammen, dass die nicht angepassten mods trotzdem funktionieren.

Du kannst höchstens beide Depots in ein Gebäude quetschen. Dann hat das Gebäude eben 2 Depot icons das klappt aber.

Es wäre schon ziemlich nützlich aus der con bestimmen zu können an welchen Stellen an der Straße gebaut werden darf und wo nicht. Ohne entsprecehende Option müsste man dann wieder mal Straßentypen doppelt definieren.
Von mir aus kann man ja diesen parameter vor dem Nutzer versteckbar machen aber es sollte ihn schon geben.

Jap. Jegliche Form code wieder zu verwenden hat so seine Vor und Nachteile, aber die originale Datei einfach durch die eigene erweiterte Variante zu überschreiben ist wohl mit Abstand die gefährlichste... und imho ist es von UG ganz klar der Falsche Weg dies auch noch zu unterstützen, indem man dann eben das originale Modul entsprechend anpasst bzw. eben nicht anpasst, sondern einfach ein neues Modul her nimmt.

und wenn du schon dabei bist, denk dran, dass es schön wäre diese Option auch für Straßen die in constructions gesetzt werden explizit einstellen zu können, um es dort zu erlauben.

Zitat von Randomx7

Fixed modified constructionutil.lua issue (moved function to new file)

Lol WHAT? jetzt kann man sogar in Ruhe original Dateien beim modden überschreiben, UG wird dann schon zusehen, dass es keine Probleme durch updates gibt^^
Und dabei hat lua so wunderbare Möglichkeiten sowas wie das constructionutil zu erweitern ohne dabei Konflikte zu erzeugen oder die komplette Datei kopieren zu müssen...

Es gibt nur ein paar kleine aber feine Unterschiede:
Die BR 422 hat Armlehnen auf der Fensterseite, bei der BR 423 bin ich mir da nicht ganz sicher aber ich meine die hatte keine.
Die BR422 hat Überwachsungskameras an der Decke hängen und
die Beleuchtung hängt zwar bei beiden ander selben Stelle, ist aber etwas anders.

Die Haltestangen im Innenraum sind bei beiden nur an den Trennwänden Glastrennwänden zu den Türen zu finden, zusätzlich gibt es noch den Griff an den Sitzen.
Im Mehrzweckbereich hängen in der BR 422 noch Griffe von der Decke. Keine Ahnung ob es diese Griffe in der 423 auch gibt.

Zitat von dampf19

Wobei Mods, die nur der Verschönerung dienen eigentlich trotzdem erlaubt sein müssten.

und genau das ist nicht so einfach vom Programm feststellbar, weshalb es die Möglichkeit gibt die Medaillen trotz mod freizuschalten. z.B. "Acheatments" von Medi und Merk schaltet das frei und meiner Meinung nach ist das dann auch vollkommen ausreichend.

No. Simply deleting an unused script does also work
Well I know that issue but I didn't expect that there are multiple versions of "tom_edgeutil_v1_0" because I expected the v1_0 to be the version so the content of all files using this exact name should be the same.
Well, that's what I excpeced...

Anyways it's not a problem at all, simply delete that file. The underbridge doesn't use it anymore.

Für mich ist das alles eine große S-Bahn Familie, von BR 422 bis BR 423.
424 bis 425 sind fü rmich Regionalbahnen bzw. im Raum Hannover sind das für mich als S-Bahn missbrauchte Regionalbahnen.

Edit: fast das wichtigste überlesen:

Die 422 ist großartig geworden und so sehr ich mich auch anstrenge, ich habe keine chanche dem Fahrzeug keine "passform geprüft" Plakette zu kleben.

Sieht ja schon fast so aus als hättest du plötzlich einen Plan auftreiben können von dem du die nachbauen konntest!

Btw. wenn du Linienziele haben möchtest: Ich wäre ja stark für S9 Bottrop Hbf oder die Gegenrichtung S9 Wuppertal Hbf.
Deutlich bekannter dürfte aber S1 Dortmund Hbf / Solingen Hbf bzw. S2 Dortmund Hbf sein.

Wenn du den Plan suchst der im Innenraum hängt: das ist wenn ich mich recht erinnern kann der da:
https://www.vrr.de/imperia/md/…chienenschnellverkehr.pdf

Und: Nach harten Bemühungen doch noch einen etwas zu finden was man bemängeln könnte, habe ich festgestellt, dass die Form unten drunter noch nicht ganz hinhaut
Da fehlt dieser, ich taufe ihn einfach mal so, "Schneeschieber"
http://www.ostbahn.org/baureihen/110610_422059.jpg

Ist aber echt super geworden das Modell, bin begeistert!

Problem gefunden und (lokal) behoben. Die Version von tom_edgeutil_v1_0 scheint sich bei den beiden mods zu unterscheiden, obwohl der Name erahnen lässt, dass es sich um die gleiche Version handeln sollte.
Das Problem wird mit dem nächsten größeren update am Wochenende behoben.

Bis dahin kann man das Problem selber beheben, indem man einfach die tom_edgeutil_v1_0.lua von der Unterführung löscht.
Diese verwendet das script schon längere Zeit nicht mehr, es wurde schlicht beim Aufräumen übersehen.

@kaleut1988 also wenn es nur um die Abneigung geht, kannst du ja einfach die BR 426 machen, dann wird sich schon jemand ohne Abneigung finden der dazu Mittelwagen macht und den panto auf einen der Mittelwagen verschiebt, das ist nämlich technisch und optisch einfach nur eine 2-teilige Version der BR 425

"Mal eben so" auf der Heimfahrt entstanden... ich flieg gleich weg.
Echt super wie du quasi am Fließband neue repaints raus haust.