Beiträge von WernerK

Hast du es mal mit anderen Fahrzeugen getestet?

Ja. Die Änderung bezieht sich in der Tat auf Version 1.3BETA. Wenn du möchstest, könntest du vorher noch eine Kopie machen und zu deiner eigenen Unterscheidung in der mod.lua unter minorVersion eine 4 eintragen.

Viele Skript-Probleme lassen sich leider nur durch Raten und Probieren lösen. Wie auch sonst, wenn kaum etwas dokumentiert ist. Ich hatte mich auch gewundert, dass mit ESC kein Absturz stattfindet, und umgekehrt, dass die Löschverzögerung bei ESC nicht zu stören scheint. Meine Theorie ist, dass da zwar dieselben Events stattfinden, aber in anderer zeitlicher Reihenfolge. Dass der Button nicht zum Menü gehört, ist möglicherweise egal, er ist auf jeden Fall vom Redraw betroffen und wird zu diesem Zweck - vermutlich - vom Hauptprogramm irgendwie gecached, gelöscht und dann wieder hingemalt.

Nach der Theorie von eis_os betrachtet das Hauptprogramm den Tooltip-Container darüber hinaus ohnehin als sein Eigentum. Ich habe mich immer schon gefragt, ob man den so einfach für eigene Zwecke missbrauchen darf, und ob es nicht Alternativen zum ständigen Löschen und Re-Initialisieren gibt. Für die meisten Fälle würde eine simple verschiebbare Box reichen. Da ich selber mit dem Tooltip arbeite, hatte ich da mal herumexperimentiert, konnte aber kein brauchbares Ergebnis erzielen. Und da ich bis auf den Aufwand für Initialisieren und Löschen bislang keine Probleme hatte, habe ich mir auch keine neuen schaffen wollen.

Mach ich doch gerne.

Die Zeilen 138 bis 147 sind wie folgt zu ersetzen:

elseif (id=="menu.construction" and name=="tabWidget.currentChanged") then
tb.destroy(true)
elseif (id=="menu.construction.railmenu" and name=="visibilityChange" and param==false) or
(id=="menu.construction.roadmenu" and name=="visibilityChange" and param==false) or
(id=="menu.construction.rail.tabs" and name=="tabWidget.currentChanged") or
(id=="menu.construction.road.tabs" and name=="tabWidget.currentChanged") or
(id=="menu.construction.terrain.tabs" and name=="tabWidget.currentChanged") or
(id=="menu.bulldozer" and name=="toggleButton.toggle") then
tb.destroy()
end

Wie gesagt, das ist bislang problemlos bei mir gelaufen, dennoch alles ohne Gewähr.

Die Erklärung: Während das Menü-Fenster geschlossen wird, greift auch das Spiel auf dessen Elemente zu und somit auch auf den blauen Button. Deswegen darf die Abmeldung durch das Skript erst später erfolgen. Mit tb.destroy(true) wird dies ausgelöst, wobei auf zufällig schon vorhandenen Code in der entsprechenden Funktion zurückgegriffen wird. In den anderen Fällen geht das nicht; da muss alles so bleiben wie gehabt, deswegen die Fallunterscheidung.

Ich hoffe natürlich auch auf eine Lösung jenseits des Workaround-Buttons in der Bottom-Leiste, die möglichst schnell und nicht allzu halbherzig von UG unterstützt wird. BwC ist nun schließlich eine nicht ganz unwichtige Mod. Andererseits funktioniert mein rein privates Patch so gut, dass ich es als Übergangslösung nahelegen würde. Zumal die Sache mit dem X auch dann durchschlägt, wenn du gerade einmal nicht daran denkst. Crash Backup ist da auch nicht, soweit ich mich erinnere.

Die allerbeste Lösung wäre für mich allerdings, wenn UG einen kollisionsfreien Bau-Modus fest ins Spiel integrieren würde.

VacuumTube: Hattest du dir mal meine "1.4" angesehen?

Praktikabel wäre das theoretisch schon, aber mit recht hohem Aufwand. Die Ladegut-Typen sind nicht nur einzelne Wörter in einer klitzekleinen Tabelle, wo du mal eben schnell was austauschen kannst - das wäre zu einfach. Jedes Ladegut ist gleichzeitig mit seiner Kapazität vernüpft, und beides zusammen steht mit vielen weiteren Angaben, wo die Ladung denn im Fahrzeug hinkommen soll, in einer Tabelle. Diese Tabelle gibt es für jedes Ladegut, und zu allem Überfluss gibt es noch je nach Fahrzeugtyp drei unterschiedliche Datenstrukturen. Im Vehicle Tweaker kann ich ein komplettes Ladegut löschen, indem ich dessen Teil-Tabelle einfach eliminiere, d.h. auf nil setze. Um aber Parameter zuzuweisen oder zu ändern, musst du sehr gezielt auf bestimmte Bereiche dieser Tabelle(n) zugreifen, und das geht eben nicht "mal eben". Natürlich könnte man auch mal schnell z.B. "STEEL" gegen "ALCOHOL" austauschen, aber das wäre sicher nicht im Sinne des Erfinders. Falls jemand aber Lust hat, das trotz dieser Vorwarnung in der gesamten Variationsbreite mal zu skripten, kann ich gerne auch den Code in den Vehicle Tweaker übernehmen, ich selber werde da aber vorläufig nichts machen, da noch viele andere Projekte auf Eis liegen, und mich leider auch die Update-Anpassungen der letzten Wochen und die Beseitigung des Lagging-Bugs in diversen Tools eine Menge Zeit gekostet haben.

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.