Beiträge von derdoctor

na wenn sich soviel andere schon probiert haben dann will ich mal von einer weitern version absehen. Wird ja dann doch etwas infllationär

Eine Weiche die mit 60 km/h befahren werden darf muss auch 500m Radius haben alles andere ist Käse.

Ich werd das nie verstehen was so schwer daran ist Weichen mit 190m. 300m, 500m, 760m 1200m oder 2500m Radius zu bauen.

Auch die Abzweigewinkel sind nicht so schwer zu behalten im Ts dann 21.1m Bogen bei 190m 33,4 bei 300 41.5 bei 500 54,2 bei 760 64,8 bei 1200 usw.

Taugen die Objekte in der Strecke was? Z.b Bahnhofsgebäude Gau Algesheim, Ingelheim oder Mainz??

wäre ja eine Strecke die mich reizen würde so wie HaSi3.0 zu "korrigieren"

Gruß Doc

Zitat von 143er

45 Sekunden ist ja nix ich bin bei 10 Minuten!

genmäß einer alten Flensburger Werbung: "Ssso'n Rechner hatt' ich auch ma'"

Ich wollte damit auch nur zum Ausdruck bringen, das die Meldung das man zu wenig Speicher hat irreführend ist, da es nicht unbedingt am Speicher liegt.

Bis vor ein Paar Monaten hatte ich auch einen Rechner mit nur 8GB Ram und hatte auch regelmäßig die Abstürze mit der Meldung das ich die 64 Bit Variante benutzen sollte und oder mehr Speicher. Ein blick in den Taskmanager während der Editor mit einer größeren Strecke normal lief verriet, dass auch bei nur 8GB Ram noch fast 2 GB frei waren. Dennoch hab ich mir daraufhin die Kiste die ich jetzt habe gekauft und es hat bezogen auf die Abstürze 0,0 gebracht!! Ich habe immer noch diese Abstürze und auch die Meldung. Und das eben nur bei Strecken die eine gewisse Grösse erreicht haben. Bei kleineren Strecken kann ich tagelang wurschteln ohne das es hackt. Ich vermute auch noch einen Unterschied ob nun die Tracks.bin so gross wird durch viele Gleise oder durch viele andere Einträge die viel Ressourcen verbrauchen (Signale, Streckenmarkierungen ) Aber gut zu wissen das auch eine 12Mb Strecke noch läuft. Macht nur bestimmt beim Speichern keinen Spass. Meinen grösste Strecke mit knapp 9mb tracks.bin braucht mittlerweile trotz schneller CPU (8 Kerne) und SSD ca 45s zum speichern.

Also nicht falsch verstehen! mehr RAM ist immer gut! Hilft aber beim aktuellen Problem nur bedingt weiter weils nach meiner Meinung nicht die Ursache ist. Btw ich habe ja seinerzeit mal die Hasi 3.0 gebaut, und ich hatte mich zwischenzeitlich mal daran gewagt Die Oberleitung von Freiburg Basel zu verbauen und habs bleiben lassen, da im Bereich von Hagen wo halt schon viele Schienen, Weichen und vor allem noch viel mehr Signale verbaut sind fast kein Arbeiten mehr möglich ist, da setzt man mal 2 Pfosten neu schiebt ein bisschen herum und Zack! Absturz: Bitte verwenden sie die 64Bit Version blablabla.... . Ja, vielleicht habe ich da früher mal irgendeinen "Futsak" verbaut der das macht, aber es ist schon eine gewisse Korrelation zwischen "Viel los auf der Strecke" und den Abstürzen zu sehen, nur ist die tatsächliche RAM Speichersituation zu dem Zeitpunkt des Absturzes mit zumindest mit den Mitteln die Windows zur Verfügung stellt, nicht annähernd Kritisch.

Ich hab 32 GB Ram und ne 4GB Ram NVIDIA Graka und hab den Fehler auch ab und an. Das liegt sicher nicht am Speicher. Als Programmierer kann man viele Lustige Texte in den Code schreiben die dann bei einer Exception ausgegeben werden.

