Gameplay-Patch angekündigt

Zwei Schritte vor, einen zurück...

Immer noch besser als das:

https://de.wikipedia.org/wiki/Sisyphos

Ich baue hauptsächlich im Pausenmodus. Zumal beim Bauen Linien unterbrochen werden um bestehende Gleisanlagen neu zu trassieren. Das sind ja trübe Aussichten.
Macht zwar Sinn die Pause zu nutzen um ausstehende Berechnungen nachzuholen, aber wenn dann der Rechner noch mehr blockiert ist das schlecht. Eigentlich sollte der Pausenmodus dazu beitragen, das es danach wieder flüssiger läuft, aber wenn dann gar nichts mehr geht. Überhaupt: Wenn das Spiel nichts zu tun hat, weil es eh gerade gestartet wurde und noch nichts zu berechnen ist, wieso läuft dann die CPU heiss?
Ich hoffe sehr, dass UG da noch mal nachbessert.

Ist es nicht normal, dass beim Start eines Spiels die Lüfter aufdrehen?
Also TPF ist da aufkeinenfall ein Einzelfall!

Zitat von eis_os

Meine Meinung nach ist das der falsche Weg, sobald die Datei wegen eines Bugfix geändert werden muss hat man dann subtil anderes Verhalten weil ein Mod eine alte Version mitbringt... hmpf.

Eine absolute Ausnahme - sollte sich an diesen Dateien künftig noch was ändern, dann so früh wie möglich in der Beta, damit jeder Modder entsprechend reagieren kann. Außerdem versuchen wir die Fehlermeldungen etwas besser zu gestalten, damit auch klar ist, wer den Fehler verursacht. Für den durchschnittlichen User sonst unmöglich, die passende Mod zu finden und zu deaktivieren.

Zitat von eis_os

Ich würde da nicht so viel Nörgeln wenn mir das Spiel nicht so sehr am Herzen liegen würde.

Das weiß ich doch - aber es trotzdem gut, es ab und an zu hören

Zitat von Railtim

Das Problem mit starken FPS-Einbrüchen beim Bauen von Schienen (insbesondere bei Kreuzungen/Weichen) kann ich leider bestätigen

Das ist bekannt und wird noch behoben.

@tomdotio
Wenn du schon Fehlermeldungen ansprichst... die sind sowohl im Spiel als auch im ModelViewer recht kryptisch. Das wäre wirklich wunderbar, wenn die sprechendere Bezeichnungen bekommen würden.

@tomdotio:

Technisch gesehen kann man für den Fall nur sehr schwer eine richtige Fehlermeldung herstellen, da das aufrufende Modell/Konstruktion ja annehmen muss das die Funktion vorhanden ist.
Man könnte theoretisch nachverfolgen welche Datei im virtuellen Dateisystem von welchen Mod überschrieben wird und dieses auch noch Ausgeben. Wobei ein Steam Mod auch nicht aussagekräftig ist.

Nur so als Anregung: Es wäre schön beim Fehlersuchen wenn Ihr zu der Mod Liste in der stdout auch noch die Bezeichnung der Mod ausgeben würdet.
Gerade bei Steam Mods sind die IDs doch etwas kryptisch und das wäre dann soweit nutzerfreundlicher wenn der Spieler dann anstatt nur modid_1 auch dann ("Bahnhof Bla Bla") herauskommt.

Vielleicht sollte ich aber mal ein paar Seiten Verbesserungsvorschläge in eine E-Mail packen und euch direkt schicken.

@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.

Ehm, die MsgBox hat einen Stacktrace, siehe hier:
Gameplay-Patch angekündigt

Der Stacktrace ist natürlich sehr kurz, da ja TPF gerade aus dem C++ Code von UG die Lua Datei lädt und der Lua Loader kennt nun mal eben nur das Virtuelle Dateisystem was UG da hat.

Die Fehlermeldungen die man bekommt sind meistens ein paar im Code verteilte Assets und geben nicht wirklich einen Grund wieder da der Code da schon weiter ist.
(Sprich der Fehler wird erst an ein ganz anderen Stelle sichtbar) Das wird aber langsam zu sehr technisch und geht zu weit hier...

