Beiträge von WernerK

Wenn du im Quellcode des Spiels etwas veränderst, kannst du alles modden. Im Extremfall käme dann ein neues Spiel raus. Eisenbahn und Straßenbahn in TpF zusammenzubringen dürfte wirklich schon ein extremer Eingriff sein, sprich seeeeeeeehr aufwändig. Alleine die Dateiformate passen schon nicht.

Ich würde mir übrigens wünschen, wenn alle, die sich so ein Feature wünschen, das mal an UG schreiben sollten. Es sind ja nicht wenige, und in TpF3 wäre es wohl am besten aufgehoben ...

Wie gesagt, eine Besetztmeldung für eingleisige Straßenbahnstrecken dürfte machbar sein, nur eben nicht "mal schnell zwischendurch". Sollte sogar besser gehen als bei der Eisenbahn, wo zwischen zwei Kreuzungsbahnhöfen nur maximal ein einziger eingleisiger Haltepunkt liegen darf.

Im Winter ist wieder etwas mehr Ruhe, da kann ich vielleicht etwas konzentrierter experimentieren. Versprechen kann ich natürlich nichts, ich hab schon Situationen erlebt, wo es saudoofe Bugs in der Spiel-API gab, die kurz vor dem Ziel den finalen Durchbruch verhindert haben oder Workarounds erforderten, die aufgrund weiterer Bugs wiederum nicht funktionierten.

Signale für die Straßenbahn wären schön, nur sind sie im System nicht vorgesehen. Dazu müsste es über Pfeifen und Klingeln hinaus Wegpunkte als universelle Schaltkontakte geben, aber ich bezweifle, dass UG diesen Wunsch erfüllen wird. Abgesehen davon, dass es sehr unterschiedliche Signalsysteme für die Tram gab und gibt. Aber auch die Stabsicherung, die ganz ohne Signale auskommt und notfalls als Entschuldigung dienen könnte.

Zu Mittellage hatte ich was geplant, bin aber niemals übers Experimentierstadium hinausgekommen. Es ginge nach meinen Erkenntnissen nur "zum Drüberlegen", wie du es ja auch gemacht hast, nur eben mit passendem Mastabstand für eine dann 9 Meter breite Fahrbahn. So weit bin ich immerhin. Zwei Haken hat die Sache: Es wird im Straßenbereich vermutlich nur über Konstruktionen die Möglichkeit geben, die mittigen Gleise mit den normalen Straßen zu verbinden. Da forsche ich noch, Problem dabei neben der Frage, ob das überhaupt geht, ist der Übergangsbereich, wo ich jemanden benötige, der mir ein Straßenimitat als mdl bastelt, da ich selber bislang keine 3D-Modelle baue. Und es werden wieder mal wartende Fahrgäste auf der Straße stehen, und da sehe ich definitiv keine Chance, das ohne CommonAPI abzustellen. Da ginge der Ball also an eis_os. Sollte so ein Gleistyp irgendwann auf Basis der eis_os-Straßen möglich sein, was wohl noch nicht der Fall ist, könnte ich ggf. einen angepassten Gleistyp entwickeln. Für doppelgleisige Abschnitte müsste das jetzt schon gehen, aber ich habe mich mit dem eis_os-Straßenpaket noch nicht intensiver beschäftigt.

Du darfst auf fremde Texturen verweisen, solange du sie nicht in deine Mod packst. Dennoch wäre es eine nette Geste, darauf hinzuweisen, dass es nicht deine eigenen Texturen sind.

Abhängigkeiten von fremden Mods sind natürlich immer etwas problematisch, weil sich deren Inhalte ändern können. Was nicht heißen soll, dass ich selber sowas nie machen würde ;-). Sollte deine Mod auch für Spielkonsolen vorgesehen sein, solltest du es aber möglichst vermeiden.

Zitat

Rein optisch wäre das bestimmt machbar. Eine Art Zugdepot mit Straßenanschluss quasi.

Straßenbahn und Eisenbahn sind im Spiel grundsätzlich zwei getrennte Systeme. Das ist schade, ist aber so. Entweder könnte UG das in TPF3 beheben (dürfte vordergründig nicht ins verstärkt forcierte Tycoon-Konzept passen, also unwahrscheinlich) oder eis_os müsste das programmieren (Riesenaufwand, also auch unwahrscheinlich). Faken kann man natürlich alles, wie besagte Eisenbahngleise auf unsichtbaren Straßenbahntrassen. Oder auch umgekehrt. Vorbildgetreu und spannend wäre die Kombinierbarkeit auf jeden Fall, denn angefangen von den guten alten Kleinbahnen bis zu modernen Tram-Train-Systemen hat es schon immer Mischungen aus Eisenbahn und Straßenbahn gegeben.

