Beiträge von Maik Goltz

Tjoa, vll mal die Zeit für die Anleitung in Zukunft von der Entwicklungszeit des Fahrzeuges abzweigen. Geht ja nichts über ein stilvolles Handbuch wenn das Fahrzeug Funktionslos ist.

Eh ja, das haben Vannipopo richtig erkannt. Das war so. Aber nur weil Maikipopo die Handbremse vergessen hatte wieder einzubauen. Sonst wäre diese auch in V1 schon drin gewesen und mit # bedienbar. Aber auch dann wäre sie nicht im Handbuch erwähnt worden, also die Tastenkombi, weil es eine Standardtaste ist.

Die Taste # (auf der englischen Tasta das / ) ist seit jeher Standard für die Handbremse im TS.

EDIT: du kannst die Handbremse sogar im F3/F4 Pult in der Kupplungsansicht bedienen.

Norbert dreht seine Meinungen alle 5min um 180° um. Das macht es ja so schwer seine Aussagen zu verstehen und seine Texte zu interpretieren. Hier fehlen Fußnoten mit Gradangaben und Semalinks zu anderen Texten damit man den Inhalt überhaupt versteht.

Nix für Ungut Norbert aber les dir mal deine Texte selber durch, dann versteht du vll auch die Verwirrung die manche mit deinen Aussagen haben.

Dass es noch riesige Lücken um Wagenpark gibt ist unbestritten. Aber die fallen ja nicht vom Himmel. Und es ist um so schwerer die Wagen zu bauen wenn man jedes Detail angemosert bekommt. Da überlegt man eben drei mal ob man nun diesen und jenen Wagen, für den man nur marginale Infos finden kann, überhaupt baut.

Zitat von Andi_M

Das liegt daran, dass im Editor keine Scripts gestartet werden, egal ob das jetzt Signale oder Loks. Es betrifft alles. ...

Nicht ganz. Es starten nicht alle Teile eines Scripts (in IsPlayer und IsEngingeWithKey gekapselte Abläufe zB nicht, weil die beiden Variablen keine Werte im Editor oder FreeRoam haben). Siehe vR Güterwagen mit Schlussscheiben. Das funktioniert auch im Editor. Lampen mit Schatten, wie die Panto-Lichter am Taurus, kann man mit geschicktem Coding auch da abschalten im Editor.

Zitat von Barrett

Das ist auch korrekt so, schließlich laufen da auch bei abgestelltem Fahrdiesel irgendwelche Verbraucher und nuckeln an der Batterie. Dann wird erst mehr geladen, und dann irgendwann nur noch die Ladung erhalten.

Die Batterie wird in der Lok aber gar nicht simuliert. Das ist nur ein Zeiger der halt hochspringt wenn man startet, mehr nicht.

Wenn der Kühlkreislauf ordentlich arbeitet warscheinlich bis der Bölkstoff alle ist oder der Dreck ausm Tank angesaugt wird.

Die Temperaturanzeige der Lok im TS ist eigentlich ein Abfallprodukt der automatischen Lüftersteuerung. Es bedarf eines Wertes der die drei Lüfter ein und ausschaltet wenns nötig wird. Die ist eben die Wassertemperatur. Der TS kennt keine Wassertemperaturen, so wie er vieles ander auch nicht kennt. Man muss es also simulieren irgendwie. Ich kenne mich in Thermodynamik nicht aus und weis nicht wie man sowas richtig berechnet. Die Temperatur läuft einfach hoch wenn man aufschaltet und zwar umso schneller je mehr RPM anliegen. Ist man im Leeflauf fällt sie langsam wieder. Das ist "alles" was da passiert. Das allein war schon kompliziert genug zu simulieren.

Denke bitte daran dass dies keine Expert-Line ist und deshalb auch diverse Gimmicks fehlen. Das ist deswegen so, da der TS mit Dieselloks nicht das ermöglicht was man mit Eloks machen kann.

