Beiträge von eis_os

Well, CommonAPI2 can't find the right byte code in the exe / memory of your game, that is very odd.

Did you do some system restore or mod management lately?

Please ensure to have no TPF2 version remaining in Taskmanager and then reinstall CommonAPI2 1.8.20240129:

Backup eis_os_commonapi2_1 folder. Unzip the new version, copy settings.lua from backup to eis_os_commonapi2_1.

Please follow this exactly so we know you have a fresh copy of CommonAPI2Native.dll and not some old version.

Ensure you have no old CommonAPI2Native.dll somewhere in TPF2 Folders.

Nachzulesen hier:

https://commonapi2.bytetransfer.de/#/features/NewLineEvents

Du kannst bei Ankunft und Abfahrt "Dinge" programmieren. Ein Beispiel, ich lass die Wagons umsortieren...

Also da steht das ein benötigtes Mod Förster Förster wohl nicht geladen ist...

Da das Straßenpaket auch als Rückfallebene dienen soll möchte ich so wenig extra Zeugs rein packen. Default Masten als Assets zu setzen bringt aber keine schönen Ergebnisse.

Das UG keine großen Antrieb hat, den Code zu ändern, kann ich verstehen.

Es ist für mich immer noch eine Blackbox. Versuche die Mast Positionscode von außen zu ändern scheitern. (Ich will eigentlich einen Doppelausleger in die Mitte meiner Grünstreifen haben).

Das Asset Feature wäre eigentlich Interessant wenn man das auch randomisieren könnte und sagen wir mal zufällig einen Einspeisepunkt oder ähnliches dran pappen könnte. Aber an der Stelle des Code gibt es keinen direkten Zugriff auf Daten der Straße.

Irgendwann wird mir das vielleicht auch zu blöde und Bau uns da eine LUA Interface ein, so das bei der Mesh Erstellung LUA Code für das Mast setzen genutzt wird. Sprich man bekommt die Straße und kann dann ne Mdl Liste und eine Liste für die Linen zurückgeben. Dann kann sich jeder austoben und hat ggf auch bessere Ideen als ich oder UG

Schön wäre es da natürlich auch endlich Oberleitungstyp und Straßentyp zu trennen. Da war ich bis jetzt bei Gleisen aber noch nicht so sehr erfolgreich.

Anderseits, dann kommt UG mit TPF3 um die Ecke das absolut nicht kompatibel ist. Das ist mir ja bei Animationscode bei TPF1 zu TPF2 passiert...

Da stehe ich wieder mit mit meinem Ideen und bin geneigt mich in einem eigenen Spiel auszutoben...

Entferne mal "adding archive C:/Program Files (x86)/Steam/userdata/1539006311/1066780/local/mods/kaleut_br_1440_1/strings.lua.zip"

Sonst mal ohne CommonAPI2 probieren, erklären kann ich mir nicht das der Texturspeicher voll sein soll... Ggf. mal mit weniger Mods probieren...

Du kannst den Namen der Gruppe frei setzen (a-zA-Z0-9_), und Modelle deiner Wahl verwenden.