Auf Steam ist ein User namens "Bot Olafson" (Nomen est Omen) aufgetaucht. Könnte wieder der spezielle "Freund" sein, zumindest was anlasslose Lobhudelei in Verbindung mit dümmsten Fragen betrifft. Seid gewarnt.

Was ich übrigens auch noch vermisse, wäre so eine Unterführung:

https://www.industriekultur-kr…eherlegung-der-eisenbahn/

Pantograf: Zu deinem letzten Beitrag siehe einige Anmerkungen von mir in der persönlichen Konversation.

charly_o:

Zitat

Auch die Idee hinter der Mod von eis_os ist wirklich genial und man fragt sich wirklich, warum das nicht von vornherein schon so gemacht wurde.

Ganz einfach: eis_os arbeitet ja bei der CommonAPI an sehr vielen Dingen, und zu dem Zeitpunkt, da ich - auf Anregung von Sabon - mein Tramsystem "erfunden" habe, dürfte er wohl noch Anderes auf dem Schirm gehabt haben. Hierzu sei aber auch bemerkt, dass eis_os direkt in den undokumentierten Hardcode des Spiels eingreift, und z.B. ich selber (und wahrscheinlich auch jeder andere hier) das nicht kann und vielleicht auch nicht will. Um nicht falsch verstanden zu werden: Die CommonAPI ist eine tolle Sache und kann viele Dinge, sie ist im wahrsten Sinne des Wortes ein Game-Changer. Für mich ist sie vor allem eine Demonstration ungenutzter Potenziale des Spiels und ein Wink mit dem Zaunpfahl an UG. Der Nachteil ist aber die völlige Abhängigkeit von der CommonAPI. Sie ist mehr oder weniger eine permanente Beta und muss immer wieder ans Hauptprogramm angepasst werden, da sie von UG nicht unterstützt wird. Während dieser Phasen kann ich kein Spielupdate machen. Wenn eis_os hinwirft - was ich nicht hoffe - kann wahrscheinlich niemand hier die Sache fortführen, während die Chance besteht, dass sich jemand noch in reine Lua-Skripte einarbeiten könnte, falls von anderen Moddern nichts mehr käme. Ich muss mich zudem darauf verlassen, dass wirklich alle Feinheiten des Hauptprogramms bekannt sind und berücksichtigt werden. Und ich möchte auch Lösungen für Mac-User anbieten. Aber wie gesagt, jeder kann frei entscheiden, und vielleicht werde auch ich selber mal eine Map mit CommonAPI aufbauen. Und selbstverständlich sollen meine eigenen Entwicklungen kompatibel zur CommonAPI sein, wenn immer es geht.

Fahrdrahthalter geht grundsätzlich auch, allerdings nicht bei den Epoche-A-Masten.

Ich habe noch nicht mit den Tramstraßen von eis_os experimentiert. Übernehmen die den Original-Fahrdraht mit Original-Abstand oder haben die einen eigenen Fahrdraht mit eigenen Abständen? Funktioniert da mein Mastensetzer-Tool?

Die Querabspannungen sind bei elektrifizierten Tramgleisen hardcoded. Du kriegst sie normalerweise nicht weg, obwohl genau das manchmal wünschenswert wäre. Es sei denn, du benutzt nicht elektrifizierte Tramgleise, dann kannst du aber auch nicht elektrisch darauf fahren. Kann sein, dass bei den Gleisen von eis_os in den Code des Spiels eingegriffen wird, so dass es dort dennoch möglich ist. Umgekehrt müsstest du dir in diesem Fall die Masten selber modden, denn ich wüsste nicht, dass es solche Masten bereits gibt. Sabon hat seinerzeit mal einen eingleisigen Auslegermasten als Prototyp entwickelt, aber wegen meiner Idee, aus der Not eine Tugend zu machen und die originalen Querabspannungen zu erhalten, wurde der wieder verworfen.

sabon: Vielleicht brauchen wir tatsächlich wieder solche Masten für Sonderfälle, denn auch die KI spannt gelegentlich keinen Querdraht. Allerdings würde ich diesen dann wieder als separates Mesh anlegen, so dass ich es ohne 3D-Kenntnisse in die mdl-Datei einfügen kann. Vielleicht gibt es auch schon irgendwo ein passendes Drahtobjekt. Notfalls nicht einmal abgelängt, das könnte man ja skalieren. Nur die Farbe müsste stimmen, also nicht Grün, sondern Anthrazit.

