Mir fällt da sofort ein Bahnhof ein an dem es sowas aber durchaus gibt
Wo wäre das *interessiertnachfrag*?
ich hab das nämlich noch nicht beobachtet das Hauptsperrsignale als Esigs aufgestellt sind.
Ansonsten ganz großes Lob ans Signalteam, habe gestern Abend erstmal den Bahnhof Letmathe meines HaSi "4.0" Umbaus (nicht HaSi 3.0!)
Signalisiert. Macht echt einen schlanken Fuß, bahnsinn!!
Gruß Doc
Alles anzeigen
Also was du brauchst ist folgendes:
- ein Modell des Fahrleitungsmastes mit 2 Nodes für die "Andockpunkte" der Kabel
Beispiel: Im Modell heist der Node 1_0500_tragseil. Dann musst du NUR tragseil angeben. Übrigens funktionieren die Null-Objekte bzw. das Dummy-Objekt in 3ds Max nicht. Es muss ein polygonales Objekt sein sonst verabscheidet sich der RW/TS!
Heisst das das man diese Nodes als Childobjekt drin haben muß?
Ich nehme mal an das diese Node Objekte beliebig klein sein dürfen. naja es gibt ja genug Teile am Ausleger die man dafür hernehmen kann.
Klingt auf jeden Fall sehr interessant.
Gruß Doc
ich habe mir mal erlaubt - skeptisch geworden durch eure Aussagen - mal die Beschriftungen in der realität mit der Downloadbaren 1451 zu Vergleichen
Die Hektometertafeln weichen in der Tat in Details von der 1451 ab. Die 6 ist noch identisch, die 7 nicht mehr, hat sie doch bei der 1451 eine Serife die auf dem Schild nicht zu sehen ist, die 1 und 2 sind auch minimal anders.
Andere Zahlen waren grad nicht greifbar, ergeben aber sicher ein ähnliches Bild. Nicht dargestellt ist z.B die 0 die extrem abweicht.
Der Schriftzug "Karlsruhe Hbf" ist allerdings 100% 1451 da kann ich keinen Unterschied erkennen.
Es stellt sich mir auch die Frage ist die Downloadbare 1451 1. Vollständig 2. Aktuell bezüglich der DB spezialitäten(Din 1451 Mittelschrift DB)?
Ich finde aber trotzdem das die Zahlen der Hektometertafeln den Zahlen der Din 1451 schon ähneln, vielleicht eben eine Spezies
die in dem ttf nicht vorkommt?
Gruß Doc
ich habe mich vor vielen Monden schon mit diesem Thema beschäftigt, damals ging es im MSTS um die Umsetzung von Bahnhofs /Haltepunkttafeln etc.
Ich bin mir sehr sicher das bis 1994 bei der BundesBahn bei der Beschriftung von Rollmaterial, Namenstafeln und den "Verkehrszeichen" durchgängig die Din 1451 und deren Derivate in verwendet wurden.
Meines Wissens wurde die 2005 eingeführte DB Schriftart hauptsächlich zur Unternehmenskommunikation und Corporate Identity eingeführt und dürfte hauptsächlich im nichttechnischen Bereich der Bahn zu finden sein, also PR, Publikationen und interener Schriftverkehr. Auch neuerlich aufgestellte Bahnhofs /Haltepunkttafeln, Lf Tafeln und Hektometertafeln und auch die Anschriften am Rollmaterial scheinen nach wie vor mit Din1451 ausgeführt zu werden.
Wobei ich aber auch schon Hektometertafeln gesehen habe die so wie es aussieht nicht mit Din1451 beschriftet sind.
Ein Beispiel kann man sehen wenn man die A3 von Duisburg Richtung Köln fährt. Die Autobahn unterquert kurz vor dem AK Hilden die Bahnstrecke Düsseldorf - Hochdahl, und dort kann man eben von unten eine solche Hektometertafel sehen wo die Zahl eher wie eine Helvetica oder sonstwas aussieht
Ich denke bei Beschriftung mit der 1451 macht man nichts Falsch. Ich habe viele Bahnhofsschilder und meine Lf und Hektometer Tafeln für den RW damit erstellt und finde das diese mit der 1451 original so aussehen wie die Schilder auf meinen Streckenfotos
Gruß Doc
Erstmal Danke Onkel doctor!
Gleiswechselbetrieb... hmmm... gibt es denn überhaupt noch 2-gleisige Strecken ohne GWB?
So wie ich die Diskussionen auf Drehscheibe Online verfolgt habe, dort gibt es immer mal wieder Diskussionen die sich um den Gleiswechselbetrieb drehen, gab es in der Vergangenheit mehrere ofizielle Bezeichnungen dafür. Was es fast überall auf 2 Gleisigen strecken gibt ist die ´"Falschfahrt auf Befehl" Mit Befehl ZS 8 (Weiss blinkendes Zusatzsignal) Auf solchen Strecken ist nach meiner Kenntnis keine Kilometrierung am linken Gleis.
Die Fahrt im Gegengleis erfolgt hier mit maximal 100kmh
Dann gibt es aber auch noch den signalisierten Falschfahrbetrieb, wo dann auf Hp2 und Hp1 und ZS6/7 gefahren wird.
Die Fahrten erfolgen in diesem Fall nach Buchfahrplan, also auch über 100kmh.
Letzteres gibt es auf der linken Rheinstrecke und auf dieser ist das jeweilige Gegengleis alle 1000m mit einer Kilometertafel versehen.
Man klann das in diesem video bei etwa 16 sekunden sehen. Dann wird der KM 116.0 passiert, da sieht man schön das auch am Gegengleis eine Kilometertafel angebracht ist, die aber keine 100erter anzeigt.
Gruß Doc
Ich glaube bei Gleiswechselbetrieb stehen auch neben dem Linken Gleis Tafeln, aber ich meine auch nicht alle 200m sondern bei jedem vollen Kilometer und dann auch ohne Hunderter. Zumindest kann man das auf den Rheintal Führestandvideos bei Youtube sehen.
Ich habe HASI 3.0 beidseitig (was anderes gibts von SAD nicht) alle 200m Beschildert . Ist vmtl nicht richtig. Aber was solls.
Gruß Doc
Ja genau, was war esdenn Genau was das Problem verursacht hat. Zu wissen das es was mit dem Update zu tun hat ist ja schonmal was, aber vielleicht gehts noch a weng detaillierter.
Ich denke grad den Prellbock würds auch interessieren.
Gruß Doc
Ich hab mir die EBO nochmal gegeben, weil man ja schon mal dazu neigt Dinge verdreht im Kopf zu behalten..
Also EBO sagt:
Zitat
§ 40
Der Überhöhungsfehlbetrag ist in Abhängigkeit von der Beschaffenheit des Oberbaus, von der Bauart der
Fahrzeuge sowie von der Ladung und deren Sicherung festzulegen; er soll nicht größer sein als 150 mm.
ZitatAlles anzeigen
§ 6
(3) In den Bogen der durchgehenden Hauptgleise muß in der Regel die äußere Schiene höher liegen als die
innere (Überhöhung). Die Überhöhung ist in Abhängigkeit von der Beschaffenheit des Oberbaus, von der Bauart
der Fahrzeuge sowie von der Ladung und deren Sicherung festzulegen; sie darf unter Einbeziehung der sich im
Betrieb einstellenden Abweichungen 180 mm nicht überschreiten.
(4) Jede Änderung der Überhöhung ist durch eine Überhöhungsrampe zu vermitteln, deren Neigung nicht größer
sein darf als
1:400.
was ich demnach behalten habe waren die Zahlen nicht jedoch der Zusammenhang.
*Quelle: http://www.gesetze-im-internet.de/bundesrecht/ebo/gesamt.pdf
Ich grad mal nachgegrübelt, im Grunde genommen ist eine Diskussion über Überhöhunhsfehlbeträge doch reichlich akademisch. Zumindet an dieser Stelle. Ich denke jeder sollte für sich festlegen was er da einstellen möchte. Ich habe bei meinen Trackrules mal alles auf 120mm begrenzt (also 4.98 und entsprechendem CurvetoAngel Wert) und trotzdem den MinRadius auf den Wert eingestellt den er haben dürfte wenn er mit 150mm Überhöht wäre.
Da dieser Wert ja nun keinen direkten Einfluss auf die Überhöhung hat, kann man das ja machen. Somit kann ich dann einen 120er Bogen auch mit 760m bauen. Das entspräche dann eben einem Überhöungsfehlbetrag von 30mm, genau das was die echte Bahn auch tut wenns um den Kompromiss Güterverkehr vs Perosnenverkehr geht. Oder welche Gründe es im Original auch immer gibt nicht auf die Vollen 150mm zu gehen.
Fazit: Wenn jemand mit Überhöhungsfehlbetrag bauen will, muss er konsequenterweise im RW mit dem echten Überhöhungswert rechnen, kann aber den Rmin auf den Wert mit Überhöhungsfehlbetrag vermindern. Soweit ich es in der EBO erlesen habe darf das mit maximalem Überhöhungsfehlbetrag 180mm sein, also 150mm echte und nochmals 30mm gefakte.
Gruß Doc
Hallo Teneberus,
ich muss mich für mein doch sehr schnelles vorpreschen in dieser Thematik entschuldigen. Ich bin gerade nochmals die Geschichte mit dem MinRadius udn der MAxCAnt Angle durchgegangen und habe festgestellt, dass Änderungen am MinRadius an der Überhöhung tatsächlich nichts bewrirken. Es ist vielmehr wie du festgeltellt hast einzig auf CurveToAnglePercent zurückzuführen. Da habe ich falschgelegen. Vielen Dank für deine wirklich erkenntnisreichen Beiträge.
Gruß Doc
Also ich habe die gleiche Erkenntnisse wie Holzlaender, MaxCantAngle und MinRadius bestimmen die Maximale Überhöung bei minimalem Radius abhängig von der Max Speedtolerance. Wie ich weiter oben schon schrieb ergibt ein Rmin von 190m und einer MAxSpeedtolerance von 160kmh und einem MaxCantAngel von 4.8 bei einem Tatsächlichem Radius von 1500m eine fast nicht zu merkende Überhöhung obwohl sie bei diesem Radius und der Gescwindigkeit schon fast am Maximum liegen sollte. Ändert man nun den Rmin von 190m auf 1400m und schaut sioch das ganze im Welteditor an dann hat man eine erheblich andere Überhöhung, denn der MAxCantAngle wurde dadurch von 190m auf 1400m verschoben. Habs grad nochmals ausprobiert.
Was ich nie ganz geschnallt habe ist eben der Wert CurvetoAnglePercent. Das blöde ist das das nicht vernünftig Dokumentiert ist.
Ich kenne den ganze Kram von ZUSI und da ist das anders, wie ich finde verständlicher gelöst. Da gibt es eine Projektierte Höchstgeschwindigkleit und die gewünschte maximale Überhöhung, z.B 120mm, dann baut Zusi anhand der echten Radien und des Regelwerks (EBO) einen Bogen mit Übergangsbögen und der Überhöung die zum Radius und Geschwindigkeit passt. Im Grunde macht RW das auch nur gibts hier noch den CurveToAngle Quatsch und der scheint irgendwie nicht so ganz ins Biild zu passen.
Ich habe jedenfalls nach den Erkenntissen von Maik (wieso ist der eigentlich weg?) und RWMatze in meine Trackrules den MaxCVantAngle nach deren Formel eingetragen: Rmin/10
BTW sind Übergangsbögen oder Klothoiden (wenns im RW denn eine solche ist) und Überhöhungsrampe untrennbar. Auf der Überhöungsrampe wird kontinuierlich die Überhöhung von 0 bis zum Maximalwert gesteigert, idealerweise korreliert dies mit dem kleiner werdenden Radius in der Klothoide/dem Übergangsbogen. Daher ist Übergangsbogen und Überhöhungsrampe identisch. Möglicherweise ist das in Österrreich anderes, denn dort werden Übergangsbögen m.W. nicht mit linearen Klothoiden gerechnet.
Gruss Doc
Da muss ich aber widersprechen.
MaxSpeedTolerance hat einen entscheidenden Einfluss auf die Länge der Überhöhungsrampe/Übergangsbogen (gut hat du ja am Schluss auch geschrieben). Je niedriger die Zahl desto Kürzer die Überhöhungsrampe/Übergangsbogen. Desgleichen der Min Radius, dieser hat einen Einfluss darauf ab wann der MaxCant Angle denn auch angewendet wird.
Nehmen wir mal eine MaxSpeedtolerance von 160 kmh bei einem Min Radius von 190m und einen MaxCantAngle von 5 an, in diesem Fall wird der maximale Überhöhungswinkel erst bei einem Radius von 190m erreicht. Bei Werten unter 190m würde die Überhöung nicht mehr gesteigert bei werten über 190m läge wird der Winkel immer niedriger. Das hiesse eben auch, dass bei einem Radius von 1400m noch fast keine Überhöhung dargestellt werden würde obwohl das ungefähr der unterste Radius für 160kmh wäre und somit der größte Überhöhungswert hier erreicht sein müsste. Setzt man nun den MinRadius von 190m auf 1400m, dann wird der MaxCant Angle, der größte Überhöhungswinkel eben schon bei 1400m erreicht und der Bogen mit diesem Radius wäre korrekt Überhöht.
Ich habe das auch lange nicht verstanden, aber die Cracks hier im Forum haben das sehr gut rausbekommen.
Daher habe ich nun für 60-160 km/h Trackrules in 20kmh Schritten erstellt (60, 80 100, 120, 140, 160) in jeder Trackrule ist beim Minradius eben der circa Wert der sich nach der Formel bei 150mm Maximalüberhöhung errechnet eingetragen, 60kmh=190m; 80 km/h=300m; 100kmh=500m; 120kmh=760m 140kmh=1200m 160kmh=1400m.
Ich finde damit kommen sehr realistische Übergangsbögen raus, das sieht genauso aus wie mit dem Absteckrechner von Zusi!
Und eben auch sehr realistische Überhöhungen.
CurvetoAnglePercent haben ich so verstanden, das dieser einen Einfluß auf die Länge der Überhöhungsrampe hat, diese sollte idealerweise auf den Übergangsbogen passen. Aber vielleicht ist diese Erkenntnis ja auch falsch
Jetzt muss man aber auch noch sehen, das der maximal zulässige Überhöhungswert von 150mm bei der echten Bahn nur selten auch wirklich gebaut wird.
Meist wird mit 100-120mm gerechnet und der Rest um die projektierte Trassengeschwindigkeit zu erreichen wird als Überhöhungsfehlbetrag "dazugeschummelt" .
Das macht sich dann für den Fahrgast in einer leicht erhöhten Querbeschleunigung bemerkbar. Aber ich fange an zu faseln, Sorry.
Gruß Doc
Also ich kriege seit dem großen Update gern mal "Something Bad happened..." beim durchswitchen auf die Signallinkdarstellung, sehe sie -wenn er es überlebt- aber.
Überhaupt ist der Welteditor nach meinem Gefühl seit dem Update viel zickiger. Ich bin grad dabei Hektometertafeln zu setzen udn kriege alle 10-15 gesetzte Tafeln eine DX Vertexshader Meldung mit anschließendem "something Bad happened"
Irgendwie suboptimal
Gruss Doc
Zitat
Hätte ich Paypal, würd ich gern RW-Tools verwenden, was Geldmache angeht ist Railworks an TOP 1(man vergleiche nur mit OMSI -> 95% genialer free stuff, 5% was kostet)
RWTools hat m.w nix mit den Ofiziellen von Railworks zu tun. RWTools ist Donation Ware und ich finde nichts verwerfliches daran sich für seine ERHEBLICHE Programmier und Rengineerarbeit ein bisscehn sponsern zu lassen
Zitat
Irgendwie hat es mir die Trackrule nicht "angenommen". Jegliche Weichen sind nicht mehr vorhanden, Superelevation funktioniert nicht und die ganzen Werte im Track wie z.B. die Unebenheit ist nicht da. Es kommt mir vor als hätte er es nicht erkannt.
Wie funktioniert denn das mit der Blueprint "bml_track_rule_se.xml" ? Habe ja niergends eine xml angelegt oder hingelegt. Ich glaub da hängts noch ein wenig
Das muss drin sein
<DefaultSuperelevation>
<Network-iTrackNetworkSuperelevation-cPropertyValue>
<MaxCantAngleDegrees d:type="sFloat32" d:alt_encoding="4.8" d:precision="string">4.8</MaxCantAngleDegrees>
<CurveToAnglePercent d:type="sFloat32" d:alt_encoding="50" d:precision="string">50</CurveToAnglePercent>
</Network-iTrackNetworkSuperelevation-cPropertyValue>
</DefaultSuperelevation>
und das
<DefaultRideQuality>
<Network-iTrackNetworkRideQuality-cPropertyValue>
<LineUnevenness d:type="sFloat32" d:alt_encoding="10" d:precision="string">10</LineUnevenness>
</Network-iTrackNetworkRideQuality-cPropertyValue>
</DefaultRideQuality>
Wobei die Superelevation Einträge von der DefaultSpeedLimit un dem MainLine Min Radius abhängig sind. Sind da komische werte drin Neigt sich da nichts oder nicht so wie es soll.
Da gibts aber meine ich ein gutes Wiki dazu, ansonsten einfach mal den Thread "Kurvenüberhöhung Erkenntnissamllung" hier im Board mal durchziehen
Gruß Doc
Ach so, ich vergass:
StS for Vice President 
Supersache ich freu mich. Dann gibts bald vielleicht auch eine Superstrecke.
Was meint ihr, wäre mit diesem getriggere sowas wie Zugflügelung möglich? Ich denke da an die die "Abellionummer" in Lethmathe, da ich in meiner HASI 3.0 die Strecke nach Iserlohn drangebaut habe könnte man da sowas bringen.
Gruß Doc
Schuster for President 
Wie wird das mit dem ZP9 laufen? Du sagst das man Streckenseitig noch was einbauen muss. Was wird das sein?
Gruß Doc
Hat sich erledigt , der gute Holzländer hatte hier im Forum schonmal auf ein Tutorial verlinkt. Dort konnte ich den entscheidenden Hinweis finden. Die Textursets müssen in einem bestimmten Ordner in der Assets-Struktur liegen. Sie dürfen nicht beim denTexturen des Objekts abgespeichert werden
Vielen Dank
Hallo werte Simulatorfreunde,
ich habe grad mal ein Problem. Da mir die originalen und auch die SAD'schen LF x Tafeln so überhauptn nicht gefallen, sie sehen weder nach DB noch nach DR aus,
habe ich mir gedacht ich baue mir (uns?) mal ein paar eigene. Ich hab mir also die DevDocs geschnappt mich ein bisschen eingelesen und mal im 3dsmax losgebaut.
Wie in den Conventions für deutsche Speedsigns vorgegeben mit einem ParentObjekt und 3 Childobjekten die ich korrekt nach Naming Convenntion bezeichnet habe. Das ganze habe ich dann, auch streng nach den DevDocs, mit den entsprechenden PlatzhalterTexturen die natürlich auch nach Naming Convention benannt wurden, versehen.
Setze ich die Dinger nun im Editor werden immer die Platzhalter Texturen geladen und nicht die aus dem Texture Set mit den Nummern. Diese aber allem Anschein nach halbwegs korrekt, bei 120kmh sehe ich zwar keine 12, aber das Muster aus der Dummy Textur in entsprechendner Breite, setze ich das Ding auf einen 40 Kmh Bereich dann zeigt er mir die Textur entsprechend schmaler, eben für eine einstellige Zahl. Wenn ich dann im Texturenverzeichnis die 3 Platzhaltertexturen lösche, sehe ich die "Missing Texture" Textur. D.h irgendwie scheint das mit der Zuordnung der Texturen aus dem Texture Set nicht zu klappen.
Daher denke ich das ich beim 3D bau nicht allzuviel falsch gemacht habe. Nicht ganz sicher bin ich mir bei dem Child Objekt 1_1200_primarydigits_3,
In den Devdocs sieht es so aus als müsste das Objekt aus 3 Polygonen bestehen die separat mit der primarynumber_0, ...1 und ...2 Textur gemappt werden. Ist das so? Oder habe ich hier vielleicht den Fehler?
Ansonsten habe ich ein Texture Set erstellt das zumindest was man im Blueprinteditor sehen kann funktioniert. Die Texturen selbst habe ich auf den Kuju und SAD schildern ausprobiert. Diese funktionieren hervorragend daran kann es nicht liegen.
Für interessierte, ich habe DIN 1451 DB Engschrift verwendet, welche bis in die 2000er Jahre auch bei der Bahn durchgängig auf Schildern verwendet wurde.
Wenn jemand einen Tip für mich hat, ich wäre sehr erfreut, ich komm grad echt nicht weiter.
Vielen Dank
DerDoctor
Erbarme... zu Spät, die Hessse koomme.....
hee, des is doch mol escht gudd erklärt, klingt genauso wie de typpp do von Badesalz