assetsCommonAPI = {   
     ["simrolle_baueme"] = {  ...  },
     ["simrolle_moebel"] = {  ...  },

Sprich dir steht es frei jedes MDL zu nutzen, nur mit halt einer Menge weiteren Optionen gegenüber UGs Methode.
Der Unterschied ist, das es sich random ein Teil aus der entries Liste heraussucht.
Damit wird es dann halt möglich zu sagen, an der exakten Position gibt es einen Baum aus der Liste dieser Bäume. Damit meine Straßen nicht so total eintönig aussehen, kann man halt die mdls auch noch in der Größe ändern, und verschieben lassen. So Straßenbäume sind ja nicht alle gleichförmig...

Beschreibung:

https://commonapi2.bytetransfe…treets?id=assetscommonapi

Hast du Strassen-Fine-Tuning (Steam ID 2021038808) aktiviert, wenn ja, das funktioniert nicht... steht in der Download Beschreibung und war letzten ein Problem bei einem Spieler...

Ja, nein, vielleicht. Ein paar Builds der CommonAPI können die Masten abschalten. Bei der Linux Version ist das nicht möglich und wie Werner mir gesagt hat, würde es auch mit Unsichtbaren Masten gut funktionieren. Masten ändern geht via catenary Block von UG sowieso.

Leider fehlt der Teil in der Inhaltsangabe im UG WIKI rechts, kommt aber unter dem Material Block:

Suche einfach nach asset/tram_pole.mdl

https://www.transportfever2.co…cksstreets#base_materials

UG verschweigt, das man dann noch assets dran basteln kann. Auch da gibt is irgendwo in den config Dateien ein Beispiel, das sieht dann so aus:

poleDoubleCrossbar = {

name = "asset/tram_pole_double_crossbar.mdl",

assets = { "asset/tram_pole_light.mdl" }

},

Man kann die Testerei meinerseits sogar auskommentiert in der Datei "eisos_town_medium_parking_tram.lua" sehen.

Dort gibt es dann catenaryFlagsCommonAPI disableCatenaryPoles bzw. catpole1 und catpole2 als Asset als Ersatz. Richtig schön war das Ergebnis aber nie.

Ich müsste dann aber selber eigene Poles bauen und ich mag definitiv keine 3D Modelling.

ch hab das schon 20 Jahre versucht und es war immer nur eine unliebsame träge Tätigkeit , da skizziere ich lieber nen Mast auf einen echten Stück Papier mit Bleistift und Lineal bevor ich ein 3D Programm starte

Und zum Thema eigenes Spiel, bringt mich da bitte nicht auf dumme Gedanken....

Mir schwirren da schon seit geraumer Zeit ein paar Ideen durch den Kopf. Ohne schöne Modelle würde es nicht sehr toll aussehen.

TrainFever->TransportFever2 ist da Fluch und Segen zu gleich, ich kann mit meinen Mitteln da Sachen einbauen die die Entwickler nicht wollen.

Sprich hab dann halt Zugriff auf ein fertiges Spiel mit Modellen zum erweitern.

Sachen wie die Limitierung der Engine an ein paar Stellen, sind halt Auch kann ich zwar vielen Code lesen, aber nicht alle wieder in sinnvoll zurückübersetzten.

Mittlerweile ist es mir möglich echte Stadtgebäude zu bauen, aber dafür ne UI zu bauen ist ein Albtraum.

Nun kann ich ne Industriekonstruktionscursor aktivieren mit eigenen Daten, aber kurioserweise kann ich damit keinen Bus oder Bahn Stationen bauen, und Stadtgebäude sind versetzt zur Cursorposition. Das war dann ne Sackgasse bei der Entwicklung der CommonAPI. Idealerweise wäre da auch ein copy&paste Cursor daraus entstanden... (Ja, ja, ich kenne den vorhandenen Mod)

Auf meiner Todolist ist für das Straßenpaket halt ne Stadtstraße mit ungerade Anzahl von Fahrstreifen für Linksabbieger. Bis jetzt finde ich aber die Verbindungen zwischen Straßen nicht schön genug...

Da sind noch so ungelöste Probleme, wie ungerade Anzahl Lanes verbinden, verschiedene Straßen usw...

Technisch kann zwar TPF2 verschiedene Breite Fahrstreifen definieren, dies ist aber später im Code nicht vorgesehen. D.h. Lanes würden sich bei Kreuzungen nicht verbinden und andere Probleme. Eine Stadtstraße mit schmalen Grünstreifen ist auf meiner Todoliste

Zitat von nightfury34

Zusätzlich habe ich mich mit der Performance auseinandergesetzt. So werden aktuell nur noch Züge, welche sich in einem gewissen Radius vom Spieler befinden, ausgewertet. Das hat der Performance schon spürbar geholfen. Jedoch funktioniert das aktuell auch nur in der Hauptansicht. Heisst Züge, welche man sich durch extra Fenster einblenden lässt und sich ausserhalb des Radius befinden, werden aktuell nicht von der Signalauswertung erfasst. Werde schauen, dass ich dafür aber auch noch eine Lösung finde.

Hmm, du müsstest ein BoundingBox Punkt eines Zuges bzw. des ersten Fahrzeugs zu rate ziehen können ob ein Zug in der Nähe des Signals ist? Warum ist das UI Abhängig?

Könnt Ihr mal bitte aufhören an jeder Ecke alles schlecht zu machen, und den Wiki Eintrag mal komplett durchlesen, da steht es doch drin:

2.1 Eigene Fahrzeugmodelle nachrüsten (Beispiel Code):

Sobald LINE_DESTINATION eingeschaltet ist, funktioniert in labelList type = "LINE_DESTINATION", ohne CommonAPI2 gibt es einen Ladefehler, daher müsst Ihr eine Code Weiche einbauen:

Siehe dazu auch: https://www.transportfever2.co…ourcetypes:mdl#label_list

In eurer mdl Datei direkt hinter function data() einfügen:

Code

local labelType = "NEXT_STOP"
if (commonapi ~= nil and commonapi.supports and commonapi.supports("LINE_DESTINATION")) then labelType = "LINE_DESTINATION"
end

Danach könnt Ihr in der labelList

Code

type = "LINE_NAME",

durch

Code

type = labelType,

ersetzten.

Code ist da, steht direkt darunter inkl Anleitung...

Alternative Mods zum automatischen Ändern der Fahrzeuge gibt es auch, es gibt auch noch das Ganze als Englische Anleitung hier:

https://commonapi2.bytetransfer.de/#/modding/LabelTypes

Und es wird auch in der Doku auch nach

Verbesserte Linienbezeichnungen  verlinkt...

Nimmst zwei Labels? Für weiteres müsstest du mir sagen was du genau vorhast. Technisch kann ich mittlerweile die Parameter auslesen und kann daher ggf. da sogar noch Erweiterungen hinzufügen...

See if the streetpackage is enabled in the savegame...

OT Kommentar:

Da schreibt man eine zu TPFMM settings.lua System kompatible Funktion, damit man einfacher settings.lua Dateien ändern kann und dann immer diese Kommentare.

UGs System kam viel zu Spät (und hat ggf. selber Probleme verursacht*) und es gibt Situation da kann man eben nicht alles per modifier machen:

Es gibt keine direkte Möglichkeit auf die Einstellungen einer Mod zuzugreifen in einem Construction Script wenn man die Teile nicht via postRunFn erstellen möchte,

sondern diese auf dem Dateisystem bzw. in einem Zip hat.

Auch ne Tonne Scripte einzubauen nur um die mod.lua settings auszuwerten, ist auch nicht der Weisheit letzter Schluss.

*(Kommt mir nicht mit das war alles so Toll, ich hab euch den Sch*** debuggert damit es wegen doppelten Keynamen der Settings in der mod.lua nicht zu einem Crash des Spiel kommt!

Das war nie ein CommonAPI2 Fehler nur Nutzer haben es mir gerne in die Schuhe geschoben,

Und der Fehler kam gerade von der Nutzung von Scriptpaketen ohne die Auswirkungen zu verstehen)

---

Zum Mod:

Ja, man könnte den Mod ändern, das wäre gerade etwas für den Einstieg in die Mod Entwicklung. Steht ja jeden Frei mal auch etwas Zeit zu investieren...

Ganz grob. transport.EdgeGeometry ist für die Lanes. Der transport Namespace wird in der Regel für alles was später mal auch für (Transport) Wege genutzt. Dafür ist dann ggf. das TransportNetworkSystem zuständig.

Irgendwo werden die mdl Lanes in ConstructionBuilder dann auch umgewandelt, da bin ich aber nur einmal kurz drüber gestolpert.

(Daher ist es auch nicht möglich eine Mdl, eine Straßen Bushaltestelle mit eigenen transportNetworkProvider auszustatten)

EdgeGeometry kommt dann beim Rendern der Debug Lanes als Eingangsdaten an.

Alles was beim Straßenrendern reinkommt sind Faces und Hermit Splines.

Die echten Daten für das "Aussehen" einer Kreuzung sind in der nicht öffentlichen zugänglichen procedural::AttributeMap im Shape.

CommonAPI2 kann das euch Anzeigen,

dort liegen dann für jede Kreuzungspunkt Sachen wie, die Lane ConnectionMap, ob da ne Busspur ist, ob es Trams gibt, ob die Straße gedreht wurde. (Für Einbahnstraßen interessant) und auch Daten wo die Straße und der Kreuzungsbereich anfängt. (Teilweise hab die Berechnungen wo ein Verbindung ist aus den Datan im LUA Code für den NodeEditor nachgebaut)

Gleise verhalten sich anders, da es ja keine Kreuzungen gibt, aber dort liegt dann auch der momentane Status wie ob ein Gleis elektrifiziert wurde, Tunnel (ja/nein) bzw. Brückentyp.

-edit-

Ich hab jetzt eigentlich keine Lust das alles von Assembler wieder in C++ zu überführen ...

Vielleicht ist ja jemand schon mal auf einen Algorithmus mit math::detail::richardson Tabelle am Ende gestoßen... Vielleicht kann aber Dino ja direkt was zu sagen...

Nunja, intern nimmt TPF2 ja überall die Hermite Splines.

Und die Mathematische Berechnung dafür sind nicht so wild aus im Assembler Code. (nein Nachbauen will ich es nicht)

float Math::{anonymous}::GenHerpLength(const T&, const T&, const T&, const T&, float, float) [with T = CVec2f]

bzw.

float Math::{anonymous}::GenHerpLength(const T&, const T&, const T&, const T&, float, float) [with T = CVec3f]

Da wirft dann TPF2 die beiden node pos und tangent rein, dann den Abschnitt von 0.0 bis 1.0 und bekommt die Länge raus.

Sehr vieles wird halt als relative position float auf dem Spline gespeichert.
Wie willst du das dann ändern?

Wenn du da was anderes nehmen wolltest, werden alle Savegames unbrauchbar. Das Kameratool... alle API Bindings (Proposal).

Sprich das wäre dann ein neues Spiel, das wird UG bestimmt nicht machen...

Wobei ich hab irgendwann mal transport::EdgeGeometry als C++ Strukturen nachgebaut, da gab es diese Fälle:

union EdgeGeometry_params {

EdgeGeometry_Straight straight;

EdgeGeometry_Arc arc;

EdgeGeometry_CubicSpline cubicSpline;

EdgeGeometry_CubicOffsetSpline cubicOffsetSpline;

};

Wenn du aber die Tangenten total obskure Dinge rein kippst, kann es dir passieren das du mit Brücken Probleme bekommst und das Spiel crasht. Zumindest war das zu TPF1 Zeiten so...

Hört sich nach curve fitting bzw. path smoothing Algorithmen an.

Also quasi wenn du eine Strecke von AB nimmst die keine Weichen beinhaltet, diese dann sehr stark glättest durch einen Filter.

Wenn ich mich recht erinnere machte das Mapnik (Renderer für OSM Daten) für das OSM Material auch. Nach ein paar Github Issues scheinen die Ergebnisse wohl leider so la la zu sein...

Ich hab da ne ganze Zeit an Debugging Zeit verheizt, schlauer bin ich nicht geworden, drum hier noch mal ein paar Informationen:

• Ich bitte euch immer ein Backup euer Savegames anzulegen
• Informationen zu geben ob Ihr auch eurer Spielversion geändert habt. Es ist ein Unterschied ob Ihr die TPF2 Build geändert habt!
  
• Solltet Ihr einen Spielstand speichern und diesen nicht mehr beim
  nächsten mal laden können, bitte ich euch diese hier als Bug zu melden.
  Wenn Ihr meint der Spielstand durch eine Funktion der CommonAPI2 kaputt gegangen ist.
  
  Darunter fallen also keine Spielstände, die nur noch im Pausen Modus laufen oder sonstige kaputte Sachen, wie ne Konstruktion schmeißt einen Lua Fehler.
  
  Ändert keinesfalls die Rahmenbedingungen oder macht Backups so das Ihr auf den vorherigen Stand zurück kommen könnt, damit wir das Debuggen können
  

• Nicht versuchen bei Fehlern (buildoverwrite ggf. genutzt) zu nutzen und dann einen Spielstand zu speichern!
  Wenn CommonAPI2 sagt, das es etwas nicht findet, ist dieses Wichtig!
  
• Überprüft die Dateigröße, ist die sav Datei nun ungewöhnlich kleiner als vorher? Dann ist beim Speichern etwas kaputt gegangen
• Upgrade von CommonAPI2:
  
  • Mach ein Backup von CommonAPI2 und Straßenpaket vor dem Updaten.
    
  • Solltet Ihr dann eure Savegames nicht laden können, bitte um genaue Informationen: Alte Version -> Neue Version
    
• Nutzt CommonAPI2 nicht bei Instabilen Systemen:

  
  

  • SSD HDD hat ständig korrupte Daten... Dann kann natürlich auch ein Spielstand kaputt sein.
  • Es gibt ungewöhnliche Crashs beim Spielen ohne CommonAPI2.
  • Der Grafikspeicher läuft über und das auch ohne CommonAPI2
  • Ihr habt das System übertaktet. TPF2 verhält sich ziemlich anders als viele andere Spiele, nur weil Spiel X läuft, heißt das nicht das eure Kiste stabil ist.
    Glaubt Ihr mir nicht? Schaut mal hier https://www.radgametools.com/oodleintel.htm, so etwas kann auch bei AMD CPUs passieren.

Allgemein habe ich nun Herausgefunden, das der Spielstand bei procedural::Shapes die Daten aus mir unerfindlichen Gründen nicht laden kann. Das komische, es sieht so aus das der Dateistream nicht mehr richtig ist, d.h. die Eingangsdaten nicht mehr gelesen werden können.

Daher der Aufruf, testet mal den NodeEditor und das Region Feature und speichert eurer Spielstände mit neuen Namen ab!

Könnt Ihr diesen Spielstand nach einem sauberen Neustart des Spiels laden? Wenn nicht, dringend hier melden, danke...

Bis jetzt hab ich nichts gefunden, da werde ich wohl das komplette Savegame brauchen.

Da UG swisstransfer benutzt für so etwas, schlage ich das mal vor. Du kannst mir dann den Link in einer privaten Nachricht hier im Forum geben.

-edit-

Und bitte deine settings.lua der CommonAPI2

Wieder bei 16%? Das sieht nach mehr aus.

Lässt sich das Spiel ohne eingeschalteten FlexStreets in CommonAPI2 laden? (Ausschalten, Speichern, TPF2 neu starten)

Noch kann ich das nicht weiter eingrenzen. Lässt sich ein neue Karte erstellen?

GGf. mal die kleine .sav.lua deines Spielstandes anhängen...