Beiträge von Maik Goltz

Zitat von Harzi

aber so wie ich den TF aus Berlin verstanden habe, verzögert der Triebwagen überhaut nicht automatisch, wenn man Vsoll runtersetzt, sondern nur über FBrV. Oder habe ich das wieder falsch verstanden??!!!

Keine Ahnung. Ich hab mich nie darum bemüht zu wissen wie ein 481 fährt. Fand die Dinger schon hässlich seit der erste hier rumgefahren ist. Glaub das war 1997 oder so. Der hat ja nen Kombihebel. Das wird sein wie bei der einen UBahn Bausreihe, da gibts du eben eine Vmax mitm einen Hebel vor und mit dem Fahrschalter Fährt und Bremst man halt, aber und das ist dann der Punkt, es beschleunigt nur so weit wie eingestellt. Macht was sicher einfacher wenn man wie auf der Stadtbahn nur 60 fahren darf. Einfach auf 60 gestellt und Fahrschalten nach vorn und gut. Bei dem Hin und Her mit dern kurzen Halten wird das sicher auch anstrengend sein sich ständig auf die gefahrene Geschwindigkeit zu konzentrieren.

Edit: grad nochmal nachgelesen. Also man stellt eben Vsoll ein, sogar stufenlos machbar, Anzeige über Roten Pinnockel im Tacho, und der Fahrschalter kennt nur eine Stellung für Beschleunigen, nämlich "Fahren". Den Rest regelt die Elektronik. gebremst wird nur mit dem Fahrschalter. Wie viele Bremshebelstellungen das Ding hat und ob und wann eine pneumatische Bremse da reingreift konnte ich auch nicht rauslesen. Schätze mal der hat nur einen Haltebremse, der rest ist rein elekrtisch. Da ist auch klar warum die Teile so ruppig fahren. Bequem ist das ja nicht gerade damit zu fahren, vor allem wenn die voll sind.

Das mit der Weile haben ist aber das Problem. Ich kann mich nicht Monatelang mit der LZB beschäftigen um vll rauszufinden dass es doch nicht geht. Das kann man machen wenn man sich 3 Jahre Freizeit genommen hat um ein Fahrzeug zu bauen und die Lebensunterhaltungskonten gut gefüllt sind. Ich werde mit Schuster abklappern was da wirklich geht und dann entscheide ich ob ich das versuche oder nicht. Die Inkompatibilität mit Muc-Aug und vll kommenden RSC Strecken ist auch nicht ganz so wegzuwischen. Momentan haben wir die Situation dass es nur eine Strecke bereits gibt, und eine weitere nicht RSC Strecke noch ausgestattet werden könnte (aber nachträglich nach Release). Also eine 1zu1 Abwägung. Was aber wenn RSC in den kommenden 12 Monaten dann 5 weitere LZB Strecken auf den Markt wirft (ich glaubs ja nicht aber man weis nie bei den Herren da drüben). Dann stehen wir da mit unserer eigenen LZB. Das gilt es leider noch zu berücksichtigen.

Für einheitlichen Scriptaufbau ist es zu spät. Das ist einfach ein Fakt. Eine Vereinheitlichung würde immens Zeit und Geld kosten.

Zitat:

(18) Erkennen Sie, dass die Bremswirkung der von der AFB eingeleiteten Bremsung nicht ausreicht, müssen Sie die Bremsung rechtzeitig manueell korrigieren. Sie können jederzeit in Bremsungen der AFB eingreifen. Falls Sie jedoch in eine AFB-Bremsung manuell mit dem Führerbremsventil und/oder dem E-Bremssteller eingegriffen haben, müssen Sie diese Bremsung auch manuell zu Ende führen.

(25) Fahren Sie bei LZB-geführten Zügen mit wirksamer AFB auf einen LZB-Halt zu, müssen Sie die Bremsung bei Geschwindigkeiten kleiner 60km/h manuell mit dem Führerbremsventil ausführen.

--------------
Nur ein Paar der Anweisungen bei AFB Benutzung. Gebremst in den Stillstand wird immer Manuell mit dem FBrV und nicht mit der AFB.

