Fehler bei Bereichsprüfung: CMO.CalculateAmpeln

Welcome to the OMSI-WebDisk!
As guest you can only see content in your selected language! Registered users can choose the visibility of other languages in their control panel, more informations here. All topics are marked with a language flag inside the forums: = English [EN], = German [DE], = French [FR].
If you're not able to speak the topic language than write in English!
  • Hallo,

    beim Erstellen von Kreuzungen mit dem ObjectEditor erhalte ich bei Ampelgesteuerten Fußgängerübergängen (mit Anforderung) einen Fehler bei bereichsprüfung und keine Ampel auf der Map funktioniert mehr, sobald eine solche Ampel geladen ist.

    Hier mal eine Beispielampel auf einer Testmap:

    Pfad der Anforderung ist der Fußgängerpfad, der über die Straße führt.




    Hatte evtl. schonmal einer dieses Problem und/oder kann mir helfen?


    LG Niklas

    Aktuell: Projekt Dreiländereck: Map & Repaints aus dem Großraum Basel


  • Advertisement
  • Du musst bei der Anforderung auch sagen, wo das ganze hinspringen soll.
    Egal, ob du nun den Haken bei Jump IF oder Jump if NO Approach drin hast, OMSI muss ja wissen, wo die Ampel dann hinspringen soll :)


    Tendenziell müsstest du einstellen:
    Stop/Jump position on time: 1 sek

    Check Approach on TL Nr: 1 (da hier die Ampel eingetragen werden soll, bei welcher die Anforderung ist, hier People)

    Stop/Jump if NO Approach: Haken rein: Soll ja nur zurückspringen, wenn keine Anforderung da ist

    Jump to time: 0 (da ja die Ampel von 1 auf 0 zurückspringen soll, wenn keine Anforderung da ist.

  • beedle der barde Dann kläre mich bitte auf, man lernt ja nie aus :D

    Wenn ich eine Anforderung habe, dann muss diese doch auch irgendetwas bewirken, oder? Also müsste diese bewirken, dass die Ampelphase von Punkt a zu Punkt b springt oder eben nicht. Und genau dies tut sie hier doch nicht?
    Das die Zahl bei "Check Approach on TL Nr." falsch ist, war mir erst aufn zweiten Blick aufgefallen, muss ich zugeben. Hatte ich dann weiter unten auch geschrieben :)

  • Hatte ich dann weiter unten auch geschrieben

    Hatte ich gar nicht gesehen.

    Check Approach on TL Nr: 2

    Dennoch muss es TL NR: 1 sein, da OMSI ja bei 0 anfängt zu zählen.;)

    Dann kläre mich bitte auf, man lernt ja nie aus

    Dort wo er das Häckchen aktiviert hat steht ja Stopt/Jump. Entsprechend hat er die Möglichkeit, die Phase zu stoppen, bzw. zu pausieren oder eben einen Teil zu überspringen. In seinem Falle ist es nun so, dass die Ampelphase bei Sekunde eins gestoppt wird. Erst wenn sich im angegebenen Annäherungsbereich (approachdist) etwas befindet, wird die Phase fortgesetzt. Was in seinem Fall durchaus Sinn ergibt, denn die Fussgänger sollen ja nur grün kriegen, wenn da jemand steht.

    Ich hoffe, ich konnte das einigermassen sinnvoll in Worte fassen.^^

  • Dennoch muss es TL NR: 1 sein, da OMSI ja bei 0 anfängt zu zählen.

    Ok, da hab ich echt nicht nachgedacht, ups :D

    Dort wo er das Häckchen aktiviert hat steht ja Stopt/Jump. Entsprechend hat er die Möglichkeit, die Phase zu stoppen, bzw. zu pausieren oder eben einen Teil zu überspringen. In seinem Falle ist es nun so, dass die Ampelphase bei einer Sekunde gestoppt wird. Erst wenn sich im angegebenen Annäherungsbereich (approachdist) etwas befindet, wird die Phase fortgesetzt, was in seinem Fall durchaus Sinn ergibt, denn die Fussgänger sollen ja nur grün kriegen, wenn da jemand steht.

    Ich hoffe, ich konnte das einigermassen sinnvoll in Worte fassen.

    Ok, hast recht. Das wäre ne andere Herangehensweise, welche ich bei meinen Ampelschaltungen noch nie in Betracht gezogen habe. Sollte eine Ampelphase, wie hier, erst durchlaufen, wenn auch eine Anforderung da ist, habe ich die Phase sich immer nach 1 sek wiederholen lassen und erst bei einer Anforderung durchlaufen lassen.
    Danke für den Denkansatz :)

  • Stop/Jump if NO Approach: Haken rein: Soll ja nur zurückspringen, wenn keine Anforderung da ist

    wie beedle der barde geschrieben hat, ich habe mich an dem "else: pause" orientiert


    Das mit der TL. Nr. hab ich wohl falsch verstanden, wird ausgebessert, ich werde Zeitnah berichten!

    Danke schonmal für die Hilfe!


    EDIT: Die Ampeln laufen wieder und die LogFile wird nichtmehr vollgespamt, es lag also an der TL.Nr. .

    LG Niklas

    Aktuell: Projekt Dreiländereck: Map & Repaints aus dem Großraum Basel


    Edited once, last by der_Nik_ ().

  • Sehr interessanter Beitrag, den ich gerade gefunden habe.

    Das Problem tritt ja bekanntermassen auch auf ALU im Bereich Heide Mitte auf.

    Wie kann man nun herausfinden, welche Ampel dort diese Probleme bereitet?


    mfg

    Daniel

  • Kann ich dir nicht sagen. Ich wusste ja schlussendlich, wo der Fehler lag und hab dann alle eigenen Kreuzungen entsprechend bearbeiten. Evtl. mal den Betroffenen Bereich auf Anforderungsampeln untersuchen.

    Aktuell: Projekt Dreiländereck: Map & Repaints aus dem Großraum Basel


  • Ha...

    Habs gefunden :)


    Sceneryobjects\DavidM2412 - Objekte\Kreuz_Ahlheim_Laurenzbach\105.sco



    Simple...wenn man es weiss :)


    Danke an @beedle der barde und @Schleswig-Holstein


    mfg

    Daniel