Beiträge von WernerK

Auf Steam gibt es inzwischen eine Mod namens Fahrpläne 1.2 Station Fix. Sofern ihr noch nicht auf 1.3 umgestiegen seid, könnt ihr auch damit zurechtkommen. Mir persönlich gefällt diese Mod besser als 1.3, auch deshalb, weil sie auf Anhieb das gemacht hat, was sie soll, und weil statt neuer instabiler Features erst einmal eine evolutionäre Anpassung vorgenommen wurde. Und auch, weil sie auf Steam an konstanter Stelle zu finden ist. Vorausgesetzt ist die Installation von 1.2. Dann die Fix-Mod hinzufügen, und alles läuft wieder so wie gehabt. Ihr müsst allerdings alle Fahrzeuge, die noch mit dem alten Befehl angehalten wurden, manuell freigeben, sonst bleiben sie dauerhaft stehen. Ihr könnt dazu die Abfahrtbefehle kurzzeitig deaktivieren oder - wie ich es gemacht habe, das Fahrzeug markieren, den Halte-Button drücken, ins Depot schicken, und wenn es dann fährt, wieder die alte Linie zuweisen.

Die Sache mit dem X ist gar nicht so unproblematisch. Ich wusste zunächst gar nicht, was gemeint war - aber mir ist es jetzt klar: das Schließen des Baumenüfensters mit dem Closer-Button oben rechts. Es kann nämlich auch passieren, dass auf dem Weg zu besagtem Button das noch oder wieder am Mauszeiger klebende Konstruktionsobjekt irgendwo eine zufällige Kollision auslöst, die gar nicht beabsichtigt ist und womöglich vom Menüfenster überdeckt wird. Wenn ich dann auf das X klicke, dann gibt's den Crash, übrigens ohne Fehlermeldung und Notsicherung. Ich habe lange gebraucht, bis ich BwC als Ursache ausgemacht hatte, zwischenzeitlich wurden auch Probleme bei starren Konstruktionen in meiner Gleisbauer-Mod gemeldet, auf die ich mir keinen Reim machen konnte. Dasselbe gilt übrigens nicht nur für das X, sondern für sämtliche Vorgänge, die während einer Kollision das Baumenüfenster schließen, z.B. auch Abspeichern.

Die Analyse des Problems und einen Lösungsvorschlag habe ich per Konversation an VacuumTube geschickt.

Bei meinen Tools

• Parallel-Tool
• Gleis-/Straßen-Modifizierer
• Rampen-Vergleichmäßiger
• Verbindungspunkt-Tool

traten in der Vergangenheit gelegentlich Lags auf, deren Ursache ich mir nicht erklären konnte. Inzwischen konnte ich - zumindest beim aktuellen Spiel-Update - ebenfalls solche Effekte nachvollziehen. Ursache war offesichtlich das "Nachhinken" der Infofeld-Funktion, sprich eine Asynchronizität zwischen GUI und Engine. Bei ausgeschaltetem Infofeld hakte es nämlich nicht, und das Überraschende dabei war, dass die Verzögerungen schon in Erscheinung traten, bevor der eigentliche Bearbeitungsvorgang ausgelöst wurde. Ursache hierfür waren die bei jeder Mausbewegung vorher auftretenden Rechenvorgänge. Was da soviel Rechenzeit benötigt, konnte ich noch nicht klären, jedoch habe ich jetzt eine Art Regelkreis eingebaut, der nicht notwendige Infofeld-Aktualisierungen einfach ausblendet. Ich bin mir aber nicht sicher, ob das stets einwandfrei funktioniert, deswegen das Ganze zunächst als Beta zum Testen. Beim Rampen-Vergleichmäßiger war bereits ein relativ simpler Fehler drin, deshalb bitte ggf. noch einmal auf 1.7 updaten - sorry!