-edit-
Du erwartest von LUA (was eher einfach gestaltet ist) das es für jede Funktionsaufruf einer Tabelle die Herkunft der Tabelle kennt. (Funktion hilft ja hier nicht, da die Fn ja nicht mehr definiert ist)
Um es besser noch mal zu erwähnen um Missverständnisse auszuschließen, die Collider Datei ist eine neue UG Datei aus der Beta und gehört zu keinem Mod.

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.

Folgender Fehler ist aufgetreten:

an den " slopeLow = 0, slopeHigh = 0," - Werten wurde etwas verändert -siehe folgende Meldung:

[MOD] JoeFried MODBOX / Arbeits- und Vorstellungsthread

Zitat von JoeFried

Folgender Fehler ist aufgetreten:

an den " slopeLow = 0, slopeHigh = 0," - Werten wurde etwas verändert -siehe folgende Meldung:

[MOD] JoeFried MODBOX / Arbeits- und Vorstellungsthread

This is exactly what the last -2 patch done, since in last -3 patch it leads to crash.

0 means no slope 0 (tan = 0), it's quite reasonable, since before here 0 means infinity, it put the modder lot's of time to discovery what it means and may leads to calculate error. What you need to do is to use a very large value in this place, like 1e7. Since slope means tan, 90° is mathematically impossible. (technically since the height is represented by pixmap, the range should be between 128 and -128)

@Enzojz

Vielen vielen Dank - es funktioniert - der Wert 1x10 hoch 7 wird nun von mir in die Dateien eingearbeitet.

Besser wäre es wenn UG das mal dokumentieren würde, was da hinein darf/soll. Oder eben eine Funktion für Mods damit man sagen kann man möchte eine gerade Wand haben

Would be better UG would document what values are valid. Or better directly a function so we can say we want a wall.

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...

Hey leute.

Sollte der Patch nicht heute verööfentlicht werden?Oder habe ich mich da falsch informiert?

Zitat von Freahk

"Of all attributes of which I know these mean" are hidden. ‎

And for enumerate, some values are not used in original game, for example only "EQUALS" and "LESS" are used in terrain alignment, "GREATER" is not used, I find it only by guessing between "MORE" and "GREATER", it's only 1 months after my guess they put it in mod wiki.

And at first slope = 0 has the same effect of slope = big number, that confused me a lot it's signification, at first based on the basis slope = 0 = vertical, I though it were cotan.

Zitat von xardi22

Sollte der Patch nicht heute verööfentlicht werden?

Ich glaube morgen, 26. hab ich in Erinnerung.

Nunja, wenn ich wissen möchte schaue ich mir im Zweifel die EXE Datei an ob UG das überhaupt einliest oder das Enum überhaupt existiert. Wobei wenn etwas eingelesen wird hat sagt das ja nicht unbedingt etwas über die Funktion aus. UG lädt ja die Datei und konvertiert den ganzen lua Kram dann in C++ Objekte, dann ist mein Assembler Fu aber auch nicht mehr genug um den C++ Code nachzufolgen oder ich hab da eher keine Lust zu.

Optimierter C++ Code ist da überhaupt nicht lustig. Die Lua Values werden dann per template c++ in den richtigen Typ konvertiert, dort gibt es dann Verzweigungen die Aussagen, dass etwas nicht konvertiert werden kann.
Damit hat man dann eine möglich herauszufinden ob da TPF zum Beispiel einen String mag oder es doch ein Boolean ist.

Des weiteren gibt es auch Code der zwar bestimmte Sachen akzeptiert (die params können auch eine Funktion sein) die aber das Spiel später mit einem Crash quittiert. Der C++ Code für Lua spricht auch zum Beispiel keine LUA Metatables an.
Im Endeffekt bis auf wenige Ausnahmen ist weiterhin die LUA Welt immer nur ein statischer Datenlieferant, dieser wird dann erst mal ausgelesen und dann in UG kompatible Objekte bzw. Bauanweisungen konvertiert. Diese Konvertierung kann auch für das Spiel recht unsinnige Werte annehmen, das sehen wir dann meistens als Crash beim Laden oder Bauen.

Ausnahme: game.interface dort kann man wirklich Einfluss auf die Map nehmen. Da darf man sogar die Werte der Parameter einer gebauten Konstruktion ändern, aber in einer Update Funktion einer Konstruktion können wir keinen Einfluss nehmen. Das Ärgert mich schon ...