Build with Collision

Willkommen in der Transport Fever Community

Wir begrüßen euch in der Fan-Community zu den Spielen Transport Fever und Train Fever, den Wirtschaftssimulatoren von Urban Games. Die Community steht euch kostenlos zur Verfügung damit ihr euch über das Spiel austauschen und informieren könnt. Wir pflegen hier einen freundlichen und sachlichen Umgang untereinander und unser Team steht euch in allen Fragen gerne beiseite.

 

Die Registrierung und Nutzung ist selbstverständlich kostenlos.

 

Wir wünschen euch viel Spaß und hoffen auf rege Beteiligung.

Das Team der Transport-Fever Community


  • Ein Fehler in einer Fehlerbehandlungsroutine wird sich tatsächlich sehr selten bemerkbar machen. ;-) Sowas bekomme ich aber auch hin. :-) Ich stolpere häufig über einfache Gleichheitszeichen bei Konditionen und versuche, FOR-Schleifen mit NEXT abzuschließen, weil ich früher sehr viel in BASIC programmiert habe.

    ... don't know much trigonometry ... don't know much about algebra ... don't know what a slide rule is for ...

  • Wie kommst du drauf das Emiliocat nicht die Steamversion nutzt?

    Na mir geht es um die Mod. Und da nutzt er laut stdout die Forumsversion: Build_with_collision/1 (1) (Build with Collision)

    Daher ist das in dem Kontext verwirrend.

    Ob Steam oder Gog ist ja egal. Höchstens auf die Build Nr kommt es an, aber auch nur in Sonderfällen und aktuell gibt es eh keine Updates.


    Damit auch ein lua Laie wie ich das mal versteht, wenn das so wäre und es so sein muss, wieso hat dann nur ein Nutzer von 1000 einen Absturz? Er wird ja wohl kaum der einzige sein der Windows benutzt.

    Gerne erkläre ich den Fehler, da ich auch gestern lange nachforschen musste, was eigentlich das Problem ist.

    Wie es in solchen Fällen eben passieren kann, ist die Ursache eine Verkettung von seltenen Umständen.


    Zunächst zu der Aussage, es wäre ein Groß/Kleinschreibung Problem mit Windows/Linux: Das gilt nur für Dateinamen. Nicht für Lua Variablen.


    Ein Fehler in einer Fehlerbehandlungsroutine wird sich tatsächlich sehr selten bemerkbar machen.

    Das stimmt grundsätzlich und ist der 1. Grund, warum der Fehler selten auftritt. Die Stelle wo der Fehler passiert, wird nur ausgeführt, wenn das "Build Anyway" Proposal schiefgeht und nicht ausgeführt werden kann (critical=true). Das passiert anscheinend nur bei Straßen Upgrades und auch da nur selten. Warum weiß ich auch nicht. Man könnte das einfach ignorieren, ich schreibe aber noch etwas in die stdout in dem Fall.


    Ich habe diesen Fall jedoch bei mir natürlich getestet und es hat alles ordnungsgemäß funktioniert.


    Das sehe ich wohl auch so, tostring ist ja eher von .net

    tostring ist eine Standard Lua Funktion und immer verfügbar. Sie ist leider nicht besonders brauchbar, da man damit keine tables darstellen kann.


    In TPF2 gibt es auch noch toString, diese Funktion wird in serialize.lua definiert (als globale Variable).

    Die habe ich in der Vergangenheit öfter ohne Probleme genutzt. toString ist etwas flexibler als debugPrint, da man damit auch einfach mehrere Sachen gleichzeitig printen kann.


    toString() ist hier tatsächlich nicht definiert.

    Warum gab es jetzt bei mir toString und bei ihm nicht?

    Ich habe meinen Testspielstand nur mit BWC geladen und konnte den Fehler direkt reproduzieren. Dann habe ich nach und nach Mods dazugeladen und getestet. Tatsächlich ergibt sich ein sehr verwunderliches Verhalten wenn man zum Testen in die Konsolte debugPrint(toString) eingibt: Zuerst ist es false aber wenn man es nochmal eingibt ist es <function>.


    Warum??

    Dazu werfen wir einen Blick in die init.lua. Diese wird von TPF Seite aus zum Initialisierung eines Lua Threads ausgeführt. Dabei werden jede Menge globale Variablen und Funktionen, die in TPF verwendet werden definiert, die über die Standard Library von Lua hinausgehen. Zb table.copy, string.starts, math.round oder die Übersetzungsfunktion. (Übrigens: jeder Modder kann diese Funktionen guten Gewissens verwenden, da sie ja immer vorhanden sind). Und eben auch debugPrint:


    Warum UG hier das require "serialize" innerhalb der debugPrint funktion hat: keine Ahnung. Jedenfalls erklärt das auch das seltsame Verhalten.

    D.h. Erst falls irgendeine andere Mod erstmalig debugPrint aufgerufen hat, ist toString definiert!


    Der Fix ist also recht einfach: https://github.com/Vacuum-Tube…0102f56d7c82011ece685ff5a

  • Falls es interessiert:

    - toString wird in serialize.lua definiert.
    - debugPrint wird in init.lua definiert und sieht so aus:

    function debugPrint(x)

    require "serialize"

    print(toString(x))

    end
    -- Man kann dann getröstet debugPrint() verwenden, anstatt toString()
    - tableutil.lua definiert noch eine Funktion table.toString(t, lvl)

    Einmal editiert, zuletzt von lollus ()

  • Das Problem ist mal wieder die Doku von UG, was sie als default env definieren.


    Da debugPrint von UG nicht wirklich genutzt wird, kann man sich das require beim laden sparen.

    init.lua wird in jedem neuen UG State ausgeführt. Jetzt optimiert UG halt mal was, das ist auch wieder nicht gut ;) (So etwas ist aber gängige Praxis, das man via require nur dann lädt, wenn man es braucht)


    Das UG selber den globalen Namespace so verbraucht, es wäre nie zu einem Problem gekommen, wenn UG toString als Funktion des Moduls definiert hätte und es auch so dokumentiert.

  • Laden von require "serialize" dauert bei mir 20ms. Also hält sich die Optimierung in Grenzen. Außerdem wird es ja gebraucht, spätestens beim Speichern.


    Joa eine Doku Übersicht von allen globalen Funktionen, die verwendet werden können, wäre sicherlich eine nette Sache.

  • ich ändere gleich mal den settings.lua eintrag 'experimentalTunnelAndBridgeMinHeight' auf true.. ich erinnere mich, daß in einem anderem fred ein user darüber halb ins schwärmen geriet.. bin also mal gespannt, was mich erwartet, wenn ichs entdeckt habe ^^

    ich tippe mal, mit dieser einstellung könnte man in einigen fällen ohne 'build_with_collision' bzw zeroheightbridge auskommen..!?!

  • Zitat

    ich ändere gleich mal den settings.lua eintrag 'experimentalTunnelAndBridgeMinHeight' auf true

    Ich hab das auch mal getan, und es ist nichts passiert - auch nicht nach einem kompletten Neustart. :( Hab ich was falsch gemacht :/:?: Sollte es bei irgendjemandem klappen, bitte mal schreiben, wie.

    ... don't know much trigonometry ... don't know much about algebra ... don't know what a slide rule is for ...

  • man könnte fast meinen , das man wenn man das Bild jetzt so anschaut, keine steilen Begrenzungen gibt ^^^^:P:/




    ob das mit den Einstellungen zusammen hängt, als ich auf true gesetzt habe... Keine Ahnung. Aber ein Slider mit der min. und max. Höhe sei es beim Tunnel oder Brücke ist sinnlos, wenn es nicht funktioniert. Hab sogar nen neues Spiel angesetzt und den Cache geleert.

  • Aaah ja, jetzt habe ich die Slider gefunden. 8)


    Es ist immer wieder erstaunlich, wie lange es dauert, bis solche Features eingebaut sind. Das einzige, was gegen niedrige Brücken spricht, ist die Rauchwolke oberhalb einer niedrigen Brücke, wenn eine Dampflok darunter durchfährt. Ist aber weniger schlimm als zu lange oder zu steile Brückenrampen ;-)


    Was natürlich schade ist, dass sich immer noch nicht die Höhe der Tunnelwände ändern lässt. Also wohl nach wie vor keine Chance für niedrige Feldbahn-Tunnels.

    ... don't know much trigonometry ... don't know much about algebra ... don't know what a slide rule is for ...

  • Ich hab das auch mal getan, und es ist nichts passiert - auch nicht nach einem kompletten Neustart. :( Hab ich was falsch gemacht :/:?: Sollte es bei irgendjemandem klappen, bitte mal schreiben, wie.

    ich habs ebenfalls geändert, dann geladen und das slidermenü war gleich da. wenn ich nix durcheinandergebracht habe, konnte ich bei strassen etwas rausholen, wie man im bild sieht. daneben die höhe, die ich beim default-wert hätte haben müssen, damit ki ne brücke zieht. bei tunnels hab ich keinen unterschied ausmachen können. merkt man gleich, wenn man bei vorhandener unterführung den tunnelregler nach links (<m) zieht und die unterführung switcht nicht zum tunnel. bei den brücken war das so (umgekehrt).

    nochmal kurz ne frage zum posten: wollte nen kleineres bild hier reinhauen (hätte gereicht), aber ich bekomms mit paint zwar kleiner, aber beim öffnen ist lediglich das bild im bild klein, mit dem rest weiße fläche?!?

    ich habe solange versuchgt zu verkleinern, daß du inzwischen längst selbst erfolgreich warst :-D

    Einmal editiert, zuletzt von ModSpotter () aus folgendem Grund: schreibfehler

  • Moin ;)

    Das ist ehrlich gesagt das falsche Thema oder gibt es einen Zusammenhang zu Build with collision?


    Das war eigentlich nie so, aber ich vermute eher, dass hier entweder andere Mods mit reinspielen, oder das letzte Spielupdate, da hat sich doch in der Richtung was geändert.

  • VacuumTube Hatte den anderen Beitrag gesucht aber nicht gefunden, deswegen hab ich es hier reingetan, verzeih mir. Das ist aber volldoof, ehrlich gesagt. (Moderator bitte verschieben in den richtigen Themenbeitrag, danke)


    Ich schau mal und starte ein spiel ohne alles nur mit deiner Mod.


    Wäre schon sehr gut wenn es rausgefunden wird, woran es liegt. Geb Dir Bescheid wenn ich das neue Spiel gestartet habe.

  • Eine Testversion für die aktuelle Beta


    Wie ihr gemerkt habt, lässt sich der Button bei Konstruktionen nicht mehr klicken.

    Jetzt ist dieser immer direkt unter dem Cursor.

BlueBrixx