Eigentlich wollte ich die Tools schon definitiv als stable freigeben, glücklicherweise ist mir noch in letzter Minute aufgefallen, dass die Ausgabe der Infofeld-Inhalte unpräzise erfolgte. Das lag daran, dass der o.g. Regelkreis auch wichtige Update-Events eliminierte. Beim Stillstand der Maus wurde oft nicht mehr der letzte Zustand wiedergegeben. Dieser konnte nur durch erneutes Verschieben der Maus aktualisiert werden. Da ich das verwirrend und somit unbefriedigend fand, habe ich noch einen Mechanismus eingebaut, der - abgesehen von wieder ein paar Events mehr - genau diesen Endzustand wiedergibt. In meinen Tests kam es trotz dieser zusätzlichen Schritte nicht zum Hängen. Sollte jemand tatsächlich noch eine Situation vorfinden, wo der Bearbeitungsvorgang länger als maximal 1 bis 2 Sekunden dauert, oder die Infofeld-Anzeige nicht mit der tatsächlichen Situation/Einstellung übereinstimmt, bitte melden!

Bastele dir notfalls eine Jokerstraße.

Ok, das hat sich dann heute abend noch geändert. Wurde auch Zeit, dass es wieder auf Steam auftaucht, denn dort - und eigentlich auch hier - ist die passende Zielgruppe. Ich persönlich finde github eher nerdig und sperrig.

Zitat von StS043

Warscheinlich haben die es satt ständig Hosenträger zum Gürtel einzubauen, damit der Murks trotzdem läuft.

Da muss der modersteller ran.

Die Fahrplan-Mod ist inzwischen repariert. Muss aber wie gehabt bei gregory365 auf github geladen werden.

Was die Datendefinition angeht, ist nicht immer der Modder schuld. Manchmal ändert auch UG heimlich die Strukturen. Vor einiger Zeit hatte ich das Vergnügen, dass bei Assets an Straßen in Modifiern urplötzlich nach Strings gefragt wurde. In der Tat müssen Asset-Einträge da jetzt mit Keys versehen werden, während das aber bei den nativen Straßen weder nötig ist noch geändert wurde. Also gleichzeitig inkonsistent + schlecht bzw. gar nicht dokumentiert. Bei diesem Update wurde so ziemlich das halbe GUI umgekrempelt, da funktionierten einige Sachen nicht mehr.

Hab gerade mal den "Deferred Proposal"-Modus getestet. Das ist wohl nur unter Settings konfigurierbar, obwohl das Konstruktionsprozesse zu beschleunigen scheint. Beim Bauen von Straßen werden z.B. die Zwischenschritte des Preview als vereinfachte Grafik dargestellt. Ich hatte allerdings auch den Eindruck, dass auch meine Tools dadurch etwas schneller funktionieren. Die wüsten stdout-Meldungen sind aber geblieben. Es kommt sogar noch irgendwas mit "ping" hinzu. Schaut es euch mal an, eigentlich finde ich, das gehört ins Spielmenü mit rein statt irgendwo in der settings-Datei vor sich hin zu schimmeln.

Aber bitte regt euch nicht über dieses sinnlose Augenkrebs-Flacker-Infofeld auf, dass auch noch exakt unter dem meiner Mods liegt.

Nein, es kommt nicht von CommonAPI, wobei ich ja weiß, dass das auch irreguläre mod.lua-Zugriffe macht. Ich habe mir jetzt mal eine mod.lua gebastelt, die nichts anderes macht, als "hallo welt" auszugeben. Da erfolgt tatsächlich eine Ausgabe, wenn ich Straßen ganz normal manuell baue. Aber auch nur an bestimmten Stellen der Map. Ich denke mal, die Map ist sektioniert, was ja grundsätzlich nicht einmal schlecht ist, und jedes Mal bei Überschreiten eines Sektors wird nach Texturen gesucht. Es scheint vor allem bei Brücken zu passieren, aber ich tappe noch ein wenig im Dunkeln. Vielleicht hängt es auch mit den "Deferred Proposals" zusammen, da muss ich wohl noch forschen.

Den Debug Mode möchte ich möglichst nicht abschalten, auch wenn es vielleicht eine Idee wäre, den brauche ich momentan verstärkt.

Zitat

Auch Mod.lua werden nur während dem Laden abgearbeitet.