Nach meiner Erfahrung wird kritisch wenn die Datei tracks.bin über 8mb groß wird, als XML entpackt ist die dann um die 75MB groß.

Nicht wirklich viel, aber da sehe ich eher einen Zusammenhang. Da hängen dann ja auch noch so Sachen wie Signalskripte usw usw dran das wird dann eher der Engine zu viel, nicht der Hardware. Ich hab auch bei den krassesten Strecken immer noch 15GB von den 32 frei. Daher liegts nicht am Ram da bin ich mir 100% sicher

Gruß Doc

Nach meiner Erfahrung sind die hochauflösenden DEM eher unbrauchbarer da diese "Unruhiger" sind.

Hab aber auch schon ewig nicht mehr runtergeladen. Es gab da mal 10arcsec Dems aus einer Japanischen Quelle, Katastrophe!! Am Besten sind immer noch die 30arcsec Dems von der USGS. Nicht so superauflösend aber wenig Artefakte und: sehr genau was die Höhenwerte angeht. (Bahhof St Wendel (Saar) ist dort auf 286m) ich echt steht an der Fahrdienstleiterbutze auch was von 284,5m.ü.n.N).

Also, die Dems sind schon Ok aber eben manchmal etwas unruhig, da sind halt schon mal Hochhäuser, Wälder Funkmasten mit drin die dann zu erheblichen Ungenauigkeiten führen. Die guten Dems sind um solche Dinge bereinigt aber eben auch nicht 100%ig. Denn die Radarlandvermessung kann nur die Oberfläche so erfassen wie sie ist: mit Bebauung und Bewuchs und eben nicht die reine Bodenhöhe. Wenn ich die Höhe eines Bahnhofsgeländes erfassen will dann schaue ich in Google Earth das ich so nah wie es geht reinzoome und dann auf der Bahnhofsfläche an 7-8 Stellen Höhendaten ablese. Dabei erkennt man dann schon das die Variationen im Bereich von weingen Metern liegen. Wenn ich jetzt noch weiss dass das Bahnhofsgelände fast eben ist und mit minimaler Neigung, dann interpoliere ich die in Google Earth gemessen gemessen Werte, begebe ich im Editor zu den Koordinaten und stelle fest das im TS etwa die gleichen Höhenwerte vorliegen, trage meinen Wert ein und planiere das Gelände anhand des Google Overlays.

Daher seh ich das genauso wie Prelli, wenn man sich an seine Methode hält wird das nachher erstaunlich gut. Zumal man mit Google Earth immer noch ein gutes Werkzeug zur Kontrolle hat (wenn man nicht grad in Jamaica baut )

Ich hab da mal was in und um Stuttgart gebaut und war nachher als ich mal in der Gegend unterwegs war entzückt wie sehr die Realität aussah wie meine Strecke ;-P

Gruß Doc

Hallo Augustusburg,

ich hab es bislang immer so gehalten das ich mit in Google Earth (nicht GoogleMaps!) die Höhen der Bahnhöfe und Abstände der Bahnhöfe vorab ermittelt habe, daraus kann man dann die Steigung in Promille oder Prozent errechnen und diesen Wert dann im Gleisbau Flyout ganz unten bei der Steigung eintragen. Hier bei sollte man aber wissen welche Maßeinheit in der Trackrule eingetragen ist. Also ob Prozent oder Promille, ich glaub irgendwelche Winkelfunktionen gehen da auch noch. Dann hast du zumindest schon mal eine ungefähre Idee. Ich gebe immer noch einen halbes Promille drauf da man ja auch noch ein bisschen Luft zum ausrunden der Neigungswechsel braucht. Mir kam es bislang auch nicht auf einen oder 2 Meter an. So genau sind die DEM Daten ja auch nicht. Ich versuche Bahnhöfe meist eben zu bauen, also mit einer 0.00000 im Steigungsfeld, das macht es beim bau von Weichenstraßen einfacher. Wenn das auch nicht immer dem Original entspricht: in Bochum Hauptbahnhof z.B. gibt es einen deutlich sichtbaren Neigungswechsel im Weichenbereich des Westkopfes, sowas ist im TS nicht mit vertretbarem Aufwand umsetzbar. Ich hab das mal probiert in Weichen Neigungswechsel einzubauen, es geht, ist aber eher was für Vatermörder.

