Beiträge von Maerkertram

ma7t3 hat bereits alles wichtige gesagt.

Ich habe mehrere Rotphasen genutzt, um eine Ampel mit Räumanzeige zu bauen, die es nur in Berlin gibt.

https://www.rbb24.de/content/d….jpg.jpg/size=708x398.jpg

Nein, zu dem Fehler MAN_D92.bus schrieb ich: "Auffällig ist erstmal das hier, wobei ich da keine Lösung für parat habe."

Ein Hinweis auf Modifikation ist dies, da diese Datei nicht orginal ist:

14112 20:53:52 - - Warning: Did not find texture file "..\..\Anzeigen\TFT_Umstiegsmoeglichkeiten\Teltow Sigridshorst626.tga"!

@B3R71N K1Dz Interessant wäre, zu welcher Uhrzeit der Fehler bei Bereichsprüfung kam, die Logfile zeigt nämlich einen langen Zeitraum. Auch wäre interessant, was danach passiert (normal weiterspielen möglich oder eben nicht).

Auffällig ist erstmal das hier, wobei ich da keine Lösung für parat habe.

Zitat

184 20:39:17 - - Error: Fehler bei Bereichsprüfung: CV.Calculate - J2 (vehicles\MAN_SD202\MAN_D92.bus)

Das hier deutet darauf hin, dass die Map modifiziert wurde. Allerdings glaube ich nicht, dass diese Warnung eine Fehlermeldung auslöst.

Zitat

14112 20:53:52 - - Warning: Did not find texture file "..\..\Anzeigen\TFT_Umstiegsmoeglichkeiten\Teltow Sigridshorst626.tga"!

@eierschale

Da sind einige nicht gute Meldungen in der Logfile drin. War das Problem einmalig oder tritt es immer wieder auf? Generell als Empfehlung, möglichst mit "Karte ohne Busse laden" und dann einen Bus platzieren. Nicht laden, zwischen Karten wechseln oder mit der Zeit mehrere Spieler-Busse platzieren.

Diesen Eintrag finde ich komisch:

Zitat

298 12:56:14 - - Warning: Did not find texture file "AFR4\1\4_-2.bmp"!

Vielleicht mal spaßeshalber die "...\OMSI 2\Vehicles\BRT_C2-Solo\Texture\AFR4\1\4_2.bmp" kopieren und 4_-2.bmp nennen?

Ja, das ist normal, dass der Eintrag manchmal fehlt. Ein fehlender Eintrag wird wie 0 gewertet. [approachdist] 0 bedeutet, dass die Anforderung erst wirksam ist, wenn man schon auf dem Pfad drauf steht.

In dem Kreuzungsobjekt sollte es mehrere Pfade geben. Der erste Pfad, der hinter der gedachten Haltelinie ist, muss noch die Ampelphase zugewiesen bekommen (also Auto bzw. Bus). Zum Testen außerdem gern den unteren Wert für approachdist (also für den Bus) auf 100 erhöhen.

Manchmal warten die Leute auf einen (KI-)Bus, der nicht mehr da ist. Was hier konkret los ist, weiß ich leider nicht. Bekannt ist die Haltestelle U Kurfürstendamm jedoch dafür, dass oft weniger Leute warten als eingestellt ist, weil rund herum so viele Haltestellen mit gespawnten Fahrgästen sind. Vorstellbar wäre, dass sich die Scripte der Fußgänger deshalb mal verschlucken.

Im MAN DL aus dem X10-Addon gibt es 83 Sitzplätze und standardmäßig 18 Stehplätze = 101 Fahrgäste. Er ist aber scriptseitig auf 60 Stehplätze (143 Fahrgäste) ausgelegt.

Zum Aktivieren muss man nur in der "...\OMSI 2\Vehicles\MAN_DL05\Model\passengercabin.cfg" den letzte Eintrag "-<DISABLED>-" (Zeile 1058) löschen.

Es ist bekannt, dass sowas in seltenen Vorfällen vorkommt. Üblicherweise ist beim nächsten Spiel alles wieder normal. Woran das liegt, ist aber nicht bekannt.

Nach meiner Erfahrung (oder Einbildung, wer weiß ...) macht es einen Unterschied, wo die Vorfahrtsfestlegung beginnt. Mach das schon 50 Meter vorher, also dass auf der Hauptstraße die Vorfahrt schon vor der Kreuzung beginnt. Bei der Nebenstraße dann analog.

Zitat von wurstbrot