Sollte eigentlich so sein, aber was ruft denn während eines Proposals eine Textausgabe auf, die nur von einer mod.lua stammen kann? Der Witz ist, eigentlich wollte ich diese Zeile schon rausschmeißen, um mich auf echte Fehlermeldungen zu beschränken, aber jetzt war es gut, dass sie noch drin ist. Ich werde da aber mal weiterforschen und ggf. mal UG fragen. Da finden - aber auch nicht immer - merkwürdige Dinge statt, und ich habe den Verdacht, dass die Zeitersparnis beim Laden des Spiels durch Verzögerungen an anderen Stellen wieder ausgeglichen wird.

stdout-Meldungen wie diese quälen mich permanent. Sie erscheinen auch, während meine Tools (z.B. Parallel-Tool) laufen und scheinen diese auch auszubremsen. Also die Frage: Ist sowas hier normal?

::C:/Program Files (x86)/Steam/userdata/1080598009/1066780/local/texture_cache/res/textures/models/industry/overlay_textures/big_01.compressed.mm.dds not in file cache!
::C:/Program Files (x86)/Steam/userdata/1080598009/1066780/local/texture_cache/res/textures/models/industry/overlay_textures/small_05.compressed.mm.dds not in file cache!
::C:/Program Files (x86)/Steam/userdata/1080598009/1066780/local/texture_cache/3B21CD99A2ACB5D8AF605B81028AF750/paving_mga.compressed.mm.dds not in file cache!
::C:/Program Files (x86)/Steam/userdata/1080598009/1066780/local/texture_cache/22F5AD12D0029EA6916D04BA1522CB9C/ripple_albedo_lod.compressed.mm.dds not in file cache!

und auch sowas:

Texture resolve error: file name without extension:
Texture resolve error: file name without extension:
Texture resolve error: file not found: models/TESTTEXUR_nrm.dds
Texture resolve error: file not found: models/TESTTEXUR_nrm.dds
Texture resolve error: file not found: models/building/House_series_II-08/II-08-3A_wd_normal.tga
Texture resolve error: file not found: models/building/era_a/res_2_borders_01_normal.dds

Hatte noch was vergessen:

WARNING: Unknown/Unsupported format used Bc7SrgbBlock in file models/railroad/crossing/crossing_crc_albedo_opacity.dds

usw. usf. (will hier ja nicht alles zumüllen , reicht, wenn die stdout das schon macht - es sind Hunderte dieser Meldungen!)

Interessanterweise wird während dieser Phase auch auf die mod.lua zugegriffen. Ich weiß das deshalb, weil da Lademeldungen von Jokerstraßen kommen. Und die kommen aus der mod.lua.

Muss ich mir jetzt ernsthafte Sorgen machen? Ich frage da auch, weil jemand auf Steam angemeckert hatte, mein Rampen-Vergleichmäßiger würde auf einmal so langsam laufen.

Meine laienhafte Theorie: Sobald ich in einem bestimmten Sektor der Map irgendwas mit Hilfe von Proposals baue, wird aufwändig nach irgendwelchen Texturen gesucht, die nicht vorhanden sind, was wiederum Zeit kostet.

Zitat von guapo298

naja, irgendetwas wurde aber im Speil geändert,

Das halbe GUI wurde geändert. Macht zwar Sinn für das Ziel der Aktion, aber dabei gab es wohl einige Kollateralschäden.

Zitat

Es macht optisch übrigens Null Unterschied welche Größe du nimmst... der verkleinert (oder vergrößert?) die immer auf ein "Standardmaß" so das alle gleich groß sind. (Nur im Classic Ui getestet)

Genau das ist das Problem: Im Controller Mode sind sie unterschiedlich groß, und das sieht extrem übel aus, besonders wenn noch extrem große und bunte Icons dabei sind. Die neue GUI ist ohnehin schon ein Design-Chaos. Wir könnten natürlich alle den Controller Mode aus Protest ignorieren, aber ich glaube, so ganz zielführend wäre das nicht.

Zitat

ja das Spiel akzeptiert jetzt Icons bis 8x ist aber kein muss.

Die Frage ist für mich eher, was aktuell Standard ist. Da möchte ich meine Mods frühzeitig dran anpassen, und mein beabsichtigtes General-Update in den nächsten Tagen wäre eine gute Gelegenheit. Die Umstellung von 28 x 28 auf 48 x 48 haben auch nur Insider mitbekommen, und die meisten dieser Icons sind jetzt halt irgendwas, und im Konsolen-Modus sieht das ziemlich chaotisch aus, mal ganz abgesehen davon, dass immer mal wieder blaue Felder auftreten oder sinnloserweise Farbicons benutzt werden. Neue Konventionen kommen leider nicht bei den Moddern an, z.B. ist eine URL in mod.lua auch eher selten anzutreffen.