eis_os: Die Masten gibt es bereits als Einzel-Assets, allerdings nur im ATS-Paket, nicht in einer gesonderten Mod. Wobei die anderen ATS-Inhalte doch eher noch eine Bereicherung für die CommonAPI wären. Aber eine Mod ausschließlich mit den Masten wäre sicherlich auch kein Problem. Oder du könntest die Masten auch ins Common-API-Paket legen. Ich hätte nichts dagegen, Sabon sicher auch nicht, wenn du ihn fragst.

Lässt sich der ATS-Mastensetzer eigentlich nicht auch für die CommonAPI verwenden? Ich habe es nicht ausprobiert, aber man könnte notfalls entsprechende Anpassungen vornehmen.

Die Begegnung auf eingleisigen Strecken lässt sich derzeit nur mit Hilfe der Fahrplan-Mod verhindern. Aber selbst beim konventionellen Betriebsablauf lassen sich zumindest eingleisige Teilabschnitte so anlegen, dass dort keine Begegnungen stattfinden. Ich habe das erfolgreich in der Praxis getestet. Ich denke schon länger an eine Besetztmeldung, die nach dem Prinzip der Fahrplan-Mod funktioniert, aber eben unabhängig von Zeitvorgaben. Man kann ja die Standorte der einzelnen Fahrzeuge zwischen und an den Haltestellen ermitteln und daraus eine Logik machen. Die Haltestellen sind dann gleichzeitig Signale, die es als solche natürlich nicht geben wird, aber was soll's, das ist dann eben Token-, Kreuzungsplan- oder Fernmeldebetrieb, also durchaus vorbildlich. Das sollte sogar mit "Bordmitteln", also ohne CommonAPI, gehen. Ich habe mich da aber bislang nicht reingekniet.

Wenn es anders nicht machbar ist, ist auch nichts gegen die CommonAPI zu sagen. Es besteht z.B. immer noch das konventionell unlösbare Problem, dass Fußgänger in dicht besiedelten Gegenden an den Strecken entlanglaufen. Gerade bei eingleisige Strecken, die dann möglichst auch noch im Straßenplanum verlegt sind, muss man das augenzwinkernd tolerieren. Auch, dass sie bei der Einzelmasten-Lösung an Haltestellen auf den Gleisen stehen, weil sich der Abstand der Warteplätze zur Fahrbahn nicht einstellen lässt. Experimentelle Konstruktionen mit Lanes funktionieren da auch nicht, da im Gegensatz zu den echten Straßen dort die Einschnapptoleranz größer ist, und sich die Lanes mit den dicht nebeneinanderliegen Spuren der Pseudo-Einzelgleise nach Lust und Laune und kreuz und quer verbinden, was dann herrliche Abstürze auslöst.

Pantograf: Meine Kleinbahngleise unterstützen sowohl Vanilla- (bzw. eis_os-Gleispaket) als auch NEP-Gleise. NEP wäre hier also Kann, aber nicht Muss. Die Details (auch in Sachen erweitertes Gleissortiment) ließen sich dann am besten per privater Konversation klären.

Das war eigentlich schon meine Idee und auch schon relativ weit fortgeschritten. Aber macht nichts, wenn jemand dieselbe Idee hat. Um Doppelentwicklungen und Inkompatibilitäten zu vermeiden, sollten wir uns zusammentun. Sabon ist ja auch schon mit dabei. Als Gleise hatte ich übrigens meine Kleinbahngleise vorgesehen, von denen es natürlich auch weitere Varianten geben könnte. Wie ich sehe, hast du auch noch neue Masten entworfen, die mir sehr gut gefallen - man kann ja nie genug davon haben. Für zweigleisige Strecken hatte ich selber noch eine andere Lösung - übrigens für 4 m Gleisabstand - angedacht, aber deine sieht auch interessant aus.

Es ist eine Variante des Parallel-Tools geplant, die speziell für diesen Zweck vorgesehen ist, auch eingleisige Stecken mit Ausweichen unterstützt und automatisch die passenden Abstände und Radien liefert, so dass auch Einsteiger keine Probleme mit irgendwelchen komplizierten Einstellungen haben.

Was auch noch geplant ist, sind Kreuzungen mit größeren Radien und spitzwinklinge Abzweigungen. Letzteres ist allerdings auch bereits mit CommonAPI möglich.

Der Gleiswechsel und die Ausfädelung dürften wohl eher Dummys sein, hab ich recht?

Zitat

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?