Wie ist das denn mit den Schaltzeiten, ich setze 2s für Gelb nach Grün und 3s für Gelb nach rot, dazwischen 2s noch als Puffer wo beide Seiten rot haben. Ich meine generell, nicht nur bei Fußgängerampeln. Da geht es mir darum was sich in OMSI bewährt hat, falls es da reale Vorgaben gibt ist das schön und gut, aber die OMSI KI ist ja schon eigen

Was mich auch noch gerade wundert und wo ich keine Dokumentation zu finde ist warum es im Ampeleditor so wie viele Zustände für Grün, rot etc gibt. Ich glaube je drei, und es steht nicht bei wo da der Unterschied ist. Gibt es irgendwo eine Liste was das dokumentiert?

Die realen Schaltzeiten funktionieren für Omsi ganz gut. Da gibt es ganze (kostenpflichtige) Regelwerke, wie Ampeln in Deutschland programmiert werden müssen. Ungesicherste Linksabbieger (also wo geradeaus und Linksabbieger gleichzeitig grün haben) brauchen in Omsi etwas länger um von der Kreuzung runter zu kommen. Faustregel für Fußgängerampel: 3s gelb, 2s rundumrot, 5s Fußgänger, 3s pro Kfz-Spur rundumrot, 1s rot-gelb.

Die vielen Zustände können von anderen Ampeln interpretiert werden. Es ist meines Wissens hard gecoded, dass grün+aus "go" heißt und gelb+rot+rotgelb "stop". Ich habe die verschiedenen Zustände z. B. für eine Fußgängerampel mit Räumanzeige verwendet.

Du musst in der Kreuzungsdatei mit dem Texteditor die [approachdist] für die Ampelphase Fussgaenger anpassen. Die ist default bei 0, d. h. wenn ein Fußgänger auf der Kreuzung läuft, kommt die Anforderung - macht natürlich keinen Sinn. Hier den Wert auf 1 setzen! Jetzt kommt die Anforderung, wenn er auf dem segment steht oder (in Gehrichtung) bis zu 1 m davor ist. Passt wunderbar, denn der Drücker für Fußgänger ist auch in echt kurz vor der Kreuzung.

[approachdist] zu editieren macht generell Sinn bei Anforderungen. Bei Fußgängern ist es aber ein Muss. Beim erneuten Speichern wurde bei mir auch nie was überschrieben.

Das Verhalten ist global, kann also nicht vom Map-Erbauer eingestellt werden. Es sind also wirklich die Kurvenradien verantwortlich, die zum Teil vom Erbauer beeinflussbar sind (auf Konnektoren und Kreuzungen). Wenn man stockenden Verkehr hat, reicht außerdem ein langsames KI-Fahrzeug, um alles aufzuhalten. Jedes Fahrzeug wählt sein Tempo zudem etwas zufallsgesteuert (z. B. 48 bis 58 km/h bei vorgegebenen 50 oder so ähnlich).

Das Wetter hat nach meiner Erfahrung einen Einfluss auf die KI. Bei Schnee Glatteis fahren sie noch langsamer als normal.

Zufall kriegst du nur rein, wenn die Ampelschaltung zufällig (verkehrsabhängig ist). Oder du fährst deine Linie mehrmals bzw. in verschiedenen Richtungen, dann kommst du auch zu einem anderen Schaltpunkt an.

Zitat von wurstbrot

Ich bin bei BRT auch relativ flott über die Kö gekommen und hatte einigermaßen "grüne Welle", obwohl ich das mit den Haltepunkten noch nicht ganz geblickt habe und dank SEV hatte ich eh keinen planmäßigen Halt. Ist es da irgendwie per Anforderung gescriptet oder gut gelungendes Timing?

Bei BRT erkennst du die Ampeln mit Anforderung an den Induktionsschleifen (schwarze Vierecke) vor der Kreuzung und bei den Route Helpern an dem weißen A. Bei BRT sind die jeweils wirklich nur dort gesetzt, wo in Omsi auch eine Wirkung erzielt wird.

Zitat

Kann ich auf einfache Weise die ganze Phase "verschieben"? Also angenommen die Phasen sind gut, wegen Timing will ich das aber +30 Sekunden alles verschieben. Geht das oder muss ich per Hand wirklich jede Phase im Kreuzungseditor ändern?

Das musst du per Hand machen. Geht aber relativ schnell im Kreuzungseditor.