Ne, eigentlich die 0.8 und 1.5 was ja eher so um 0.30 rum sein müsste. Ich wollte die Bremseinsatzpunkte unter 4000m halten was nur mit den Werten geht. Mag sein dass ich da falsch ansetze aber so empfand ich das Erkennungsverhalten besser angepasst weil sonst bei ständig neu erkannten Tafeln auch die Vsoll umherhüpfen tut und nicht nur die Zielentfernungsanzeige. Das lässt sich aber jederzeit ändert und theoretisch auch an die Zugmasse koppeln. Aber im TS hat das Bremsverhalten dann kaum auswirkung auf die Bremswege. In den Rilt steht dass 0.8 für den Komfort ausreichend sind. Und auch das Buch was ich hier über Fahrdynamik habe sagt sowas aus. Bei den ICE sind die Kurven sehr flach weil die eben auch viel schneller fahren. Ich muss nochmal in die Ril der 103 in den Angang zur LZB70 schauen, da standen die Werte für die 103 wohl so drin. Ich gebe aber auch gern zu dass ich nicht so der Mathematiker bin und froh bin diese Formel so zu haben ohne genau zu verstehen was die da macht

Bremskurve ist starr und wie folgt berechnet:

lzb.vSollSpeed = math.sqrt(((targetVsollSpeedlimit * 0.28) ^2) + (0.8 * (lzb.targetDistance - 20))) * 3.6;

vSollSpeed ist das was an der Tafel erreicht werden muss und als Führungsgröße angezeigt wird, also 0-200
targetVsollSpeedlimit = ist der feste Wert der Tafel in m/s
targetDistance = natürlich der Abstand von Lok zur Tafel in meter -20m als karenz um bissel luft vor dem ziel zu haben

Die Zwangsbremskurve wird genauso berechnet aber ohne -20m und mit 1.5m/s² Verzögerung statt 0.8m/s²

Wie man an der Verzögerung sieht ist das alles etwas stammer als in dem Diagramm von Frank. Das ist für den TS besser zu handlen als wenn man die seichten Kurven nimmt. Man kommt ja gut zum stehen damit, und RSC machts genauso.

Auf dem Screen erkennt man gar nix relevantes, nicht mal auf 42"... davon ab ist das auch egal jetzt. Zielstellung ist bekannt und nun muss man das Ziel nur noch erreichen.

In Wirklichkeit ist die Stelle aber nicht so eng beschildert. Das macht da irgendwie wenig Sinn, denn egal wie man da fährt, man landet bei den 110 und da sind die 160 und 140 einfach überflüssig beschildert da sie unterhalb der Bremskurve liegen.

Mit "springen" meine ich etwas anderes, und ich bin mir sicher das damals schon gesagt zu haben. Nämlich die "Weitsichtigkeit" ist hier das Problem. Bei der RSC LZB werden ständig Hp0 erkannt die über 7000m weg liegen und irrelevant sind, aber dennoch meist nur sehr kurz in der Anzeige auftauchen und mit der Schnarre teilweise auch angekündigt werden, um dann kurz darauf durch die Preparierung auf Hp1 zu springen. Hier wird einfach nicht weit genug vorprepariert. Da sollte aber dann eigentlich nichts passieren da die Signale ausserhalb der Sichtweite liegen. Erst wenn diese unter 7000m rutschen werden die relevant für die Ankündigung im MFA. Und wenn relevante Tafeln davor stehen, wird das Signal noch irrelevanter in der Entfernung und ich ging in der SItuation dann mit <4000m ran, da eh nur Hp0 interessant ist. Zumindest bei der 103. Die LZB Quakt also oft sehr sinnlos rum obwohl da gar nichts ist.

Ja, dieses Ausschlussverfahren funktioniert aber nur mit der aus meiner sicht unperformanten extra Schleife. Da können in den 9900m gern 50 Tafeln stehen, es werden alle erfasst aber die dann auszuwerten ist die Krux. Ich habe aber grad eine andere Idee gehabt. Ich werde die Sollbremskurve als Stützgröße ab 4000m vorausprojezieren (natürlich rein mathematisch und logisch) und dann hintenan die ganzen Tafeln und Signale in der Schleife auf diese Kurve setzen und alles was oben drüber landet fliegt weg und alles darunter wird ausgewertet und dann priorisiert. So ähnlich macht RSC das auch, aber die haben da noch ganz andere Merkwürdigkeiten drin die ich nicht einbauen möchte. Dann dürfte das problem der sich "versteckenden" Reduzierungen weg sein, aber ob das performant ist ist sehr fraglich. Das Script in der 103 hat einen Benchmark eingebaut. In dem Teste ich wie die Interframezeit und die Scriptlaufzeit im Verhältnis stehen. Der Wasserstand ist teilweise bei 70%. Das bedeutet, wenn da jetzt noch komplexe Mehrfachdurchläufe reingebaut werden, dann kommen wir eventuell über 100% und dann hält das Script den TS auf und die Framerate sinkt oder es stottert. Da lag schon immer meine Befürchtung und allmählich kommen wir da auch ran mit all dem Krimskram in den Loks.