Dann vll doch ma mit den 1200t probieren Das dürfte aussagekräftiger sein. Die Blechkisten schieben ganz schön nach wenn die voll sind. Hab extra die Bremsleistung etwas reduziert damit man das Gefühl bekommt da schiebt wer nach.

Nichts ist schlimmer als Knöppe die da sind aber nichts bewirken in einer Simulation. Dann lieber ganz weglassen. Aber PZB ist ja auch nicht das schlimme sondern die LZB. Aber ich bin da an was dran, habe was gefunden wie man die LZB vll doch von den anderen Signalen entkoppeln kann. Aber das ist dann definitiv inkompatibel zur RSC Variante. Würde aber, wenns denn geht, genauer funktionieren und auch im Mischbetrieb. Aber bisher alles Spekulation. Viele Tests und viele viele Tage/Wochen Arbeit werden ins Land gehen dafür.

Es geht nicht um die Abstellgleise. Es geht darum, ob ein auffahrender Zug aus dem Einfahrgleis bei Zwangsbremsung in eine Rangierfahrt rammeln würde oder nicht. Das sollte möglichts so nicht sein sonst wäre der Durchrutschweg eben zu kurz.

Mach dir 15 ran und beladen sie einfach im Editor schon. Das dürften um die 1200t sein. Das ist zwar für eine 111er nix aber es geht ja um Bremswege und nicht um Beschleunigung. Und bitte mit 80 bei der Tonnage. Sonst halt 6-7 Dostos und dann eben mit 84 übern 500er. da sollte maßgebend sein.

Edit: ach dat is doch auch falsch mit 80 und 1200t natürlich nicht. Da dann doch eher nur 70 oder gar 55. Denn du würdest schon vor dem 500er zwangsgebremst weil die Bremskurve überschritten wäre in U oder M. Also lieber mit den Dostos versuchen.

Test doch mal den Durchrutschweg an der Stelle ob eine Rangierfahrt über die Weiche überhaupt rechnerisch drin wäre. Nimmr dir mal die 111er, bastel dir nen schönen Zug hinten dran, also Masse, und dann fährste mit Streckengeschwindigkeit und PZB on auf das Hp0 zu. Das ist also Test1, Zwangsbremsung am 1000er. Danach den selben Zug, auch wieder Hp0, aber am Vorsignal bestätigen und runter auf 84, aber dann rollen lassen mit 84 und über den scharfen 500er drüber. Der Weg den du über das Signal rutschst ist ja der Durchrutschweg, noch bissel Luft geben weil man ja nicht Puffer küssen muss wenns mal passiert, und dann siehst du wie weit das noch von der Weiche weg ist. Ich würde aber sagen das wird nix. Da rutschts du definitiv in den Gefahrenbereich rein. Also das ESig nach hinten bauen um den Sicherheitswert den du ermittelt hast + die Rangierwege und dann passt das.

Für die ohne Verstand ist ein Ra10 aber schon hilfreich Grenzen sind ja dehnbar. Ein Ra10 steht fest. Und die Rangeirfahrt auf das Ausfahrgleis geht aber nicht wenn zB eine Lok auf dem gezeigten Gleis vom Zug muss. Die muss zwangsweise auf das Einfahrgleis raus um dann umsetzen zu können oder sonst wo hin zu fahren. Es ist also doch eher ein konzeptionelles Problem im Gleisplan. Warscheinlich würde man es so nicht bauen wenn Lok abgezogen werden müssen. Ich bin aber kein Bahner und reime mir das auch nur aus der gegebenen Logik zusammen. Ich baue lieber nach Vorbild, da steht der ganze Mist schon da und man muss nur nachbauen