Wie bereits bestätigt wurde, liegst du mit deinen Annahmen richtig. Sobald die Kachel mit der Ampel geladen wird, startet der Zyklus bei Null. Ob du bei grün ankommst, ist also Abhängigkeit von deiner Geschwindigkeit, der Anzahl der geladenen Nachbarkacheln und aus welcher Fahrtrichtung du kommst.

Bei Omsi 1 waren deshalb alle Ampeln mit der gleichen Umlaufzeit immer synchron geschaltet, was dann mit Omsi 2 auf einmal nicht mehr funktionierte. In mindestens einem Fall hatte ich deshalb die Schaltphase einer Ampel verschoben, weil man an jener Stelle meist mit konstanter Geschwindigkeit ankommt.

Eine richtige kachelübergreifende Grüne Welle hatte ich vereinzelt auch verbaut. Es ging zum Beispiel um 2 Kreuzungen im Abstand von 120 Metern mit unterschiedlichen Objekten. Dort habe ich dann die "Haltelinien" (also die Pfade mit Ampelzuweisung) aus dem einen Objekt in das andere verschoben. Ist nur nicht ganz trivial, die Koordinaten dafür herauszufinden. Also mehr oder weniger zwei Kreuzungsobjekte in eines gemacht nur dass ich zwischen den beiden Kreuzungen trotzdem Splines verwenden kann.

'Berechnung des Gesamtvolumenstroms in die Außenwelt und umgekehrt (V zählt je Richtung, d.h. insgesamt wird 2*V bewegt)
    (L.L.velocity) 20 / abs (C.L.cabinair_windowdoor_minkmh) + (C.L.cabinair_windowdoor_effectivity) * 3.6 / * (S.L.cabinair_Vrate_doorwindow)

Dieser Abschnitt stammt aus der heizung.osc des SD202. Die Formel hatte für mich damals keinen Sinn ergeben. Deshalb habe ich die für den DL05 aus dem X10-Addon umgeschrieben und kommentiert. Ich legte fest: Wenn 1 m² Türfläche (oder Fenster) offen ist, wird das Luftvolumen des Busses 1-mal pro Stunde ausgetauscht. Diesen Wert habe ich abgeschätzt und sicher ist der auch eigentlich abhängig von der Größe des Busses.

Wie man sieht, steht hier auf einmal ein geteilt durch 3600 in der Formel, also ein sehr viel geringerer Luftaustausch als vorher! Allerdings kühlt der DL deshalb nicht 3600-mal langsamer aus, denn die Konstanten zur Ermittlung der offenen Fenster sind bei mir in m² und bei MR waren dort wohl schon Korrekturfaktoren drin. Lange Rede, kurzer Sinn: Busse mit Original-Script kühlen wirklich schnell aus.

'Pro m² wird das Luftvolumen des Busses 1-mal pro Stunde ausgetauscht. Bei Tempo 15 doppelt so stark.    
    (L.L.velocity) 15 / abs 1 + 3600 / * (S.L.cabinair_Vrate_doorwindow)

Ich verfolge das Projekt schon von Anfang an und es wurde schon zurecht viel Lob abgegeben. Besonders gut gelungen finde ich die Proportionen. Dadurch dass die Fahrbahnbreiten, Abstände, Gehwege usw. sehr genau gebaut sind, ergibt sich ein stimmiges Gesamtbild. Man erkennt ganz genau, wo man ist ohne dass jedes Haus einzeln gebaut werden muss. Auch bei der Genauigkeit der Szenerie orientierst du dich am Spieler, also viele Details z. B. bei den Haltestellen und dafür weniger in den Seitenstraßen. Weiter so!

Beim KI-Verkehr ist sicher noch Luft nach oben wie auf vielen Maps. Weil der Rest aber so weit oberhalb der Erwartung ist, kann ich das leicht verkraften. Schön, dass nach so langer Zeit noch neue gute Maps begonnen werden.

Also DockDist hat einen Einfluss, wie weit im Umkreis nach People Boxen gesucht wird. Hatte das am Bahnhof Berlin-Zoo mit seinen mehreren Bussteigen herausgefunden.

Wenn du mehrere Würfel im Abstand von 1,5 Metern hast, funktioniert es erfahrungsgemäß trotzdem.

Fußgängerpfade brauchst du eigentlich gar nicht. Das Fehlen führt nur dazu, dass die Leute sich beim aussteigen wegbeamen.

Ist die Docking Distance ungewöhnlich klein? Gibt es mehrere Würfel, die sich um eine Box "streiten" könnten?