Ich werde die Sache die nächsten Tage mit der RSC Methode versuchen (was bedeutet: rumprobieren und rumstochern). Aber aus Programmierersicht finde ich das eine unschöne Lösung. Nur anders wirds nicht gehen bei diesem Wirrwar an Geschwindigkeitsveränderungen im Gleis. Eine richtige LZB auf einer neuen Strecke mit ordentlichen Blockstellen wäre einfacher zu bauen. Aber das nutzt mir leider gar nichts, weil die blöde Lok ja auf den RSC Strecken funktionieren muss. Und 2 LZB Systeme werde ich kaum entwickeln wollen.

Ja Norbert, da hat der Vanni recht. Du hast es nicht erfasst. Die Loks funktionieren total unterschiedlich in der LZB. Dass der Zielentfernungsanzeiger zB separat läuft, um die nächste höhere Geschwindigkeit vorbildgerecht anzuzeigen, was der in der RSC Lok nicht tut. Leider hat das einen Nebeneffekt, nämlich dass der ständig rumspringt wenn im Gleis lauter unnütze Geschwindigkeitsbereiche aufgelegt sind, obwohl sich keine Geschwindigkeit ändert. Ausserdem funzt meine LZB auch im anderen Fst Aber spass macht der ganze Mist nicht. Weils einfach falsch ist was die da machen oder wie die das angegangen sind. Abrücken werden die aber davon nicht mehr. Alle Strecken mit LZB von denen werden so funktionieren. Da kann ich nicht wo anders lang entwickeln.

Hab grad mal etwas verändert um zu sehen ob das dann klappt (ich hab den Stack erweitert und erfasse mehr SRs) aber das bringt gar nichts. Diese Stelle da vor Lüneburg ist grandios und defintiv nicht vorbildgerecht. von 200 auf 160-140-110 innerhalb von 957m. Da würde man bei der echten Bahn doch nur die 110 stellen. Die haben das da einfach zu eng zusammengerückt. Dazwischen sind noch zig Gleisgeschwindigkeiten die dann den Erkennungsprozess ohne extra Schleife erschöpfen. Ich hau die LZB weg und bau ne neue. Das verzögert die 120 weiter, weil das einer der Hauptgründe ist warum die nicht fertig wird.

Zitat von FraPre

Es wundert einen zwar hier und da mal etwas, wie z.B. das PZB - Thema I60R / I80, aber gut.

Diese Sätze sind es die mich quer tangieren. Das soll jetzt kein Vorwurf sein. Aber das klingt immer so abstrakt und polemisch. Ich les in dem Satz zwar dass da irgendwas ist mit den beiden Systemen, aber nicht was nun, nicht mal grob. Wie soll man Fehler beseitigen, wenn man erstens nicht weis wie es in natura wirklich genau funktioniert oder was verbaut wurde (was ich eben nicht immer weis) und zweitens man nur so Brocken als Erklärung hingeworfen bekommt. Wenn du es genau weist, dann erläutere es doch bitte einfach in kurzen Sätzen. Dann kann man schauen ob man das angeht oder lieber nicht weils vll im TS zu aufwändig wird oder gar nicht geht. Aber letztlich isses oft so, dass von den Wissenden nur spitze Bemerkungen kommen und die Unwissenden im Unwissen gelassen werden. Klar, keiner ist gezwungen Infos zu verteilen, aber es wäre zumindest auch ein Selbstnutzen dabei wenn man als echter Eisebahner und Wissender diese "Simulation spielt". Leider bisher stets negative Erfahrungen was das angeht. Ich weis eben nicht alles, das hab ich auch nie gesagt. Und bei Sachen wie speziellen Abläufen, die man allenfalls mal in nem Video sieht aber sonst keinerleier akurate Infos ranbekommt, da ist das Latein dann eben am Ende. Ich versuche dann das was ich weis umzusetzen damit man überhaupt was hat. Bei der LZB geh ich sicher den falschen Weg, aber einen anderen hab ich grad nicht. Das geb ich auch gern zu. Wenn jemand weis wie man eine LZB mit den Boardmitteln des TS ordentlich abbilden kann (in einem Modul), auch gern nur theoretisch mit entsprechenden Berechnungsgrundlagen und Formeln, dann bitte preisgeben. Aber bitte nicht sagen "mach es doch wie RSC oder HRQ" oder "ihr verlangt doch Geld dann macht mal schön selbst". Das hilft keinem weiter.