Eine gewisse Streckenkenntnis ist auch nicht schlecht, dann gerade bei Gebirgsstrecken hat man selten immer die gleiche Neigung und es ist natürlich interessanter auch schon mal einen Neigungswechsel an den richtigen Stellen zu haben. Das Höhenmodell in Google Earth ist zwar außerhalb er großen Städte recht ungenau, aber so ungefähr kann man da schon die Höhen an bestimmten Stellen ermitteln um dann eben mit der oben genannten Methode die Neigungen der Abschnitte zu ermitteln.

Vor der Benutzung des "An Gelände anpassen" Tools kann nur dringend Abraten. Das Ergebnis davon ist fast immer äusserst unbefriedigend! Und macht mehr Arbeit als sonstwas. Aber die Ansprüche sind ja für jeden andere.

Habe leider keinen Urlaub mehr, und muss ab Montag wieder schaffen. Sonst hätte man mit Anydesk oder sowas mal was machen können.

*Staubwegblas*

Ich hab mich mal wieder mit den SBS Signalen beschäftigt und hab mal ein bisschen Trial and Error gemacht. Folgende konnte ich heraussfinden:

Wenn das letzte Hauptsignal vor einem SBS Blocksignal (SBS HVk HSB xx xxxxx) ein HS oder HSP aus dem Letzten HV Schusterpaket ist, reagiert das SBS Blocksignal so, dass es erst bei Annäherung auf 200m vor dem Signal auf Hp1 geht. Ich habe mehrere SBS HSB ausprobiert und die machen alle das gleiche. Die HS und HSP habe ich nicht getestet.

Tausche ich nun das letzte Hauptsignal vor dem SBS in ein Blocksignal aus dem Schusterpaket, funktioniert es!! Es funktioniert auch wenn ich vor das SBS Blocksignal ein ein Schuster Vorsignal stelle. Dann ist auch egal was davor für Signale stehen. Da scheint dann ja irgendwas zwischen den neuen Schusterfreewareskripten und dem Schuster HV Paket was m.W. noch nicht mit diesem Skript: Skript-Module_Signal-Trigger_V9.5 läuft. Oder? zumindest haben die "Sourcen" (Skriptpaket_HV-Signale_V6.11) eben eine viel niedrigere Buildnummer.

Könnte da mal jemand von den Koryphäen mal in den Code schauen???

Bzw gäbe es für sowas eine Lösung die ich nicht gefunden habe?

Liebe Grüße und vorab schonmal vielen Dank für alles

Gruß Doc

man darf Payware auch in Freeware verbauen. Man sollte allerdings vermeiden auch nur ein Fitzelchen der Payware in einem Download anzubieten.

Man muss bei einer Veröffentlichung die User daraufhinweisen das für dein Freeware addon der Besitz!!! dieses oder jenes Addons erforderlich ist.

D.h. wenn ich irgendwann z.B. meine KBS 680 zum Download anböte und du die Strecke fahren wolltest, müsstest du dir vorher Freiburg Basel kaufen sonst hättest du viele Milchflaschen. Weil ich den Content nicht anbieten darf, das wäre eine Urheberrechtsverletzung. Trotzdem würde ich vor Veröffentlichung aber bei dem Team/Distributor nochmal anfragen ob das auch wirklich ok ist.

Du musst nicht alle Gleise anklicken/markieren nur immer ein Stück das zwischen den roten Dreiecken liegt. Bei korrekt verlegten Weichen wäre das natürlich jede Weiche, aber eben nicht jedes Segment.

Ich hab für 130km Strecke etwa 1 Stunde gebraucht, aber es geht ganz sicher auch durch Entserzen und "zu Fuß" editieren, muss aber damit nicht schneller sein

Hallo zusammen und Frohe Weihnachten

<CatenaryBlueprint>

...

<BlueprintID d:type="cDeltaString"></BlueprintID>

