Beiträge von eis_os

Das wäre bei CommonAPI2 ggf. busMaybeTramOnly wenn CommonAPI2 läuft.

Dann fährt weder ein Auto noch ein LKW drüber. Das ist dann ne echte ÖPNV Spur. Hilfreich für Bushaltestellen, dann fahren die LKWs dran vorbei...

https://commonapi2.bytetransfe…ts?id=laneconfigcommonapi

Wobei trainOnly ein split bekommt, damit Industriegleise dann nicht mit der E-Lok befahren werden...

UG filtert die transportModes da etliche Kombinationen zu erheblichen Crashs führen.

Um eine Linie zu zeichnen, brauchst aber nix an transportModes zu ändern...

https://wiki.transportfever2.c…g:tracksstreets#materials

Da ich meinen eigenen Dampf Client API geschrieben habe, hab ich gute Chancen das ich das nicht schlimmer mache als es gerade ist und ich weiß was ich tue

Der ModHub ist das neue Teil Ingame ModBrowser. Ich kann mir auch denken warum UG das so gemacht hat, um oben Links eine % Anzeige darzustellen.

Laut SteamSDK Beschreibung kann man sonst nur auf eine Status Änderung via callback reagieren.
Das wäre https://partner.steamgames.com…ISteamUGC#ItemInstalled_t

Ich kann gefahrlos modhub::SteamModHubBackend::Init::lambda_fn(mdata); aus dem Spiel entfernen, bzw. das Interval ändern.
Man bekommt halt kein Feedback bzw. erst wenn man im Menü wieder ist oder nur alle X ms. Wie ich schon oben ausgeführt habe, hat das keine ModRep Verbindung,

Quasi macht die lambda Funktion nichts anderes als ständig die Steam API nach der Liste:

• Mutex
• ISteamUGC->GetNumSubscribedItems()
• Vector allozieren für die IDs
• ISteamUGC->GetSubscribedItems()
• Mutex
• SteamModHubBackend->flathashmap reallozieren
• Für alle IDs dann:
  • ISteamUGC->GetItemState()
  • ISteamUGC->GetItemInstallInfo() ggf. Progress?
  • Alle die Daten in eine flathashmap schreiben

D.h. es muss dann nach jedem Durchlauf mindestens 8 Bytes * ModIds für die Ids alloziert werden im Thread

Via TCP müssen mindestens jeweils ein Datenpaket zum SteamClient gesendet werden, und die Daten dann abgeholt werden.

Bei 2000 Mods hast dann schon mal 2002 Roundtrips zum Kernel, lecker.. Ach und GetItemInstallInfo holt auch den Pfad ab, wenn wir den bei 512Bytes einstellen, haben wir dann alle 200 ms 1MB durch den Kernel gejagt für nicht Spielrelevantes.

Außerdem, gibt es für alle solche Sachen einen Schalter in CommonAPI2, man muss den Fix nicht aktivieren, wenn man nicht möchte.

Keine Ahnung ob sie einen Bugreport haben wollen, manche Nutzer hatten einen Erfolg.

Ich hab mir das mal näher angeschaut und UGs Code funktioniert so:

  while ( !a1->m_modhub_steambackend->mdata->thread_should_exit )
  {
    mdata = a1->m_modhub_steambackend->mdata;
    if ( !mdata->disableSleep )
    {
      sched_yield();
      requested_time.tv_sec = 0LL;
      requested_time.tv_nsec = 200000000LL;
      while ( nanosleep(&requested_time, &requested_time) == -1 && *__errno_location() == 4 )
      {
        ;
      }
    }
    modhub::SteamModHubBackend::Init::lambda_fn(mdata);
    SteamAPI_RunCallbacks();
  }

disableSleep = 1 im Hauptmenü und wird im Spiel 0, d.h. UG bremst den thread per nanosleep aus.
Wenn ich da bei Sekunden ne 2 ms machen, mein 8600G ist mit den par Kb unterfordert so das man nix im Spiel merkt...

Ob das daher Spiel relevant ist, keine Ahnung. Es könnte sein, wenn man viele Mods im Abo hat, das sich das dann doch summiert.

