Beiträge von StefanDD

Discord Einladung
Trete unserem Discord-Server bei (klicke hier zum Beitreten).

    Die BR 111 ist zwar noch einer der besten im TS, aber man merkt schon ihr alter an. Schlimm ist es nicht, aber ein Upgrade auf die neue PZB Version wäre schon nicht schlecht.

    Wie oben schon erwaehnt, arbeitet die PZB der BR111 (auch der EL) in manchen Bereichen nicht so wissenschaftlich wie in den neuen Loks. ;) Im vorliegenden Fall ist eine Kombination von Startprogramm und die Auslegung von unerlaubter Befreiung der Suendenbock. Die 111-er PZB wertet die Befreiung aus dem Startprogramm als Befreiung aus restriktiver UF (das ist ja eigentlich noch richtig) und erzeugt eine ZWB an JEGLICHER Beeinflussung innerhalb der naechsten 550m, obwohl das eigentlich in der Realitaet nur dann passiert, wenn eine 500Hz Beeinflussung innerhalb dieser Strecke kommt.
    Loesung hier: einfach nicht aus dem Startprogramm befreien und die 550m mit <45km/h abzuckeln...

    kann es sein das bei der Locon die Kameras fehlen

    Ja .. ist mir auch aufgefallen. Ausserdem, hab ich vorhin die Lok auf dem Monitor abgeklopft, aber der Lokkasten scheint hier gar nicht aus Metall gemacht zu sein. Ich glaub das ist alles ein Moerderschwindel... :ugly:

    ...weil sie kein Interesse haben sich in eine Lok "einzuarbeiten"...


    So unterschiedlich sind die Interessen..

    Die meisten Leute die Simulatoren moegen, stoeren sich nicht an Liebe zum Detail. Ich finde nicht, dass die vR Loks viel Einarbeitung benoetigen. Vergleiche doch mal deren Handbuecher mit z.B. dem Handbuch von Falcon 4 oder DCS A-10C. Letztere sind Hardcore Simulationen, vR Loks sind nun wirklich nicht so hart zu bedienen, es sei denn, man ist geistig ueberfordert oder liebt das eher Schlichte und Simple. :)

    Ist es bei Euch in der Lok auch 32Uhr irgendwas?


    Was mich bei DTG wahnsinnig aergert ist die unglaubliche FAULHEIT, mit der Addons gemacht werden. Da werden die Ebula und GSM-R Consolen aus frueheren Addons kopiert, die Blueprints und Texturen enthalten alle Elemente fuer eine funktionierende Uhrenanzeige (wie bei BR120 oder BR155) und alles was fehlt ist eine kleine Geometriedatei fuer den Fuehrerstand die dem TS sagt, wo er die verschiedenen Zahltexturen anzubringen hat. Dass sie nicht versehentlich fehlt sieht man am leeren GeometryID Eintrag in DigitalClock.bin. Das heisst, aus reiner FAULHEIT wurde das weggelassen.


    DTG1: "Oops nach dem copy&paste schweben die Digitalstellen der Uhr im Raum!"
    DTG2: "Ach, da musst Du nochmal in Blender rein und die Projektionsflaechen neu positionieren"
    DTG1: "Mmh. Ach was, wir loeschen den Geometryeintrag im Cab-Blueprint -- ist doch egal, die doofen Krauts kaufen's doch eh!"
    DTG2: "Aber dann sieht man ja die alte Testzeit 32:10:10 auf der Textur"
    DTG1: "Egal -- wenn's einer merkt, sagen wir, das liegt halt' am Brexit!. Hahahah..."
    DTG2: "Teezeit!"

    @aleister (post 180)


    Ich frage mich was genau solche eher selbst-referenziellen postings uns mitteilen sollen ?(
    Moment -- ich probier' das auch mal:
    "Koche gerade Moehrensuppe ... ob ich mir die neue Lok von vR kaufen werde, weiss ich noch nicht... Wuerde mich eher ueber was anderes, thread-fremdes freuen ... es klingelt gerade, und der Vermieter steht vor der Tuer und will wissen, was das mit der angekuendigten ES64F4 zu tun hat? Nichts, antworte ich, und lade ihn herzlich zur Moehrensuppe ein" LOL!

    Bei dieser Lok wird die Traktionssperre sinngemaess so errechnet:


    wenn Zugbremse nicht nahezu geloest oder Handbremse angezogen oder Tuerschalter nicht auf geschlossen oder dynamische Bremse nicht nahezu geloest oder Rischa auf Null dann
    Traktionssperre = EIN
    ANSONSTEN und wenn Leistungshebel zwischen Null und 10% dann
    Traktionssperre = AUS


    Daraus folgt auch, dass man den Leistungsschalter nicht zu schnell ueber 10% ziehen darf, damit das Skript die Position unterhalb 10% und oberhalb Null wenigstens kurz registriert.

    Heute beim Fahren des neuen Gleistransport-Szenarios auf HaSi hatte ich das selbe Problem bzw. den selben Fehler, wie auch schon mal in der 101: Nach dem dritten Wechsel des Führerstandes wollte die PZB nicht mehr, sprich sie gab kein Lebenszeichen mehr von sich.

    Das ist hoechstwahrscheinlich nicht so -- die PZB ist schon da. Wie hast Du den FSt gewechselt? Wenn man nicht im Stillstand wechselt, wird der Wechsel nicht akzeptiert und es kann sein, dass man die PZB an/ausschaltet und keine LMs angehen sieht weil sie im noch als aktiv geltenden FSt laeuft. In einer solchen Situation mal folgendes probieren: im ANGESCHALTETEN Zustand ("PZB An" Meldung) und im Stillstand zweimal Strg + [+] oder 2x Strg + [-] druecken. Dann sind die Leuchtmelder wieder da, oder?

    Das eigenartige Verhalten bei reiner PZB Fahrt in Doppeltraktion, dass die Bestätigungen erst bei der zweiten Lok greifen(ob das allerdings auf allen Strecken gilt, weiss ich noch nicht)

    Was genau ist das Verhalten? Was greift bei der 2. Lok? Wenn Du in Doppeltraktion ein restriktives Signal bestaetigen willst, was passiert anders als mit nur 1 Lok? Ich hoffe Dich verwirrt nicht, dass es im TS immer das vordere (aus Sicht der Fahrtrichtung) Zugende ist, welches Beeinflussungen ausloest...


    UPDATE: Warum ich das ueberhaupt getestet habe, ist mir scheierhaft :), aber in Doppeltraktion funktioniert m.M.n. alles so wie es soll! Inwiefern soll das Verhalten bei BR111/112 anders sein?


    Ich moechte ja gerne helfen, brauche aber ein bisschen konkretere Informationen!

    Mir ist nur aufgefallen, bin auf Bahnknoten Seddin mit nem Kesselwagenzug gefahren, das zum einen die Leuchtmelder ausfallen, wenn man den Fst wechselt und zum Anderen beschleunigt die Lok nur bis 105 km/h oder so und dann bricht apprupt die leistung ab.

    Im TS hat der nur der FSt mit dem man angefahren ist "den Schluessel", d.h. die Traktionsnadeln etc. haengen im anderen, wenn man waehrend der Fahrt umschaltet. Daher werden auch die PZB LM nicht angezeigt. Wenn man in den anderen FSt will und unter PZB Fuehrung fahren will, einfach voll abbremsen und dann wechseln. Dann sind auch die Leuchtmelder an (Startprogramm ist dann auch wieder aktiv!).


    @MarcoL397
    Bitte mal Foto in Beitrag 84 anschauen. Ich finde, wenn ueberhaupt, das Gegenteil ist der Fall, und im TS sieht die Lackierung meistens zu matt aus und zeigt nicht genuegend Glanz...

    DTG hat hier aus Schludrigkeit oder bewusst die Bremsfunktion der AFB ausgeschaltet. Ich haenge einen kleinen Patch an, den man per Hand installieren muss, der das Problem aber behebt. Alles was die Patchdatei macht, ist die Initalisierungsroutine der AFB nochmal korrekt aufzurufen.


    Installation (nur fuer Experten):
    1. Anlegen von "Assets/DTG/BR120Pack01/RailVehicles/Electric/CommonScripts"-Verzeichnis und Entpacken von "BR120_EngineScript.out" aus BR120Pack01Assets.ap [RailVehicles\Electric\CommonScripts\BR120_EngineScript.out] in dieses neue Verzeichnis "Assets/DTG/BR120Pack01/RailVehicles/Electric/CommonScripts" .
    2. Umbenennen dieser "BR120_EngineScript.out" in "orig_BR120_EngineScript.out
    3. Kopieren der angehaengten "BR120_EngineScript.out" in das gleiche Verzeichnis (RailWorks\Assets\DTG\BR120Pack01\RailVehicles\Electric\CommonScripts), so dass man dort jetzt 2 .out Dateien hat: BR120_EngineScript.out und orig_BR120_EngineScript.out



    Viel Spass!

    @[1247]DetPhelps Scheint den meisten hier ja zu gefallen, also wäre es eh sinnlos, diesen Vorschlag zu machen. Mir kommt das nur sehr komisch vor. Man erkennt schon stark, dass die Textur einfach darüber gelegt wurde. Und sonderlich scharf sieht das auch nicht aus. Naja, abwarten.

    Was genau hast Du denn erwartet? Meiner Meinung nach sind bei keiner einzigen Lok im TS Leuchtmelder oder beleuchtete Anzeigen tatsaechliche Lichtquellen sondern halt Texturen mit als beleuchtet gerenderten Instrumenten die druebergelegt werden.

    ...Railtraction sollte sich mal die Mühe machen und sich die Erlaubnis einholen das Ding zu überarbeiten....

    Ich habe mir die Skripte von RT mal grob angeschaut (im Bytecode) und kann sagen, dass das RT BR648 eine Weiterentwicklung des RT BR218 Skriptes ist. Man haette also ohne Probleme die Aenderungen mit 3 Zugarten zur BR218 rueckportieren koennen und koennte das immer noch. Man macht es aber leider nicht, wahrscheinlich eben weil die Kaeufer ja schon bezahlt haben und der Aufwandsanreiz fehlt :(



    P.S. Ich fahre die RT BR218 mit meiner eigenen vollstaendigen PZB, und ich wuerde den Patch dazu auch veroeffentlichen, wenn ich die Erlaubnis von RT dazu haette (oder jemand dafuer von RT die Erlaubnis einholt). Ich wuesste aber garnicht, wen man da ansprechen sollte und die Wahrscheinlichkeit, dass die dem zustimmen wuerden ist sehr gering.

    Ich denke, wenn Maik privat oder vR offiziell postulieren, dass was nicht "geht" oder "machbar" ist, sollte man natürlich dahinter in Klammern setzen: "(mit ökonomisch vertretbarem Aufwand)". Eine noch realistischere Bremsensimulation, oder z.B. slip/Rutschverhalten von Raedern etc., ist prinzipiell immer machbar. "Geht nicht" soll dann einfach heissen: "wuerde ewig dauern, massiven Aufwand zeitigen, und koenntet ihr nicht bezahlen :P", nur halt in verknappter Form.


    Ich persönlich freue mich über input von usern wie flusi737, die enthusiastisch sind, und das sogar mit Taten (Videomaterial) untermauern, aber es geht nicht nur um das Wasser, mit dem natuerlich alle kochen -- und da ist vR ganz vorne mit dabei -- sondern um einfach auch technische Limits. DTG hat leider keine ge-jittete Lua engine verbaut, sondern Lua 5.02 und die volle Lokphysik gehört eigentlich in den C++ Code, aber davon verstehen die leider selber nichts (weil halt nur zugekauft). vR und Co. betreiben schon extreme Handstände und verlagern einiges der Physik in die Luaskripte, aber das frisst Frames und ist aufwändig.