Beiträge von Maik Goltz

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

    Für PZB müssen mit den verbauten Signalen funktionsfähige/kompatible Magnete/Balisen (je nachdem was man eben braucht) verbaut werden. Für das ÖBB Signalsystem müssten auch unsere vR PZB Magneten (hier im Downloadbereich zu finden) genügen. Diese müssen entsprechend landesspezifisch verbaut werden. Bei der ÖBB gibt es zB keine 500er und so wird eben nur 1000 und 2000 für PZB Betrieb gelegt. Funktioniert im Prinzip wie die alte Indusi. Ist also komplett kompatibel zum DB Standard.


    Zur LZB gibt es bisher nicht viel zu sagen. Hier gilt dann besonders der Steckenbau, vor allem der LZB Abschnitt muss auch LZB typisch gebaut sein. Wie was wann und wo es im TS2013 wirklich geht, wird gerade erforscht.

    Der Unterschied zu früher ist warscheinlich, dass heutige Plastezüge den Ästen nicht mehr "ausweichen" können. Da gewinnt der Ast, auch wenns nur ein Zweig ist. Mit den alten robusten Fahrzeugen ist weniger passiert wenn mal ein Zweig abgeknickt ist. Deswegen ham die jetzt so viel Angst vor dem Geäst. Aber lieber mehr Sicherheit bei der Bahnfahrt als das Nachsehen zu haben wenn dem Tf die Eiche ins Gesicht klatscht.

    Wo da welches Komma sitzt ist mir eigentlich egal. Ich verlange von so einem Magazin dass es mir aktuelle und hilfreiche Informationen liefert. Das tut es weitesgehend. Eine Rechtschreibkontrolle läuft beim Lesen nicht mit bei mir. Zumindest inhaltlich ist es etwas besser geworden. Mir wird da ein wenig zu viel direkt von Fremdauthoren reinkopiert, ohne nochmal drüber zu lesen. Deswegen sind da auch die ganzen Fehler drin. Auf die Korrektheit der Angaben wird scheinbar sowieso nicht geachtet. Wie auch, die Verleger haben wohl eher wenig Ahnung von der Materie die ihr Heftchen beinhaltet. Aber hey, was erwartet ihr von einem 5€ Magazin. Perfekte Fachliteratur aus Nischenabteilungen ist meist deutlich teurer und nicht immer besser aufgemacht. Zumindest der Supportautomatismus bei Albo funktioniert gut. Man hat selbsttätig erkannt dass ich eine Doppelbestellung hatte und nachgefragt ob dies beabsichtig wäre. Da es mein Fehler war (die Printausgabe ist schwer zu unterscheiden von der PDF Version im Shop) meinte ich nur, dass es storniert werden kann wenn das denn noch geht. Prompt hatte ich eine Gutschrift. Das funktioniert also.

    Sorry dass ich deine Beiträge gelsen habe aber ich muss der Allgemeinheit wegen doch interagieren.

    Es ist ein RB bestehend aus BR 111 und Doppelstockwagen. Vmax 160 und ich mit 200 Km/h hinterher. Das ist die zweite Aufgabe von mir, die deine Geschichte einfach wiederlegt.

    Falsche Situation. Das meinte ich nicht. Nochmal nachlesen und verstehen und dann mir unterstellen ich würde Falsches behaupten.


    Solltest du mit der Digitalen Geschwindigkeitsanzeige der 101 nicht umgehen können, ist das dein Problem aber nicht das von RSC. Ein Jumping zwischen 0 und irgend einen anderen Wert, ist ganz Normal, denn wenn das Signal nicht mehr Hp0 hat, kannst du musst du nach :thumbsup: Geschwindigkeitsangabe und Entfernungsanzeige fahren.

    Ich bin durchaus in der Lage die Informationen die ich erhalte korrekt aufzusaugen. Das Jumping bei vorausfahrenden Zügen ist eben nicht normal weil es eigentlich dann auf 0 bleibt und nur die Entfernungsangabe variiert, aber eben nicht die VZiel. Es gibt lediglich die Schnarre wenn sich der Block nach vorne schiebt der besezt ist. Wenn man über die Sichtnetfernung der LZB dem Zug hinterherhinkt dann hat man auch keine 0 mehr sondern die Streckengeschwindigkeit. Es gibt keine Situation die dabei ein Springen der Anzeige verursacht, schon gar nicht so wie da. Also ist das was ich sage schon mehr oder weniger korrekt. Man möge mich aber gern mit fachkundigen Beweisen berichtigen.


    Stelle ich fest, dass es keine gibt, fange ich keine Bastelstunden an.

    Tja, DU, wir sind aber daran interessiert den Kunden etwas zu bieten was sie teilweise auch verlangen. Wenn du nicht gewillt bist deiner Kundschaft eine Leistung zu erbringen die dir auch neue Kundschaft zustellen kann, dann bist du im Geschäftswesen falsch angesiedelt. VR ist nun mal nicht ein Nachmacher sondern bereits mit der Br143 ein Voreiter gewesen. Nun muss nachgelegt werden da wir hinterherhinken. Aber ich baue nicht einfach was nach wie das manch andere gern tun sondern ergründe neue Möglichkeiten und binde damit wieder Kundschaft. Lern das mal zu verstehen. Das hat alles seinen Sinn und ist keine reine Zeitverschwendung wie du immer meinst.


    Das die LZB von RSC für Augsburg-München ausgelegt ist, sollte nicht neu sein. Infolge dessen, kann ich diese nicht in einer Lok implementieren, die auf irgend einer Strecke mit LZB unterwegs ist.

    Ist sie rein technisch nicht. Die Funktionen sind weder neu noch auf die Strecke begrenzt. Sie sind einfach nur nicht dokumentiert. Ich komme schon noch dahinter wie das geht. Es wäre aber deutlich einfacher wenn RSC eine Dokumentation bereitstellen würde. Müssen tun sie das natürlich nicht. Und den Beweis dass es auf anderen Strecken auch funktioniert werde ich dir schon noch erbringen. Da mach dir mal keine Sorgen.

    Das ist mir klar. Aber es geht ja darum was man im TS machen kann. Dass es im echten Leben funktioniert wissen wir ja. Wenn im TS ein LF da steht dann wird es erkannt und gemeldet. Nochmal zur Erinnerung, es gibt keine LZB Blöcke im TS. Man fragt lediglich Signale und LF ab.


    Edit: hmm ok, möglicherweise gar kein Problem diese Situation. Im Bild sieht man oben rechste die zur Verfügung stehenden Informationen über den Streckenzustand vor einem. Da hier die LZB scheinbar auch endet (keine Ahnung ob das wirklich so ist auf der echten Strecke), müsste sogar ein LZB ENDE Verfahren eingeleitet werden. Die Situation ist also schon Streckebau technisch falsch denn LZB ENDE müsste direkt am Signal stattfinden und auch dort müsste das LF stehen, bzw braucht da gar kein LF stehen denn LZB ENDE bedeutet maxial 160 ab dem Signal. Sowas hat RSC aber auch fabriziert. Das müsste alles umgebaut werden um eine einwandfreie LZB zu garantieren. Diese Situation hier liese sich rechnerisch natürlich aufdröseln, aber es gibt noch kompliziertere Stellen wo man schlecht entscheiden lassen kann was nun wichtiger ist (LF oder Signal). Mistig kompliziert der ganze Kram. Kennt jeman die Formel (möglichst total vereinfacht) für die Berechnung der LZB Bremskurve? BrH's haben wir ja nicht zur Verfügung, nur Zuglänge und Zugmasse.



    ps: die Informationen die das Bild über den Streckenzustand vermittelt sind als nichtig zu betrachten, das ist aus einer Beta und nicht aus dem aktuellen Stand.

    Heisst das, mein Beispiel, Zugteil A stell ich auf Ziel A ein und Zugteil B stell ich auf Ziel B ein. B-Spielerzug.
    Das noch im Editor Modus.
    Im Spiel wird gekuppelt, dann hat der ganze Zug Ziel B? und das bleibt dann bei der Trennung ?
    StS


    Das müsste probiert werden. Kommt auf die Programmierung an. Aber das könnte durchaus funktionieren. Man darf aber nicht an den Schaltern der ZZA rummachen sonst ist das nichtig.

    Ein guter Support leistet auch Hilfestellung für Fremdgeräte sofern möglich und es dem Wissenstand der Mitarbeiter zugetraut werden kann, vor allem dann, wenn das eigene Produkt davon durchaus abhängt. So ist zumindest mein Verständnis von gutem Support. Und ich weis auch wovon ich rede. Die Telekom und auch andere verweigern aber sobald sie merken dass ein Fremdrouter verwerndet wird sofort den kompletten Support und weisen auf die falsche Gerätschaft hin. Oft hat es mit dem Gerät aber gar nichts zu tun. Es ist also kein technischer Aspekt sondern ein rein formeller.

    Das Signalteam, besser gesagt der Mathias ist schon eingebunden. Aber er kann da nicht viel tun ausser einer Kleinigkeit die aber schon mal sehr viel hilft. Das kann er natürlich nicht für München-Augburg machen, das müsste dort aber gemacht werden.


    Weitere Tests ergeben aber weitere Problematiken, die sich vorwiegend aus dem Streckenbau ergeben. Das heist nicht dass die Strecke fehlerhaft gebaut ist, sondern dass sie nicht LZB tauglich gebaut. So darf ein Einfahrsignal möglichst nicht direkt hinter einem LF7 stehen. Da kommt es dann zu der Situation dass das LF7 zB. 160 Signalisiert, aber das Signal das 10m weiter steht meint ein Hp0 zeigen zu müssen weil der Block belegt ist. Die LZB bekommt das erst mit wenn man an dem LF7 vorbei ist. Da hat man also genau 10m Weg um von 160 auf 0 zu bremsen.


    Desweiteren gibt es ein Problem solange man sich zwischen Link0 und LinkX eines Signales befindet. In der Zeit kann die LZB nur bis zum LinkX schauen und sagt verschiedene merkwürdige Dinge voraus. RSC hat die Problematik mit den als Blockstellen fungierenden Zwergen umgangen, welche aber wiederum andere Fehlfunktionen bei normalen Zügen aufweisen (Head to Head Situationen die sich nicht auflösen lassen).


    Es wird also alles andere als einfach daraus eine wirklich funktionierende LZB zu bauen. Es bedarf zumindest woh noch einiger Tage an Tests nur um überhaupt erst einmal rauszufinden wie sie wann und wo reagiert. RSC Strecken können wir nicht anpassen, aber Berlin-Wittenberg sicher schon. Viel wäre nicht zu tun ausser ein paar LF zu verschieben und einige Gleisgeschwindigkeiten zu korrigieren, bzw. überflüssige LF zu entfernen, oder fehlende aufzusetllen.


    Was definitiv wohl nicht geht, ist flankierende Züge wissen zu lassen, dass da jemand mit 200 langmachen will. Die fahren einem einfach in den Weg rein, da der Block aus derem Sicht frei ist. Da sind dann also die Szenariobauer gefragt darauf zu achten, dass die LZB, durch solche Zugbewegungen in bis zu 10km Entfernung (weiter kann die Funktion nicht schauen), nicht beeinflusst wird. Man muss also die Strecke frei halten, es sei denn es ist gewollt dass ein Zug die Schnellfahrt aufhält. Das funktioniert dann sogar recht gut wenn man die LZB vernünftig parametrisiert und scriptet.

    Klaus, das selbe Problem hatte schon eine andere Aufgabe an genau der gleichen Stelle. Du schickst die Züge die von dort kommen, wieder dort hin zurück, warscheinlich damit das Gleis in Siegen frei bleibt. Das funktioniert scheinbar nicht bei allen. Der Zug bekommt Priorität und stellt sich schon mal den Weg frei. Fährt aber nicht los weil er mit dem Spielerzug konkuriert. Beide streiten sich im die Weiche und so kann man zwar losfahren, aber nicht dahin wohin mal will. Du darfst keinen Zug in diesen Tunnel leiten bevor nicht der Player aus dem Gebiet raus ist.


    Edit: Zug3 ist wohl das Problem. Der Fährt wie in der anderen Aufgabe in den Gleisstummel und dann in den Tunnel zum verschwinden. Genau das ist das Problem an der Stelle.

    Das meinte er nicht. Ihm gehts um die ZZA. Da die Umschaltung durch den Zug gesendet wird, schalten eben alle ZZA im Consist um. Einziger Versuche wäre die Voreinstellungsmöglichkeit zu mißbrauchen. Also in die einzelnen Teile im Flyout entprechend das eintragen was in der Anleitung steht. Hier kommt dann aber zum Tragen wie vorbildlich programmiert wurde. Ich denke es funkioniert nicht, da jeder Wagon beim setzen der Anzeige dies durch den Zugverband meldet und sich alle daran anpassen. Heist, wer zuletzt meldet hat das Sagen.

    Soweit ich mich erinnern kann (Quelle liegt grad nicht vor) gab es zu dem Thema vor ein paar Monaten tatsächlich ein paar Ausführungen. Darauf hin hatte AVM (Hersteller der Fritzbox) sich schon massiv beschwert. Ich halte das nicht für eine Satire, aber einen durchaus schlechten Artikel der die ernsthaftigkeit der Sache nicht ganz rausbringt. Ausserdem wird das doch eh schon praktiziert. Kabelanbieter lassen nur ihre eigenen Modems zu. Man muss also einen Router finden der dann mit dem Modem kann. Oft wird dazu eine modifizierte Fritzbox vom Kabelanbieter selbst gegen Gebühr zur Verfügung gestellt. Ich hatte erst neulich das Vergnügen eine normale Fritzbox an einem KDG Anschluss in Gang bringen zu müssen. Die Fritzbox war regulär kabeltauglich aber es war auf dem Standardwege nicht dazu zu bewegen zu funktionieren. Man musste einen undokumentierten Weg einschlagen um das zum laufen zu bringen. Kundenfreundlich und vor allem Benutzerfreundlich ist sowas absolut nicht. Und die Telekom macht auch schon lange solche Sachen mit ihrem Entertain. Wenn man nicht deren Router dran hat, dann leisten sie nur Support wenn man anfängt zu betteln, oft aber gar nicht. Gründe dafür gibt es technisch gesehen nicht wirklich. Der T-Com Router lässt sich aber fernsteuern und das finde ich wiederum sehr verwerflich. Du kannst die ja nicht aussperren. Wenn da einer meint er müssen an deine Daten ran dann macht der das einfach. Es geht nichts über einen selbst gekauften Router.

    Was du meinst ist ein Flanging/Phasing Effekt der typisch ist für Loopsounds die identisch sind und mehrfach abgespielt werden. Wenn also mehrere Loks des selben Typs hintereinander hängen oder Wagons mit gleichem Sound, dann kann das auftreten. Dagegen machen kannst du wenig. Es gibt für den Hersteller von AddOns einen Workaround, aber die meisten ignorieren das schlicht. Musst du also so hinnehmen oder selber hand anlegen und rausfinden wie man das verhindert.

    Hab den Sim mal probiert und kann da leider keine Freude dran finden. Grafik ist altbacken, aber das ist sie bei Zusi3 auch. Entscheidender ist dass der Simulator nicht sehr weit fortgeschritten ist. Es sind nette Gimmicks drin die ich mir im RW wünschen würde, aber dafür fährt sich das sehr bescheiden. Und wenn man sich dann mal die Strukturen anschaut, dann sieht man da deutliche Grenzen der Verwertbarkeit. Auch die Performance wird nicht unseren deutschen Ansprüchen gerecht werden können, wenn man damit deutsche Strecken bauen will. Ist weit weg von fertig und ich finde es gewagt von Astragon dieses Produkt so auf den Markt zu werfen. Das kommt der Zielgruppe von Astragon-Produkten überhaupt nicht nahe. Da werden sich einige dann beschweren dass es nicht einfach zu bedienen ist. Mal schauen. Mir gefällt es nicht.

    Um einen Lösungsweg noch an die Hand zu geben den ich mir ausgedacht habe, der quasi eine eigenen LZB Umsetzung darstellt ist, die LZB völlig von den anderen Signalen zu lösen und mit separaten, in Form unsichtbarer Signale zu setzenden LZB Blöcken. Der LZB Rechner in der Lok reagiert dann nur noch auf diese Blöcke. Diese Blöcke kümmern sich nicht im die anderen Signale sondern bilden eben ein eigenes Blocksignalsystem. Sie müssen dazu auf stopping false stehen, damit die anderen Züge davon keine Notiz nehmen und gar dort anhalten. Das bedeutet natürlich dass KI Züge nicht mit LZB Führung fahren können, das spielt aber auch weniger eine Rolle da diese sich sowieso nicht an Signalen stören. Diese selbst erfundene Variante lässt sich überall einbauen, nachträglich und auch in einem Szenario (wer Lust hat hunderte Tafeln zu stellen). Um dies umzusetzen muss erst rausgefunden werden wie die beiden Abfragefunktionen genau arbeiten und wie man mit denen die Unterscheindung vollziehen kann, und dann muss der einzige, der sich mit Signalen wirklich auskennt, die Blöcke coden damit sie das tun was sie müssen, nämlich kaskadierend Informationen über die Blockzustände in beide Richtungen tauschen. Damit könnte man die 12000m die man mit den Funktionen wirklich nach vorn schauen kann auch nutzen und zwar richtig. Diese Variante löst aber noch nicht das Problem mit den reinfahrenden Zügen. Da habe ich noch keinerlei Idee.

    Ja ice und du verkennst schon wieder die Tragweite dieser Tatsache die auch so stimmt. Wenn vR jetzt ein Fahrzeug mit LZB rausbringt, welches universell einsetzbar sein muss, weil die Kunden das eben so erwarten, und wir dann sagen dass es aber nur auf München-Augsburg funktioniert und nicht auf Berlin-Wittenberg oder anderen Drittentwicker-Strecken mit LZB Voraussetzung, dann haben wir wieder ein riesen Problem. Das selbe Problem haben wir aber auch, wie man hier im Forum auch deutlich erkennen kann, wenn wir die LZB einfach weglassen. Nun sitz ich hier und mach mir nen Kopp wie ich beides überein bekommen kann. Leider hilft der TS dabei nicht freundlich mit sondern schmeisst mir einfach die Knüppel zwischen die Beine. Das ist der Punkt abseits der Funktion der LZB.


    Dass die LZB nicht richtig funktioniert, merkt man erst, wenn man mal richtige Szenarien baut für München-Augsburg, wo dir eben auch mal Zügen in den Weg kommen. Da hat der Dispatcher ein Problem mit, da dieser nicht wissen kann dass das Fahrzeug LZB benötigt und viel weitere Vorausschau. Da kommt es dann ständig zu plötzlichen VZiel Absenkungen auf 0. Das Ganze natürlich dann bei 200km/h und der Zug bremst bei AFB Betrieb sofort runter und das völlig sinnlos, weil nach dem passieren des nächsten Link0 eines normalen Signales, die VZiel wieder auf 200 zurückspringt und meint da ist nichts. Der Zug der im Weg fährt ist aber noch da. Und so kommt es dann dass 1-2km, je nach Signalabstand, plötzlich wieder VZiel 0 ist und auch da bleibt weil die Strecke eben tatsächlich blockiert ist. Und schon rauschst du über das Hp0 drüber und womöglich in den Zug rein, weil du in 2000m nicht zum stehen kommst ohne Notbremsung, und selbst die wird es kaum schaffen weil der Bremsweg mit mindestens 2000m bemessen ist. Wenn man auf einer leeren Strecke fährt mag die Täuschung funktionieren. Aber nict mit üppigem Betrieb. Und das verhindert eben auch Mischbetrieb. Damit meine ich Züge die nicht 200 fahren sondern nur 160 oder sogar nur 80. Hinter so einem Zug hast du im TS keinen Spass mit der LZB weil die das nicht erkennt und ständig zwischen 0 und Vmax rumeiert statt vorausschauend die 0km/h stets zu erweitern, so dass eine AFB nicht bremsen muss sondern nur Vist halten, trotz zu erwartendem Hp0. Dieses Hp0 "wandert". Und das kann man nicht mit der Methodik erreichen die RSC benutzt. LZB funktioniert eben etwas anders als normale Blocksignalschaltungen. Die Blöcke "fahren" vor dem Zug her und halten Abstand wenn sich vor ihnen ein Zug langschleicht. Um das zu verstehen muss man mal eine LZB Beschreibung lesen. Die ist aber sehr ausführlich und deswegen liest sowas eben keiner.


    Jetzt hab ich die Wahl. Ich versuche die RSC LZB zu ergründen und einzubauen und sorge dafür, dass das Fahrzeug wo anders nicht funktioniert. Dazu lasse ich mir dann die Meckerei der Kunden gefallen und büse Umsatz ein. Oder aber ich konstruiere eine eigene LZB, die aber die selben Funktionsaufrufe (welche nach wie vor undokumentiert sind) benutzen müssen, und bin gezwungen kommende Strecken, die LZB Betrieb erfordern, damit irgendwie auszustatten. Diese LZB funktioniert dann aber nicht auf Muc-Aug, und schon wieder haben wir ein Problem. Nun muss ich also 2 LZB Syteme bauen, in eine Lok. Habe ich dazu lust und Zeit? Nein. Muss ich das tun? Ich denke nicht! Momentan versuche ich nur herauszufinden wie diese beiden Funktionen arbeiten und was man damit überhaupt machen kann. Dann werde ich entscheiden was in die künftigen Fahrzeuge kommt und wie kompatibel das zu den RSC Varianten sein kann. Da RSC die Informationen nicht preisgibt wie die Signale dafür präpariert sind, ich dies auch nicht rausfinden kann, wird es wohl keine Kompatibilität geben können.


    So, und jetzt reichts mit der Debatte um die LZB. Je mehr ich hier schreiben muss, und das muss man weil sonst keiner wirklich das Problem verstehen will, das gehört eben auch zum Support, um so weniger Zeit ist für die Fahrzeuge da.