Hat sich eigentlich irgendwas an den Formaten der Icons geändert? Die Kategorien waren ja zuletzt 48 x 48 groß und in Graustufen. Und was hat es mit der vierfachen Größe auf sich? Weiß jemand was? Yoshi?

Leider wird es in Zukunft schwieriger sein, Texuren und Icons zu analysieren, da sie ja alle gepackt sind. Also am besten irgendwo nochmal entpackt speichern.

BTW Werden eigentlich noch die alten Menü-Icons in einfacher Größe/Auflösung, sprich ohne @2x, für irgendwas gebraucht?

Bitte macht nicht einen beliebten Denkfehler: Tram bleibt Tram, und Zug bleibt Zug. Das sind - leider kann man nur sagen - zwei verschiedene nicht zueinander kompatible Systeme, auch wenn man da rein optisch hier und da mogeln kann.

Ich habe aktuell übrigens festgestellt, dass state-Variablen in Game Scripts nicht aktualisiert werden, wenn dasselbe Savegame gespeichert und nochmal geladen wird. Zumindest bei mir nicht. Fehler ist bereits gemeldet. Ich schreibe das hier, damit ihr vielleicht mal prüft, ob ihr dasselbe Problem habt.

Ich finde die Idee mit der dicken ultrabrutalen Warnmeldung gar nicht so schlecht. Denn der Normaluser liest sowieso keine Manuals. Aber UG wird das glaub ich nicht beeindrucken In der Tat gibt es wohl neue Maus-Events, was immerhin ein Fortschritt im Kleinen wäre. Ich muss die mal austesten, aber heute habe ich mich erst mal stundenlang mit einem dicken Bug beschäftigt.

Zitat

Ich hänge mal das Beispiel an was mir geschickt wurde.

Danke! Ich wollte dich ohnehin schon danach gefragt haben. Mit den anderen Sachen, die wohl neu zu sein scheinen, muss ich dann wohl mal rumexperimentieren. Schade, dass es da nicht auch Beispiele gibt. Die große Frage ist immer noch: Wird auch ein simpler Klick irgendwo ins MainView als Event gemeldet? Dann bräuchte ich keine unsichtbaren Konstruktionen mehr als Krücke; die haben ja auch noch den Nachteil, dass die hinterher auch wieder sauber gelöscht werden müssen, um nicht als Zombie-Modelle im Savegame ihr Dasein fristen.

Ich könnte mir natürlich die Motivation von UG vorstellen: Irgendwann beschweren sich User, die meinen, CommonAPI sei ein offizielles Tool von UG, dass irgendwas nicht funktioniert. Und dann muss UG jedesmal sagen: "Da hat jemand nicht dokumentierte Funktionen benutzt, da haben wir nichts mit zu tun." Das kann zwar auch bei anderen Mods passieren, da hat UG aber dann die Schnittstellen zumindest selber gecheckt und ist dann auch verantwortlich.

Aber trotzdem wäre es schön, wenn sich schon jemand die Mühe macht, das Spiel zu verbessern, und wenn die Community das gut findet, sich da was einfallen zu lassen und im Idealfall das selber einzubauen oder zumindest die offiziellen Schnittstellen zu verbessern. Wobei das dann und wann tatsächlich passiert, aber ich denke, da wäre noch mehr möglich.

Das beste wäre, wenn Features aus CommonAPI und auch aus anderen guten Mods ganz offiziel ins Spiel übernommen würden. Sinnvolle Linienbeschriftungen, Straßenbahnen im Mittelstreifen, Fahrpläne, Build With Collision etc. gehören einfach ins Hauptprogramm, dann entfallen auch die ständigen Anpassungsarbeiten. Es ist ja der Beweis erbracht, dass es technisch möglich ist. Die Modder würden dadurch nicht arbeitslos, sondern könnten sich schon wieder anderen Problemen widmen.