</iBlueprintLibrary-cAbsoluteBlueprintID>

</CatenaryBlueprint>

Wenn man in der aktuellen Trackrule das so einträgt - also BlueprintID ohne Eintrag - und dann irgendein Gleis zwischen den kleinen Roten dreiecken antickt und einmal Oberleitung aus und wieder anschaltet sind die Originalstrippen auch weg. Merke: man muss nicht jedes Gleissegment anticken oder Markieren. Es werden alle Gleise innerhalb der roten Dreiecke geändert.

So was in der Art vermute ich auch bei TE.

Die Strecke wurde vielleicht mal mit so einem Eintrag:

<BlueprintID d:type="cDeltaString">Scenery\Procedural\oxfo_padd_Catenary01.xml</BlueprintID>

erstellt und dieser wurde möglicherweise später aus den Trackrules entfernt. Ich habe das auch schon so gemacht, da ja die Handverlege OL von TSC oder auch von den Freiburg Basel Jungs viel geiler ist.

Ich habe aus meinen Trackrules einfach das Objekt für den Fahrdraht entfernt, alle Gleises angetickt einmal aus und wieder an, speichern, fertig. Es geht bestimmt auch durch Entserzen der Tracks.bin und der Suchen-Ersetzen Funktion eines geeigneten XML Editors

Erstgenanntes ist natürlich blöd bei Trackrules die aus einem anderen "Stall" stammen. Aber selbst wenn man den Eintrag wieder setzten würde (z.B. durch Update des Assets-Ordners wo die Trackrules liegen) bleibt die OL aus. Man müsste erst die o.g. Schritte erneut durchführen.

Gruß Doc

Hallo BR 218.

Das ist mal ein ganz listiges Update. Da wird genau das gemacht was ich auch schon versucht habe:

Die ganzen *.ban Dateien die mit der Neigetechnik zu haben zu löschen. Wie ich oben schon schrieb verhält sich der ICE TD (der ja auf dem ICE T basiert, sowohl in Echt* als auch bei Dovetail) dann wie ein ganz normaler Zug, er geht mit der Überhöung in die Kurven. Nur geht leider keine Sifa und kein PZB mehr. Ich versuche es aber trotzdem mal nach der Anleitung. Denn alle die beschriebenen Dateien gibt es auch beim ICE TD.

Aber trotzdem vielen Dank für den Link

Gruß Doc

Edith: hat gesagt das ich zwar bei meinem ersten Versuch die PassengerCab Animationsdatei PassView_Tilt.ban vergessen habe zu entfernen, aber auch das diese ebensowenig nützt da die Sifa und Indusi ähm PZB sowie die Zugkraftanzeige den Dienst quittieren wenn diese Animationsdateien fehlen.

*ja ich weis die Dinger sind nicht ganz auf gleicher Basis, der 605 enthält die Siemens Neigetechnik die auch im 612 verbaut ist und der 411/415 ist mit der FIAT Technik ausgestattet.

Hallo Maik,

das klingt ja mal fundiert. Dann füge ich mich in mein Schicksal

Gruß Doc

Einen Versteckten Schalter bei dem Fahrzeug gibt es nicht?

Da bin ich aber beruhigt, dass es nicht an den Strecken liegt. Komisch das das noch niemandem aufgefallen ist, die Rezensionen (auch wenn alle schon älter) gehen alle gegen Jubel wie toll das doch funktioniert.

Vielen Dank

Gruß Doc

Hallo zusammen,

ich hab schon seit einigen Jahren den ICE TD von DTG auf der Platte, mich aber immer nur sporadisch damit beschäftigt. Ist ja ganz nett gemacht das Teil, aber leider scheint - zumindest auf meinen Strecken - der Zug einen Bug in der Neigetechnikumsetzung zu haben:

Es sieht so aus als hätte es damit zu tun Je nachdem wie ich beim Bau der Strecken die Kurve angesetzt habe, denn manchmal - aber nicht immer- neigt er zur falschen Seite! Es lässt es sich beim Bau einer Strecke ein ums andere Mal nicht vermeiden eine Kurve bzw. Teile davon nicht in einer Baurichtung zu erstellen.