Tja, dei Problematik der Fantasiestrecken. Würde die DB jemals so eine Einfahrt bauen lassen wenn dort Rangierbewegungen mit mehr als nur einer Lok stattfinden? Ich denke nicht. Wenn nur Loks rangiert werden dann setzt du einen Zwerg vor die da kommende Weiche und so 2 Loklängen in Richtung ESig eine Ra10. Das ist zwar bissel eng aber das kommt eben drauf an wie schnell dort gefahren werden darf. Bei 160 am ESig würde ich das nicht machen weil der Durchrutschweg zu kurz ist. Aber das ist eben alles nur würde/wenn und nicht Vorbild nachgebildet.

Ich habe gerade, angetrieben von dieser Diskussion, nochmal die beiden Scriptfunktionen die RSC für die LZB "erfunden" hat versucht zu ergründen. Die Rückgabewerte sind recht eindeutig, aber das was man damit anfangen kann ist wenig sinnvoll. Dazu bin ich absichtlich auf einer normalen, vernünftig signalisierten Strecke gefahren die ich genau kenne. Die Ergebnisse sind unbrauchbar. Wenn ich da nun an Berlin-Wittenberg denke, dann sage ich hier und jetzt festlegend: Mischbetrieb ist unmöglich. Entweder man hat eine Rennstrasse die speziell für den Einsatz dieser "LZB" gebaut wurde, oder man hat keine LZB. Es gibt keinerlei Unterscheidung im Signaltyp. Es wird jedes restriktive Signal das zuerst kommt erkannt und gemeldet, eines dahinter aber nicht. Um das mal leicht deutlich zu machen:

Signal Abfrage (nur Signale die einschränkend Anzeigen werden gemeldet)
..erwartet: Sichtrichtung (0 oder 1), Startpunkt gesehen von Playerzug Front in Meter, Sichweite in Meter
..liefert:
- Signaltyp (der ist entweder -1 wenn kein Signal gefunden oder 1 für den Rest)
- signalAspekt (-1, 1, 2 oder 3 ... "-1" Kein Signal, "1" ist Hp2, "2" ist Hp0, "3" wär eine andere From von Hp0)
- Distanz (logischerweise die Distanz zu diesem, nächstgelegenen Signal)

