Die beiden Zeiger stellen jeweils den Bremszylinderdruck (C) von einem Drehgestell dar. Normalerweise sollten, bei unproblematischen Betriebsverhältnissen, beide Zeiger nahezu den gleichen Druck anzeigen. Somit ist meist nur ein Zeiger zu sehen, da der andere darunter läuft. Wenn, wie auf deinem Bild, nur ein Zeiger auch Druck anzeigt, kann das zum Beispiel bedeuten, dass die E-Bremse in einem DG ausgefallen ist und diese dann nur pneumatisch bremst. Eventuell war das ja die Situation auf deinem Bild. Oder die AFB/LZB Haltebremse war aktiv. Die bremst glaub ich auch nur ein DG um den Zug festzuhalten.
Posts by Maik Goltz
-
-
neue und vor allem moderne Fahrzeuge die derzeit im Dienst stehen enthaltend
Die würde man aber nicht in so ein KI Paket stecken, wenn man überhaupt die Möglichkeit bekommt, diese zu bauen. Das würde den Aufwand und die anderen Dinge drum rum, gerade bei ganz neuen Fahrzeugen, nicht rechtfertigen. Das kostet dann in der Entwicklung mehr als es jemals einbringt in so einem Pack. Sowas würde ich also eher nicht erwarten. Außerdem hat Matthias doch schon gesagt, auf welchen Kundenstamm das Paket ausgerichtet ist. Eben genau nicht an die, die schon TTB haben. Aber genau die mosern jetzt hier rum, dass es nicht das ist, was sie erwartet haben? Liest eigentlich noch irgendwer, was gepostet wird, bevor man antwortet?
-
Der Effekt ist nicht gerendert. Das ist simple Photoshop Arbeit.
-
Ich verstehe Grundsätzlich nicht warum man auf die Konsolen setzt.
Weil man schlicht und einfach so ein Spiel Heute nicht mehr entwickeln kann, ohne die Konsolen zu berücksichtigen. Ist einfach zu teuer nur für den PC Nischenmarkt so ein Produkt auf die Beine zu stellen. Nicht nur Butter wird teurer, auch Entwicklungskosten steigen enorm. Die bekommt man aber nur mit PC nicht wieder rein. Der Konsolenmarkt erlaubt solche Entwicklungen noch.
-
Was vielleicht auch noch anzumerken ist, dass der Oberstrom an der Hochspannungsseite gemessen wird und die anderen Ströme meist an der Niederspannung (nach dem Trafo und dem Schaltwerk).
-
Ist die inzwischen aber bei DTG abgegeben oder noch nicht?
Da wird nichts bei DTG abgegeben. Ist ja keine Auftragsarbeit für DTG.
Der Stand ist aktuell folgender. Das Modell ist soweit komplett fertig. Das war es aber auch schon eine ganze Weile. Die Zeit brachte aber noch weitere Detailverbesserungen, die aus anderer Arbeit einhergingen. Bin gerade dabei, die schon 2 Jahre alte Antriebssimulation nochmal komplett neu zu machen, mit neuen Erkenntnissen. Soundarbeit war bisher nur ein Testballon für neue Methodiken (Granular Synthese) gewesen, die leider nicht wirklich funktionieren. Unterm Strich: das dauert noch...
-
Fragen solcher Art reizen die Entwickler eher dazu den Release weiter zu verzögern
Um ehrlich zu sein, solche Fragen interessieren in der Entwicklung überhaupt nicht. Weder positiv noch negativ beeinflussend. Es gibt einen Plan und der wird verfolgt. Der wird nicht von der Kundschaft beeinflusst. Da gibt es viel gewichtigere Einflüsse die ein Projekt aufhalten, canceln oder gar beschleunigen.
-
Das größte Problem dabei ist, dass der zur Verfügung stehende Speicher bereits ausgereizt ist auf der Strecke. Hinzufügen weiterer Dinge führt wohl unweigerlich zum OOM Crash. Das zeigt halt schön die hardwaretechnischen Einschränkungen auf, denen ein solcher Simulator auch heutzutage immer noch unterliegt. Speicher frei machen heist Qualität massiv reduzieren. Um den passenden Verkehr, den man in München erwartet, herzustellen, müsste der TSW aussehen wie ZUSI2
-
Komischerweiße funktioniert aber bei der 143 der Bremssound noch, bei anderen Fahrzeugen nicht mehr.
Einfach erklärt. In Loks mit funktionierendem Bremsartwechsel wird die HLL im Script berechnet und nicht der Wert vom TS übernommen. Der Sound hängt auch an dem berechneten Wert. Die Berechnung scheitert seit dem Update aufgrund des Gleitkommafehlers (X = X != X als Ergebnis).
-
als Nischenkunde fühle ich mich trotzdem übersehen
Ja, aber das ist doch auf jedem erdenklichen Markt so. Ich ertappe mich auch ständig als Nischenkunde und kann nichts dagegen tun als es hinzunehmen. Und das hat nix mit Software zu tun.
-
Vielleicht kann euch ja beim Thema Sound linusf behilflich sein.
Er ist sozusagen der Soundgott des TSCOhne es abwerten zu wollen und Linus wird das bestätigen. Im TSC sind die Voraussetzungen halt super, denn die nötigen Tools und Vorgänge sind nahezu alle im Spiel integriert. Soll heißen, das Sound-Proxy System ist vorhanden und muss nur bestückt werden. Im TSW oder eben der UE4/5 gibt es das nicht. Da muss die Steuerung des Sounds auch mit programmiert werden. Ob Linus das mal eben so kann, weis ich nicht. Kann er es nicht, kommt er nicht weit.
-
Aber wir reden hier ja auch nicht (nur) von DTG, sondern von den Entiwcklern des Hamburger U-Bahn-Simulators.
Schon klar, aber wenn die das erreichen sollen, was du dir vorstellst, brauchen die eben auch 12 Jahre. Mir scheint aber, dass das Produkt vornehmlich zum Geld verdienen erstellt wird. Das zeigt das Marketing darum (auch wenn es nicht viel ist). Da wird irgendeine finanzielle Instanz hinter stehen, die nicht 12 Jahre oder länger auf die Rendite warten wird.
-
Oder braucht es einfach wieder Idealisten wie damals die OMSI-Jungs, die aus Eigeninteresse und persönlicher Begeisterung ihr Projekt auf die Beine gestellt haben?
Die wird es immer geben. Aber am Beispiel Lotus (als eines von vielen) sieht man doch, was das allgemein bringt. Nicht viel. Ein paar Leute quälen sich da durch, ja, aber eben nicht viele. Nur gibt es für solche Simulatoren oft eben wenig or gar keinen Content. Man kann sich höchstens selbst was bauen. Das ist für die allermeisten Spieler aber nicht möglich. Also versinkt so ein Simulator schnell in einer sehr engen Nische. Der TSC war von Anfang an breiter aufgestellt. Ziel war das große Spielerpublikum. Das ging damals auch in die Hose, also wurde es eingestampft. Wir haben es dann tatsächlich ein paar Enthusiasten (aber eben auch mit viel Profitgedanken im Hinterkopf) zu verdanken, dass es überhaupt mit zu Railworks wurde und dann Erfolg verbuchen konnte. Heute ist das undenkbar. TSW ist ein Produkt in das, mit dem Ziel Profit zu machen, sehr viel Geld reingesteckt wurde. Weit bevor es veröffentlich wurde. Da mussten aber eben viele Abstriche gemacht werden, weil es sonst wie der TSC damals geendet hätte. Der TSW hat von Anfang an einen guten Erfolg bei der breiten Masse zu verzeichnen. Ist der erste TS der auf einer Konsole spielbar ist. Und so weiter. Sowas entwickelt man nicht nebenher. Das kostet Millionen. Und muss also auch Million einbringen, sonst macht das keiner.
-
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.
-
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.