Und vermutlich in solchen Kurven ist der 605 (und vielleicht auch der (411/415) zum Kurvenäußeren hin zu neigen. Es macht dies auch nicht der ganze Zug sondern meist nur die In Fahrtrichtung vorderen Wagen. Der hinterste, gedrehte Wagen mit FST neigt korrekt.

Ich vermute da ich nicht einen Thread finden konnte der sich mit diesem Problem befasst, dass ich echt der einzige bin der dieses Problem hat. Drauf gekommen bin ich, nachdem ich bemerkte das der Cab Kamera ( Kopf des TF sich entgegen der üblichen Praxis sich nicht mit in die Kurve neigte, auf die Außenansicht schaltete und sah, dass sich der Zug deutlich gegen die reguläre Überhöhung neigte also quasi wieder senkrecht stand anstatt sich noch tiefer in die Kurve zu legen. Weiteres Indiz: der letzte Wagen neigte sich exakt entgegengesetzt also korrekt zur Überhöhung und hatte zu den anderen Wagen an der Kupplung einen recht großen Überstand im oberen Bereich des Wagenkastens, eben durch die diametrale Neigung zu den vorderen Wagen.

Nun habe ich 3 Fragen:

1. Hat das irgendjemand sonst schon einmal bemerkt?

2. Hat jemand eine Idee in welcher Datei man schauen könnte? (Lua Script Decompiler??) Oder weiß sogar jemand Konkret was hier die Ursache ist. (Der SEC Hitachi Zug neigt auf meinen Strecken überall korrekt)

3. Gibt es Analog zu diesem Hitachi Zug beim ICET T / TD einen Schalter zu abstellen der Neigetechnik? Denn das Umbenennen/Unkenntlichmachen der *.ban Dateien (Cab_Tilt.ban, 411-6_tilt.ban etc) macht zwar das der Zug nur noch normal durch die Überhöhung neigt, führt aber auch leider dazu das SIFA und PZB nicht mehr funktionieren, was für mich nicht zielführend ist.

Auch habe ich der Doku keinen Hinweis auf einen Schalter für die Neigetechnik gefunden.

Vielen Dank für Hinweise die zur Lösung meines Problems führen können.

Liebe Grüße Doc

Ah das macht Sinn, es kann sein das ich mich dadurch mehrfach selbst ausgetrickst habe.

Beim allerersten mal setzen habe ich in der Tat vergessen die Zahl einzutragen, hab das Ding nochmals angeklickt und dann erst die Zahl eingetragen. Da stand der dann natürlich schon auf 0 und blieb es auch. Daher dann immer Zugbeeinflussung. Und beim Testen habe ich zwar auch mal neu gesetzt aber auch ein Paarmal nur eine andere Zahl eingetragen.

Das war guter Tip! Vielen Dank Lord Tulpe

Gruß Doc

Hallo liebe Streckenbaugemeinde,

ich habe da grad mal so ein Problem mit den wunderschönen GPAs von Kollege Schienenbus.

Und zwar scheint es nur die GPA über 100km/h, also die die einen 2000er Magneten enthalten zu betreffen.

Ich hab einen GPA im korrekten Abstand (485m) vor einen vor einem LF7 eingebaut und hab in das 2. Kästchen des Flyouts laut Doku die Prüfgeschwindigkeit eingetragen.

Als ich dann in einem Szenario dann mit 105km/h mit der Fopix 218 drübergefahren bin, hat es mich hingestellt. Was mich dann veranlasst hat weiter zu testen.

Dabei fand ich heraus das es mich auch mit 10 km/h an diesem GPA schon hinstellt. Daraufhin habe ich mal eine 80 in das erste Kästchen eingetragen. Siehe da, bei 10 km/h konnte ich dann durchfahren, beim nächsten Versuch mit 90 hat es mich dann hingestellt.

Da dacht ich, 'naja hat er das falsche Kästchen in die Doku geschrieben' und habs dann nochmal mit 79 kmh Probiert. Zack schon wieder hingestellt. Mhhh sollte ja nicht passieren da im Kästchen ja 80 steht, also mal rantasten.

Nächster Versuch mit 65 = Zwangsbremsung, mit 58 = keine Zwangsbremsung! Da dachte ich dass da vielleicht ein Offset drauf ist. und hab mal 95 eingetragen, -> mit 79 durch mit 85 Zwangsbremsung. Tja aber bei den Geschwindigkeiten gibts ja den 1000er GPA also mal schneller probieren.

(ich habe aus Zeitgründen erstmal die niedrigen Geschwindigkeiten ausprobiert da mit der Wanderdüne sonst Stunden braucht bis die auf Tempo ist).

Also wieder was höheres eingetragen. Diesmal 140 kmh aber bei 140 gibts schon bei über 101 kmh Zwangsbremsungen. Also wohl doch kein Offset, zumindest kein gleichbleibendes.

Was habe ich falsch gemacht?

Wenn ich die GPA 2000 korrekt nach Doku aufstelle gibts immer eine Zwangsbremsung.

Trage ich die Prüfgeschwindigkeit ins linke Fenster ein scheint es zu Funktionieren. Allerdings nicht mit den Geschwindigkeiten die ich eintrage.

Kann es auch am benutzen Fahrzeug liegen? Kann man diese entsprechend Tunen? (Übrigens funktionieren die TSC GPA einwandfrei mit der 218)

Wahrscheinlich hat wieder niemand außer mir dieses Problem, aber vielleicht hat ja doch jemand eine Idee.

Da die anderen SBS PZB Magnete (auch die 1000er GPA) korrekt funktionieren und die SBS Dinger wirklich toll aussehen würd ich die schon gern verwenden.

Liebe Grüße vom Doctor

So wie ich das Eingangspost von CHR Train verstehe hat er eine Track Rule Verwendet die automatisch die Strippe erstellt und dann mit einem "Masten-setz-Tool" die Masten gesetzt. Das geht solange wie alles 2 Gleisig ist und keine Weichen verbaut sind gut und auch fix, nur: alle mir bekannten Setztools steigen in Weichenbereichen früher oder später mal aus da die Kriterien (Gleismittenabstand, etc) dort u.U. nicht erfüllt werden.

Ich Weichenbereichen muss man daher eigentlich immer von Hand setzen. Wenn du eine reale Strecke gebaut hast dann scheu einfach im google Overlay wo die original Masten stehen oder wenn nicht dann messe die mit dem Entfernugs/Linealtool ab. Ich denke im weichenbereich ist man mit 35 -50m Mastabstand im Bereich wo es noch gut aussieht.

Just my 5 Cent

Gruß Doc

Zitat von peterpotato

Glaube ich nicht, ich glaube derdoctor hat nicht nachvollziehen können, warum ich für Kurven(überhöhung) und "gerade" Strecke unterschiedliche Trackrules genommen habe, obwohl es mit einer geht. Ich hätte für Kurven nicht extra eine Regel basteln müssen, so verstehe ich das.

Das habe ich in der Tat nicht herausgelesen und kann es in der Tat nicht nachvollziehen für was das gut sein soll. Aber gut, manchmal liegt man halt daneben wenn man Leuten helfen will.

Genau so wie StS hab ich es auch gemeint. Korrekte Überhöhungswerte in die Trackrules einbauen, dann kannst du nach belieben im Editor die Überhöhung an oder abschalten. Eine eingeschaltete Überhöhung auf einer Geraden ist auch nicht tragisch. Ich empfehle übrigens jede Kurve am Anschlusspunkt des Übergangsbogens an die Gerade die Gleise einmal zu trennen und neu zu verschweissen. Ich denke alle anderen erfahrenen Schienenleger hier werden zustimmen.

Gruß Doc

Wieso eine mit und eine ohne Kurvenüberhöhung??? Das kannst du doch individuell beim Gleisverlegen einstellen.

Entweder du machst den Haken bei Gleisüberhöhung rein oder nicht. Eine extra Trackrule brauchts dafür nicht.

Gruß Doc