Wer Linux und CommonAPI2 nutzt und alle 200ms ein Frame Einbrauch verzeichnet, dem könnte ich ggf testweise einen Patch dafür schreiben, das im Spiel nur noch nanosleep ausgeführt wird.

Alternativ Versuchsweise, dieses im Speicher / TransportFever

48 C7 45 D0 00 00 00 00 48 C7 45 D8 00 C2 EB 0B

durch dieses hier ersetzen:

48 C7 45 D0 14 00 00 00 48 C7 45 D8 00 C2 EB 0B

Das würde dann nanosleep 20ms warten lassen..

-edit-

PS: Das passiert natürlich nur mit der Steam Version. Wie viele Mods Ihr im Spielstand aktiviert habt ist unerheblich. Die Anzahl der im Workshop abonnierten Mods ist ausschlaggebend. Sprich auch eine leere Map ohne Mods. (Wie am Anfang, hat man dann halt ~8MB/s zusätzlichen Traffic intern. (Also Loopback zurm Steamclient, nicht nach außen)

Dieses ist eine Testversion, gerade bei traintracksonstreets ist ein Backup des Spielstands zu machen.

Mir geht es in letzter Zeit nicht so gut, daher erwartet bitte keine Support Leistung. (Bleibt halt bei der normalen Download Version)

This is a test version , specially traintracksonstreets should be only used with a savegame backup

I am not that healthy in the moment, please don't expect support.

Stabile Version, stable version 1.9.20251010 is here:

CommonAPI2 Download

1.9.20260315-dev

- fix CGameTime::GetGameTime1 animation stuttering on windows (bascule bridge)

- fix and enable old CommonAPI user filter settings for tracks and streets

- FlexStreets: add extradataCommonAPI for StreetType to access extradata in postRunFn (sol2 wrappers)

- FlexStreets: add setting traintracksonstreets (requires FlexStreets)

- FlexStreets: add support for own materials streetTrain, streetTrainTrack, crossingStreetTrain

- FlexStreets: simplify StreetGeneratorOverlay, add train tracks to street transition, add crossingTrainTrack materials in overlay

- FlexStreets: simplify ExtraMaterial, change memory layout, so it can be used as StreetTypeMaterial

- rename setting flexstreetstracks to traintrackcatenary

- add commonapi.supports.TRAINTRACKSONSTREETS

- inspect window: BASE_EDGE_STREET: add api.res.streetTypeRep.get to console when pressing street type

- inspect window: show MOVE_PATH entries

- inspect window: add MOVE_PATH_AIRCRAFT(hidden)

- Show currently run postRunFn mod when verbosity setting is debug

- streetTerminalCommonAPI openDoors = left: try to use right animation if left animDuration is zero

Wenn ich irgendwann dazu komme, werde ich versuchen das neue Straßenpaket dann auch noch anzuhängen ... (heute aber unwahrscheinlich)

-edit-

Entfernt wegen neuer Version / Removed because of new version

Also ich hab mal ein pcap (nur während des Spiels) in Wireshark geladen, das sieht mir während des Spiels nach einer Workshopliste aus. Zumindest das große Datenpaket.

Die ModRep hat ne std::list<std::pair<int, std::string>> m_workshopId2path; Liste, also daher sollte es nicht kommen.

Spaßeshalber hab ich - da ich Puzzle liebe - mal ein commonapi._native.dampf.getMods() gemacht,

und finde so auch die Daten TCP Steam wieder, wie Timestamp oder sizeOnDisk

  {
    folder = "/ZEUGS/Games/Steam/steamapps/workshop/content/1066780/1957631242",
    handle = 1957631242,
    sizeOnDisk = 9996549,
    timestamp = 1676107902,
  },

Sprich es gibt vom Anschein nach zumindest bei mir hier ein regen Datenaustausch zwischen Steam Ciient und Steam API im Spiel.

Ob das durch UG verursacht hat, keine Ahnung.

Wireshark:

0000479A  1a 00 00 00                                        ....
0000479E  01 20 01 00 00 00 ba 19  10 20 1c 47 10 00 (0a 15   . ...... . .G....
000047AE  af 74 00 00 00 00) 6f a6  73 24                     .t....o. s$
    0008967C  05 00 00 00                                        ....
    00089680  0b 05 00 00 00                                     .....
000047B8  1e 00 00 00                                        ....
000047BC  01 20 01 00 00 00 45 64  99 9d 1c 47 10 00 (0a 15   . ....Ed ...G....
000047CC  af 74 00 00 00 00) 00 08  00 00 03 28 ff a1         .t...... ...(..
    00089685  0e 08 00 00                                        ....
    00089689  0b 01 {05 89 98 00 00 00  00 00} 2f 5a 45 55 47 53   ........ ../ZEUGS
    00089699  2f 47 61 6d 65 73 2f 53  74 65 61 6d 2f 73 74 65   /Games/S team/ste
    000896A9  61 6d 61 70 70 73 2f 77  6f 72 6b 73 68 6f 70 2f   amapps/w orkshop/
    000896B9  63 6f 6e 74 65 6e 74 2f  31 30 36 36 37 38 30 2f   content/ 1066780/
    000896C9  31 39 35 37 36 33 31 32  34 32 00 00 00 00 00 00   19576312 42......
    000896D9  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ........ ........
...
    00089E89  00 00 00 00 00 00 00 00  00 00 [7e 60 e7 63]         ........ ..~`.c

() = WorkshopID (bzw. Handle)
{} = sizeOnDisk

[] = timeStamp

-edit-

Bin mir nun ziemlich sicher woran es liegt. Es liegt an dem neuen ModHub von UG.

Keine Ahnung was UG sich dabei gedacht hat... da gibt es halt einen Thread der ständig die Steam IPC nutzt um die ModHub Daten zu füttern.

Nur der Thread läuft auch während eines Spiels.

Urban Games macht halt Urban Games Sachen...

Ihr versteht schon, das LO Interface der Loopback Adapter ist um TCP Verbindungen zwischen Userprozesse zu ermöglichen.

Naja, ein dump wäre nur aussagekräftig während des Spiels.
Während man im Hauptmenü ist, lädt TPF2 ja ggf. noch Mods per Workshop herunter, der Traffic wäre also normal. Auch das an der Stelle TPF2 nach dem Mapping zwischen IDs und Dateipfade macht.

(Das macht CommonAPI2 ja auch sobald ne neue Liste von Mods irgendwie aktiv ist)

Bei einer Mod wird halt an verschiedenen stellen, auch in der CommonAPI2 schlussendlich eine Funktion aufgerufen, die aus der Workshop ID dann den Pfad erstellt. Das macht im Endeffekt dann die Steam API schlussendlich.

Ich könnte da wohl via CommonAPI2 einen Cache einbauen, keine Ahnung ob das sinnvoll ist. Aber was ich nicht verstehe, warum es keine Änderung zwischen einen Savegame mit Mods und ohne Steam Mods gibt.

Unter Einstellungen mal den Debug Modus von UG abstellen, speichern und Spiel komplett neu starten. (wichtig! und dann den traffic anschauen.)

Die UG LUA Console hat auch ne Funktion die irgendwie ne Modliste nutzt, ggf. gibt es dort Probleme,

Mir fällt da gerade nichts ein. Das müsste alles im selben Process laufen und daher kein lo traffic machen.

Das SteamOverlay hab ich bei mir abgeschaltet, kann also auch eigentlich nicht der Steam Browser sein.

Ja im Hauptmenü hab ich so 37MiB/s, im Spiel viel weniger.

Ich hab mal mir den Spaß gemacht und den call zu UI::CGameUI::CheckAchievements via debugger raus genommen, das hat nix geändert.

Alternativ könnte es auch noch modio Kram sein...

Im Hauptmenü oder im Spiel?

Es könnte intern die Nachfrage bei File IO sein, sprich Mapping zwischen dem virtuellen Filesystem und dann zu einem bestimmten Steam Mod. (Workshop ID zum Verzeichnis Nachfrage)

Dann gäbe es noch die Steam Achievements...

Meine Mini Testmap mit CommonAPI2 zeigt da so 179KiB/s da gerade an.

Wird es denn weniger wenn du ein Spielstand ohne Workshop Mods startest?

Auf Steam gibt es CommonAPI2 nicht,

auf Steam gibt es nur eine leeres Mod damit Spieler Ihre alten Savegames ohne Änderungen weiterspielen können.

https://commonapi2.bytetransfer.de/

Hallo

Wer mit api.type.ConstructionDesc.new() eine dynamische Konstruktion in der postRunFn erstellen möchte, wird vielleicht feststellen,

das die Funktion für preProcessScript als erstes Funktionsparameter auch capturedParams enthält.

Dies halte ich für einen Fehler / Bug seitens Urban Games. Das müsste als zusätzliche Funktionsparameter übergeben werden.

Das setzen von preProcessScript ist zwingend erforderlich, sonst kann man eine ConstructionDesc nicht hinzufügen.

Im Gegensatz ist preProcessFn in einer con nicht zwingend erforderlich und wird auch nicht benötigt wenn man eine vorhandene con Datei in der postRunFn via api ändert.

Konvertiert man seine normale funktionierende con also in eine dynamisch komplett erzeugte erhält man einen Crash bzw. internal error am cursor:

Exception type: Configuration error

This error is usually caused by modding. Some game resources contain semantically incorrect data.

Details:

Error message: key not found: name

Minidump: 

In file: urban_games/train_fever/src/Lib/lua/Value.cpp:20

In function: const class std::variant<struct lua::Nil,bool,double,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >,struct lua::Table> &__cdecl lua::Table::Get(const class std::variant<struct lua::Nil,bool,double,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >,struct lua::Table> &) const

Ihr müsst modules.capturedParams = nil setzen, Beispiel:

preProcessFnScript = function(modules, change)
    if change.added then
        modules[change.slotId] = change.module
    else
        modules[change.slotId] = nil
    end
    modules.capturedParams = nil
    return modules
end

Ich habe keine dementsprechende Information in der Dokumentation von TPF2 gefunden.

https://wiki.transportfever2.c…uction_postRunFn.lua.html

Wenn Ihr sie findet, hab ich vielleicht Tomaten auf den Augen oder UG hat die Doku geändert

Einfach eine leere Tabelle oder nil bei preProcessScript zurückgeben, wird nicht funktionieren, da man dann keine Module mehr bauen kann.

Da der Fehler eher nichtssagend ist und ich daher mein ganzes Script debuggen musste,

vielleicht stolpert ja in Zukunft jemand über diesen Beitrag und diese Info ist bei der Entwicklung eines Mods hilfreich.

PS: Nein, das hab ich nicht an UG gemeldet.

Früherer versuche UG zur Dokumentation zu bewegen sind immer gescheitert, ggf. erhält man diese Info wenn man sie kontaktiert... (das ist aber nicht hilfreich für alle anderen Modder)

Eigentlich nö, aber du kannst natürlich auch 123 als fileName nehmen, das wäre aber für Lua auch egal, schauen wir mal:

>> commonapi.dmp(api.res.trackTypeRep.getAll())
{
[0] = "eis_os_1000mm.lua",
[1] = "eis_os_1000mm_5_5m.lua",
[2] = "eis_os_750mm.lua",
[3] = "high_speed.lua",
[4] = "standard.lua",
<metatable> = <__name: sol.std::map<int, std::__cxx11::basic_string<char> >>
}

Das ist eine c++ std::map<int, std::::string> (Schlüssel können nur int annehmen, die Werte sind immer ein std::string, und daraus wird halt ein lua string)

postRunFn mit dynamischen Gleisen funktioniert genauso wie alle Repository Funktionen via Dateinamen zu ID Mapping.

Das ID Mapping übernimmt UG intern. Beachtet, es können ID Lücken entstehen... (sprich getAll ist nicht mit ipairs zu nutzen)

repository.add(fileName, resource, visible)

Wichtig ist, bei fileName etwas eindeutiges zu vergeben. Dieser sollte trotzdem, wie ein echter Dateiname keine obskuren Zeichen beinhalten...

Sollte ein Dateiname schon vergeben sein, wird TPF2 crashen, mit einem "duplicate Name" error. Typisch wird einem der Dateinamen natürlich nicht gesagt...

Also repository.find nutzen, ist das Teil schon da?

Intern hat jedes repo eine m_name2index. Die eigentlichen Einträge werden in der Regel intern mit ids angesprochen und liegen auch in einem std::vector.

Alternativ via (file)Name zum Beispiel wenn die Daten von einer Konstruktion kommen. Irgendwann wird aber trotzdem dann gemappt.

Randnotizen:

Die postRunFn Id kann sich auch von der im schlussendlich im Spiel befindlichen id unterscheiden.

Alle Texturen müssen für Straßen vorgeladen werden.

Das war früher anders und UG hat dieses dynamisch gemacht. Nachteil war, hat mein eine kaputte Straße gebaut, gab es dann einen Crash...

Bei Brücken errechnet beim Bau wohl für jeden möglichen Brückentyp die Kollisionen. Daher bitte keine X Brücken hinzufügen....

Mit CommonAPI2 erhält man ggf. mehr Informationen (Teile die UG nicht gemappt haben, bzw. bald auch extra Daten der CommonAPI2 für Straßen zumindest.)

Also du löscht den Bahnhof beim Start des Videos und die Fehlerhafte Entity gehört zu einem anderen Bahnhof?

Du nimmst auch new_mod.lua_forNEP2.3.lua ?

Du hast auch NEP² v2.3 für die TpF2 Build 35230 oder höher (aktuell Version) und nicht die 1.9 installiert?

Vielleicht hat VacuumTube als Ersteller des Mods eine Idee..

Da ist ein Ausrufezeichen, bitte schaue wie und wo NEP2 installiert wurde, ggf. hast du einen Ordner in Ordner

Nep bekommst du hier:

Natural Environment Professional 2

mods\unixroot_natural_environment_pro_tpf2_2\unixroot_natural_environment_pro_tpf2_2\

Es darf aber nur so sein.

mods\unixroot_natural_environment_pro_tpf2_2\

Das Addon benötigt eine richtig installierte Version von NEP2 und ist nicht ohne den Basismod lauffähig.

Schau erst, das NEP2 wieder von TPF2 erkannt wird.

Auch wenn sich verschiedene Bahnhöfe überschneiden visuell, eine Komponente kann nur einer Entity gehören.

Ich wüsste auch nicht -bis auf Speicherfehler - wie eine Komponente von zwei Entities genutzt werden können.

TPF2 meckert hier das ein Teil fehlt. Wobei die BaseNode 172033 von den Komponenten richtig aussieht.

Gibt es in der Nähe von 172033 irgendwelche NodeEditor Daten? Wobei dieses Lageabhängig wäre und keine weiteren Bahnhöfe beeinflussen könnte...

Wurde der Bahnhof ggf. mal verschoben mit irgendwelchen Tools?

Im Inspektor von CommonAPI2 für 172033 kannst du da ein bzw zwei Tracks auf der Karte finden?

D.h. Unter BaseNode -> Tracks:

Müssten dann für die meisten Nodes zwei Gleise auffindbar sein mit dem Auge Symbol.

Vielleicht ist eine Base Edge abhanden gekommen, auch da wäre mir kein Weg bekannt, dieses zu Triggern...

Ohne CommonAPI2 probieren.

Das sieht komisch aus:

commonapi2.utils: cannot open A:/SteamLibrary/steamapps/common/Transport Fever 2/mods/Gebäude_ElevatedStation_1/res/config/track/zzz_mock_elevated_station.lua: No such file or directory

commonapi2.utils: cannot open A:/SteamLibrary/steamapps/common/Transport Fever 2/mods/Gebäude_ElevatedStation_1/res/config/bridge/elevated_station.lua: No such file or directory

Die stdout.txt zeigt keinen Crash... Hängt das Spiel?

Die stdout.txt ist nicht von einem Crash.

(Schau einfach in die txt Datei)

Wenn die Konstruktion fehlerhaft ist, bekommst du weiterhin Probleme, du müsstest versuchen die Konstruktion zu entfernen um das Problem dauerhaft zu lösen

Ich möchte nur anmerken, das die Gleisgeschwindigkeit per Region in CommonAPI2 geändert werden kann. Schon ewig

Unfertig in CommonAPI2 kann man auch den Gleistyp von der Oberleitung trennen. (ca 20%) fertig.

Bevor hier wieder wegen paralleler Entwicklung gemeckert wird.