Speedabfrage
..erwartet das selbe wie Signalabfrage
liefert:
- Typ (-1,1,2,3 ... "-1" nix, "1" Gleisspeed, "2" LF Speed, "3" Signal Speed
- Geschwindigkeit ... die zulässige Geschwindigkeit des Typs
- Distanz

So, nun sollte jedem versierten Menschen auffallen dass uns da etwas Sorgen macht. Nämlich dass man nicht über die Speedabfragen drüberschauen kann. Vernünftige Gleislegemethoden und ordentliche Signale aber werden leider viele kleine Änderungen hervorrufen. Und so spielt diese Angabe eben das im Taurus zu beobachtende PingPong. Es ist nicht einwandfrei feststellbar ob die Restriktion auch wirklich von Belang ist. Steht ein LF 20m vor einen einschränkenden Signal hat man ein Problem. Genauso wenn eine Gleisgeschwindigkeitsänderung davor ist. Die Funktion ist nicht in der Lage dies "auszublenden". Sie Verfängt sich daran und das macht eine vernünftige LZB unmöglich ohne die LZB Trasse komplett abzutrennen. Auf Muc-Aug geht das nur weil da kein KI Verkehr zwischen den Signalen rummacht. Lasst mal einen langsameren Zug vor einem IC fahren und schaut was euch die LZB versucht zu sagen. Da kannst du auch erst mal stehen bleiben. Das springt zwischen vielen möglichen Geschwindigkeiten umher. Das ganze im Mischbetrieb gesehen würde die LZB Funktion total unnutz machen weil man auf Signalsicht fahren müsste und die LBT genau nur dies anzeigt. Nix mit 9000m Vorschau.

Nochmal zu den Prellböchen. Ja, es geht nur um Stumpfgleise. Es passiert nur da. Das Gleisende wird einfach falsch definiert oder erkannt vom TS. Ich habe aber zB nich einen solchen Fall auf meiner gebauten Strecke. Als ich die gleichen Gleise dann mal auf einer anderen Strecke reingetauscht habe, da waren sie wieder da diese Dinger, an fast allen Stumpfgleisen mit einem Bogen irgendwo drin, also wie bei dir auch. Auch ohne Überblendungen, die übrigens enorme Probleme bereiten können wenn sie nicht funktionieren. Vorm Überblenden immer abtrennen und schweißen, ganz wichtig.

Ein Grund warum man in der Tracks.bin nicht mit anderen Tools werken sollte. Das "serzen" hinterher ist manchmal an der Stelle gefährlich. Da treten scheinbar Fehler bei Floats auf und dann wird irgendwas am Gleis minimal verschoben gerendert und das verursacht den Prellbock Versatz (und nicht nur diesen). Das passiert auch wenn man Gleismodelle einfach tauscht wenn sie schon liegen. Wenn die getauschten Modelle und XSec nicht genau auf das alte passen dann entsteht Render-Murks.

PZB ist ja bei vR vorhanden und wird auch in jedes kommende EL Fahrzeug eingebaut. Nur leider dauert die Entwicklung eines EL Fahrzeuges extrem lange wenn es nicht wie die 111er auf einem Vormodell (143) basieren kann. Die 120er kann ich nicht auf der Basis aufbauen. Die funktioniert ganz anders und so fängt man nämlich fast bei 0 an. Und eine BR128 oder Gravita funktionieren wieder ganz anders und da gehts wieder von vorn los. So Modular wie ich mir die neuen Scripte erdacht und auch angelegt habe, ist das Ganze dann leider doch nicht. Einzig Module wie eines dass die Simulationsparamter ausliest und in die Dantenbank schreibt ist wirklich wiederverwertbar. Alles sonstige ist stets neu zu erfinden. Das dauert mitunter Monate. Wer die marktüblichen Software-Entwicklungskosten kennt, weis wovon wir hier reden. Ein Standardfahrzeug von der Funktion her ist in 3 Tagen gemacht. Das Modell natürlich dauert genauso lange wie bei jeden Fahrzeug. Also 3-x Wochen. Dazu kommt dann noch der Sound der auch bei einfachen Fahrzeugen sehr komplexe Arbeiten bedeuten kann. Bei EL Fahrzeugen aber noch mehr da hier der Sound großteils auch vom Script gesteuert wird. Und so muss letztlich jeder arbeiten der sowas entwickelt. RSC hat dafür mehrere Leute die gleichzeitig an einem Fahrzeug bauen. Das geht dann eben schneller. Patrick baut alles allein, bis auf den Sound. Ulf baut nur Modelle und macht Logistik, ich bringen den Teilen das Fahren und Klingen bei. Wenn man da dann auf Unzulänglichkeiten stößt dann ist das ein Schlag ins Gesicht. Ihr müsst euch das so vorstellen wie eine Wand in die ihr Löcher bohren müsst um jeweils eine Schraube reinzudrehen. Gehen wir mal von 50 zu drehenden Schrauben aus: ihr bohrt also 50 Löcher, nach jedem gebohrtem Loch kommt der Dübel rein und die Schraube hinterher, nun seid Ihr bei Loch 47, also fast fertig, und plötzlich gehts nicht weiter weil das Loch 10mm zu kurz ist und sich dahinter eine Wnad aus Diamant befindet. So ist die Scriptarbeit im TS zu sehen. Man kommt irgendwann an einen Punkt wo es nicht weitergeht. Den Punkt kann man aber unmöglich vorher erkennen. Und so muss man dann die meisten Löcher neu ansetzen um irgendwann mal an ein Ergebnis zu kommen wie man es haben wollte, und dabei verrückt es natürlich an der Wand, was wiederum mit dem LZB Problem gleichzusetzen ist. Es wird vll eine LZB, aber nicht die die man haben wollte.

Zitat von Prelli

Vielleicht bietet sich ja die Möglichkeit, eine bereits programmierte PZB eines anderen herstellers in Lizenz zu benutzen, damit man das rad nicht 2x erfinden muss.

Das Thema hatten wir schon und es ist einfach so nicht möglich. Jede Lok funktioniert anders und jeder Entwickler baut seine Scripte anders auf. Eine unuverselles Modul das eine PZB repräsentiert ist so nicht möglich da es keine Richtlinen gibt wie ein Fahrzeug dazu aufgebaut sein muss. Meine PZB würde in der 145 nicht funktionieren ohne sie komplett umzubauen. Andersrum wird Patrick nicht sein Script komplett umbauen nur damit eine vR PZB darin läuft. Hier fehlen einfach grundlegende Prinzipien der Implementierung von externen Modulen in das Hauptprogramm. Es ist alles total schwammig. Jeder kann machen was er will und macht es auch. Es steht nirgendwo geschrieben dass man für eine PZB bestimmte Controller mit bestimmten Namen und Leuchtmelder mit bestimmten Vorraussetzungen in ein Fahrzeug einbauen muss. Da gibt es mindestens 10 verschiedene Möglichkeiten das zu tun und ein iniverselles Script für so einen Wildwuchs würde keiner entwickeln.

Zitat von dw-agency

Dann die Beschwerden über die LZB von RSC und dass man damit nicht arbeiten kann - warum entwickelt man dann nicht eine eigene LZB?

Weil es nicht geht! Weil man dazu Änderungen am Hauptprogramm vornehmen müsste. RSC hat es ja getan, aber total falsch weil sie gar nicht wissen wie eine LZB wirklich funktioniert. Wir drittentwickler können da nichts dran ändern. Hinweise dass die Sachen falsch sind und Anfragen für Änderungen werden von RSC komplett ingnoriert. Wir können also entweder versuchen die LZB Umsetzung von RSC irgendwie nachzubildern, was ohne Dokumentation eher schwer ist, oder wir lassen es eben ganz. Ich habe mich persönlich eher für letzteres entschieden. Ob das das nun RSC anlasten kann oder nicht ist mir egal. Das Schlimme ist dass die dort auf sowas erst gar nicht reagieren wenn man es anfragt. Ich warte schon seit Eiwgkeiten auf Antworten auf eigentlich simple Dinge. Aber die antworten darauf nicht. Die reagieren nur wenn es in derem Interesse liegt. Expertenfunktionen sind leider nicht in deren Interesse. Klar, weil Änderungen der Art auch für die nicht wirtschaftlich erscheinen. Dann ist es eben so. Gibts nur noch simple Fahrzeuge ohne Sonderfunktionen. Das wird auf lange Sicht sowieso das Ziel dieser Simulation. Es bewegt sich alles in Richtung Show und nicht Richtung Funktion. Von daher kann ich den Frust anderer Entwickler sehr gut verstehen. Jeden Tag versucht man die Probleme zu umschiffen die nicht da sein müssten wenn RSC sich kümmern wollen würde. Aber das kümmert da eben nicht. Und das ist das was ich denen ankreide.

EDIT: will noch was reinwerfen was hier nämlich irgendwie noch keiner von euch so richtig gemerkt hat. Ihr als Kunden verlangt von uns Entwicklern immer perfekte Fahrzeuge mit tollen Funktionen für einen niedrigen Preis, regt euch dann aber über uns Entwickler auf, wenn wir den Hersteller der Grundplattform kritisieren, weil er uns die Möglichkeiten gar nicht offenlegt die der Kunde aber wünscht. Wie soll man das nun überein bringen. Wenn ne Türklinke fehlt wird gemeckert, wenn ne PZB nich da ist wird gemeckert, wenn sie da ist wird gemeckert, wenn sie falsch funktioniert wird gemeckert, wenn ne Farbe nicht stimmt, oder ne Schriftart falsch ist oder oder oder, es wird immer nur gemeckert, aber NIE hinterfragt warum das so ist. Bleiben wir mal bei der Scripterei und dem was ich eben so mache mit den von Ulf gebauten "Fahrzeugrohlingen". Würde ich Ulf die tatsächlichen Kosten für die Programmierung, die auf dem freien Markt eben üblich sind, auf die Rechnung schreiben, wäre er warscheinlich pleite bevor auch nur eine EL das Licht der virtuellen "Welt" erblickt. Da wir alle aber keine großen Kuchen sondern kleine Brötchen backen und uns damit auch zufrieden geben, machen wir es eben dennoch. Wenn ich dann also seit Oktober versuche den Intercity EL irgendwie ans Laufen zu bekommen, und es bis heute wegen immer neuer Probleme die der Simulator selbst aufwirft, nicht geschafft habe, dann ist es doch wohl durchaus legitim die Kritik an RSC zu suchen. Oder zumindest diese mal mitzuteilen. Öffentlicher Druck ist oft gar nicht so schlecht um etwas Bewegung reinzubringen. Leider hilft das bei denen gar nicht. Und so frusten wir eben jeden Tag aufs neue und drehen die Schraueb die hinten rausfallen wieder rein. Und das demotiviert extrem. Mal davon ab dass es überhaupt nicht wirtschaftlich ist. Hier werden keine Massen verkauft, wie StS schon anmerkte. Es sind eher sogar weniger als er vermutet.

Das Forum hier ist wohl der falsche Ort für Entwickler. Aber der Kunde ist eben hier und lässt seinen Frust über die Fahrzeuge von Drittentwicklern auch aus und das oft ohne jedewede Grundlage oder auf Basis der falschen Grundlage. Dinge die das Hauptprogramm nicht richtig kann, die der Drittentwickler nicht beheben kann, werden dennoch dem Drittentwickler nachher am Produkt angekreidet. Da ist der Fehler im System der Kritiken. Kritik wird hier nicht differenziert, noch nie. Sie wird einfach ungewichtet bemängelt. Es gibt aber eben vielschichtige Arten der Kritik. Manche ist unangebracht, macnhe ist aber in der Tat wichtig und angebracht. Wer Zusammenhänge nicht erkennt sollen sich der Kritik aber enthalten. Mir wird hier zu viel spekuliert, gemutmaßt und angenommen. Wie wäre es damit die Beteiligten einfach vorher nochmal zu fragen wie es wirklich ist! Das ist auch der Grund warum ich hier stets gegenhalte. Ich versuche nicht zu mitmaßen, sondern teile Erkenntnisse mit die auf eigenen Erfahrungen mit dem ganzen Zeug basieren und möchte damit verhindern dass die Leute die Mutmaßungen als Wahrheit dahinnehmen. Das ist der Grund. Oft wird etwas gesagt dass so überhaupt nicht stimmt, aber keiner hält dagegen und sagt eben wie es wirklich ist. Den undankbaren Job tu ich aber gern. Nur lasse ich mich dafür dann auch nicht grundlos an die Wand drücken. Da wird eben dann ausgeteilt.

Viel Text wenig Nutzen...

Diese RSC LZB funktioniert so aber in meiner 120er EL nicht. Die Umrechnungen auf die ZSoll und VSoll sind so komplex dass diese Funktionsweise total aus dem Ruder läuft wenn man mit AFB fahren will. RSC hat das ganze sehr einfach gelöst. Deren AFB kennt nur 3 Leistungstustände (ZSoll) und das wars. Die in der 120 ist aber stufenllos. Und mit das eiert dann nur hin und her. Das Ergebnis was aus der Signalabfrage kommt zu mitteln ist wieder sowas von aufwändig, dass es wenig Sinn macht das zu verfolgen. Wenn die LBZ Pingpong spiel muss man versuchen das Verhalten zu smoothen und dazu muss man extrem viel zwischenspeichern und Werte vorhalten die der TS von sich aus nicht liefert. Wer das für ein Fahrzeug schon mal gemacht hat weis was ich meine. Alein schon eine weich arbeitende AFB zu bauen ist ein graus weil die VIst umherhüpft wie ein Flummi.

Die ganzen Umstäden könnte ich aus meiner Sicht so beschreiben: mit der 143 EL war das Ende des Möglichen bereits erreicht. Die 111er arbeitet ähnlich der 143 mit ein paar anderen Gimmicks. Für die 120 habe ich alles neu erfinden müssen weil die eben ganz anders funktioniert und da stoße ich regelmäßig an eine Grenze des machbaren. Das ist auch der Grund warum sich beim IC Zugverband mit Steuerwagen zur Zeit nichts tut. Es geht einfach nicht voran. Wirtschaftlich ist das schon lang nich mehr anzusehen. Aber versprochen ist versprochen...

Und wie soll der Trigger erkennen welcher Zugtyp sich ihm nähert. Also ob der Zug mit aktiver LZB fährt oder nicht. Man kann leider keine Messages vom Zug an ein Signal senden. Und die in TS verfügbaren Zugtypen sind wenig nützlich. Ich weis dass RSC das über den Zugtyp mit regelt. Aber das schränkt dann wieder die Szenariomöglichkeiten extrem ein weil der Zug mit aktiver LZB immer ein bestimmter Typ sein muss. damit kannst du ihm dann keine KI in den Weg stellen damits abwechslungsreicher wird. Etc pp.

Also mit mehreren Links eines Signals wird es wohl nicht gehen, weil man die Links nicht direkt abfragen kann aus dem Fahrzeug. Klar könnten die Links als Trigger dienen und dem Fahrzeug so stets einen Zustand melden, aber die Frage ist welchen Zustand sollen sie melden. Die Idee mit gestapelten Signalen hatte ich vor einiger Zeit schon und wir hatten auch schon darüber ansatzweise distkutiert. Die Problematik beginnt einfach an der Stelle wo ich aus dem Fahrzeug den Zustand in 10km Entfernung abfragen soll. Das geht nur mit diesem RSC Trick und der meldet gnadenlos jedes restriktive Signal und nicht etwa nur bestimmte. Wenn man dem Call irgendwie sagen könnte "frage nur signale vom Typ LZB ab" dann wäre es wohl kein Problem. Aber sowas geht nicht. Und damit ist die Sache grundsätzlich hinfällig da man hier auf Strecken mit Mischbetrieb keine praktikablen LZB Blöcke einrichten kann. Jedes Signal würde einen Block abschließen. Wenn man ganz alleine fährt ist das noch kein Problem da eben alle Signale dazwichen dann auf "grün" stehen bei denen von RSC. Bei den Signalen vom Signalteam, welche eben nicht standardmäßig alle auf grüne Welle schalten, würde so immer in 1-3km Entfernung ein Hp0 erkannt und die LZB würde einem ein Werk von Mozart oder Bach vortrellern und ne Show von BlinkenLights abhalten. Nimm mal den ICE3 und bau eine Aufgabe mit ordentlichem KI und mit den neuen Signalen auf einer Strecke wo du 200 fahren kannst/könntest. Wird nichts. Da fährst du maximal 60 vll weil die LZB keine 4km weit schauen kann. Wenn man auf Muc-Aug die Signale tauschen würde gegen welche die keine grüne Welle erzeugen, dann kannst du da auch keine 200 mehr fahren.

Benoki: denken, glauben und wissen sind leider verschiedene Dinge. Eine PZB zu prorgammieren ist sehr viel Aufwand. Wenn Patrick diesen nicht wirtschaftlich betreiben kann dann ist es eben so. Die LZB von RSC ist eben keine LZB sondern ein Trick, und HRQ hat davon nur eine eher schlecht funktionierende Variante nachgebaut. Aber genau das ist eben das was uns, uninformierten Entwicklern, letztlich zur Verfügung steht. Und das ist eine ziemlich schlechte Grundlage. Deswegen wird man in naher Zukunft wohl keine LZB Implementierung von Drittentwicklern sehen.

"Prellbock auf, Gleis" ... ja du sollst auch nicht auf den Gleisen rumlaufen

Trenn mal an dem kleinen Knick auf und schweiße wieder. Dann sollte der weg sein. Man sieht hier leider nicht genau wie es weiter geht. Ist das ein Stumpfgleis? Ist hinten dann der Prellbock dran, oder ist es eben dieser der da vorgerutscht ist? Wenn ja, gibts nix, Gleis raus und neu, möglichst einen Trackrule Cut hinter der Weiche machen.