@Frank, dass es bei der echten Bahn funktioniert (zumeist) ist ja durchaus bekannt. Aber im TS ist keine echte Bahn. Mir ist bewusst dass deine Auflistung dem Prelli nur zeigen soll, dass die Geschwindigkeiten auf der RSC Strecke möglicherweise realsitisch sind, aber das bringt jetzt auch nichts weiter für die LZB Simulation. Setz dich in die 103, schalte die Debugausgaben an, lese und erkenne ein Muster, teile die Lösung bitte mit.

Edit:
Ein paar infos über das was die 4 Meldungen der Debugausgabe anzeigen

- "nextSR" = nächste (erste) erkannte Geschwindigkeitsveringerung
.... typ -1 = nix in 9900m | typ 1 = Gleisgewindigkeitsänderung | typ 2 = Lf Tafel | typ 3 = unbekannt | typ 0 = EOT

- "afterNextSR" und "afterNextSR nn" sind die beiden darauf folgenden Geschwindigkeitsverringerungen die gefunden werden. Dabei gilt: ist afterNextSR vom typ 2 dann suche afterNext nn (+25m von afterNext) <- die typische irre Bausituation im TS (erst gleis dann tafel) soll hier ausgemerzt werden

- nextSig = das nächste gefundene Signal mit restrikiver Signalisierung (Hp1 wird ignoriert)
.... typ -1 = nix in 9900m | typ 1 = Signal gefunden dass kein Hp1 zeigt | typ 0 = EOT
.... bAspect = Signalbild -> 2 = Hp0 (was anderes wird hier nicht ausgewertet)
.... pAspect = ProMap signalbild <- von RSC undokumentiert verwendete IDs auf den LZB Strecken (hier wird irgendwas gesteuert in der LZB was ich nicht weis)

- currSpeed = was grad unterm Rad anliegt in m/s
... TrackLim = Gleisgeschwindigkeit | SigLim = Linkgeschwindigkeit bei Fahrt von L1 nach Lx eines Signals
(während der Fahrt in einem Link ist keinerlei Erkennung möglich!! <- ist der link zu lang dauert es ewig bis die LZB neue Daten bekommt)

.. distTo = Weg in Metern zum erkannten Objekt
.. Lim = erkannte Geschwindigkeit am erkannten Objekt

Das ist kein Fehler in der LZB von RSC sondern ein Umstand, den die Verwendung von Signalen und Tafeln (inkl. aller Geschwindigkeitsbeschränkungen am Gleis) für ein LZB System mit sich bringt. Hier stehen 4 Reduzierungen direkt hintereinander. Für eine ordentliche Abarbeitung muss man, und so macht es RSC wohl, in jedem Frame, und somit in jedem Update Schleifendurchlauf, eine Repeat Until Schleife mit einbauen die alles abgrast was in 9900m so rumsteht und auswertet. Ich mache das nicht so, weil ich das für Verschwendung an Performance halte (bisher) und es auch gar nicht nötig wäre wenn alles richtig gebaut wäre. Es funktioniert auch mit meiner Methode die da ein Stack aus 3 Restriktionsabfragen in Fahrtrichtung und einer Signalabfrage besteht, die dann jeden Frame gegeneinander ausgewertet werden. So habe ich aber nur 4 Aufrufe dieser komplexen Funktion innerhalb eines Updatedurchgangs. Für eine normale LZB bräuchte man nicht mal so einen Stack. Eine Signal- und eine Gleisabfrage würden reichen, wenn man die Strecke entsprechend mit einem separaten Signalsystem (LZB Blöcke) ausstatten würde, was auch geht wenn man es möchte. Daher kommt der vermeintliche Fehler weil meine LZB nicht weiter als 3 Schilder schaut. Die 110 sind aber das 4. Schild und das wird dann ignoriert und erst erkannt wenn das 1. durch ist. Die Beschilderung da macht eben keinen Sinn. Die stehen viel zu eng zusammen. Soweit ich weis kommt das nur einmal auf der Strecke vor und wird deshalb von mir einfach mal ignoriert.

