Beiträge von eis_os

-edit ausgelagert in eigene Nachricht -

Erstmal etwas generelles: Es gibt in TPF2 Straßen und Eisenbahngleise

Straßen haben einschaltbare Tramgleise mit Oberleitung und Masten.(Poles)

https://www.transportfever2.co…ing:tracksstreets#streets

Wenn du in TPF2 sagst, eine Straße solle bitte Tramgleise haben, werden noch Trammaterialen gerendert, bei "Elektrisch" gibt es noch Oberleitung mit Masten.

Sowohl Trammaterial für die Schiene, die Oberleitung und die Masten werden in der Straße definiert

Möchtest du also eine Straße haben mit 1000mm Tramgleise und 1435mm, musst du die Straßen verdoppeln und die Materialien ändern,

bei 10 Straßen brauchst du 10*2 Typen = 20 Stück!

CommonAPI2 Newstreets hat noch einen neuen Typ neben Straßen: Tramgleise (diese werden auf Straßen genutzt)

Ein Tramgleis kann nun nicht nur die Materialen sondern auch die Erstellung der Oberleitung überschreiben:

http://commonapi2.bytetransfer.de/#/modding/TramTracks

Hast du nun ein Tramgleis "1435mm" dann kannst du das nun beim Straßenbau auswählen,

du hast 10 Straßen mit 1000mm Gleisen ganz normal definiert. Kannst diese aber auch mit Tramgleis 1435mm bauen

Du kannst nun beim Bauen mit CommonAPI2 newstreets sagen:

Bau mir nun die Straße aber mit Tramgleis 1435mm.

Die Straße ist dabei egal, daher ist ein Tramgleis nicht an eine bestimme Straße gebunden.

