Posts by eis_os

Willkommen in der Transport Fever Community

Welcome to the fan community of Transport Fever and Train Fever, the economic simulators of Urban Games. The community is free for you to share and inform yourself about the game. We cultivate a friendly and objective interaction with each other and our team will be happy to answer any questions you may have.

 

Registration and use is of course free for you.

 

We wish you a lot of fun and hope for active participation.

The Team of the Transport-Fever Community

    Da ich gefragt wurde, bezüglich wenn ich wieder eine neue Release hochlade.


    Ich arbeite an einer Funktion damit Fahrzeuge wieder zurück zur ersten Haltestelle zurückkehren wenn sie leer sind.

    Die Fahrzeuge kehren auch alle brav vorzeitg zur ersten Haltestelle zurück, nur das Spiel kommt intern so stark durcheinander, das es unter Linux wahllos Speicher freigibt ;(


    Also was macht man dann in so einem Fall?

    Man denkt sich, nutze besser UGs apis (auch via UG Console):

    Code
    1. >> cmd = api.cmd.make.setLine(77925, 69818, 0)
    2. >> api.cmd.sendCommand(cmd, function(a, b) commonapi.dmp(a); commonapi.dmp(b); end ) nil
    3. { vehicleEntity = 77925, lineEntity = 69818, stopIndex = 0, <metatable> = <__type.name: CmdData::SetLine>
    4. }
    5. true


    Nur, es passiert natürlich mal wieder gar nichts, dem Fahrzeug ist es egal, obwohl die API true zurückgibt...


    * Hintergrundinfo:

    CommonAPI2 gibt ein neues Script Event heraus wenn ein Fahrzeug ein neues Ziel wählt, das könnten andere Mods auch nutzen. (Timetables zum Beispiel)

    Ich möchte es nutzen um meines LKWs Leerfahrten zu vermeiden...

    Wenn es Vulkan ist, braucht die einmalige Texturkompression teilweise recht lange ohne Info. (siehe dazu auch stdout.txt).

    Ich habe die Steam 32019 und >20210310 unter Linux und Windows bis dato mindestens 500 mal gestartet und sehe keine Hinweise auf Probleme im Renderer.

    Und du kannst jederzeit deinen Spielstand auch ganz ohne CommonAPI2 starten...


    Für derartige Fehlerberichte nutzt bitte den relevanten Thread. (Ohne Tests und Berichte kann ich auch keine Fehler beseitigen)


    -edit-

    Und da ihr immer meint, ich erzähle euch ein Märchen:


    Mein 3200G APU hat nur ein bisl Stress... (Nutzt bis zu 4GB Arbeitsspeicher als Video RAM) :o)

    Für was war den der ganze "testing" Zweig? Das ist die vorab Version der nächsten Version = Beta (Vulkan Beta/Testing)


    CommonAPI ist speziell, während des "Beta Test" der nächsten Version hab ich auch nen Vulkan Renderer geschrieben.

    Von einem stabilen UI Toolkit sind wir noch immer entfernt, aber jede neue Version repariert hier und da Sachen.

    Gegenüber dem Modding Update sind nun weite Teile brauchbar. Die Zugziel UI ist daher mittlerweile im Linienmanager, das ist erst seit dem Vulkanupdate überhaupt machbar.


    Ein weiteres Beispiele, die während dieser "testing" Phase behoben werden konnten: Inkompatibilitäten mit Shader Mods.

    Technisch gesehen, jein. :S


    Ein GameScript liegt im GameScript Repository in GameRes(sourcen). Eine Funktion wird in der Regel mit GameState ("das Spiel im Sinne der Spieldaten") aufgerufen.


    Das sind eine Menge C++ Funktion Closures (std::function bzw. boost), die dann gebunden an LUA Script States sind (GUI/Game) werden.


    (guiInit wird ziemlich früh geladen, daher kann man die UI auch erst wirklich beim ersten guiUpdate aufbauen)


    TPF2 benutzt mindestens zwei GameStates und load/save wird auch genutzt beim Übergang dieser beiden. Seit Dienstag kann meine CommonAPI2 Windows Dev Version so ein GameScript updateEvent via C++ Code auslösen wenn TPF2 die nächste Station eines Fahrzeugs auswählt.


    Man sollte den Skalierungsfaktor auch von einem Element ausrechnen können, das garantiert schon im UI vorhanden ist. (Zum Beispiel die Menüleiste unten). Habe aber gerade keine Zeit das mal zu testen...


    PS: Man kann den Skalierungfaktor während des Spiel ändern, das am Anfang des Spiel einmalig zu machen ist auch nicht wirklich richtig.


    Funkt bei mir, hat die Screensize des Ausgabefensters von TPF2, wenn ich im Fenster Modus Spiele ist es entsprechend der Fenstergröße. Aber das nutzt eben nicht den UI Skalierungsfaktor. (Ich hab mal die Frage via Buschfunk weitergeben)

    Fenstergröße ermitteln und dann eben ausrechnen:


    local mainView = api.gui.util.getById("mainView")

    mainView:getContentRect()


    w und h


    -edit-

    Laut meinem Notizen, ziemlich am Anfang waren die Größen aber 100% und nicht UI skaliert, ich habe es nicht mehr in letzter Zeit getestet. Sprich in TPF2 kann es sein das die Werte bei 200% UI Skalierung falsch sind...

    Nein, das ist definitiv keine Lösung. TPF2 crasht wenn LINE_DESTINATION als type geladen wird in einem Modell und die Funktionen dafür nicht im Speicher verändert werden,

    ich muss dafür extra den Type Converter patchen. Die richtige Lösung ist weiterhin:

    Code
    1. if (commonapi ~= nil and commonapi.supports and commonapi.supports("LINE_DESTINATION")) then
    2. end

    Beachten, LINE_DESTINATION ist erst wirklich aus, wenn es in der settings.lua der CommonAPI2 abgeschaltet wurde und das Spiel beendet.

    Du kannst das gerne irgendwo in ein Helper auslagern, zum Beispiel in ein Script.





    lem0th

    Wie gesagt, ich brauche die stdout.txt (auch gerne per privater Nachricht) nach der Fehlermeldung. Ich tippe darauf, das Windows den mods/irgendwas Ordner nicht zwischen zwei Partitionen verschieben kann.

    Ok, Reskins+ definiert in mod.lua:

    Code
    1. requiredMods = {
    2. { },
    3. },

    Ok, das ist etwas sehr wenig, wirft das requiredMods = { { }, }, in /Steam/steamapps/workshop/content/<userid>/2428102757/mod.lua raus, dann sollte der Fehler nicht mehr passieren. Noch besser wäre es natürlich wenn der Mod Autor da was sinnvolles reinschreibt. CommonAPI2 warnt da das die "nichts" Abhängigkeit nicht erfüllt ist.


    Ein Crash wie hier gesagt wird, kann ich aber nicht feststellen. Man muss die Warnung halt wegklicken...

    Wenn es wirklich mit der Windows Version zu einen Crash kommt, dann bitte melden. Danke.

    Not sure, what do you really mean?


    1. Stop A
    2. Stop B <--- Endstop 1
    3. Stop C
    4. Stop D <--- Endstop 2


    You can mark several stops in a line as "endstops".

    After a Bus/Train leaves Stop B, Endstop 2 will be displayed... You can mark as many endstops as you like, every stop in a a line can have it's own text. Duplicate stops at the same station can have their own text too.

    Technisch hatte ich da mal die Lösung in Sinn: Sollte Bahnsteig X besetzt sein, nutze Bahnsteig Y. Dann könnte man zum Beispiel mit einem Mittelbahnsteig Güter sowohl "links" und "rechts" laden und somit die Ladekapazität verdoppeln. Und es wäre auch kein Drama, da die Güter auf dem Bahnsteig bleiben würden. Sprich man muss die Güter nicht noch per Hubwagen durch die ganze Station transportieren.

    Auf meiner Todoliste steht:

    settings.lua in modlisten zu speichern/wiederherstellen

    UGs Savegame Mod Settings speichern/wiederherstellen


    UG behindert mich, das ich im Spiel keinen Zugriff via UG API auf ModRep erhalte, noch zu den Modlisten irgendwelche infos habe.

    Die UI ist dafür ja schon portiert, sprich, der Code wird im Failback UI im Hauptmenü genutzt und auch im CommonAPI2 Button links unten im Spiel angeboten.

    Daher sehe ich da kein Handlungsbedarf gerade etwas zu ändern.


    Wie man meinem vorherigen Post entnehmen kann, habe ich UGs Version als erstes verlinkt.


    Ich verweise mal auf: (und der TPFMM Standard ist definitiv älter)

    https://xkcd.com/927/


    Sprich, noch mehr Standards aus Nutzerseite muss es eigentlich nicht wirklich geben und von dem was ich gelesen habe, könnte man die Grundeinstellungen für Savegames via settings.lua ermöglichen, diese dann in mod.lua auslesen und damit die param defaults für UGs System füttern.