Beiträge von BigBenjy


Abonniere unseren Kanal auf WhatsApp (klicke hier zum abonnieren).

    Moin in die Runde,


    heute geht es um die Fahrzeugsteuerungs-HMI, also den mittigen Bedien-Bildschirm, der sich neben dem Tacho befindet. Anfangs stand der für mich vor allem als lästiges Beiwerk eines modernen Fahrzeuges auf der Umsetzungsliste. Als Teil des zentralen Blickfelds sollte sich natürlich trotzdem "was bewegen" - schließlich hab' ich aber doch nich ein gewisses Herzensprojekt in der Umsetzung finden können. Aber der Reihe nach, wir beginnen mit einem ersten Blick aufs Panel:



    Bei der unheimlich umständlichen Art des TSC, digitale Ausgaben und Menüs im Führerstand nachzubilden, war zumindest von vornherein klar, dass hier nur ein Bildschirm/Menüpunkt nachgebildet wird. Die Wahl fiel verständlicherweise aufs Menübild "Fahren".


    Zunächst zeigt die Kopfzeile die Fahrzeugnummer und das Datum mit der aktuellen Uhrzeit an. Die etwas wilde Bezeichung "ZugNr." und die Darstellung der Fahrzeugnummer ohne Leerzeichen zwischen Baureihe und Ordnungsnummer entspricht dabei der Realität. Als Datum wird eines zur Jahreszeit passendes generiert - alternativ kann aber auch ein explizites via DynamicNumbering-Parameter vorgegeben werden, wenn im Szenario gewünscht.


    Dann beginnen wir mit den Hauptanzeigen von links:


    Je Fahrzeugeinheit gibt es einen Balken, der die aktuelle Netzspannung angibt. D.h. maximal vier wird es zu sehen geben (bei 4x BR 483 als Vollzug), während bspw. der 484-Vollzug nur zwei Spannungsbalken zeigt, da ja nur zwei Halbzug-Einheiten gekuppelt sind.


    Dann folgen Balken für Zug-/Bremskraft sowie den Netzstrom. Die Lösung, positive Werte mit blauen Säulen und negative in rosa darzustellen, finde ich persönlich sehr einträglich. :thumbup: Für die Zugkräfte liegt die Nullinie mittig (Säulen entwickeln sich von dort nach oben oder unten) - für den Netzstrom unten, so dass positive und negative Werte dort beide mit nach oben wachsenden Säulen dargestellt werden. Spannende Sache, denn die Umsetzung mit Mitteln des TSC erforderte etwas Gehirnschmalz und KnoffHoff.. *denk*


    Die Zug-/Bremskraft wird in % angegeben. Soweit logisch, denn unabhängig von der Kombination gekuppelter Einheiten ergeben sich sehr ähnliche Ausgaben. Nicht für den Tf dokumentiert ist jedoch, worauf sich die 100 % beziehen: auf die absolute, max. Zugkraft? Auf den geschwindigkeitsabhängigen Zugkraftverlauf (vgl. Beitrag weiter oben) oder gar auf eine programmierte Sollvorgabe? Auf Videoschnipseln war für mich erkennbar, dass auch bei bei kleinen Geschwindigkeiten Werte bis 100 % erreicht werden können - das spricht für die Hinterlegung des Zugkraftverlaufs, also habe ich das auch gemacht :) Mit dem kleinen Pfeil links der Skala wird die Sollvorgabe angezeigt (also quasi die Stellung des Fahr-/Bremshebels) und mit der Säulendarstellung dann das vom Fahrzeug erzielte Ergebnis. Insbesondere bei Bremsungen ist es üblich, dass nicht dauerhaft der Zielwert erreicht wird. So können die automatisch unterhalb 7 km/h anlegende ep-Bremse sowie die Haltebremse andere Werte anfordern, als vom Triebfahrzeugführenden ausgewählt.


    Der rechte Balken gibt den Netzstrombezug an - und zwar für den gesamten Zugverband. Wer mit einem 483-Viertel unterwegs ist, wird es also nicht schaffen, die Säule besonders weit nach oben zu treiben. Spannender wird es ab 3/4-Zügen: schon bei den Fahreigenschaften hatte ich berichtet, dass Spitzfahrten samt Hilfsbetrieben mitunter mehr benötigen, als die 4.000 A-Grenze (die hier als fixer Zielwert hinterlegt ist) hergibt. Die Begrenzung des Leistungsbezugs ist hier umgesetzt und ihr werdet diese sicher hier und da beim Beschleunigen beobachten, wenn beim Vollzug schon vor Erreichen der 100% Zugkraft die 4000 A erreicht sind. Trotz der Wirkungsgradverluste vom Fahrmotor bis zum Stromabnehmer ist es auch im rückspeisenden Fall machbar, die 4 kA-Grenze zu erreichen. Möglich macht das eine entsprechende Auslegung bzw. kurzzeitige Überlastbarkeit der Komponenten entlang dieses energetischen Pfads.


    Hier noch zwei Ansichten von Beschleunigung und Bremsvorgang:





    Hier zeigt sich nun, warum es sinnvoll war, anfangs so großen Wert auf die möglichs exakte Erreichung auch originaler Zugkräfte zu kommen - wir vollen diese nicht nur prozentual angeben, sondern auch auf den Netzstrom schließen - und zu guter Letzt: auch Kilowattstunden zählen!


    Das ist in meinen Augen ein besonders interessantes Feature, dem Tf schon auf dem Hauptbilschirm seinen Verbrauch anzuzeigen - und es verleitet natürlich stark dazu, die Zahlen im Blick zu behalten ;) Angezeigt werden drei Werte: zuerst, was der Stromschiene entnommen wurde. Dann, was wieder zurückgespeist wurde und schließlich als Differenz daraus als Netto-Verbrauch.


    Nur, um sich mal eine Vorstellung zu machen: allein mit dem 483-Viertel habe ich von Hennigsdorf bis Teltow reichlich 100 kWh netto verfahren, dafür aufgenommen wurde vom Fahrzeug mehr als das Doppelte. Zum Vergleich: es dauert bei mir ein paar Wochen, bis ich diesen Bedarf in der heimischen Wohnung angehäuft habe... Gut also, dass wir für virtuellen Stromverbrauch nix bezahlen ^^ Es ist durchaus möglich, bei der NSB Rückspeisequoten bis um die 50 % zu erzielen. Das hängt natürlich von den Witterungsbedingunen, der Fahrweise und dem Streckenprofil ab. Wer bspw. auf den Außenästen für längere Zeit hohe Geschwindigkeiten zu halten hat, wird kleinere Quoten erzielen.


    Und ja: es wird möglich sein, sich mit anderen im Simulator zu messen. Wichtig zu wissen ist dafür allerdings, dass der Hilfsbetriebeverbrauch abhängig von der Jahreszeit zum Spielstart in zufälligen Intervallen bestimmt wird. Eine bullernde Heizung wird natürlich für mehr Energiebedarf sorgen als mildes Übergangswetter. Es ist aber möglich, sowohl die Startwerte für "Aufgenommen"/"Rückgespeist" als auch den Hilfsbetriebeverbrauch via Fahrzeugnummern-Parameter explizit zu setzen, um vergleichbare Bedingungen zu schaffen.


    In diesem Sinne heiß es dann in Kürze: auf die Plätze, fertig, Energiesparend fahren*LLAP*


    Viele Grüße,

    Benjamin

    Hallo zusammen,


    heute werfen ein Blick auf das Türsystem. Das Grundgerüst der zufällig etwas zeitlich versetzt öffnenden und schließenden Türen samt Überwachungsstatus konnte natürlich vom 481er übernommen werden.


    Vermissen wird man das bisher so berlin-typische "laaa-lüüü-laaa" als Türschließ-Warnton, der es bekanntlich sogar bis in diverse Songs geschafft hat. Stattdessen wurde beim 483 auf Konformität mit der "TSI PRM" gesetzt, die zahlreiche Regelungen für mobilitätseingeschränkte Fahrgäste enthält. Zu denen zählen bei weitem nicht nur die klassischen Rolli-Fahrenden, sondern beispielsweise auch anderweitig geheingeschränkte, kleine, hörgeschädigte, ältere, schwangere Menschen - oder schlicht solchen mit schwerem Gepäck. Das zeit sich in diversen Details am Fahrzeug - wie einem Sitz mit niedrigerer Höhe nahe des Faltenbalgs, entsprechend ausgestatteten Mehrzweckabteilen und im neuen Traditionsfarben-Lackierungsschema mit farblich abgesetzten Türen.


    Angepasst sind auch die Türtöne nach PRM, neu hinzugekommen sind zusätzliche grüne Leuchten: beim Öffnen der Türen sind grün blinkende Leuchten bei langsamem Gepiepse zu hören. Während die Türen geöffnet sind, hilft ein regelmäßig ertönender Piepton, der etwas an Krankenhausstationen erinnert, den Hörgeschädigten. Und je nach Schließmodus gibt's verschieden schnelle Piepser mit rotem Geblinke.


    Im Spiel ist das Ganze - soweit es der Train Simulator Classic sinnvoll hergibt - nachgebildet: alle roten und grünen Türleuchten sind je Seitentür unabhängig voneinander umgestezt, d.h. je nach zeitlichem Versatz beim Öffnen oder Schließen blinken die nicht unbedingt synchron - ganz wie beim Original, das auch diesen "Discomodus" der Türleuchten hat. Die Blinkfrequenzen sind mehreren Vorbildvideoschnipseln entnommen - wobei man sich beim schrittweisen Auszählen der Videoframes durchaus etwas verrückt vorkommt :D Ein Abgleich mit der TSI PRM hat die Werte bestätigt und bei der Einstellung des Gepiepses geholfen. Damit letzteres im Spiel nicht völlig wild klingt, sollten die drei unabhängig voneinander laufenden Seitentüren je Wagen (beim Vollzug also 24 Türen) nicht wild durcheinanderpiepsen, sondern synchrinisiert sein. Dafür wurden Taktgeber eingeführt, die vom führenden Fahrzeug generiert werden und dann durch den gesamten Zugverband an jedes Fahrzeug kommuniziert. So ist insgesamt für die vielen neuen, zu koordinierenden Details an dieser Stelle nochmal eine ordentliche Menge Code programmiert worden...


    Was nicht dabei ist: der 483/84er verfügt bekanntlich über eine Klimaanlage, so dass die Türen im offenen Zustand nach einigen Sekunden automatisch wieder zulaufen. Das ließe sich im Spiel zwar nachbilden, aber auch dafür sorgen, dass reihenweise Fahrgäste gegen geschlossene Türen laufen. Es gibt leider keinerlei Möglichkeit, im Fahrzeugskript abzugreifen, wann durch welche Tür ein Passagier gehen will.. Deshalb fiel die Entscheidung dagegen aus. Was in einem späteren Update aber denkbar wäre, ist die Möglichkeit einzelne Türen abzusperren - bestünde daran Interesse?


    Nun sind's allein zu den Fahrgasttüren wieder viele Worte geworden... dazu ergänzend noch ein paar bewegte Bilder:


    Externer Inhalt www.youtube.com
    Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
    Durch die Aktivierung der externen Inhalte erklären Sie sich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.


    Sind die Displays des FIS/Ibis bedienbar?

    Da es mit dem Fahrzeug kein IBIS gibt, ist auch der Bildschirm nicht bedienbar. Er zeigt aber das aktuell gewählte Zugziel an. Abhängig vom Feedback könnte ich mir vorstellen, entgegen der Vorbildausstattung auf dem Display evtl. noch ZZA-vor/zurück-Buttons einzubauen.


    Viele Grüße,
    Benjamin

    Hallo zusammen,


    heute ein tieferer Einblick in das Thema Zugzeilanzeigen:


    Im TrainSim wird es mit dem Ringbahn-483 kein vollständiges IBIS geben, aber wechselbare Zugziele. Diese sollten möglichst nah ans Original kommen. Dazu haben wir uns zunächst mal das original angesehen und festgestellt, dass die Anzeiger mit 200, 192 und 160 Pixel Breite an Front, Seite und Innenraum unterschiedlich groß sind, obwohl teils die gleichen Schruftarten zum Einsatz kommen. Das sollte natürlich beim Spielerzug auch so separat umgesetzt werden, weil es optisch doch einige Auswirkungen hat. Zusätzlich sollte auch die Anzeige der HMI des Führerstands einbezogen werden.


    Ganz grundsätzlich sind die Zugzielanzeiger (ZZA) mitunter ein sehr charakteristischer Bestandteil der Optik, vor allem an der Fahrzeugfront - je größer sie präsent sind, umso mehr prägen sie das Gesamtbild. Wenn man bedenkt, welche Drehgestellschrauben und Innenraumschlaufen mittlerweile ausmodelliert werden, sind ZZA einfach nicht mehr zeitgemäß, wenn sie mit Vektor-Schriftarten aus Windows-Bordmitteln à la "Arial" Zugziele umgesetzt werden. Daran ändert auch nichts, wenn die Vektorschrift dannn mit "Pixel-Hintergrund" ausgefüllt wird - es gibt dahingehend bis heute immer wieder Umsetzungen zu sehen, die meilenweit am Vorbild vorbeigehen. Auch wenn wir das in Vergangenheit v.a. für KI-Fahrzeuge ebenso gehandhabt haben, wollten wir doch davon wegkommen und hin zu einer originalen Optik. Aber machen wir uns nix vor: die vorbildnahe Optik erkauft man sich mit hohem Umsetzungsaufwand, vor allem wenn gleich eine ganze Serie an Zugzielen geboten werden soll. Doch es gibt ein paar "Verrückte" in der Szene, die ebenfalls so denken und schon so manche Originalschriftarten "nachgepixelt" haben. Da auch wir schon davon profitieren durften, nochmals ein dickes Dankeschön an dieser Stelle!


    Ich habe für künftige ZZA-Umsetzungen mehrere Tools entwickelt, primär eigentlich für andere Projekte - dazu bei Zeiten mehr - deren Workflow hier kurz gezeigt werden soll.

    Das Ziel ist es, die Pixelgrafiken nicht mehr vollends händisch zusammensetzen zu müssen.


    Im ersten Schritt sollen aus Pixelmustern die Buchstaben des "Alphabets" einer Schriftart als Grafik entstehen.

    Dazu benötigt es jede Menge Vorbildfotos, um zunächst alle benötigten Buchstaben, Ziffern und benötigten Sonderzeichen "nachzupixeln", d.h. als maschinenlesbares Pixelmuster zu erfassen. Das geht mit Textdateien ganz einfach, in den Matrizen abgespeichert werden -> "." = Pixel aus und "x" = Pixel an.


    Bei der S-Bahn stehen neben den üblichen Zeichen natürlich als Sonderzeichen v.a. Ringbahnsymbole und Flugzeugsymbol im Fokus. Die NSB verfügt zudem über mehrere mögliche Schriftarten - hier umgesetzt wurden zunächst Fett- und Schmalschrift in voller Höhe. Die zweizweilige Darstellung folgt evtl. noch später.


    Mit einem "Musterpixel" als Grafikvorlage werden aus den getippten Pixelmustern Grafiken:



    Nun sieht das aber insbesondere bei den neuen, stark leuchtenden LED-Anzeigen etwas zu "brav" aus, weil diese im Gegensatz zu alten Flipdot-Anzeigen häufig überstrahlen, so dass der Schein eines Pixels seinen Nachbarn überragt. Dazu wurde der Programmkern erweitert, so dass auch über ihre eigentlichen Pixelränder hinaus strahlende Anzeige-Pixel passend zu Zeichen zusammengesetzt werden können und sich benachbarte Pixel überlagern können. Im Gegensatz zum Standard-Modus genügt es hier nicht mehr, einfach Pixelgrafiken entsprechend des Matrix-Musters zu "stempeln", sondern die Farbwerte müssen sich additiv überlagern, so dass ein smoother Überstrahl-Effekt entsteht - man braucht also eine echte Filter-Anwendung.


    Beispielhaft dazu mal einige Zeichen aus dem Softwaretest:



    Links klassisch, rechts daneben im Testmodus fürs Überstrahlen (schwach rote Ränder um jeden Anzeige-Pixel, die stark rot werden, wo sie sich überlappen). Halbrechts im Ergebnis eine leuchtende "6" und ganz rechts noch eine zusätzlich generierte Glow-Maske: die gibt nicht nur den Effekt sehr eindrücklich wieder, sondern wird im Train Sim Classic auch im zweiten Texturkanal benötigt, um auch den passenden Shader nutzen zu können, der für strahlende Ergebnisse sorgt ;)


    Mit einem weiterem Tool werden aus den Einzelbuchstaben der jeweiligen Schriftarten dann Schriftzüge "gestempelt" (wobei im Leucht-Modus auch hierher Informationen zu ggf. übertrahlenden Rändern der Buchstaben übertragen werden müssen). Es wurde eine Skriptsprache entwickelt, die es erlaubt, für ganze Zugziel-Sätze stapelverarbeitend Befehle vorzubereiten. Dabei können vorbereitete Hintergründe zum Einsatz kommen, auf die mit entsprechendem Versatz die Schriftzüge passend aufgebracht werden.


    Wir sehen hier beispielhaft das Ziel Potsdam mit und ohne Überstrahl-Effekt.



    Um auch hier einfach mal zu testen, dass leuchtende Überlagerungen genauso für Nachbarbuchstaben (wie für Nachbarpixel eines Zeichens) funktionieren, ein übertriebenes Beispiel der S46 - klappt offensichtlich:



    Schließlich hab'ich versucht, ein halbwegs realistisches Leuchten der LED-Anzeige im Spiel zu erzeugen, die weder hinter dem getönten Glas weder am Tage, noch nachts oder im Tunnel völlig unrealistsich wirkt - gar nicht so einfach...

    Im Falle der Spielerzug-ZZA für den 483 / 484 wurden solche ZZA-Texte mit mehrfachem Versatz viermal für die verschiedenen Anzeigen ggf. abgewandelte Texte via Skript umgesetzt.



    Das Beispiel zeigt auch gleich den Einsatz mehrerer Schriftarten in einer Anzeige. Auf diese Art sind 57 Zugzielanzeigen mit ringbahntypischem Inhalt entstanden, die im Spiel ganz klassisch durchgeschaltet werden können.


    Als kleines Goodie zum fehlenden IBIS wird immerhin auch in der HMI stets das aktuell geschilderte Zugziel angezeigt:



    Zudem wird auch im Innenraum die ZZA mitgeschaltet:



    Und noch eine Impression von außen:



    Die gezeigten Tools werden uns für andere Projekte eine unverzichtbare Hilfe sein, konnten aber auch hier schon ihre Leistungsfähigkeit toll unter Beweis stellen :)


    Viele Grüße,

    Benjamin

    habt ihr denn zumindest schon das IBIS Problem gefixt beim 481er, um die Ringbahn im IBIS korrekt eingeben zu können? Oder hab ich ein Update dazu verpasst?

    Update gab es noch keines.


    Dazu muss ich mir ehrlich gesagt noch 'ne Meinung bilden. Die kurzfristige Pre-Releaseidee ist nicht passfähig zum 481-Update, wo grad mehrere teilfertige Erweiterungen drinstecken - mal schnell mit gexiftem Ringbahnbug geht so nicht - das wäre kurzfristig wenn überhaupt ein Extra-Entwicklungsast, der dann nicht weiterverfolgt würde. Eigentlich nur mehr Arbeit.


    Im Grunde habt ihr alles in der Hand, was ihr braucht: ihr könnt seit V1.04 das prioritäre Laden von Linienlisten aus dem Szenarioordner nutzen, wo ihr speziell zugeschnittene Listen verbauen könnt. Über den schon gezeigten Trick, den Startbahnhof anzupassen (ohne dass das viele praktische Auswirkungen hätte), geht von jedem Bahnhof aus eine volle Runde. Im Fall von Gesundbrunnen (der mehrfach in der Liste enthalten ist) als Ziel sogar beliebig oft - dabei muss nur der letzte Eintrag (noch) einmalig sein in der Linienliste.


    Bis hierher klappt das auch alles veröffentlichungsfähig - privat kann man sich natürlich vorübergehend auch beliebige Stationseinträge in der Datenbank mit neuer ID duplizieren, um auch von jedem Startbahnhof aus mit genau diesem Zugziel beliebig oft im Kreis fahren zu können.


    Viele Grüße,

    Benjamin

    Die Gedanken kann ich verstehen und teile die Ansicht, dass ein IBIS den Zug so richtig zum Leben erweckt. Das ändert aber nichts daran, dass eine Auftragsarbeit im abgestimmten Rahmen bleibt.


    Für den 483/484 sind dennoch einige Tausend Zeilen neuer Code entstanden, um die speziellen Eigenschaften des Triebzugs (insb. im direkten Vergleich mit dem 481), die auch im TSC umgesetzt sind, in der gewohnten Qualität darzustellen.

    Auch wenn's kein IBIS geben wird, arbeite aktuell an einem anderweitigen, kleinen Goodie, das den Spielspaß erhöhen soll - dazu bei Gelegenheit mal mehr.


    Danke auch für die Rückmeldungen zum Modell, ich gehe davon aus, dass es da noch Anpassungen geben wird bis zur finalen Version.


    Viele Grüße,
    Benjamin

    Genau, ein vollwertiges IBIS wird es hier leider nicht geben können - das ist bei einem Fahrzeug, das "nebenbei" zur Strecke kommt, vom Aufwand her nicht darstellbar. Es bleibt natürlich die klassische Möglichkeit, via Szenarioskript Ansagen einzubinden.


    Viele Grüße,

    Benjamin

    Das "Überschwingen" wurde mir kürzlich auch für einige aktuelle Regio-Triebzüge berichtet und ist ja ein klassisches regelungstechnisches Problem. Das musste in der Ausführung für den 483 hier gar nicht "umgesetzt" werden, sondern ergibt sich ganz automatisch in bestimmten Situationen. Wenn man bspw. von Gesundbrunnen gen Humboldthain volle Kanne anfährt und das Fahrzeug noch im recht zackigen Gefälle der Ringbahnunterführung die Vmax erreicht, dann wird die auch kurz überschritten, bevor dann wieder auf Vsoll gebremst wird. Also ja, der Effekt wird je nach Fahrverhalten stellenweise zu beobachten sein, auch wenn das System natürlich darauf getrimmt wurde, dass das im Regelbetrieb nicht oft passiert:thumbup:


    Viele Grüße,

    Benjamin

    Hallo zusammen,


    nachdem @icetea2202 schon viele Einblicke in die Entstehung des 3d-Modells gegeben hat, möchte ich mit der Einbindung in den TSC fortsetzen. Im ersten Teil schauen wir uns die Fahreigenschaften etwas genauer an.


    Aus anderer Anwendung im Hauptberuf habe ich ein Simulationsprogramm zur Hand, mit dem ich auf Basis von Fahrzeug- und Streckendaten die Fahreigenschaften von Fahrzeugen nachvollziehen kann (eine Fahrdynamiksimulation). Die erste Hürde war also, einen vollständigen, technischen Datensatz zur BR483/484 zusammenzubekommen - das war nicht ganz einfach, ist aber teils unter Annahmen sehr gut gelungen. Mitunter wurden mir via "Vitamin B" auch ein paar spannende Angaben zugearbeitet, die in den (halb)öffentlichen Unterlagen nicht zu finden sind. Vielen Dank an die Helfer! (Disclaimer: aus diesem Grund verzichte ich in den folgenden Diagrammen auf die Achsenbeschriftungen, um gewisse Rückschlüsse auszuschließen.)


    Basis für die Fahreigenschaften ist wie auch im 481-Addon ein zu 2/3 besetztes Fahrzeug. Danach wurden zunächst mal die "Fleischmassen" bestimmt. Nachdem Leistungsangaben, Zugkraftkurven etc. vorhanden waren, war schonmal klar, was das Fahrzeug bei Spitzfahrt können soll.


    Ich habe zudem einen kleinen, vereinfachten Infrastrukturdatensatz für die S47 zusammengestellt und das Programm mal laufen lassen. Hier Beispielhaft das Eregbnis für eine Fahrt Hermannstr. -> Spindlersfeld, also gar nicht soweit weg von unserem Ringbahnprojekt.



    Der Übersichtlichkeit halber ist die zugehörige Zugkraftkurve ausgeblendet, in blau also der bei Spitzfahrt entstehende Geschwindigkeitsverlauf. Das Tool generiert reichlich mehr Zahlen, so dass auch auf Leistungs-/Strombezug ab Stromschiene usw. geschlossen werden kann, was für jeden Zeitschritt in einer Tabellenkalkulation nachverfolgbar ist.


    Das Ganze resulitert unter anderem aus den Fahrzeug-Vorgaben für die Zug- und (elekrischen) Bremskräfte. Die sind hier mal übersichtlich aufgetragen:



    Man kann unter anderem erkennen, dass die elektrische Bremsleistung erst "kurz vor Null" abfällt, d.h. es wird der größte Teil im Normalbetrieb elektrisch gebremst, das werdet ihr später auf der HMI auch an der Rückspeisequote sehen. Erst bei Unterschreiten von 7 km/h wird die Druckluftbremse zugeschaltet - wie beim 481 greift im Stand zudem die Haltebremse.


    Außerdem fällt auf: der konstante Bereich des Bremskraftverlaufs reicht bis in deutlich höhere Geschwindigeitsbereiche, d.h. es kann mit mehr elektrischer Leistung gebremst und rekuperiert als beschleunigt werden. Es ergibt Sinn, Fahrzeuge so auszulegen - denn umgewandelte Bremsenergie kann zunächst in die Hilfsbetriebe gespeist werden, bevor man beginnt, die Netz-Rückspeisung auszuschöpfen, wobei natürlich wie beim Beschleunigen auch Wirkungsgradverluste anfallen. Es ist jedenfalls auch im Vollbahnbereich üblich, solch hohe elektrische Bremsvermögen vorzusehen.


    Interessantes Detail: um die bis zu 104 kN je Viertelzug abzurufen, bedarf es bei der aktuellen Netzspannung von 750 V dann Strömen bis ca. 1 kA. In der Regel liegt die Netzstrombegrenzung im Netz der Beliner S-Bahn bei 4000 A je Zug - d.h. allein das Traktionieren schöpft das Ganze voll aus (so viel vorab: die Kiste zieht auch im Spiel ab wie Schmidt's Katze, wenn man den Hebel auf den Tisch legt. Ein großer Spaßfaktor für die Schienenrüpel unter uns, zu denen im am PC auch gern mal gehöre :D ). Da laufen dann aber noch keine Nebenbetrieb, insbesondere Heizung/Klima. Wie das genau gelöst ist, fragt ihr die Siemens- und Stadler-Experten - auch bei der Auslegung des Originals war das ein Punkt, um den man sich ganz zum Anfang kümmern musste. Schon bei einer der ersten öffentlichen Präsentationen (ich meine, es war 2016 an der TU Berlin) wurde erklärt, dass das Ganze ein "mehrdimensionales Schachspiel" sei. Man kann sich ausmalen, dass die Heizung/Klima während des (maximalen) Beschleunigens ggf. kurzzeitig zurückstecken muss und entsprechend zu regeln ist. Aus dieser Überlegung heraus entsteht dann übrigens auch die nicht ganz neue Diskussion um die Erhöhung der Netzspannung auf 1500 V, die die Problematik entschärfen würde. Euch wird beim Fahren von Vollzügen im Simulator auffallen, dass der Netzstrombezug schon vor 100% Regler die Grenze von 4 kA erreicht.


    Nun müssen die theoretischen Erkenntnisse und Überlegungen noch irgendwie in den Train Simulator Classic kommen. Die Umsetzung im Railworks ist wiederum mit Hürden verbunden, wie auch andere Entwickler schon häufig berichtet haben. Dazu gibt es also einige zusätzliche Berechnungsskripte und "Übersetzungsregeln". Bekanntlich ist der TSC eine Wunderkiste, die stellenweise leider schlecht dokumentiert ist - nicht alles lässt sich so handlich aus der Theorie übertragen.


    Es gibt Knicke im RW-prototypischen Zugkraftverlauf, die kaum ein Original so hat. Der Fahrwiderstand setzt sich aus nur 2 Gliedern (konst. und quadratisch) in kruden Einheiten im Sim zusammen, wo im Original in der Regel auch ein lineares Glieg genutzt wird. Auch für sowas sind möglichst passige Übertragungen zu finden - mathematisch teils kein Hexenwerk, aber es kostet alles Zeit, die man sich dafür nehmen muss. An dieser Stelle vielen Dank an alle in der Community, die teils unermüdlich auf der Insel nachgebohrt haben und die sich über die Railworks-Versionen hinweg teils geänderten Werte und Formeln nachverfolgt (und dokumentiert!) haben. Ohne solche bruchstückhaften Einblicke wäre kaum eine sinnvolle Umsetzung möglich..


    Beispielhaft sei noch der E-Bremsbug des TSC genannt - der ist gegenüber der BR481-Umsetzung diesmal von der ersten Minute an ins Umsetzungskonzept eingeplant worden und konnte deshalb ein ganzes Stück robuster umgangen werden. So viel: die meisten Manometer sind rein virtuelle Ausgaben und geben keine Werte aus, die der TSC gerade zu verarbeiten glaubt. Entsprechend umfangreich fallen die Skripting-Aufsätze über die eigentliche Fahrzeugtechnik hinaus aus.


    Am Ende gibt es so viele Besonderheiten zu bedenken, dass es eigentlich gar nicht ohne Kontrolle dessen, was am Ende im TSC passiert, gehen kann. Also: man nehme sich ein kompaktes 483-Viertel und stelle die eingangs genannte Spitzfahrt nach. Das Lua-Skript macht dabei sekündlich Ausgaben zum Fahrzustand, die wir mit dann der Theorie vergleichen können.


    Als erstes die Beschleunigung - hier im Vergleich der Theorie (blau/grau) gegenüber dem TrainSim (orange/gelb).



    In der Grafik weicht der Verlauf im untersten Geschwindigkeitsbereich etwas ab - hier zieht die neue S-Bahn (NSB) schneller an, als anfangs in der Theorie angenommen und wurde im Sim anhand von Videos und Mitfahrten entsprechend nachjustiert. Sonst ist das alles aber erfreulich deckungsgleich, d.h. die Theoriewerte werden auch im Simulator ziemlich genau erreicht. Das Abflachen der gelben Zugkraftkurve im TrainSim resultiert aus dem Tempomaten, der bei Erreichen von Vmax (=VSoll bei ausgeschaltetem Tempomaten) sanft abregelt - man erahnt da auch noch den Knick im blauen Theorie-Geschwindigeitsverlauf.


    Außerdem ist bei diesem Fahrzeug ganz besonders wichtig, dass auch die konkret erreichten Zugkraftwerte dem Original entsprechen: wir wollen schließlich noch die verfahrenen Kilowattstunden zählen! Dazu in einem späteren Beitrag mehr..


    Und hier auch noch das Brems-Ergebnis bei voller Betriebsbremsung aus Railworks (blau = Theorie, die wir weiter oben schon gesehen haben; orange = Messung aus dem TrainSim):



    Nanu, das sieht aber nach einigen Abweichungen aus?! Der Reihe nach: wir erinnern uns, der Zug ist zu 2/3 besetzt. Daher schöpft der Zug hier nicht die maximale Bremskraft aus, um auch voll beladen noch die gleiche Vollbrems-Verzögerung erreichen zu können. Rechts überragt die Bremskraft dann aber doch die Vorgabe. Erklärung: die Theorie-Kurve zeigt die Dauerleistung, die das Fahrzeug im elektrischen Bremsbetrieb bringt. Kurzzeitig können die Komponenten aber überlastet werden, was im oberen Geschwindigkeitsbereich zu mehr elektrischem Bremsvermögen führt. Der Ausreißer kurz vor Null resultiert noch daraus, dass hier die Gesamtbremskraft inkl. Druckluftbremse, die sich ja kurz vor Halt zuschaltet, aufgezeichnet wurde - in der Theorie hatten wir aber nur die E-Bremskurve betrachtet. Hier zeigt sich mal wieder, dass ein paar spärliche Datenblätter und Theoriewerte oft nicht reichen, um das Fahrverhalten realistisch abzubilden. Ich bin jedenfalls bei jedem Projekt dankbar für die zusätzlichen Infos, die mir so zugetragen werden!


    Nicht nur in den Diagrammen geht das alles sehr zufriedenstellend auf - auch im Simulator ist der traktionsstarke und sehr handlich bedienbar gestaltete Hobel eine Wucht. Die Tester sind bislang zufrieden und auch diejenigen, die schon den echten 483 unterm Hintern hatten, haben sich noch nicht beklagt. Aus Fuzzisicht mag die "NSB" mit aufgeweichtem Traditionslackschema und DB-corporate Innendesign gegenüber Vorgängerbaureihen ein wenig charakterlos wirken - aber fahren kann sie! Zusammen mit dem recht charakteristischen Sound (dazu kommen wir auch noch..) haben wir dann doch wieder eine Sammlung von Eigenschaften, mit der sich "die Neue" dann doch ins Fuzzi-Hirn einbrennt.


    Und damit es heute auch noch etwas fürs Auge gibt - der 483 hat seit den letzten Screens viele Fortschritte gemacht, die wir uns noch in weiteren Beiträgen genauer ansehen wollen. Ein Eindruck von den vielen Testkilometern..




    Viele Grüße,

    Benjamin

    Hallo zusammen,

    Chris Trains RS1 mit Soundupdate wäre auch zu testen.

    ..ging auch mit dem gestrigen Update noch nicht. Habe daher mal einen Blick draufgeworfen.. und gehe nicht davon aus, dass von DTG diesbezüglich noch was kommen wird.


    Hintergrund ist, dass Perotinus die Audio-Proxies offenkundig händisch bearbeitet und dabei eigene IDs für neue Inhalte vergeben hat. Hab ich auch schon oft gemacht - bei der Komplexität der Files ist allerdings die Gefahr hoch, IDs doppelt zu vergeben, wo sie eindeutig sein sollten - ist mir auch schon passiert. Ich habe auch einige betroffene Stellen gefunden, es aber mit ein paar Anpassungen wieder zum Laufen bekommen. Hier scheint der TSC mit den 2023er-Updates einfach weniger fehlertolerant zu sein, insb. bei gleichen IDs in verschiedenen Sektionen des Proxies, die bisher teils toleriert wurden. Es lohnt m.E. auch in vielen Soundpatch-Fällen den Blueprint-Edi zu nutzen, mit dem sich solche "formalen" Fallen umgehen lassen.


    Man kann sich fürs Erste selbst helfen:


    Vielleicht mag Perotinus ja die Änderungen übernehmen und eine angepasste Version in der Filebase einstellen.


    Jedenfalls auf diesem Wege vielen Dank linusf und Perotinus für die Soundmods. Mit den beiden Updates rockt der RS1 so richtig default_punk.gif


    Viele Grüße,

    Benjamin

    Hi Alex,

    1)The author from http://h-transport.pxtr.de/dbmu.htm writes that some Dostos(especially the original, dark green ones) came with block brakes instead of disc brakes, could anyone confirm this and if the other infos(car numbers,etc) can be trusted from this site? We thought all the German Dostos came with disc brakes from the factory.

    2)Interesting facts wrote by @BigBenjy, we would need as much as possible some help with photos showing interior and exterior differences between different steuerwagen variants(original,"Berlin",partially modernised,etc) so if anyone could post here it would be greatly appreciated.

    as far as I know: the fleet of (partly) modernised (former) DR double deck coaches trace back to two series deliveries: 1979 series with block brakes and 1986 series using disc brakes. Your render image shows the DBmq(z) 775 modernised from the 1986 series with disc brakes, later rebuilt to class 778.0 coaches. On top, there were two exemplars of the DBmq(z) 776 that were modernised from the 1979 series with block brakes, later rebuilt to class 778.2 coaches.


    Best regards,

    Benjamin

    Hallo zusammen,

    Mal blöd gefragt, was passen da denn passenderweise für Loks dazu ?


    Also mit welchen Loks waren die Züge damals bespannt ?

    auf dem Renderbild ist ein DBmq(z) 775 zu sehen. Das ist die teilmodernisierte Variante des DR-Steuerwagens, von denen es in der dargestellten Scheibenbremsversion genau 7 Stück gab, die im Zeitraum '92 bis '98 unterwegs waren, bevor sie vollkommen zu 778.0ern umgebaut wurden. Entsprechend gab es davon nur die mintgrüne Version; durch die fehlende UIC-Datenleitung waren die Wagen auch nur mit ehem. DR-Loks einsetzbar, die über die 34-polige Steuerleitung verfügen. Verkehrsrot, Einsätze vor ehem. Bundesbahnbaureihen und DBAG-Neubeschaffungen scheiden mit diesem Vorbild aus. Ich kenne von den Wagen lediglich Einsatzbilder mit Holzroller und 143 in den Großräumen Berlin und Leipzig. Möglich gewesen sein sollten auch DR-V100 und DR-V180, mit denen habe ich bisher aber nur Bilder zusammen mit dem eng verwandten 776er gesehen.


    Viele Grüße,

    Benjamin

    Das kann ich bestätigen, das Buch liegt uns auch vor. Glücklicherweise konnten wir bis jetzt mit Hilfe unseres Netzwerks Informationen zusammentragen, die weit über die veröffentlichten Inhalte hinausgehen - so haben sich Gedanken für manche Features ergeben, die über die des 481-Addons hinausgehen. Davon aber bei anderer Gelegenheit mehr :)


    Viele Grüße,
    Benjamin

    kommt von deiner Seite her auch ein passendere Fahrzeug, was uns all die Jahre begleitet hatte?

    Bei uns laufen mehrere (Fahrzeug-)Projekte parallel, darunter auch der bereits angekündigte Dosto. Wenn die weiteren Vorhaben einen entsprechenden Stand haben, wird es wie gewohnt auch dazu noch einige Zeit vor dem Release Ankündigung & Infos geben :)


    Viele Grüße,

    Benjamin

    KiDmorbid Der 483/484 ist eine Auftragsarbeit für die Ringbahn, insofern obliegt grundsätzlich Jan die Hoheit darüber, was vorab gezeigt wird. Wir haben uns in den letzten Tagen dazu koordiniert: es wird auch direkt vom TTB der eine oder andere Beitrag zum Fahrzeug kommen. Nick, der das 3d-Modell erstellt hat, macht in Kürze den Anfang :)


    Viele Grüße,

    Benjamin

    Moin!


    Kann ich nicht bestätigen und konnte es hier soeben mit exakt der gezeigten Fahrzeugnummer problemlos umsetzen. Irgendwas händisch am Addon geändert oder eins der Szenariopacks, die das Feature (noch) nicht kennen, nach der S-Bahn installiert? Dann am besten den 481 in aktueller Version noch einmal ohne vorherige Deinstallation drüberinstallieren.


    Viele Grüße,

    Benjamin

    Das IBIS kann sich verschlucken, wenn Stationen einer Tour doppelt vorkommen - also beim Ring. Dafür gab's halt bisher keine sinnvolle Anwendung... Nach Ankündigung der Ringbahn wird es natürlich eine Anpassung des Skripts mit einem der nächsten Updates geben. Bis dahin kann man sich aber mit Nutzung des neuen "Priority Loading"-Features eigene, maßgeschneiderte Listen ohne Dopplungen für bestimmte Szenarien bauen.


    Viele Grüße,

    Benjamin

    habe das Szenariopaket erneut installiert, dann hat es funktioniert. Ist aber wohl auch nicht so im Sinne des Erfinders....

    Im Gegenteil, solche Prüfungen haben ihren Sinn: wie schon per Mail geschrieben war das Szenariopack nicht (mehr) vollständig installiert. Das musste mit dem erneuten Aufruf des Installers korrigiert werden, sonst wäre das Bonuspack nicht sauber installiert worden.


    Viele Grüße,

    Benjamin

    Hallo,


    sowas wie versetzte Kupplungshaken können schonmal vorkommen, wenn man in Fahrzeugen rumbastelt. Die Partikelemitter des Ausgangsmodells setzen keinerlei Gizmo-Mesh aufs Dach, insofern ist die Ursache also nicht im Szenariopack bzw. Bonuspack zu suchen.


    Die verdrehte Drehgestellblende ließ sich auch mit den parallel vom User zugesandten RW-Einstellungsset nicht nachstellen - wird aber trotzdem ein Prüfpunkt fürs nächste Update.


    Viele Grüße,

    Benjamin

    Hallo zusammen, lieber Jan,


    zunächst auch von mir ein default_cheers.gif auf das, was in den letzten zehn Jahren entstanden ist. Und gleichermaßen darauf, dass die kreative Schiene auch in den nächsten Zehn hin und wieder zur Station namens "Addon-Release" führen möge. Ich freue mich auf das, was da noch kommt ;)


    wie wäre es mit einem fahrbaren 480 den ihr dann mit der Ringbahn von bahnjan veröffentlicht? :love::liebe:

    Nicht nur 480, auch ein 485 würde da sehr gut hinpassen *Hust* BigBenjy

    Jan und ich haben uns zur Ringbahnplanung schon ausgetauscht. Wir schauen mal, was TTB-seitig so möglich ist ;)


    Viele Grüße,

    Benjamin