Beiträge von nobsi

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

    [...] möchte ich mal den Führerstand des vR Karlsruher Kopf mit der Re 420 Lion wechseln.

    wenn jemand einen solchen Wunsch äußert, frage ich mich immer: was will er wirklich? Will er tatsächlich "nur" einen Führerstand tauschen, oder meint er - bewusst oder unbewusst - mit dem Führerstand Funktionen einer Lok in eine andre verpflanzen zu können?

    Mich würde auch schwer interessieren, wie das geht -

    Eine allgemeine Bauanleitung dafür gibts nicht, weil jede Lok anders ist. Der TS braucht nur einen Engine-Blueprint für den Einstieg, wie die Lok dadrunter aufgeteilt ist, macht jeder Autor mit seiner Lok so, wie er es für sinnvoll hält.


    Wichtig ist erstmal, zu klären, was ist was.
    Der Führerstand ist ein 3D-Modell, mit einigen Bedienelementen, die selbst 3D-Unterobjekte sind, die Namen haben, und evtl. eigene Animationsdateien.
    Die Lok hat Funktionen, die über Namen angesprochen werden (Stichwort: "Controller"). Da hängen auch noch als "Übersetzer" die Lua-Scripts mit drin.


    Will man versuchen, einen Führerstand durch einen anderen zu ersetzen, muss man also erst mal beide Führerstände im Detail untersuchen, und überlegen, wie man die unterschiedlich benannten Bedienelemente zuordnen will. Wenn man Glück hat, kann man die wichtigsten Bedienelemente durch Umbenennung in den Blueprints wieder verbinden. Wenn man Pech hat, liegt die Blackbox eines compilierten Lua-Scripts dazwischen.
    Zur Einarbeitung in das Thema gehört also auf jeden Fall:
    - im Blueprint Editor die verschiedenen Blueprints daraufhin untersuchen, wie sie verbunden sind
    - Lok-Scripts untersuchen, wie Eingaben verarbeitet werden
    Am besten beginnt man dabei mit den alten Kuju-Loks - da sind die Lua-Scripts offen lesbar.


    --------
    Ergänzung 2016-10-17:
    wenn es nur darum geht, die Position der "Kopf-aus-dem-Fenster" Kamera zu verschieben, ist die Lösung einfach: das passende "HeadOutCameraBlueprint" suchen (z.B. bei der Beekay BR44 ist es (RailWorks)\Assets\RomanticRR\BR44_Pack\BR44\CabView\BR44_HeadOutCam.bin) und die deutlich erkennbaren x/y/z Koordinaten nach Wunsch ändern.


    Bei der Suche nach dem passenden Blueprint hilft RWTools: damit kann man eine Asset-Liste für den Ordner der interessierenden Lok erstellen, darin kann man die verschiedenen Komponenten erkennen.

    "spezifische Szenarien" müssen möglich sein. Denn das sind ja gerade die spannenden Szenarien: Szenarien, in denen "unvorhersehbares" geschieht, das zu Verzögerungen, Umleitungen usw - also Abweichungen vom Fahrplan - führt. Die 80 oder mehr % der Szenarien, die nur ein Klon von "Sie übernehmen den RE... von A nach B und halten an jedem Bahnhof" sind, müllen (mir) nur die Platte zu. Sowas geht mit Quickdrive einfacher und abwechslungsreicher.


    Aber im Grunde existieren die technischen Möglichkeiten bereits im TS und sind nur nicht in der von euch ( @Tebe, @Euro Voyager ) gewünschten Weise kombinierbar:
    Fahrplan gibts in TS-Szenarien sowieso, da könnte man auch den ganzen Tag eintragen. Da fehlt nur, dass der Spieler den Abfahrtszeitpunkt wie im QD selbst wählen kann (und natürlich Szenario-Autoren, die bereit wären, soviel Fahrplan einzutragen ;) )
    Beim QD ist's umgekehrt, da kann man zwar alles möglich einstellen, aber die KI ist fest auf den Spieler bezogen. Ein Spieler-unabhängiger Fahrplan würde das viel abwechslungsreicher machen.
    Allerdings - mal kurz rechnen:
    in einem QD-Szenario hab ich z.B. 40 KI-Züge, die auf den Spieler fixiert sind. Wenn ich mal Halbstunden-Takt annehme, müsste ich für einen ganzen Tag ca. 2000 Züge konfigurieren (und hab noch keinen abweichenden Sonntagsfahrplan). Das 3CCR-QD besteht aus 15 QD-Szenarien ... macht insgesamt 30000 Züge - nee, das wäre nie erschienen.


    Es würde aber auch anders gehen, wenn man auf exakte Fahrplanzeiten verzichtet:
    es würde reichen, in den im QD ohnehin existierenden Spawn-Filtern nicht nur Zugtyp und Länge, sondern auch Tages- und Jahreszeit einschränken zu können. Damit könnte man erreichen, dass nachts weniger Verkehr als am Tag ist, oder nachts vorwiegend Güterzüge fahren, man könnte auch mal Schneefräsen einsetzen usw.
    Eine solche Erweiterung müsste selbst für den aktuellen TS problemlos umzusetzen sein, erst recht für TSW.


    Eine praktikable Fahrplanunterstützung könnte ich mir so vorstellen:
    man könnte je Strecke mehrere Basis-Fahrpläne hinterlegen, aus denen man für ein Szenario einen auswählen kann, so ähnlich wie man aktuell im TS bei der Erstellung eines Szenarios aus den Strecke oder Szenario beiliegenden Wetter-Schablonen auswählen kann. Für den TS wäre das mit dem aktuellen Dispatcher wohl kaum machbar, das sollte für den TSW aber kein Hindernis sein.

    Zitat

    Ich versteh nur nicht, was der ganze Spaß soll.

    Es geht um die hobby-mäßige Beschäftigung mit dem TS. Das heißt im Idealfall, dass Leute, die etwas machen, anderen zeigen, was man im TS machen kann, und erzählen, was es für Probleme gibt und wie man die lösen oder umgehen kann. Es geht nicht darum, mit maximaler Effizienz den höchstmöglichen Output an kostenlosen Downloads für all die Abzocker da draußen zu generieren.


    Zitat

    Dass wird hier zu nichts führen...

    Ich hoffe, es führt dazu, dass mehr Leute anfangen, sich aktiv mit dem TS zu beschäftigen.

    @Tebe
    jetzt komm ich nicht mehr mit. Ein Fahrplan ist doch geradezu der Prototyp eines Szenarios, sozusagen die Mutter aller Szenarien.
    @Euro Voyager hat auch irgendwie was gegen Szenario gesagt, aber weiter oben selbst einen Fahrplanmodus als Wunsch genannt. Aber ein bestimmter Fahrplan ist doch das Szenario überhaupt. Natürlich kann weder der TS noch der TSW den gesamten Fahrplan der Welt von 1830 bis heute kennen, muss sich also immer auf einen Ausschnitt beschränken.

    @bkl11 Der Hauptteil bleibt aber ja doch ein szenariobasiertes Spiel.

    na logisch ... die Mehrheit (damit meine ich nicht sowas wie 50,1% sondern eher was > 95%) braucht das. Und ein Payware-Hersteller wird nicht absichtlich die Mehrheit seiner User in den Allerwertesten treten.

    Was man im Video sieht, sind Blueprints in der UE4. So sieht jedes UE4 Spiel "unter der Haube" aus. Also nichts neues... ;)

    na logisch ... ich hab noch nie verstanden, was die Leute, die wünschen, der TSW möge statt Blueprints Editor-Presets verwenden, eigentlich tatsächlich wollen. Blueprints sind doch nicht weiter als gespeicherte Presets *denk* .

    hallo @manuellvb2016 versuche, den Bahnhof aus verschiedenen anderen Gebäuden zusammenzusetzen.
    Die Chancen, dass jemand viele Stunden Arbeit investiert um dir für ein Privatprojekt einen "realistischen" Bahnhof Nachbau zu liefern sind sehr gering. Die Frage danach ist natürlich trotzdem erlaubt :)


    Ein "Privatprojekt" wird dein Projekt sehr wahrscheinlich bleiben, weil es sehr unwahrscheinlich ist, dass du vom Autor der Originalstrecke die Erlaubnis zur Veröffentlichung bekommst (eine solche Erweiterung enthält im TS zwangsläufig die ganze Originalstrecke)

    Sag mal kannst du die Beiträge nicht lesen oder was?

    und was ist Dir? Kannst du nicht lesen, in welchem Bereich du dich befindest? Kannst du die Regeln für diesen Bereich nicht lesen?


    das gilt auch für einige andere hier! Hier scheinen einige User blind auf "neuer beitrag" zu reagieren. Erst lesen, dann schreiben!


    Ich habe einige vollkommen unkonstruktive Beiträge entfernt. Ein paar "grenzwertige" Beiträge habe ich belassen, weil sie zumindest den einen oder anderen wichtigen Hinweis enthielten.

    Railarts hat die entsprechende Lizenz. Die Assets im eigenen Paket unterzubringen ist durchaus im Sinne der mit dem TS2013 von DTG eingeführten Paket-Struktur (*.ap) - damit eben keine Strecke einer anderen irgendwas vermurkst. Ein paar Megabyte Plattenplatz für die vermeintlichen Duplikate sind heutzutage eigentlich kein Thema mehr - endlose Support-Diskussionen hingegen schon.


    Es blickt nur dann keiner mehr durch, wenn verschiedene Strecken dieselben Assets verwenden. Das wäre nur dann sauber, wenn diese selben Assets nur als Requirement angeführt würden. Aber dann gäbe es wieder (berechtigten) Sturm im Wasserglas von den Usern die sich verschaukelt fühlen, weil sie eine Strecke kaufen, und dann noch weitere Assets kaufen sollen, damit die Strecke funktioniert.

    ...nochmal wegen dem Wetter: präziser ausgedrückt meinte ich eine Wetterdarstellungen entsprechend der gerade vor Ort herrschenden Bedingungen,

    als zusätzliche Option im Quickdrive könnt ich mir das gut vorstellen. Sonst eher nicht. Ich wäre jedenfalls arg frustriert, wenn ich in Amerika nur vormittags und in Europa nur nachts fahren könnte (eben nach realem Job), und im realen Winter auch im TS immer nur trübes(?) Winterwetter hätte.



    ...das ist ja die Idee: eben nicht immer das gleiche Wetter zu haben.

    geht heut im TS eh schon (im QD)

    Suche Strecke Magdeburg-Frankfurt/Oder,

    hab mir das grad mal auf GE (Google Earth) angeguckt. Das sieht eher nach 3 bis 4 Strecken aus als nach einer ;) Will ja glaub ich niemand 100 € für eine Strecke bezahlen. Oder ein Freizeit/Freeware-Bauer traut sich ... wird dann vermutlich in 5-10 Jahren fertig :)