Warum das UG nicht so von Anfang an gemacht hat, keine Ahnung... (Funfact, TPF nennt das intern sowieso tramTrackType https://www.transportfever2.co…tructionbasics#edge_lists)

Ich finde die Trennung viel logischer. Dem Schienenhersteller bzw. Verkehrsgesellschaft ist es doch egal wie der Asphalt bzw. Gehweg einer Straße aussieht...

Und ja, ich habe keine Maste in meinem Paket.

Wenn das hier halt nix wird, bin ich geneigt meinen eigenen Mastbauer anzubieten... und nein Werners Baukasten funktioniert bei meinen Straßen nicht.

Die Assets gehen, aber da fehlen halt die Isolatoren oder die Verbindungen zwischen den Masten und den Fahrdraht. Die Automatische Erstellung geht bei meinem breiten Straßen gar nicht.
Hier hätte ich auch lieber nur Masten im Grünstreifen, sind halt andere Anforderungen.

Wenn mir also jemand Masten anbieten könnte, inkl. Isolatoren wäre ich schon happy und mach dann halt mein eigenes Konstruktionssystem... Vielleicht kann ich ja mal einen Prototypen basteln...

Ganz einfach:

Auto Tram Elektrisch benutzen die Oberleitung & Masten der jeweilig Straßen.

Danach ist alles "elektrisch" für Fahrzeuge, einer ladbaren Konfiguration für Gleise aus res/capi_config/tramtrack/

Die Details könnt Ihr meinem Handbuch entnehmen, dir steht es frei eigene Konfigurationen anzubieten (in eigene Mods, CommonAPI2 lädt das dann analog zu anderen Ressourcen):

http://commonapi2.bytetransfer.de/#/modding/TramTracks

Irgendwann wird das Menü halt unübersichtlich und das System kann ich quasi nicht groß ändern. Dropdown war nur mir gut zureden möglich.

Anstatt Dummy Poles zu rendern, wird bei hasCatenaryPoles = false nur noch die Oberleitung gerendert, keine Isolatoren oder sonst noch irgendwelche Leitungen.

hasTramTrack = false schaltet die Tram Texturen ab.
hasOwnTramTrack / hasOwnCatenary sagt aus, überschreibe Gleisematerialen/Oberleitung der Straße

Im Endeffekt hast du dann einerseits eine Straße und irgendein Gleispaket mit Oberleitungskonfiguration.

An der Umsetzung aller Ecken und Kanten bin ich noch dabei, aber es läuft eigentlich schon recht gut.

-edit-

Da es für "Nur Fahrleitung" keine Masten gibt, würde ich gerne ein generelles Paket nur mit einem Mastbauer haben, den wir übergreifend Nutzen können.

Zum besseren Verständnis, das sind keine Straßen.

CommonAPI2 trennt Tramgleise & Straßen.

Du kannst also auch die Gleise wegschalten und quasi ne Obuslinie bauen, oder andere Wilde Sachen. Auch sind damit zwei Spurweiten möglich ohne das es eine Straßentypexplosion gibt.

Mit CommonAPI2 wird wirklich nur der Fahrdraht gerendert.

Damit sind dann zum Beispiel Einzelmasten in der Mitte möglich.

https://commonapi2.bytetransfe…racks?id=hascatenarypoles

In meinem Tramtrackpaket gibt es auch elektrifizierte Gleise ohne Fahrdraht,

das wäre dann zum Beispiel Akkutrams interessant oder an Bahnübergängen.

Leider hab ich einen kompletten Renderer zusammen, somit ist die Fahrdrahthöhe noch fest.

Und wenn es um Performance geht:

Seit dem Herbst Update von TPF2 werden alle Straßen in TPF2 komplett geladen. Also 1000 Straßen zu erstellen ist auch nicht der Hit...

Damit wird verhindert, das die Engine während des Spiel crasht weil Texturen einer Straßen fehlen...

PS: Du kannst auch nur das Tramgleispaket laden mit der CommonAPI2 Funktion oder dein eigenes Tramgleis Mod erstellen.

Nochmalig öffentlich die Bitte meinerseits, die Masten als Einzelpaket als Assets anzubieten.

Die würden sich gut auch mit dem CommonAPI2 Straßen bzw. Tramgleispaket vertragen.

Also bei CommonAPI Tramgleispaket nur Oberleitung auswählen, und dann die Masten per Hand setzen.

Wie verhinderst du das zwei Bahnen auf den eingleisigen Strecken begegnen?

Technisch kannst du via CommonAPI2 eine nur Tramgleis Lane so zusammenschalten an Kreuzungen, das die Strecke in beide Richtungen genutzt wird. (ohne internes Doppelgleis).

Das Problem was ich habe ist immer noch, wie ich das hinbekomme das mit keine zwei Trams auf der Strecke begegnen...

Nach Binäranalyse sollte hasBus = true gehen

result.edgeLists = {
  {
    type = "STREET",                             
    params = {
      type = "standard/country_new_small.lua",    

      hasBus = true  -- Build 35915
    },

Da ich die UI Bilder gestern auf Windows erstellt habe, bin ich mir sicher, das die Funktion sowohl auf Linux und auch auf Windows läuft:

(Oben rechts, neben der Suche hast du den NodeEditor als Symbol und auch den Magneten für das Einrasten...

Ich gehe davon aus, CommonAPI2 fehlt im Spielstand als Mod und oder improveui ist nicht angeschaltet (1 oder 2)

Development Version 20241024 Build 35915

Now for linux too! Nun auch für Linux

Beitrag

RE: CommonAPI2 Entwicklungsdiskussion, Fragen & Antworten

Neue Version 20241024, endlich gibt es eine Linux Version.
Technisch hat das bedeutet, das ich alle Fragmente neu erstellen musste.
Daher hoffe ich mal, das UG nicht direkt wieder ne neue Version herausbringt, die alles komplett anders macht.

Da mir das Einrasten nicht immer gefällt, gibt es nun eine Funktion in improveui.
Man kann das Einrasten abschalten:
>

Damit wird intern die Tastenfunktion "Einrasten" umgedreht. Dieses gilt getrennt für Konstruktionen und Gleis/Straßenbau

Wer die Gruppierung…

eis_os

24. Oktober 2024

Neue Version 20241024, endlich gibt es eine Linux Version.

Technisch hat das bedeutet, das ich alle Fragmente neu erstellen musste.

Daher hoffe ich mal, das UG nicht direkt wieder ne neue Version herausbringt, die alles komplett anders macht.

Da mir das Einrasten nicht immer gefällt, gibt es nun eine Funktion in improveui.

Man kann das Einrasten abschalten:

>

Damit wird intern die Tastenfunktion "Einrasten" umgedreht. Dieses gilt getrennt für Konstruktionen und Gleis/Straßenbau

Wer die Gruppierung nicht mag, kann mit improveui 2 den Standard auf nicht Gruppierung umschalten.

New version 20241024, finally a linux version.

Technical I had to rebuild all fragments for all functions.

Hopefully a next version of TPF2 won't change totally again.

As I don't like the new snapping function to be enabled all time, I added a new function to improve ui.

There is a new magnet icon: >

This will invert the snapping key functionality. This setting is split between constructions and street and track building

If you don't like grouping by default, now it's possible to use improveui 2

1.9.20241024-dev

- !!! BUILD 35915 Linux and Windows only !!!

- !!! THIS IS A DEVELOPMENT VERSION, backups required !!!

- Fixed all linux fragments

- improveui: disable grouping with improveui setting 2

- improveui: add new toggle button to switch snapping

- UIHacks: add internal lua interface to invert constructNoSnap key meaning for ConstructionBuilder and StreetBuilder

-edit-

Removed old version, please check the news thread.

Alte Version entfernt, bitte die neusten Nachrichten anschauen.

Ganz simple einfache Fragen:

Wenn UG die API Funktion der UI ändert via Update, nun einen anderen Art Parameter erhalten möchte und das nicht im Changelog vermerkt. Ist das dann der Fehler eines Mod Authors?

Wenn du eine API anbietest und du nirgends öffentlich ansagst, das deine API Bindung Probleme hat und man das nur mit temporären Zwischenvariablen lösen kann? Ist das ein Fehler eines Mod Erstellers?

In der Zeit der Entwicklung des Mods hat die UI noch sehr komische Sachen gemacht...

Und so eine API anzubieten ist nicht einfach.

Ich kämpfe da selber ständig mit in der CommonAPI2. Ich kenne beide Seiten und erlaube mir daher ein Urteil.

-edit-

Da ich da nicht noch weiter ausholen möchte, nein ich denke da Beispiele in der Community, die keine wirkliche Hilfe von UG bekommen haben, bzw. nicht hilfreich waren...

Auf den Fork hatte ich schon verwiesen.

Das liegt an der Natur der Sache wenn man mit Pointern arbeitet eines Iterators.

Noch schlimmer wird es wenn du einen Crash erzeugen kannst,

wenn du Daten von der API erhältst und dann nicht wieder in die selbe API kippen darfst.

Mein VehicleScript Objekt in LUA darf eine Kopie der Daten machen damit ich einen Zug ändern kann. Alle anderen Versuche haben da Fehler produziert.

Wenn man dann keinen Support durch UG erhält , bzw. der Support selber nicht weiß warum etwas passiert, ist das etwas bescheiden.

Zum Beispiel hat die UI des Build Cursors (zum Akzeptieren/Abbrechen) einen eigenen UI Manager. D.h. Angebunden UI Elemente müssten theoretisch eine eigene LUA Runtime erhalten, damit da nix durcheinander kommt.

Es gibt bei UG wohl geschätzt zwei Angestellte, dir das beantworten könnten.

Man kann mit einer instabilen API nicht arbeiten. Wenn man nicht viel Zeit investieren möchte, bleibt eigentlich nur die Entwicklung eines Mods nicht weiter zu verfolgen. Das API Funktionen offensichtlich kaputt gemacht werden ist dann noch ein anderes Thema. UGs Lösung. Der LUA Thread wird ohne Fehlermeldung abgebrochen! Sehr toll beim Debuggen...

Das ich offensichtlich Böse werden muss und das an die große Glocke hängen muss, das ist dann auch Übel.

Beispiel: mod.lua Parameter Crash bei doppeltem Key. Das hätte UG debuggen können, es war Ihnen egal. Irgendwann musste ich sehr unfreundlich werden, weil CommonAPI2 immer beschuldigt wurde, diesen Fehler zu produzieren....

Hier ein Beispiel, das nirgends im "Handbuch" steht und recht schnell komplex wird:

Du darfst keinen Zeiger zu Entity Daten über GameScript Funktionsgrenzen halten.

Warum?

Nehmen wir an UG, bindet via Sol eine API, der dir zu einem c++ vector<irgendwasausdenentitysystem> zeigt.

Du baust dann ein sehr einfachen LUA code

local d = getIrgendEtwasAusDemEntitySystem()

p = d[1]

<Aufruf nach einem Update der UI>

print(p.irgendwas)

Was ist nun p?

Ein sol Objekt das auf ein Element im Vector im Arbeitsspeicher zeigt, ggf. ist es ein Const Pointer. Sprich du darfst es selber nicht mal ändern über die Schnittstelle.

Was passiert wenn du nun d irgendwie änderst durch eine andere API, du fügst ein Element hinzu?

- Wenn der C++ Vector noch groß genug ist, bleibt alles gut

- Wenn der C++ Vector nicht groß genug ist, wird ein neuer Speicher alloziert und die Daten + das neue Element dort hin kopiert. p ist nun im Eimer.

In C++ heißt es, das Iteratoren oder Pointer invalid werden, das bekommt man aber nirgends zur Laufzeit mitgeteilt. das steht im Handbuch deiner STL Library deines Compilers.

Ok, du sagst ich ändere ja im UI Thread mit keiner API diesen vector.

Was passiert aber nach dem Aufruf einer Funktion im UI Thread deines GameScript?

Vielleicht erst mal gar nichts, weil das Teil im UI Bereich liegt, aber wenn durch Userinteraktion irgendwo der Vector verändert wird?

Dein LUA Sol Lua Objekt zeigt nun ggf. auf einen validen anderen Eintrag, ggf. auf etwas anderes im Arbeitsspeicher oder gar nichts. Bravo, dein Game Script im UI Thread ist instabil geworden.

Was passiert wenn dein Pointer auf Entity Daten zeigen?

- GameScript UI Funktion wird aufgerufen

- Spiel läuft weiter

- Neue Daten werden von Simulations/Script Thread -> zum UI Thread kopiert.

- Deine UI Funktion wird aufgerufen.

- p.irgendwas

*Kaboom*

Für LUA und SOL hat sich eigentlich nichts geändert.

Nunja, aber die Welt drumherum hat sich massiv geändert, du hast eine neue Kopie der Daten im Arbeitsspeicher an ggf. einem ganz anderem Ort!

Dein Pointer zeigt irgendwo hin...

Schauen wir mal das ganze bei einem Game Tick an:

-GameScript Simulations Thread Funktion wird aufgerufen:

- Spiel läuft weiter

- <irgendwas passiert hier>

- Deine Funktion wird erneut aufgerufen.

- p.irgendwas

*Kaboom*

Jetzt die große Frage? Passiert das ständig, nein. Wenn deine Daten im Vector immer noch am selben Platz liegen kannst du 1000 Spieljahre durchlaufen lassen, dein Mod funktioniert. Ist p.irgendwas als Integer gebunden, bekommst du halt mal falsche Daten. Als float, kann es dir passieren das du den Pointer als Float nicht lesen kannst. Das mag dein CPU gar nicht und du bekommst ein Exception.

Du hast nun ein Spieler, der 1 Zug mehr hat oder irgendwas macht. Der Vector muss größer werden und liegt an einem anderen Platz.

Und nein, das kann dir auch keine KI richten oder erklären...

Ich spiele TPF2 eher auf Linux als auf Windows, Savegames sind kompatibel (selbe Build nutzen!) Mods in der Regel auch, Dateinamen waren halt problematisch. Seit TPF2 mehr auf UTF8 achtet, hat sich das aber verbessert. (Spiele aber mit nur wenig Mods)

Auch zwischen GOG und Steam kann ich problemlos Zeugs verschieben.(Gut meine GOG Version mit CommonAPI2 nutzte dann halt auch mal den Steam Workshop Ordner mit.)

Fehlerhaftes verhalten zwischen Scripts und TPF2 führen auf Linux eher zu Speicherüberläufen, das mag die GCC Runtime überhaupt nicht. Durch die andere Kompilierung werden auch fehlerhafte Nutzung der TPF2 UI via LUA nicht so sehr verziehen.

Proton hab ich für TPF2 noch nie genutzt, das ist überflüssig.

CommonAPI2 sollte hoffentlich bald auch wieder laufen, das ist aber ein anderes Thema.

Es steht dir offen etwas besseres zu entwickeln ...

Also wenn du die Haupt Linien UI meinst, die ist sehr speziell.

CommonAPI2 nutzt die UG Linien UI und hab den Code dafür schon 3 mal neu gemacht, ich muss den Liniennamen suchen, damit ich die richtige Linie herausfinden konnte.

Grundsätzlich bindet UG keine Spezialelemente, bedeutet, du hast dann zwar ne Tabelle aber keine Funktion um herauszufinden welche Line der Nutzer gewählt hat.

Es kann sein das UG das mittlerweile geändert hat...

(Wegen der ständigen UI Änderungen hab ich ja meine UI Inspector geschrieben, damit kann man dann die UI zur Laufzeit erkunden)

Du brauchst keine Zustimmung, der Code steht unter GPL3 (Dein neuer Code muss nur halt auch unter GPL3 stehen)

https://github.com/IncredibleH…bles/blob/develop/LICENSE

Es gibt ja auch genügend Forks, aktiv ist der hier:

https://github.com/Gregory365/TPF2-Timetables

Texture resolve error: file not found: streets/new_medium_tram.tga ?

Das scheint ne TPF1 Datei zu sein, also in TPF2 Build 35915 ist das eine dds Datei...

Gestern beides noch zusammen gestartet. Steam Windows und Build 35915

Entpacke die Dateien ggf. nochmals. Schau was dein Virenscanner macht. Das CommonAPI2 die VTable via Namen nicht finden kann ist sehr ungewöhnlich...

Den Code für Windows hab ich seit geraumer Zeit nicht mehr angerührt.

Ggf. startete mal dein Windows System neu, vielleicht hat ASLR genau ein Bytemuster im Spielspeicher erzeugt das vermeintlich auf den Namen zeigt...

Das kann nicht sein.

CommonAPI2 hat ne Abfrage um die richtige Version mit der richtigen Build zu nutzen.

Nutze eine Development Version - 20241006 - und nicht buildoverwrite...

Definitiv ist zumindest für mich die LUA Runtime unter Linux etwas mehr anfällig wenn sol seine Pointer nicht im Griff hat.

Technisch sollte es keinen Unterschied geben zwischen Windows und Linux, aber die Compiler übersetzen den Code halt sehr unterschiedlich. GCCs Ergebnis ist auch bei jedem Build sehr unterschiedlich.

Die CPU Register Nutzung wird sehr stark optimiert, daher ist das Verhalten eines Mods sehr unterschiedlich von Build zu Build.

In "ea0530e9" haben wir das hier:

PANIC: unprotected error in call to Lua API (stack index 1, expected string, received sol.UI::Window*)

ist sehr ungewöhnlich.

Wenn etwas ein string sein soll aber ein sol.UI::Window ist muss etwas sehr falsch sein, da man in der Regel in eine Variable für string nicht für ein UI Element benutzt.

Auch wenn du sehr viele Daten durch die Gegend schaufelst, ist da wo ein string sein sollte nachher kein sol.UI::Window.
Die "Schaufel" ist ein Stück C++ Code und serialisiert dann bei jeden Frame die Game Script Daten und kann kein sol oder userdata...

Wenn so etwas mit UI Elementen öfters vorkommt, würde ich sagen das der Teil mit UI ein Problem hat..

Der Fehler kann natürlich auch von einem früheren "Out of Memory" kommen und der LUA Stack ist schon kaputt.

Im Endeffekt heißt das:

Alle LUA->SpielAPIs anschauen. Nutzung von temporären nur auf dem Stack liegende Objekte vermeiden.

api.bla(api.blub.new()) vermeiden und daraus:

local blub = api.blub.new()

api.bla(blub)

Und ja, ich nutze normalerweise Linux aber noch nie Timetables, daher hab ich keine Erfahrung mit den Mods...

Da würdest da eigentlich das Vulkan Device verlieren. Aber ich bin kein Programmierer der Vulkan täglich anspricht.

Bedeutet also nicht das es nicht trotzdem zu einem Out of Memory Fehler kommt.

Wir haben unerklärliche Out of Memory Fehler schon öfters mit Nvidia Hardware gesehen, sogar beim Starten des Spiels.

Ich würde empfehlen den Urban Games Support via Webseite zu kontaktieren...

https://www.transportfever2.com/de/support/help-desk/

Unten Rechts gibt es einen blauen Button "Support", wenn nicht mal die Cookie Einstellungen im Browser prüfen

In Build 35905 funktioniert Draw Calls nicht,

die Testing Version 35915 hat einen Fix dafür laut changelog:

Fixed crash when accessing debug window "draw calls"