Es gibt auch keine andere brauchbare Engine, die das kann. Die UE ist mit Abstand die beste für den Zweck. Natürlich abseits der Programmierung einer speziellen Engine, was heutzutage aber eben nicht mehr finanzierbar ist.
Beiträge von Maik Goltz
-
-
Aber warum holt man sich dann nicht mal einen Fachmann an Bord?
Weil die Preise dafür in keinem Verhältnis stehen würden, vermute ich mal ganz gewagt. Zumal EIN Fachmann nicht reichen wird bei der Komplexität dieser speziellen Materie. Man braucht mindestens 2 oder gar 3 Leute die sich auf unterschiedlichen Ebenen damit auskennen. Soll heißen, man braucht einen Experten für Aufnahmen, einen für Implementation und einen der überhaupt erst mal den Grundstock in der Game-Engine dafür legt, also einen Programmierer mit Audio-Erfahrungen. Viel Spaß bei der Suche und wenn was gefunden wurde, dann beim bezahlen. Lohnt in keinem Ausmaß für so ein Spiel. Gilt auch irgendwie für den TS/TSW, wobei der TS hier einen Vorteil verbucht. Nämlich, dass die spezifisch angepasste Audio-Engine schon da ist.
Nur mal ein Beispiel woran die Dinge oft scheitern können. Ich habe mich für den TSW 420 mit der Möglichkeit der Granular-Synthese In-Game (also realtime usage) beschäftigt. Ich kenne mich mit Granular-Synthese recht gut aus und weiß, was theoretisch damit im Bezug auf Sound für Züge möglich wäre. Ich besitze unzählige verschiedene und teure Software und hatte auch sündhaft teure Hardware (jetzt nicht mehr, lohnt nicht für TS). Alles schön und gut. Aber in der UE ist die Granular-Engine (das Synth-Plugin für die Audio-Mixer Engine) unbrauchbare und hat überhaupt kein UI. Es fehlen Möglichkeiten der Anpassung der Parameter oder sie sind stark beschnitten. So zum Beispiel ist die Grain-Anzahl stark begrenzt, die die Grain-Länge auch. Außerdem kann man nur vorgefertigte Fading-Curves verwenden und keine eigenen einbringen wie z.B. das wichtige variable Trapezoid. Um das in das Plugin zu integrieren und eine nutzbare (aus kommerzieller Effizienz-Sicht) UI zu erstellen, braucht es einen Core-Engineer für die UE der auch Audio Core programmieren kann. Davon gibt es auf der Welt eine Hand voll. Da kostet die halbe Stunde dann zig Tausend €. Und das ist viel Arbeit die da gemacht werden müsste. Da kommst schnell auf 100k. Sowas steht in keinem Verhältnis. Ist auch ein Grund warum TSW nicht einfach FMOD benutzt. Ist einfach viel zu teuer, leider. Würde wirklich hervorragend bessere Ergebnisse erzeugen, aber das Lizenzmodell für FMOD ist absurd. -
und vielleicht sogar Content dafür erstellen. Die meisten Menschen empfinden das als sehr seltsames Hobby.
Oh ja. Nicht nur als seltsames und nutzloses Hobby, sondern auch als absolut unbrauchbaren Hauptberuf. Selbst Steine schleppen steht höher im Kurs. Man redet am besten nicht drüber. Wenn wer fragt, womit man sein Geld verdient, sagt man eben einfach Bauarbeiter
Dann kann man direkt zum wesentlichen übergehen. -
Das mit dem gespeicherten Spielstand, haut in der Regel mit vR-Loks nicht hin.
Stimmt so aber auch nicht. Ab Script Version V3 (BR101) sind alle vollständig Save-Game tauglich (bis zu dem Moment wo ich das nicht mehr gemacht habe, danach weis ich nicht).
-
Ich kann da sowieso nichts dran ändern, weder bei vR noch bei DTG. Und für mich brauche ich keine möglichen Fixes. Also investiere ich da auch keine weitere Zeit in die Analyse. Ich benutze das Zeug schon lange nicht mehr.
-
Die nutzen die Eingabe bei der AFB eben simpler. Bei den neueren vR Loks ist es etwas komplizierter, um den GamePad Usern zu ermöglichen, die AFB Geschwindigkeit direkt einzustellen. Und genau das macht jetzt offensichtlich Probleme. Das System AFB aber funktioniert normal. Die GamePad Eingabe ist das Problem. Die Setzt den Wert der von AFB VSOll Steller gesetzt wird direkt wieder zurück. Deswegen bewegt sich der Hebel nicht. Und somit bleibt die AFB VSoll wo sie ist, auf 0. Mit RailDriver Input funktioniert die AFB normal, da dort diese Funktionalität übergangen wird. DAs Problem aus code Sicht liegt wohl in dem was wir schon mal hatten, dass aus einer Eingabe von 0, eine 0.00000061 wird und somit ein Vergleich mit 0 gleich false ergibt. Das darf so nicht passieren. Das ist ein Core Code Fehler. Der muss raus, dann funktioniert alles wie gehabt. An der AFB muss dazu nichts verändert werden.
Klar, aus Kundensicht ist es die vR AFB die nicht funktioniert. Punkt. Aber beim DTG ICE3 Velaro D und dem IC2 ist die selbe Funktionalität verbaut. Die gehen also auch nicht mehr. Das sind DTG Produkte und hätten getestet werden müssen, wurden se aber wohl nicht. Hätte man das getestet und berücksichtigt, gäbe es kein Problem, nicht bei vR, DTG oder anderen Anbietern, die solche präzisen Vergleiche nutzen.
-
Ich sags auch gern für Ice nochmal, es hat nichts mit der AFB zu tun. Die AFB ist nur das System das von dem Fehler seitwärts getroffen wird. Das Problem liegt auf Ebene der Eingabe und Eventauslösung im Core. Das kann nur DTG lösen. Und das hätten Sie auch vorher testen müssen, denn es gibt diverse Fahrzeuge auf dem Markt, die solche Dinge nutzen, die da jetzt kaputt sind.
-
-zuerst habe ich die bestehende RailWorks64.exe in einen Backup-Ordner verschoben
-dann das Update gezogen
-und dann nachdem ich gesehen habe dass die RailWorks64.exe im aktualisierten RailWorks-Ordner fehlt die Backup-64bit-exe wieder zurück verschoben.
Das bringt auch nichts. Die .exe Datei beim TS war schon immer nur ein Wrapper/PluginLoader. Der eigentliche TS steckt in der GameManager.dll
-
Ich wollte auch nicht den Nutzer zur Verantwortung ziehen. Nur klarstellen, dass es auch an DTG liegen kann und nicht nur an Drittanbietern, die "anders" oder "falsch" ihren Content erstellen. Bei so einem Update ist DTG in der Pflicht, auch diese Dinge zu testen. Es ist ja kein verbotener Content und ja eben sogar offizieller Drittanbieter-Content der über Steam von DTG verkauft wird. Das war meine Intention. Nicht die User dafür zu verantworten.
-
Wie hier einige schreiben funktioniert bei einen Ersteller die AFB nicht und von anderen Erstellern geht sie komischerweise. Also wird es da eventuell die Möglichkeit von Programmierunterschiede im Skript geben.
Um es ganz klar zu sagen, es hat nicht mal was mit AFB zu tun. Die AFB funktioniert per se einwandfrei, auch nach dem Update. Das Problem liegt im Handling von Control-Eingaben. Die haben mit dem Script nichts weiter zu tun, außer dass man die Ergebnisse dort auswertet und dann anwendet. Da ist was im Core faul. Offenbar das gleiche Problem, wie damals bei dem Sprung auf 64 Bit. Da gab es nämlich genau den selben Fehler. Liegt also definitiv auf Seiten DTGs.
-
Ihre eigenen Programm Verbiegungen (zB. Skripte) gemacht haben die jetzt Schwierigkeiten machen. Da ist DTG aussen vor, woher soll der Programmier daß wissen?
Da würde ich dann schon gegen halten wollen. Zumindest bei den Produkten, an denen DTG fleißig mitverdient. Das muss auch getestet werden seitens DTG bei so einem Core Update. Und per Script kann man eigentlich nichts am Programm verbiegen. Zumindest bei den vR und TSG Produkten wurde nichts gemacht, was nicht auch DTG macht. Bei anderen kann das schon sein, da dort teilweise nicht zu verwendende LUA Calls drin sind und teils sogar externe DLLs reingeladen werden (wenn das überhaupt noch geht). Das ist dann natürlich was Anderes. Da kann DTG wegschauen, da diese Dinge nicht "normal" sind.
-
Das wirst du sicherlich an DTG weitergeben?
Warum sollte ich. Mir wurde mal gesagt, dass das nicht meine Produkte sind
-
Also ich hab noch immer den vollgemüllten TS den ich seit 10 Jahren benutze. Da ist viel unterschiedliches drin, von massig PayWare, über diverse Freeware und auch Mods und viel Testgelumpe, das nie die Welt erblickt hat. Läuft nach dem Update alles wie immer. Hab ein paar Dinge angetestet. Alles kein Problem. Die AFB in der 101 (und wahrscheinlich nachfolgenden, ähnlichen Loks) geht tatsächlich nicht mehr, was daran liegt, dass der VSoll-Steller aus irgendwelchem Grund blockiert. Erschließt sich mir nicht direkt was da abgeht. Ändern kann ich es eh nicht. Der Rest geht aber tadellos.
Alle, bei denen der TS abschmiert, müssen etwas haben, dass dafür verantwortlich ist. Eventuell aber auch ein System-Problem, das nichts mit dem vorhandenen Content zu tun hat. Da müssen Daten gesammelt werden und Gemeinsamkeiten gefunden werden. Am normalen Content oder am TS liegt das nicht.
-
Maik lass es doch sein, Du weisst schon was ich meine.
Nee, eben nicht, sonst würde ich ja nicht fragen. Wenn du das normale Antriebsgeräusch eines Triebzuges mit Asynchronmotoren meinst, dann sag das. Das hat aber wenig mit U-Bahn zu tun. Es gibt U-Bahnen die klingen so und U-Bahnen die klingen anders. Je nachdem wie der Antrieb funktioniert. Und das gilt halt für alle Schienenfahrzeuge. Von der Straßenbahn, über U-Bahn und S-Bahn hin zur großen Eiseenbahn und so gar noch weit darüber hinaus. So können Busse, LKWs, ja sogar Fahrstühle, Krane, Klimaanlagen so klingen. Hat alles nur was mit der verwendeten Antriebstechnik zu tun, nicht mit dem was es ist. Sorry, ist kleinlich, aber mich störte das schon immer, wenn du das so sagst und damit meist auch schlechte Qualität (aus deiner Sicht) anprangerst.
Zum Zug selbst, er klingt halt wie dein Stadler so klingt. Kräftig, laut, sinnvoll. Genau entsprechend dem Antriebsystem, verteilt über alle Wagen, unterflur in sehr kompakter Bauweise. Fast wie ein ICE3 oder 4. Wobei auch der 4er da sehr negativ rausschaut mit seinem brachial lautem Betriebsgeräusch. Da stehen sich die beiden recht nah. Besser als wenn man gar nüscht hört, finde ich. -
in der Beschleunigung hört es sich wie eine U-Bahn an
Das ist der von dir immer wieder mal gebrachte Spruch. Erklär doch bitte mal, wie ein U-Bahn nun genau klingt. Mal davon ab, dass es hunderte von verschiedenen U-Bahn Fahrzeugen gibt und die klingen alle sehr unterschiedlich. Was du wohl wirklich meinst, ist ein rein technisch begründetes Geräuschentwicklungsunterfangen, das dann aber eben nun mal so richtig ist wie es ist, auch in größeren Schienenfahrzeugen. Hat mit der Aufhängung der Motoren zu tun.
Ist die Wahrnemung von Geräuschen zwischen Menschen wirklich so unterschiedlich?
Oh ja, rein technisch bedingt schon. Ist erstaunlich wie unterschiedlich der menschliche Hörapparat töne der Umwelt wahrnimmt und wie das Hirn daraus unterschiedliche Ergebnisse zaubert.
-
Ich kenne jetzt die Lok nicht aus dem realen - ist die "Stufenschaltung" denn wirklich so genau, das der nicht rüber geht? Ich weiß es jetzt nicht. Am Anfang kann man ja erstmal bspw bei 40 Ausfahrt auf 30 hoch fahren lassen und stellt dann einfach auf 40, wenn die 30 erreicht sind? Wie machen das denn 143 Lokführer?
Dachte ich damals auch, als ich die erste 143 gemacht hatte. Aber die Lok nutzt bei der Geschwindigkeitsregelung ja die Anschnitt-Steuerung voll aus und ist relativ präzise dabei (nicht so wie heutige Maschinen). Heist quasi stufenlos. Die angezeigte Fahrstufe ist dann nur ein Näherungswert zur nächsten Vollstufe. Nur bei Hilfssteuerung werden Vollstufen benutzt. So ist es auch in der 112 umgesetzt, was den Aufwand erheblich steigerte.
-
Da sollte man sich bei vR nochmal mit dem Skript der 112 auseinander setzen, die all das deutlich besser gemacht hat.
Die 112 ist die komplexeste Lok, die ich bei vR jemals gemacht habe (vielleicht erinnern sich noch einige an das Drama damals
). Da steigt außer mir keiner durch. Kann man auch nicht verlangen. Dafür funktioniert sie halt sehr gut. Mit einer reinen Kopie wäre es auch nicht getan, da die 143 doch erheblich anders ist. Man müsste also viele Änderungen vornehmen und dazu muss man da durchsteigen. -
Herr Goltz weiss auch nicht mehr, aber alles zollt Beifall.
Das scheint dir ja ein besonderer Dorn im Auge zu sein. Mich interessiert der Beifall nicht die Bohne. Ich sage nur was ich denke.
Bitte alle "Beifaller" den Beifall künftig an Herrn B. spenden. Ich will den nicht und bauch den auch nicht. -
Wieso befürchten (oder hoffen) so viele, dass sich derbe was ändern wird? Warum sollte sich was ändern? Der Investor/Shareholder hat gewechselt, sonst nichts. Ist dann eben jetzt kein reicher Brite mehr, sondern ein großer Spielepublisher. Da wird sich gar nichts ändern, schon gar nicht für die Kunden. Das Video da oben ist genau das, was heute normal ist. Irgendwer denkt irgendwas zu wissen, trägt es pompös in die Welt, alle glauben dran, Shit happens.
-
Ja darum versteh ich immer nicht warum die Grafik für alle schlechter gemacht wird anstatt mehr Grafikoptionen anzubieten.
Weil der Aufwand zu groß ist und in keinem Verhältnis zum Nutzen steht für den Entwickler. Man kann nicht mal eben alles in ein Menü stopfen. Viele Sachen lassen sich gar nicht at-runtime verändern, also auch nicht per Menü. Geht auch bei der UE4 nicht alles. Finde es schon ab und zu amüsant, was für Placebos da so kursieren mit den Ini-Settings. Vieles davon hat gar keine Wirkung. Sämtliche Assets und Funktionalitäten müssen stets an diese Gegebenheiten angepasst werden, sonst ist die Performance ganz hinüber. Wer einen High-End Rechner hat, ja, dem ist das alles egal. Aber das sind halt nun mal die wenigsten Spieler.
