Beiträge von MrSumner


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

    @srallinger
    Da bin ich jetzt erstmal auch ein wenig überfragt. Bei mir ist das manchmal aufgetreten, dass ich den "Throttle" nicht vollständig auf Leerlauf ziehen konnte, sondern der immer leicht drüber hängen geblieben ist. Auch mit dem Richtungswender hatte ich gelegentlich Schwierigkeiten, die beim nächsten Anschließen wieder nicht dabei waren. In dem Fall schiebe ich das Problem auf eine zu ungenaue Kalibrierung. Dann wäre das Problem aber auch nicht ständig, dürfte in Deinem Fall also eher nicht greifen. Wie @hrieger richtig geschrieben habe, in der 103 habe ich an den Bremsen nichts verändert.


    Die Bremsachsen werden aber grundsätzlich schon erkannt? Gibt es so eine Art untere Schwelle, bis zu der Du die Bremsen lösen kannst? Und es betrifft jetzt nur die Einheitsloks, sowie die 103?


    Ich hab jetzt leider bis nach Januar nicht die Möglichkeit Dein Problem mit meinem Raildriver nachzuvollziehen. Aber Du kannst mir trotzdem mal Deine Skripte hier hochladen (entweder in eine .rar packen oder in .txt umbenennen), dann schau ich mal drüber, ob mir da was auffällt.


    Lg,
    Sumner

    Ich habe mir nun nochmal das Verhalten der Einheitslokomotiven genauer angeschaut und nun folgende Änderungen eingepflegt. Interessanterweise wurde die Achse komplett richtig erkannt, so dass die Zugbremse in den "Schnell Lösen"-Bereich kommt und dort festsitzt. Ich habe nun diesen Bereich aus der Raildriver-Bremsachse entfernt und auf die "Bail-Out"-Funktion der Lokbremse dieses "Schnelle Lösen" gelegt. Damit sollte sich die Lok nun realistischer Fahren als jemals zuvor. Dieses versehentliche Zischen ist damit auch kein Problem mehr. Es geht um folgende Änderungen, die in blau hervorgehoben sind. Ich empfehle dringend, eine neue Kopie Eurer Skripte zu erstellen und diese Änderungen nun explizit nur für die Einheitsloks (E10, E40, 110, 140) von Virtual Railroads anzuwenden!


    1.) Zugbremse, zu finden in "Case 2003 'Train or Auto Brake"


    2.) "Case 2005 'Bail Off" - wird aktiviert, wenn die Lokbremse nach rechts gedrückt wird.


    Damit werden nun die Bremsen sauber angesteuert.


    Für jeden, dem die Steuerung der Fahrstufen etwas zu ungenau ist, schlage ich für die Einheitslok noch folgende Änderungen vor:


    3.) Case 2002 'Throttle


    Mit diesen Änderungen wird nun die gesamte Länge des Throttles als Fahrtregler verwendet. Allerdings ist damit die Nutzung der E-Bremse nicht mehr möglich. Bei den Einheitslok lässt sich die aber eh nicht ohne weiteres Entkoppeln, so dass das unterm Strich nicht stören sollte.


    Damit die Änderungen aus 3. aktiv sind, muss noch folgendes eingetragen werden:


    4.)


    Im Anhang findet ihr 2 txt.-Dateien. Diese könnt Ihr in .mw3 umbenennen, dann habt ihr das Skriptformat für den Raildriver. Die oben geschilderten Änderungen findet ihr in dem Skript der Einheitsloks.


    Als Bonus habe ich noch ein Skript für die BR 103 EL angehängt. In diesem Skript sind neben @hriegers obligatorischen Änderungen eingearbeitet, sowie auf die 103 zugeschnittenene Schaltstufen, ähnlich wie in Schritt drei in der Beschreibung oben. Damit sollte sich auch die Baureihe 103 nun viel sauberer mit dem Raildriver fahren lassen, als bisher möglich!


    In diesem Sinne allen eine fröhliche Weihnacht und viel Spass beim ausprobieren!
    Euer Sumner

    Hallo zusammen,


    es gibt mal wieder etwas neues. Diesmal sind die Einheitslokomotiven die Stars: Bei einer Fahrt mit der BR110 Verkehrsrot hatte ich Schwierigkeiten, die Lok in Bewegung zu setzen, obwohl alle Achsen richtig erkannt werden. Trotz richtigem Aufrüsten, Türen geschlossen, wollte die Lokomotive keine Leistung aufschalten. Kurzes Umschauen in der Lok brachte das Ergebnis: Die Bremse löst sich nicht vollständig, wenn die Bremse am Raildriver gelöst wird. Das liegt in dem Fall an der Simulation des Füllstoßes. Das Hinzufügen des folgenden Befehls im Skript sorgt dafür, dass nun, sobald die Bremse am Raildriver vollständig gelöst wird, kurzzeitig der Bremshebel zurückgezogen wird, als ob kurz "ü" gedrückt wird. Im Skript sieht das wie folgt aus:


    Es gibt dazu nun neueres in den Posts weiter unten. Daher ist dies hier obsolet und kann gelöscht werden.



    Weiterhin viel Spass und alles Gute,
    Euer Sumner

    Schade auch das sie nicht an den Raildriver gedacht haben, sonst funktioniert immer alles mit dem Script, hier leider noch nicht. Also entweder selbst Hand anlegen oder auf ein Update warten. Würde bei den unzähligen Rangieraufgaben die auf uns warten schon Sinn machen!

    Da ich da natürlich auch schon drüber gestolpert bin, habe ich auch schon versucht das zu lösen. Der Witz ist, dass das Standard-Skript bei mir gut funktioniert. Das Problem tritt erst auf, wenn man @hriegers Anleitung befolgt, um die Achsen des Raildrivers neu zu belegen. Ich verstehe nicht, warum das jetzt auf einmal passiert. Meine Lösung war jetzt relativ einfach: Ich habe das Skript, welches ich als DTG-Standardskript verwende kopiert. Anschließend geht es um folgende Zeilen unter Case 2002 "Throttle".


    Also solltest Du in dem Case 0 auch noch folgende Zeilen umändern so daß Gas dann im DYN BRAKE Bereich liegt und Du somit mit Gas 0% anfängst:
    m=lever(1).islope(0) in m=lever(1).islope(1)
    b=lever(1).iintercept(0) in b=lever(1).iintercept(1)

    Mache ich diese letzte Änderung rückgängig, kann ich die BR 361 ganz normal mit dem Raildriver fahren. Es wird auch weiterhin nach vorne/oben Leistung die Fahrleistung erhöht. Unterm Strich bleibt damit die Richtung des Raildrivers invertiert, der Leistungsregler liegt aber dann auf der unteren Hälfte des Raildrivers, nicht auf der oberen. Also in Kurz, schreibt in das Skript an die entsprechende Stelle (Case "2002" Throttle - Case 0) die blauen Zeilen anstelle der Roten, und ihr könnt auch diese Lokomotive gut bewegen.


    Beste Grüße,
    Sumner

    Hallo nochmal und sorry für den Doppelpost.


    Im Skript der BR 111 ist mir noch ein kleiner Fehler unterlaufen. Dadurch springt manchmal der Fahrschalter auf "Aus", obwohl er nur auf "Ab" gezogen wurde.


    Es handelt sich um die Zeile
    "Else If (AnalogValue(0)>minbrake-20 And AnalogValue(0)<minbrake+15) 'Ab". Im Readme entspricht das dem Punkt 3 im Abschnitt Kalibrierung der 111.
    An die Stelle des roten größer als (>) muss ein größer gleich (>=) gesetzt werden. Also:
    "Else If (AnalogValue(0)>=minbrake-20 And AnalogValue(0)<minbrake+15) 'Ab"


    Ich werde den Download aktualisieren. Wenn Ihr Euch das Skript der 111 aber bereits für Eure Zwecke konfiguriert habt, dann ist es in jedem Fall leichter, das fehlende Gleich-Zeichen in Eurem Skript zu ersetzen.


    Beste Grüße,
    Sumner

    So, mein kleines (Vor-)Weihnachtsgeschenk ist ab sofort verfügbar. Ich habe jetzt gerade meine Änderungen hochgeladen. Sobald ein Admin die Dateien freischaltet stehen sie hier im Downloadbereich zur Verfügung. Lest bitte unbedingt das Readme, sonst werdet Ihr mit der Nutzung Schwierigkeiten bekommen. Ich hoffe, dass Ihr ebenfalls viel Freude mit den Skripten habt. Für mich jedenfalls ein tolles Ding, die 111 so zu fahren. Solltet Ihr noch Probleme oder Fragen haben, lasst es mich wissen.


    In diesem Sinne,
    Frohe Weihnachten!


    Lg, Sumner

    Hallo erneut!


    Zu guter letzt kann ich heute auch noch einen Erfolg von der BR 111 EL vermelden. Da hat mich das Makroworks-Skript schon ganz schön getreten, aber nach langem Ringen ist es mir nun auch gelungen, der BR 111 den Raildriver aufzuzwingen. Mit meiner Modifikation springt nun der Fahrschalter nicht mehr aus der Stellung "Auf" zurück auf Fahrt und lässt sich damit mit dem Raildriver zuverlässig steuern. Des weiteren habe ich "Notches" für die 111 definiert, so dass der Fahrschalter im Spiel auch immer fix in Stellung bleibt und nur bei kritischen Schwellenwerten bewegt wird. Dabei habe ich die Stellung "Aus" aus dem "Throttle"-Bereich rausgezogen, so dass der Fahrschalter erst auf "Aus" gestellt wird, wenn er zwischen "Throttle" und "Dynamic Brake" liegt. Auf die Art kann ich die Gefahr eines versehentlichen Abschaltens unter Last minimieren.


    Der ganze Erfolg hat aber dennoch zwei kleine, wenngleich wichtige Haken:


    1.) Das Skript muss in der BR 111 "aktiviert" werden:


    Damit ich die Funktion so herstellen kann, wie oben beschrieben, muss der Fahrschalter in der BR 111 EL als allererstes mit der Tastatur (2x "A") in die Stellung "Fahrt" gebracht werden. Anschließend kann dann über den Raildriver der Fahrschalter wieder auf "Aus" gezogen werden. Anschließend Lok normal aufrüsten, und es sollte keine weiteren Probleme währrend der Fahrt geben. Das liegt scheinbar an der Art, wie das Makroworks-Skript mit dem Train Simulator kommuniziert. Makroworks gibt dem TS eine Fahrschalterstellung vor und umgeht dabei den Tastendruck. Meine Modifikation sieht nun vor, dass im Bereich "Auf" die Taste "A" dauerhaft gedrückt wird, bis der Fahrschalter am Raildriver zurückgezogen wird. Wird die Taste "A" im Vorfeld nicht 2x gedrückt, interpretiert der TS die Eingabe als erstmalige Eingabe. In Konsequenz geht der Fahrschalter auf "Ab". Wird in dem Zustand der Fahrschalter am Raildriver von Leerlauf auf Volle Leistung gezogen ergibt sich im TS folgende Bewegung: "Ab-Fahrt-Ab". Deshalb ist die "Aktivierung" des Skripts notwendig, damit dann auch die richtige Reihenfolge "Ab-Fahrt-Auf" geschaltet wird.


    2.) Das Skript muss ggf. von Euch einmalig feinjustiert werden:


    So wie ich das Skript mit meinen geringen Fähigkeiten umschreiben konnte, basieren die "Notches" sehr unsauber auf den Schwellenwerten, die bei der Kalibrierung des Raildrivers festgelegt werden. Da hier wohl mit Unterschieden zu rechnen ist, kann es gut sein, dass die Werte, die ich verwendet habe, auf einem anderen Raildriver nicht richtig ausgelöst werden und damit Probleme verursachen. Die Änderungen im Skript sollten aber von jedem gut zu machen sein.


    Heute werde ich leider nicht mehr dazu kommen, aber ich werde noch dieses Wochenende ein ReadMe verfassen und Euch dann meine Skripts zum ausprobieren überlassen.


    In diesem Sinne,
    Euer Sumner

    Hallo zusammen.


    Mittlerweile habe ich noch ein bißchen weiter mit den Macroworks-Skripts experimentiert. Da ich außer in der Schule und nach Anleitung nie selber etwas programmiert habe, verstehe ich auch nicht zu 100%, welche Änderungen sich wie auswirken. Dennoch konnte ich, wie schon beschrieben, sowohl die BR 143 als auch die BR 156 mit dem Raildriver fahrbar machen. Ich habe in der Zwischenzeit angefangen, eine Anleitung zu schreiben. Die erläuterungen stellen sich aber als so umfangreich dar, so dass ich nun beschlossen habe, lieber meine Skripts zu Verfügung zu stellen. Dann wird die einzige Änderung, die ihr machen müsst, darin bestehen, in dem Skript den Pfad zu Eurer Raildriver.dll anzugeben. Ich werde mich noch vor Weihnachten darum kümmern, dass die Skripts hier im Downloadbereich zu finden sind.


    In der Zwischenzeit habe ich angefangen mit der BR 111 EL zu experimentieren. Bisher habe ich noch kein Ergebnis erzielt. Allerdings habe ich noch ein paar Ideen, wie man den Raildriver bzw. die BR 111 überreden kann, so miteinander zu arbeiten, dass man den "Throttle" tatsächlich gut verwenden kann. Auch hier werde ich Euch auf dem laufenden halten.


    Beste Grüße,
    Sumner

    Hallo @srallinger,


    benutzt Du wie ich mehrere .mw3-Profile für Deinen Raildriver? Dann musst Du den entsprechenden Dateipfad in jede einzelne .mw3-Datei mit einbinden, die Du nutzen möchtest. Ich hatte da anfangs auch meine Probleme, ein einfaches Copy&Paste hat das Problem dann aber bei mir gelöst.
    Vielleicht hast Du Deine .mw3-Dateien vor der Neuinstallation gesichert? Dann verweisen die vielleicht noch auf einen falschen Pfad, weil das Template nur beim erstellen der .mw3-Dateien wirkt (bei mir nicht mal das so richtig). Hoffe, das hilft schon mal weiter.


    Ansonsten kann ich noch großartiges von meinen versuchen mit der vR BR 143 EL berichten. Auslöser war das jüngste Update für Makroworks. Im Vergleich zu dem Raildriver-Interface von Cobra One arbeitet Makroworks etwas besser in dem Sinne, dass es etwas schneller mit dem TS2016 kommuniziert. Ich habe mich also in die Tiefen des Skripts aufgemacht um herauszufinden, ob sich da nicht etwas drehen lässt. Nach ein bißchen experimentieren und einlesen ist es mir nun gelungen das Skript so umzuschreiben, dass ich die vR BR 143 (zumindest die Steamversion) genau so fahren kann wie die anderen Lokomotiven auch. Es bewegen sich die entsprechenden Fahrschalter und Bremshebel exakt wie sie es sollen. Es ist eine relativ einfache Änderung im Skript notwendig, allerdings ist davon auszugehen, dass diese Änderungen mit anderen Lokomotiven nicht kompatibel sind. Es ist also zwingend eine eigene .mw3-Datei für die BR 143 notwendig. Ob die Anpassung bei den anderen Lokomotiven wie der BR 243, BR 156/256 (?) und BR 112 ebenfalls funktioniert, kann ich auch noch nicht sagen, da ich diese Lokomotiven (noch) nicht besitze. Sofern hier jemand ebenfalls Interesse an den Skriptänderungen hat, kann ich hier gerne eine kleine Anleitung zur Verfügung stellen.


    In diesem Sinne,
    Euer Sumner

    Großartige Strecke, für mich die beste deutsche Strecke im TS bisher. Vielen Dank, Jan.


    Zum Thema Fehler: Bin mir nicht ganz sicher, habe es nur kurz gesehen. Aber: Km 28,8 aus Berlin in Richtung Wittenberg: Hektometer-Tafel zeigt 0-0.
    Ansonsten der bereits bekannte Erdrutsch in Berlin.


    Beste Grüße,
    Sumner

    So, sorry für den Doppelpost, ich denke aber, dass die Anleitung so besser zu finden sein wird:


    Wem die Güterzüge von TTB ebenfalls zu laut sind, hier nun eine kurze Anleitung, wie das behoben werden kann. Ihr benötigt dafür ein Programm, mit dem ihr XML-Dateien öffnen und bearbeiten könnt (beispielsweise "Word" oder "Wordpad"), sowie ein Programm, mit dem ihr .AP-Dateien öffnen könnt, wie beipielsweise Winrar.


    Im Kern scheint das Problem der lauten Güterzüge dadurch verursacht zu werden, dass der TS 2016 glaubt, den Ton der Außenansicht auch in der Innenansicht abspielen zu müssen. Die entsprechende Anweisung in der XML wirkt sich aber auf "alle" Innenansichten aus, so dass der gleiche Sound aus der Außenansicht immer abgespielt wird, egal ob Innen- oder Außenansicht aktiv ist. Mit dieser Anleitung könnt ihr dem TS erklären, dass er auf die Sounds die Cab Occlusion anwendet.


    Die zu bearbeitenden Dateien findet ihr unter "Eurem Installationsverzeichnis/.../Railworks/Assets/TrainTeamBerlin".



    Wichtig: Macht unbedingt eine Sicherheitskopie dieses Ordners, falls Euch die Anpassung nicht gefällt oder Fehler verursacht.


    Je nachdem, ob ihr Vol.1, Vol.2 oder beide der Szenariopacks installiert habt, gibt es zwei Ordner, die für die Sounds der Güterwagen relevant sind:


    1.) "TTB_GW_st"
    2.) "TTB_GWagSound"

    Ordner Nr. 1 beinhaltet "TTB_GW_st.ap", die ihr mit Winrar oder ähnlich öffnen müsst. Ordner Nr. 2 ist bei mir entpackt gewesen, also braucht ihr hier kein Winrar. Ihr findet dann einen Ordner "Audio", in dem die Änderungen durchgeführt werden müssen. In diesem Ordner befinden sich viele Dateien und weitere Ordner, wir interessieren uns aber nur für die .proxyxml - Dateien (z.B. TTB_Gwag_Container.proxyxml). Diese öffnet Ihr nun mit dem Textbearbeitungsprogramm Eurer Wahl. Zunächst werdet ihr von viel Text erschlagen sein, mit der "Suchen & Ersetzen"-Funktion mancher Textprogramme ist die ganze Angelegenheit aber schnell erledigt: (Nochmal zur Erinnerung: Sicherheitskopie!) Aktiviert nun die "Suchen&Ersetzen"-Funktion.

    In die Suchzeile kopiert ihr: INSIDE</PlayState>
    In die Ersetzen-Zeile kopiert ihr: BOTH</PlayState>



    Achtet darauf, exakt die hier angegebene Schreibweise anzuwenden, sonst könnten Teile der .proxyxml verändert werden, die nicht geändert werden sollen. Anschließend klickt ihr auf "Alle Ersetzen". Anschließend speichert ihr die Datei, schließt das Programm wieder und bestätigt noch, dass Winrar die Datei im Verzeichnis erneuern soll. Das wiederholt ihr nun für jede .proxyxml in beiden Ordnern #1 und #2.



    Abschließend könnt ihr nun eine Testfahrt unternehmen und Euch an der neuen, viel realistischeren Soundkulisse auf dem Führerstand freuen. In der Außenansicht verändert sich hingegen nichts, bleibt also alles wie gehabt. Gefällt Euch die Änderung nicht, einfach mit der Sicherheitskopie alle gemachten Änderungen überschreiben.



    Mit der gleichen Technik könnt ihr natürlich auch alle anderen Sounds der KI-Züge umschreiben. Allerdings waren die wahrnehmbaren Änderungen eher klein, so dass ihr Euch den Aufwand in meinen Augen sparen könnt.



    Vielen Dank an alle, die mir dabei geholfen haben zu verstehen, wie der TS 2016 mit Sounds umgeht.



    In diesem Sinne allzeit gute Fahrt!
    Euer Sumner




    Danke schonmal für Eure Antworten. Es bringt mich einer Lösung vielleicht etwas näher. So wie ich das sehe, ist Maiks Erklärung möglicherweise der Schlüssel zur Lösung des Problems. So naiv wie ich bin werde ich jetzt einfach mal versuchen, anstelle "Inside" in den Sound-Blueprints "Both" einsetzen. Ich werde in Kürze berichten, ob und in wie weit dass eine Lösung sein kann. Alternativ bleibt vielleicht auch mit Hilfe der Informationen von Christrains (danke hierfür) die Möglichkeit, die Gesamtlautstärke ein wenig herab zu setzen. Allerdings hoffe ich, dass bereits eine Änderung auf "Both" das plötzliche Scheppern in ein etwas realistischeres Ergebnis verändert.



    @Prelli: Du weißt nicht zufällig, wie die User das gemacht haben? Ggf. kann mir auch einer von denen weiter helfen? Bereits erledigt, Siehe Edit 2. Danke nochmals!


    Edit 2:


    Mittlerweile habe ich mir mal in den entsprechenden soundproxy.xml der Güterwagen alle Eintragungen wie oben geschildert angepasst. Um es kurz zu machen: Das Ergebnis ist vielversprechend, genau so wie ich es mir vorgestellt habe. Anstatt der plötzlichen lauten Fahr- und Stoßgeräusche hört man nun auf dem Führerstand lediglich ein dumpfes Grollen. Je nach Entfernung zwar durchaus immer noch relativ laut, aber weit entfernt von dem, was mich ursprünglich die Frage hat stellen lassen. Ich werde jetzt erstmal noch ein paar weitere Szenarien fahren, um sicher zu gehen, dass das auch wirklich bei beiden Szenariopacks funktioniert und meine Anpassungen ggf. auch auf die Personenzüge ausweiten. Diese klingen zwar nicht ganz so verkehrt, aber bestimmte Geräusche sollten auch bei denen eigentlich nur gedämpft zu hören sein. Ich werde dann nochmal entsprechend berichten.


    Wenn Interesse besteht, schreibe ich hier auch gerne eine kurze Anleitung für die Interessierten. Ist eine relativ schnell gemachte Änderung in den Dateien, die aber die Immersion deutlich verbessern. Dann sind die Szenariopacks vielleicht doch noch was für Dich @Prelli.


    Beste Grüße,
    Sumner

    Hallo zusammen,


    nachdem sowohl Google als auch die foreninterne Suche mir nicht weitergeholfen hat, folgende Frage:


    Vor kurzem habe ich mir die beiden hervorragenden Szenario Packs von TTB für Berlin-Wittenberg und München-Augsburg geholt, unter anderem um die tollen Szenarios der Community hier fahren zu können. Beide Packs finde ich richtig gut, insbesondere in München ohne Ruckeln, dass macht richtig Freude. Die Sounds finde ich auch gut, allerdings ist in meinen Augen die Lautstärke der Güterwagen viel zu hoch. Der ist zwar passend, wenn man neben dem Gleis stehen würde (also z.B. Aussenansicht), allerdings habe ich das gleiche Niveau an Lautstärke, wenn ich im Führerstand bei 200 fahre. Dass führt unter anderem dazu, dass ich in diesen Momenten quasi nichts mehr von meinem eigenen Zug bzw. meiner eigenen Lok höre, inklusive SiFa, PZB und LZB. Kennt einer von Euch vielleicht eine Möglichkeit, die Lautstärke der Sounds zu reduzieren (z.B. um ca. 50%)? So habe ich mich auch gewundert, dass ich bei den Güterzug-Szenarien hinter mir den Güterzug deutlich habe Rumpeln und Scheppern gehört habe. Wenn ich auf einer recht lauten ELok mit aktiven Lüftern fahre, würde ich auch da erwarten, dass von den Güterwagen kaum etwas zu hören ist. Für mich wäre daher etwas weniger deutlich mehr.


    Vielen Dank schonmal für Eure Antworten.


    In diesem Sinne,
    Euer Sumner

    @holzroller


    First of all thank you for your post regarding the Raildriver Interface. At the moment I'm still experimenting with the vR BR 143 Expet Line, so far with mixed results. Still I am somewhat optimistic to solve the problems I've encountered so far. Especially those new features Cobra One is currently working on are exactly what I was looking for (without knowing until recently). I'm looking forward to drive the vR BR 111 EL in a more realistic manner. So thank you for the information.


    Edit: I've just read through your post again, realizing the problems I encountered probably will solve themselves with the new upcoming version of the rD Interface. Closer reading sometimes helps :).


    Best wishes
    Sumner

    Da hier nun öfter von ökonomisch sinnvoll oder nicht gesprochen wurde, möchte ich als abgeschlossener Ökonom mal ein wenig Licht ins dunkel bringen. Ich bewerte hierbei explizit nicht, ob der Preis angemssen ist, sondern erläutere nur ein paar Grundkonzepte der BWL und VWL:


    1. Ob der Preis angemessen ist, entscheidet der Kunde:


    Hier im Forum wurde viel über die sogenannte "Zahlungsbereitschaft" diskutiert. Dem einen sind die 40 Euro einfach zu teuer, dem anderen nicht. Das ist aber unterm Strich eine subjektive Einschätzung. Die zentrale Frage, die sich jeder hier stellen darf: Stiftet es mir einen entsprechenden oder sogar höheren Nutzen. Sehr technisch ausgedrückt bedeutet das nichts anderes als "Ist mir der Railjet 40 € wert." Für mich war es über lange Zeit sehr interessant hier zu beobachten, wie versucht wurde, die eigene Zahlungsbereitschaft als angemessen bzw. "richtigen" Preis zu verteidigen. Interessant ist hier folgendes: Es gibt diesen einen richtigen Preis eigentlich nicht. In einem funktionierenden Markt (dass ist eine sehr sehr starke Annahme, die in der Realität nie zutrifft), passt sich der Preis dann mit der Nachfrage meist auf ein Gleichgewichtsniveau an.


    2. Es müssen Entwicklungskosten, Folgekosten etc. mit berücksichtigt werden:


    Wie es zur Preisgestaltung in diesem konkreten Fall kommt, weiß ich nicht. Aber, rein ökonomisch betrachtet, sollte sich langfristig ein Preis einstellen, der gerade den sogenannten "Grenzkosten" entspricht. Damit ist gemeint, dass der Preis gerade so eine Höhe annimmt, dass die laufend anfallenden Kosten der letzten produzierten bzw. verkauften Einheit. Bei Gütern wie Autos, aber auch bei Steaks fallen mit jeder verkauften Einheit Kosten in gewisser Höhe an, die auch davon abhängen, wie viel produziert und verkauft wird. Das Konzept der Grenzkosten erlaubt hierbei einfach den Punkt festzustellen, ab dem eine zusätzliche Einheit mehr kostet, als durch sie eingenommen wird.


    Hier gibt es aber einen entscheidenden Unterschied zwischen Autos und Software: Software kann, anders als Autos, heutzutage unbegrenzt mit fast keinen Kosten repliziert werden (Grenzkosten nahe 0). Mit anderen Worten: Im Gleichgewicht sollte Software langfristig immer (!) nahezu kostenlos sein (im übrigen das gleiche auch bei Filmen und Musik).


    Ein entscheidender Punkt wird hier tatsächlich komplett übersehen, nämlich "versenkte Kosten". Für die Entscheidung, welchen Preis ein Produkt haben sollte, sind Kosten, die bereits angefallen sind, nicht mehr zu berücksichtigen: Die Entwicklung war mit Sicherheit zeitaufwendig und damit so oder so auch kostspielig. Nun ist das Produkt fertig, und kann, wie oben bereits ausgeführt, beliebig oft verkauft werden, mit relativ geringen marginalen Kosten.


    Vernünftig wäre es aus Sicht des Entwicklers und des Publishers daher, sogenannte Preisdiskriminierung zu betreiben: Angefangen mit einem hohen Preis (hier ca. 40€) und den über die Zeit hinweg langsam abzusenken. Das sorgt dafür, dass die Einnahmen tatsächlich maximiert werden. Derjenige, der ungeduldig ist und unbedingt den Railjet vom ersten Tag an fahren möchte, der schlägt auch gleich zu. Andere, denen der Preis zu teuer ist, die warten halt ab, bis der Preis gesenkt wird.


    Es bleibt damit fest zu halten, dass der einzige Fehler wäre, den Preis langfristig auf dem gleichen Niveau zu belassen. Und soweit ich das hier schon gelesen habe, soll der Preis auch zu gegebener Zeit gesenkt werden. Also macht es RWA und JT damit nicht ganz verkehrt.



    Zum eigentlichen Thema: Ich freue mich auf den Railjet, aber meine Zahlungsbereitschaft beträgt nicht 40 €. Daher werde ich auch ein wenig abwarten, wie sich der Preis entwickeln wird, bevor ich hier zuschlagen werde.


    In diesem Sinne,
    MrSumner

    So, Du findest hier im Anhang mal zwei Dateien:


    Einmal meine .mw3-Datei mit Tastenbelegung, Kalibrierung, etc. Einfach die Endung .txt entfernen, dann sollte das direkt gehen. Wichtig ist jedoch, dass ich Steam und damit den TS2016 in einem anderen Verzeichnis installiert habe. Den Pfad müsstest Du dann entsprechend der Anleitung von der Raildriver-Website auf Deine Bedürfnisse anpassen.
    Übrigens ist mir das noch als Gedanke gekommen: Ic h für meinen Teil verwende mehrere mw3.Skripts, je nach Land und Lok. Die musste ich alle per Hand auf mein Installationsverzeichnis anpassen. Eventuell handhabst Du das ähnlich. Vielleicht hast Du dabei einfach vergessen, dem betreffenden Talent-Skript auf Dein Installationsverzeichnis anzupassen?


    Zum zweiten die Datei mit der Ordnerstruktur. (Hoffe, dass ist das was Du meintest ;) ). Meine tatsächlich verwendeten Skripte liegen dann aber noch in einem anderen Ordner auf C, das dürfte bei Dir auch so sein.


    Hoffe, das hilft Dir weiter.
    Lg, Sumner

    hrieger:
    Nach ein wenig ausprobieren ein ganz großes Lob! Funktioniert hervorragend, genau so wie ich es mir von Anfang an gewünscht habe. Verstärkt gleich nochmal die Immersion in deutschen Zügen.


    @srallinger:
    In meinem Testlauf habe ich mir auch kurz die Hamsterbacke vorgenommen. In dem Szenario konnte ich den Talent anstandslos fahren und steuern. Das lief alles über den "Throttle", also den Kombihebel. Durch die Änderungen im Skript mit Beschleunigen nach vorne etc.
    Also liegt es zumindest nicht in erster Linie am Raildriver oder Makroworks. Zwei Möglichkeiten halte ich für denkbar:
    1. Vlt. noch angezogene Zug/Lokbremse? Ich habe bemerkt, dass der Hebel für die Lokbremse im Talent die Zugbremse steuert.
    2. Eventuell noch alter Treiber? Ich habe den Raildriver erst seit Anfang Oktober, eventuell hängt es also am Treiber.


    Ansonsten kann ich Dir anbieten, meine .mw3 Datei zur Verfügung zu stellen. Eventuell kannst Du den Zug ja damit in Bewegung setzen ;)


    Beste Grüße,
    Sumner

    @hrieger:


    Vielen Dank dafür. Die Umwandlung werde ich heute mal ausprobieren und dann berichten.


    Bei der Gelegenheit habe ich noch eine Frage betreffend Raildriver und der Expert Line von vR:


    Bisher habe ich die Erfahrung gemacht, dass die meisten Lokomotiven von Virtual Railroads sich ganz gut mit dem Raildriver fahren lassen, allerdings nicht die BR143 EL. Ich schätze, dass liegt daran, dass hier die Lokomotive aufwendig die Geschwindigkeit regelt und damit nicht mit dem Raildriver kompatibel ist.


    ich frage mich jetzt, ob ihr ähnliche Beobachtungen auch mit den anderen Ex-DDR-Lokomotiven gemacht habt (BR 243, BR 156, BR 112), oder ob eine der genannten Lokomotiven besser mit dem Raildriver zusammenarbeitet als es die alte 143 macht? Habt Ihr da schon Erfahrungen gemacht?


    Vielen Dank und beste Grüße,
    Sumner