Jetzt muss ich doch mal was losewerden wenn ich das hier wieder lese. Das richtet sich an die echten Eisenbahner (also Tf etc.). Warum kommt ihr immer mit solch abwertenden Bemerkungen daher, die sich lesen als würdet ihr da grad in der Stammtischrunde der DB-Kantine sitzen und euch totlachen über den "Simulatoren Mist" und was da so als "Funktion" herbeigezaubert wird. Zumindest hat man den Eindruck sehr oft. Ich meine dieses Gerede ala "ja nett aber total falsch und voll daneben...". Warum nicht lieber erklären wie es richtig ist, aber bitte so, dass man es auch erfassen kann und nicht davon ausgehen, dass das Gegenüber es schon weis und nur hingewiesen werden muss. Klar, wer täglich auf der Lok sitzt der lacht über den Kram hier nur müde. Aber hilfreich ist das nicht. Helfen kann nur vernünftiges Erklären um diese Missstände aus dem Weg zu räumen oder ganz zu lassen, weil der TS es vll gar nicht hergibt. Ich sitze hier oft und saug mir den Kram aus den Fingern, weil die Dokumente die man als nicht Eisenbahner allenfalls bekommt, sehr dünn bestückt sind mit Information (aus guten Gründen, das weis ich auch). Und natürlich tut der TS sein übriges dazu um die Sachen einzuschränken wo es nur geht. Dass in der 103 keine PZB90 in dem Sinne drin ist weis ich auch. Es ist eine I80 System PZB 90 die wohl leicht abweichend funktioniert, vor allem bei den Leuchtmeldern. Dazu darf ich sagen, dass die Zeit fehlt hier die verschiedenen PZB Systeme abzubilden. Das würde den Entwicklungsaufwand dermaßen strecken, dass es nicht mehr lohnt. Sicher ein Grund warum vizzart keine PZB einbauen möchte in ihre Fahrzeuge. Eine rein wirtschaftliche Entscheidung. Warum sieht man auch oft genug hier. Man versucht als Hersteller die Systeme zumindest abzubilden, aber bekommt dann von den Eisenbahnern nur eins aufs Dach weil wat nicht stimmt. Das macht echt keinen Spass. Klar, der Kram ist kein Zusi von Carsten Hölscher, aber das soll und kann es auch nicht werden. Da sollte man echt mal die Kirche im Dorf lassen. Mit 20 mann Teams kann man sowas vll betreiben, aber dann sollte sich keiner über AddOn Preise von 50€ wundern. Ihr kricht hier ne PZB und LZB, die zumindest halbwegs vorbildnah arbeiten, für'n Appel und ein Ei, eigentlich als zusätzliche kostenfreie Gimmicks, wenn man es auf wirtschaftliche Ebene runterbricht (weil immenser zusätzlicher Zeitaufwand). Also was soll der Humbug mit der kleinlichen Meckerei immer. "Perfekte" Eisenbahnsimulation gibts vor der Haustüre am nächsten Bahnhof. Wir spielen hier alle nur mit Eisenbahn und viel mehr geht auch gar nicht zu Hause am PC.

So, und nun wird wieder gefetzt weil ich sowas ja nicht anmerken darf als Element eines Herstellers. Mir aber wie immer egal. Meine Meinung verändert sich nicht dazu. Dass wir/ich auf die gesagten Dinge eingehe/n, wenn auch oft stillschweigend, dürfte reichlich bewiesen sein.

Hab das nur eingebaut weil es eben von Sebastian "eingefordert" wurde und ich nix weiter dazu finden konnte UND weils simpel einzubauen war ohne sich zu verbiegen. Das was es wirklich macht kann man nicht integrieren, bzw weis ich es nicht mal genau weil sich die Ril's dazu doch eher ausschweigen. Solche Infos gelangen immer erst nach dem Bau zu mir und da isses zu spät. Sowas findet also allenfalls in das nächste Fahrzeug mit PZB (und der nötigen Entwicklungszeit).