Mit subtilen Änderungen und Lücken in der Dokumentation muss man bei UG leider immer rechnen. Wenn der Autor das weiß, seine Mods pflegt - sprich regelmäßig und gerade nach Spiel-Updates selber benutzt - und am Testprogramm teilnimmt, sollte er frühzeitig ein Patch anbieten oder notfalls UG konsultieren. Auf jeden Fall sollte er ein Feedback an die Benutzer geben, wenn aus irgendwelchen Gründen kurzfristig oder generell ein Patch nicht möglich ist.

Falls du dich da auf die CommonAPI bezogen hast, wäre die allerdings ein schlechtes Beispiel, da ich mir vorstellen könnte, dass UG die aus Prinzip nicht besonders unterstützt. (Das sei eine Feststellung und kein Vorwurf.)

Mag ja sein, dass im Hauptprogramm nicht alles optimal programmiert ist (könnte ich auch nicht beurteilen, zu viel Fachchinesisch ), aber wenn offensichtlich ausschließlich eine einzige Mod, die von Anfang an einige bislang nicht behobene Bugs aufweist, instabil läuft, läge es zumindest nahe, das Problem zunächst dort zu suchen.

Was das Handling der Threads betrifft, ist das in der Tat ein ziemliches Gewusel. Ich sehe das Problem in der Synchronisation, aber das ist mit viel Ausdauer in den Griff zu bekommen. Wenn in meinen Skripten was abgestürzt ist, dann aus Unwissenheit und manchmal auch Schlampigkeit, aber eigentlich nie, weil das Hauptprogramm Mist baut. Was anderes sind Lags, zu denen das Hauptprogramm tatsächlich seinen Teil beiträgt, aber auch die sind mit Workarounds einigermaßen in den Griff zu bekommen. Und dann gibt es noch einige wenige API-Befehle, die wirklich buggy sind, und die muss man halt kennen.

Das ist schon mal wenigstens etwas. Allerdings scheinen die entscheidenden Mängel zumindest laut Versionsgeschichte nicht behoben zu sein.

Da müsste man vielleicht etwas mogeln. Wobei es m.W. auch Standseilbahnen gibt, die zwecks Gewichtsausgleich ein rundum durchlaufendes Seil haben. Aber eben nicht die Malbergbahn.

Standseilbahn wäre tatsächlich was, was ich mir schon lange wünsche. Müsste eigentlich modbar sein, Drahtseilbahn gibt es ja auch, und Steilstrecken sind auch kein Problem, auch die Bremszahnstange dürfte keine Schwierigkeiten bereiten. Von mir aus könnte es jede beliebige Standseilbahn sein, aber Malbergbahn wäre natürlich besonders reizvoll.

BTW San Francisco Cable Cars gibt es erstaunlicherweise auch noch nicht.

Immerhin hast du so die sav.lua bereinigen können, wo die Fahrplan-Mod im Laufe der Zeit ebenfalls jede Menge Müll ablagert.

Wenn ich es richtig sehe, hat sich da seit Monaten nichts mehr getan, nicht einmal Bugfixes. Schade für ein so bravourös gestartetes Projekt. Ja, ich sehe das auch so, man wird es komplett neu schreiben müssen. Vielleicht ist das der Nachteil des gitHub-Konzeptes: Du bist gezwungen, fremden Code, in den du dich mühsam einarbeiten musst, zu übernehmen, weiterzuentwickeln und vor allem zu pflegen. Das schafft Reibungsverluste. Am besten wäre es gewesen, wenn UG selber die Fahrplan-Idee aufgegriffen hätte, naja, da werden wir wohl auf TpF3 warten müssen, wenn überhaupt.

In der Praxis kann man eigentlich sowas nur erzeugen, indem man entweder immer mehr neue Daten in eine Tabelle schreibt oder regelmäßig auf Daten zugreift, die man eigentlich nicht mehr braucht. Denn der alte Datenmüll würde ansonsten intern über eine Garbage Collection regelmäßig aus dem RAM gelöscht. Hast du das mal an die Autoren gemeldet? Könntest du deine Änderungen evtl. auch hier veröffentlichen? Mich z.B. würde das auch interessieren, da ich ebenfalls die Fahrplan-Mod benutze und meine, ebenfalls so ein Verhalten beobachtet zu haben.

Das sorglose Zumüllen von Ressourcen ist übrigens auch in der .sav.lua zu bemerken. Wenn du z.B. Einträge löschst, bleiben sie hier trotzdem drin. Abgesehen davon, dass du bei Änderungen an der Anzahl der Haltestellen manuell Einträge verschieben musst, am besten auch direkt in der .sav.lua, weil die UI leider auch buggy ist und Tastatureingaben ignoriert. Aber das ist wieder ein anderes Thema.