Beiträge von wurstbrot

Mir fiel auf dass der X10 MB Sprinter keine transparenten Scheiben hat. Ich hab mir die Dateien mal angeschaut und der Fehler gefunden: die dds-Texturen haben keine Transparenz bei diesem Auto, die noch übriggebliebene png-Variante schon. Offenbar ein kleiner Konvertierungsfehler, den ich mir schnell korrigieren konnte indem ich aus der png eine neue dds erstellt habe im Photoshop.

Bitte nur beim künftigen Update nicht einfach die dds Dateien entfernen, auch wenns optisch den Fehler behebt. Die pngs (wie auch tga) fliegen einem gerne früher oder später um die Ohren, auch mit 4GB Patch. Es ist sehr löblich dass im X10 Addon gerade bei den KI-Autos konsequent auf dds gesetzt wurde.

Btw eine Frage: die trafficdens-Daten scheinen mir ziemlich penibel genau ausgerechnet worden zu sein. Welche Datengrundlage hatte das? Ich kopiere sie mir gerne raus für andere Karten, weil mir so der Verkehr am realistischsten über den Tag verteilt erscheint Da ist mir aber unklar ob die Stau-stadteinwärts/stadtauswärts Werte dazugerechnet werden müssten, falls man diese nicht gesondert verwendet sondern zum Beispiel nur mit der NormalCars Gruppe arbeiten würde. Auch würde mich mal interessieren mit welchen Verkehrseinstlungen in OMSI die Dichte ermittelt wurde: ich nehme mal an 100% Verkehrsdichte und maximale Anzahl von Fahrzeugen auf voll damit es keine Begrenzung gibt? Wäre natürlich performancemässig heftig, aber mich würds mal interessieren was das Optimum wäre.

Bei einer Nachtfahrt auf der N4 (die übrigens einen sehr sportlichen Fahrplan hat, vielleicht sollten Abends/Nachts einige Ampeln wie bei X10 Berlin sich abschalten...) fiel mir im Innenstadtbereich auf, das gewisses Stottern und OMSI-Gedenksekunden jenseits des üblichen Nachladens wohl eher durch die Texturen der Szenerie als durch KI-Verkehr verursacht werden. Gemäß meinen Einstellungen war um diese Zeit kaum Individualverkehr unterwegs und es fuhren insgesamt auf der gesamten Karte nur 4-6 KI-Busse. Trotzdem hatte ich alle paar Meter ein Stottern, insbesondere beim Abbiegen oder Sichtwechsel. Eigentlich hatte ich das immer der KI zugeschoben, denke aber nun dass diese da zwar auch eine Rolle spielen kann, nicht aber den Hauptgrund darstellt. Dieses Stottern empfinde ich schlimmer als irgendwelche fps-Schwankungen oder das Nachladen an den Kachelgrenzen. Meine fps hatte ich bei 36 gelockt und die wurden auch stabil in der Innenstadt geliefert. Nun, warum trotz 36 fps so ein abgehacktes Spielerlebnis? Die Antwort bekommt man, wenn man die Texturen in den Optionen auf Low stellt und bei den Objekten, sofern vorhanden, die #low-Varianten geladen werden. Dies reduziert das Stottern auf ein Minimum. Hier kommt wieder eines der Flaschenhälse von OMSI zum Vorschein: es mag nun mal keine großen Texturen, und vor allem nicht in Masse. Auf der Karte sind standardmässig meist 2048er Texturen verbaut, die Low-Varianten haben meist 512er. Jede Texturgrößenstufe rauf oder runter ergibt eine Größenänderung um Faktor 4. Von High auf Low umzuschalten gibt also im Schnitt die 8-fache Ersparnis.

Nun gibt es aber nicht zu jeder Textur eine Low-Variante, z.B. bei den Grabenring-Texturen. Da wäre also noch Potential bei einem Update was rauszuholen. Auf der anderen Seite können 512er Texturen sehr verwaschen aussehen, insbesondere wenn sie Logos und Schaufenster von Geschäften enthalten. Ich wäre mal gespannt ob es noch stottern würde wenn man z.B. 1024er Texturen grundsätzlich verwenden würde in der Low-Fassung für solche Geschäftsbereiche und ansonsten konsequenter bei Low 512er verwenden würde da wo es nicht so auffällig ist. Außerhalb der Innenstadt könnte man eine Stufe rauf gehen und auch bei Low auf die 512er verzichten und 1024er nehmen.

Bei den night-Texturen bin ich mir nicht sicher ob da eine Unterscheidung auch Sinn machen würde, vielleicht aber schon, denn gerade im Winter sind sie morgens lange aktiv und auch schon am Nachmittag zugeschaltet, und zwar zusätzlich zur sonstigen Texturlast.

Interessant ist was OMSI so alles an Texturen lädt. Wie gesagt, ich fuhr die N4, OMSI hatte aber auch Frankenberg-Texturen im Speicher, und ich meine in der Liste auch Beverau gesehen zu haben. Da stellt sich OMSI quasi selbst ein Bein und man kann sich schon fragen was denn nun eigentlich an den Kachelgrenzen nachgeladen wird;-D Beides Areale die nicht geladen werden sollten bei maximal einer Nachbarkachel.

Edit: und eben ist mir aufgefallen dass ich dabei die Halycon-KI-Menschen drin hatte, die unbearbeitet ebenfalls stark zum Texturdilemma beitragen, Nachts aber immer weniger zu Gange sind;-D Trotzdem sind prinzipiell die Beobachtungen nicht falsch, und alles spielt in der Summe eine Rolle.

Für OMSI 2 ist es ziemlich egal welche SSD, ich habe bis heute keinen Unterschied gesehen ob OMSI auf meiner schnellen M.2 lief, die so um die 2,7 GB/s schafft oder auf einer SATA SSD die nicht über 500MB/s kommt. Der Flaschenhals ist im Programm selbst. Nur auf einer Festplatte würde ich es nicht empfehlen.

Die Kaufentscheidung würde ich also nicht von OMSI abhängig machen, sondern davon was sonst noch drauf laufen soll, und da gibt es dann größere Unterschiede. Allerdings ist es für OMSI von Vorteil wenn eine schnelle SSD vorhanden ist, auf der die Windows-Auslagerungsdatei läuft. Denn die wird ausgiebig genutzt, egal wie viel RAM man frei hat. Auf dieser muss aber nicht das Spiel installiert sein.

Teste das Fahrzeug auf Grunddorf oder eben Aachen und nicht auf einer Freeware-Karte die bei Dir erstens schon selbst zig Fehler ausspuckt und zweitens unzählige andere Busse geladen hat.

Sicher spuckt fast jedes Fahrzeug in OMSI immer mal Fehler aus in der Log, kann aber für die Aachen Citaros zumindest sagen dass es nicht mehr sind als bei den meisten anderen Bussen.

Mir ist was bei den Spiegeln der Busse aufgefallen:

Die Standardsichten sind ja darauf ausgelegt dass Performance gespart wird, deshalb sieht man eigentlich den linken Spiegel in der Hauptsicht nicht. Der Hintergedanke ist klar und nachvollziehbar, funktioniert aber nicht, denn der linke Spiegel wird trotzdem die ganze Zeit gerendert. Man spart also nix, beziehungsweise nur an den anderen Spiegeln. Dann müsste man aber den linken Spiegel nicht "verstecken";-)

Ich habe beim LE ein Setup gemacht, welches die gleiche Performance bietet, aber meiner Meinung nach eine bessere Sicht, mit dem Bonus dass bei der Sicht nach rechts die rechten Spiegel ohne Einschränkungen rendern, was hilfreich beim Rechtsabbiegen ist. Der Trick ist dass der Dreifach-Innenraumspiegel hier versteckt wird und nur aktiviert wird wenn man ihn wirklich braucht, zum Beispiel an den Haltestellen.

Hier eine Kombination aus der Modifikation der Sichten und Spiegel:

    ////////////////////////////////////////////////////////
        Kameras
    ////////////////////////////////////////////////////////


    0: Blick nach ganz links
[add_camera_driver]
-0.783
5.000
1.850
-0.10
62
-110
-5

    1: Blick nach schräg links
[add_camera_driver]
-0.683
4.700
1.850
-0.10
62
-70
-5

    2: Blick in den linken Spiegel
[add_camera_driver]
-0.665
4.650
1.850
-0.10
62
-20
0

    3: Blick nach vorne (std)
[add_camera_driver]
-0.665
4.650
1.850
-0.10
62
0
-5

    4: Blick in den rechten Spiegel
[add_camera_driver]
-0.665
4.650
1.850
-0.10
55
33
-5

    5: Blick zur Tür
[add_camera_driver]
-0.665
4.650
1.850
-0.10
62
70
-5

    6: Blick nach ganz rechts
[add_camera_driver]
-0.683
5.000
1.8
-0.10
62
115
-5

    7: Fahrscheinverkauf-Sicht
[add_camera_driver]
-0.683
4.650
1.8
-0.10
40
52
-36
[view_ticketselling]

    7b: Blick in den Rückspiegel
[add_camera_driver]
-0.713
4.650
1.850
-0.10
45
45
15
[view_schedule]

##########################
Linker Außenspiegel
##########################

[add_camera_reflexion_2]
-1.348
5.56
2.1
0
52
175
-10
0.1

##########################
Rechter Außenspiegel
##########################

[add_camera_reflexion_2]
1.4
6.12
2.2
0
52
195
-12.5
0.3

##########################
Innenraumrückspiegel
##########################

[add_camera_reflexion_2]
0.100
5.348
2.3
0
40
200
-18
0.05

##########################
Innenraumrückspiegel-Zoom
##########################

[add_camera_reflexion_2]
0.100
5.348
2.3
0
12
200
-16
0.05

[add_camera_reflexion_2]
0.100
5.348
2.3
0
10
200
-16
0.05

[add_camera_reflexion_2]
0.100
5.348
2.3
0
18
200
-16
0.05

Für eine Performance-Spar-Variante, wo der linke Spiegel wirklich nur gerendert wird wenn man in die Ansicht links der Standardsicht schaltet könnte man aus obigem Beispiel nur den Spiegel-Teil nehmen, und dann vom linken Aussenspiegel die letzte Zeile etwas nach unten tunen, denn bei 0.1 könnte es noch sein dass dieser in der Standardsicht rendert. Vielleicht reicht hier statt der 0.1 schon 0.08. In der City würde diese Änderung einen Unterschied von 30% in den fps ausmachen, also z.B. statt 20 fps hätte man 26. Das wäre dann gewünschte Effekt dieser Sichten.

Wie gesagt, das Beispiel ist aus dem LE, ich nehme aber mal an dass es auf die anderen Citaros übertragbar ist. Wichtig beim Testen ist dass dabei die Kopfbewegungen an sind und man auch ordentlich Gas gibt und die Eisen gehet, denn dadurch ändert sich die Kopfposition, und innerhalb dieser Toleranz müssen die Werte immer liegen.

Zitat von beedle der barde

So extrem vermutlich schon nicht ganz.

Das (wahrscheinlich) grösste Problem von Omsi ist, dass es (vermutlich wegem Alter) die CPU-Kerne nicht sinvoll nutzen kann. Bei mir sind zwei Kerne dauerhaft auf 100% Auslastung, einer auf 80% und die restlichen 3 im bereich von 0-30%. Eigentlich sollte es ja ausgeglichen sein.

Eine i9 mit mehr Kernen wird also nicht sehr viel helfen, da geb' ich dir recht. Aber die höhere Taktfrequenz dürfte schon ein bisschen 'was ausmachen.

Bis zu 4 Kerne werden genutzt: eins davon hat die Hauptlast, die anderen 3 baumeln um die 50%, was aber nicht zu unterschätzen ist. Daraus ist abzuleiten dass OMSI bis höchstens von 6 Kernen profitiert. Warum 6? Weil dann headroom fürs Betriebssystem und andere Hintergrunddienste bleibt die OMSI weniger in die Quere kommen. Bei AMD Ryzen 1000er/2000er Serie gibts eine Ausnahme: hier ist 8 Kerne das Optimum, da man dann OMSI in einen eigenen CCX mit seinen 4 Threads zwingen kann. Wenn OMSI auf diesen Prozessoren auf beiden CCX verteilt läuft gibt es kleine Einbußen. Ein 6-Kerner hätte da Nachteile. Ab Ryzen 3000 sollte dieses Phänomen aber keine Rolle mehr spielen, hier sollte ein 6-Kerner der Sweetspot sein, wenn der Takt hoch ist. Die höchsten Takte gibts aber mit nur mit mehr Kernen;-)

Ansonsten ja, perfekt wird das nie. Nicht mal sehr gut oder gut. Vergessen wir nicht dass es oft nicht die fps sind die einem den Spaß verderben, sondern das Gezuckel und Geruckel, weil OMSI es mal wieder nicht hinkriegt die kleinsten Datenmengen von A nach B zu schaufeln;-)

Definitiv sehr schön dieses Update, auch wenn das Addon schon älter ist. Trotzdem qualitativ immer noch eines der Besten. Ich wundere mich dass ich so wenig darauf gefahren bin;-D

Was mir aber auffiel ist dass es noch einige Kreuzungsobjekte gibt, die bei Regen nicht nass werden, also weder glänzen noch das Nässe-Geräusch machen. Akut könnte ich die Stellen nicht benennen, aber hier und da war es der Fall.

Was man sich auch noch vielleicht ansehen könnte sind die KI-Busse die am Bushof enden oder die Linie wechseln (ich glaube 47 auf 43). Die blockieren gerne den übrigen Verkehr, gerade wenn es Gelenkbusse sind. Vielleicht hier ein wenig mit den Würfeln und Einstellungen spielen. Bei den Linienwechslern fällt mir auch auf dass da das typische OMSI-Problem auftaucht, dass die neue Linie erst bei Abfahrt "einspringt". Ist zwar nur eine Kleinigkeit, aber man kann das mit den Profilen umgehen. Im alten Forum hatte ich mal einen Beitrag gemacht wo das super geklappt hat im Nachtverkehr der Linie 6 am Mainzer Hauptbahnhof. Vielleicht finde ich den und verlinke ihn noch hier.

Edit: Gefunden: https://forum.omnibussimulator…&postID=597085#post597085

Ich finde das DB-Logo bei der Zielanzeige "Bad Hügelsdorf Hauptbahnhof" ziemlich seltsam auf der linken Seite neben der Liniennummer. Das macht die ganze Anzeige inklusive Liniennummer ziemlich unsymetrisch und tut ehrlich gesagt in den Augen weh, gerade wenn die Liniennummer schon so dick ist. Wenn da schon ein Logo hin soll dann würde es sich auf der rechten Seite besser machen.

Es besteht weiterhin (Schilder). Und ich befürchte es bleibt so bis sich der Entwickler dem mal annimmt (wovon ich nicht ausgehe) oder es tatsächlich jemand mit viel Ahnung von der Materie entsprechend moddet.

Bei den Türen habe ich mir halbwegs beholfen mit Umbenennen der entsprechenden Trigger im Script.

Zitat von Maerkertram

Weißt du, ob Omsi bei der Grafikeinstellung zur maximalen Anzahl KI-Umläufe das auf die geladenen Umläufe bezieht? Oder wählt er sich beim Spielstart schon Umläufe aus, von denen dann nur ein Teil zu der bestimmten Uhrzeit sichtbar ist?

Die Grafikeinstellung "Maximale Anzahl an Fahrplan KI" bezieht sich nicht auf Umläufe sondern Fahrzeugmodelle. Wenn nur Solo-Busse auf allen Linien fahren würden, dann wäre es natürlich gleichzusetzen mit Anzahl der Umläufe. Züge und Gelenkbusse bestehen aber aus mehreren Fahrzeugen.

Wie das OMSI nun auswählt ist aber etwas mysteriös. Kann nicht sagen ob das schon am Anfang geschieht oder on the fly. Wahrscheinlich aber letzeres, denn beim Neuladen der Situation werden die Fahrzeuge (leider) neu verteilt.

Zitat von Sherlock Holmes

Dass die Busse auch, wenn sie nicht mehr auf der Karte sichtbar sind, "geladen" bleiben, hat m. E. nach wahrscheinlich den Nutzen, dass gespeichert wird, welches der Fahrzeuge aus der AI-List in dieser Spiel-Session diesem Umlauf zugewiesen wurde. Denn so oft man auf denselben KI-Umlauf trifft, soll schließlich der exakt gleiche Bus zu sehen sein.

Gestaltet man sich nun den Fahrplan so um, dass ein Umlauf nur eine Tour enthält, oder wäre es OMSI-seitig so, dass mit dem Despawn der Bus vollständig "weg" wäre, würde das zwar der Performance guttun. Je nachdem, wie die AI-List gestaltet ist (ob sich alle Busse nur durch die Wagennummer unterscheiden, oder ob zig verschiedene Modelle mit unterschiedlichen Repaints zum Einsatz kommen), wie der Spieler Kenntnis von den Umläufen auf der Linie hat, und wie wichtig es ihm ist, immer dem gleichen Bus zu begegnen, wenn das in der Realität auch so sein müsste, brächte das aber wiederum Einbußen im Realismusgefühl, welches auf der Karte aufkommt.

Wenn man bspw. an einer Endhaltestelle immer auf eine KI-Linie trifft, und über Stunden hinweg jedes Mal ein anderer KI-Bus dort steht, wirkt das nicht so realistisch. Je nach Kartengröße fällt das eben mehr oder weniger auf.

Mir zum Beispiel ist es eher wichtiger, den Eindruck zu haben, dass der Gesamtbetriebsablauf auf der Karte realistisch ist, als ein paar FPS mehr zu erreichen. Anderen kommt es viel mehr aufs reine Busfahren an, während der KI-Busverkehr bestenfalls Nebensache ist.

Das ist richtig. Man muss natürlich abwägen auf welchen Linien es Sinn macht. Ich würde es beispielsweise auf X10 nur bei Zügen anwenden, und bei der Bus-KI dann nur bei denen reinen KI-Linien die nicht da Pause machen wo Spielerlinien enden. Ausnahme vielleicht am Zoo, in dem Bereich wird man von den Eindrücken eh erschlagen und würde als Spieler nicht so genau hingucken. Und da wo man bestimmte Busse/Wagenummern erzwingen möchte eventuell mit car_use Touren explizit Wagennummern zuweisen.

Man muss auch eins berücksichtigen: wenn Dir OMSI anfängt rumzukrebsen oder gar abstürzt und Du den Spielstand neu lädst, wird den Umläufen eh ein neuer Wagen zugeteilt und der von Dir beschriebene Effekt ist hin. Man kann halt nicht alles haben... Und bei Zügen ist es mir als Spieler echt wurscht ob am RE XY nun die 143-123-4 zieht oder die 143-432-1... Da ist es mir lieber der Zug macht Platz für andere Busse und ein paar fps wett.

Zitat von kendrick

Ich werf hier einfach mal Hardware Accelerated GPU Scheduling in den Raum, welches mit der Build 2004 ergänzt wurde. Es wäre mal interessant zu wissen, ob Omsi davon in irgendeiner Art und Weise

Hatte ich auch vor ein paar Tagen dran gedacht, weil es erst mit dem letzten Nvidia Treiber aktivierbar wurde. Hab aber wenig Hoffnung dass es irgendetwas in OMSI bringt, denn jegliche Treibereinstellungen brachten bis jetzt nichts, außer denen die einfach das Bild verbessern (AA, SSAA, SGRSTAA etc etc etc). Da kann man ja reinhauen fast was man will, OMSI ist dermaßen CPU lastig dass sich die GPU sowieso zu Tode langweilt, wenn sie nicht gerade von vor-vorgestern ist.

Zitat von Maerkertram

Grundsätzlich kann ich den Verlauf der Performance bestätigen und auch dass die einmal "gesehenen" Busse scriptmäßig irgendwie weitergeführt werden, selbst wenn sie nicht mehr sichtbar sind. Die Idee, dass die Fahrzeuge zum Ende ihres Umlaufs entladen werden, hatte ich noch nicht. Ich habe nämlich beobachtet, dass Busse oft einfach an der Kachelgrenze stehen bleiben.

Also Beispiel: Ich fahre um 8:00 im X10 vom Zoo nach Teltow. Um 8:05 fahre ich über die Kachel X und weil ich zügig fahre, gerät ein Bus hinter mir aus dem Sichtbereich. Um 9:30 komme ich aus der Gegenrichtung wieder auf Kachel X an. Mir kommt jetzt ein Bus entgegen, der schon von außen als die Fahrt von 8:05 Uhr mit +85 Minuten identifiziert werden kann (z. B. weil das KI-Ziel nur 1x am Tag geschildert wird). Hilft das vielleicht für eine Experimente?

Hatte ich so noch nicht beobachtet. Allerdings hätten sich dann doch gerade Abends wenn sich Aussetzfahrten häufen auch solche Situationen gehäuft. Oder im depot in den Hallen.

Bisher habe ich nur beobachtet dass wenn die Tour beendet ist, der Fahrplan also de facto fertig abgearbeitet ist, die Busse/Bahnen auch aus der Liste der Busse im Debugfenster verschwinden. Und natürlich dass je mehr Busse sich dort sammeln die Gesamtperformance auch mal gerne locker um 30% oder mehr gemindert wird. Ich glaube auf X10 auf höchster Fahrplanpriorität vor allem mit Zügen könnte man das ganz gut testen. Weil gerade Züge füllen die Fahrzeuganzahl extrem auf nach einer Weile. Wenn man also die Fahrpläne so beschneidet dass die Züge nach dem Despawn quasi fertig mit dem Fahrplan sind, müsste das einiges bringen. Das ist der Hintergedanke dabei, und ein erster Test auf der Szczecin Karte brachte auch positive Ergebnisse: die Fahrzeuge verschwanden aus der Liste. Der nächste Gedankengang wäre das auf reine KI-Buslinien auszudehnen. Gerade wenn diese durch Gelenkbusse bedient werden dürfte der Effekt spürbar sein. Wobei bei X10 wäre das glauib ich nur eine Handvoll von Linien. Allerdings könnte es beim Zugverkehr viel bringen.

Zitat von Maerkertram

Bei den oben verlinkten Bildern, bei denen die Weiterschaltung nicht funktioniert, liegt das vermutlich daran, dass der Bus danach eine 180-Grad-Kurve fährt. Sprich, wenn der Bus 50m vom 1. Würfel entfernt ist, aber in dem Moment 55m vom 2. Würfel entfernt ist, erkennt er diesen nicht mehr.

Stimmt, im Beispiel 1 gehts tatsächlich um 180 Grad zurück. Allerdings ist zwischen der Haltestelle die nicht weiterschaltet und der folgenden regulären eine mit "never" abgeschaltete nicht weit entfernt, eventuell unter 50m. Vielleicht kann man dies mit einem direkten Link ja umgehen.

Zitat von Maerkertram

Welches Fahrplansystem verwendet wird, hat dafür keinen Einfluss. Bei X10 sind beide Systeme gemischt verbaut. Das hat vor allem praktische Gründe, also was einfacher zu machen ist. Die meisten Linien inkl. aller Spieler-Linien haben StationLinks. Züge und bestimmte KI-Busse haben Tracks+Trips. Den einzigen Vorteil von T+T, den ich kenne ist, dass die EN92 als KI-Bus bei T+T Einstieg an der Starthaltestelle machen können, bei Links aber nicht. Das liegt daran, dass sie erst später auf das neue Ziel umschildern.

Das geht auch per Trick bei anderen Bussen. Hatte ich vor Ewigkeiten auf Mainz ausprobiert bei am Hauptbahnhof endenden Fahrten der Linie 6 und verwendung von StnLinks. Im alten Forum gibts irgendwo das ganze mit Beispielbildern. Da hatte ich für Haltestelle 1 einfach die Abfahrtzeit später gesetzt. In meinem Beispiel kam der Bus z.B. 23:56 an, der nächste Trip startete auch direkt um 23:56, Abfahrt war aber mit "4.000" eingetragen und somit um 0 Uhr. Hat geklappt, sogar mit Alters Citaros, die auch etwas speziell sind was das Anfahren der Buswürfel betrifft. Aber man muss sich schon im klaren sein dass verschiedene Busse sich auch unterschiedlich verhalten können, daher sollte man sowas immer durchtesten mit den Bussen die man auch einsetzen möchte, und nach Möglichkeit keine spezielle sondern eine allgemeine Lösung wählen.

Zitat von Schleswig-Holstein

Redest du da jetzt gerade von Fiktiv Stettin oder von BHD? Denn auf BHD ist fast alles mit Kreuzungsobjekten gebaut.

BHD. Es gibt oder gab auch Kreuzungen wo jegliche Verkehrsregeln ignoriert wurden, sogar wenn man sie explizit im Editor korrigiert hatte. Aus dem Kopf fällt mir die Kreuzung nähe Haltestelle Mozartstraße ein, wo die Vorfahrtstraße abbiegt, man aber geradeaus fährt. Hab aber nicht geprüft ob das ein Kreuzungspbjekt ist oder nicht. Wenns ein Kreuzungsobjekt ist, dann kanns aber eventuell auch an zu kurzen Pfadstücken liegen. Jedenfalls wärs bei Splines völlig unmöglich, da kreuzende Splines nicht eine Einheit sind. Der Bus fährt da ja geradeaus, und vor allem ignorieren Fahrzeuge aus der Straße von rechts (Stadtauswärts nach H "Mozartstr.") immer die Vorfahrt. Sie müssten mir Vorfahrt geben weil ich auf der Vorfahrtstraße bin, und in Gegenrichtung weil ich von rechts komme. Jedenfalls kann man da einstellen was man will, es nutzt nix. Klassisches Verhalten bei Kreuzungen aus Splines... Wundert mich also warum das auftritt wenns ein Objekt ist.

An anderen Stellen die ich aber gerade nicht benennen kann kommt ähnliches: Vorfahrt wird zwar geachtet, aber erst mitten auf der Kreuzung, nämlich da wo ein Pfadsegment aufhört und ein anderes beginnt. Häufig bei Linksabbiegern.

Vielleicht funktioniert das wirklich nur bei Splines... Zumindest scheinen Kurven in solchen Fällen bei Splines nicht problematisch zu sein. ist aber auch alles erstmal nur eine Annahme.

Grundsätzlich sind Kreuzungsobjekte sowieso besser, allein weil bei Splines Verkehrsregeln nicht vernünftig funktionieren. Spielt aber nicht immer eine Rolle, zum Beispiel da wo keine non scheduled AI fahren soll (Bahnhofsvorplätze etc). Ein Gewusel aus zig invis splines sollte man aber vermeiden wenn es geht. Ein kompliziertes Kreuzungsobjekt wird aber auch seine Leistung konsumieren, es enthält ja auch zig Pfade. Ich nehme aber an dass die halt sauberer verbunden sind als bei Splines, und OMSI sich bei Splines eben totrechnet wenn es nicht 100% sauber ist, was kaum hinzukriegen ist per Hand. Es könnte also durchaus Sinn machen die Splines der Kreuzungen in ein Objekt zu backen, was auch dafür sorgen würde dass die Verkehrsregeln eingehalten werden. Es wäre aber für die Karte ein unglaublicher Aufwand, denn man müsste natürlich jeden einzelnen Track (ob Typ 1 oder 2...) anpassen, Verkehrsdichten und Vorfahrtsregeln auch.

Unabhängig davon muss man für die non scheduled AI alles unnötige sperren. Auf der Karte gibt es Abschnitte wo sich Pfade überlagern und nicht sauber gesperrt sind. Die Straße am Hauptbahnhof ist so ein Beispiel. Ich glaube da verlaufen parallel Pfade, die man kaum auseinander halten kann. Sind diese nicht gesperrt, wird die AI von einem zum anderen hüpfen ohne dass man das sieht. Und leider reicht nur ein Pfadsegmentchen aus und schon wird der andere Pfad auch befahren. Wenn Du mal gesehen hast dass Autos am Bahnhofsvorplatz reinfahren, oder es versuchen (vielleicht ist das mittlerweile ja behoben) dann liegt es genau daran.

Zitat von Schleswig-Holstein

Interessant, dass das dann nur auf Splines zu funktionieren scheint.
Aber auf einem Objekt hast du das auch nicht hinbekommen, oder?

Mir war das einfach nur zu mühselig bisher den Kreuzungseditor dafür zu bemühen. Ich nehme mal an dass es dann auch klappen würde. Bei den Splines ist es halt im Editor ein einfacher Splinesplit, dann sperren des neu entstanden Pfades für non scheduled AI und dann halt die Verlinkungen. Bin mir jetzt nicht sicher ob man im Kreuzungseditor so einen Schnitt machen kann, habe ihn ewig nicht mehr benutzt. Wobei es mich schon wundert warum es im ersten Beispiel nicht klappt. Sind ja auch zwei verschiedene Pfadsegmente. Aber eventuell stört die Kurve dabei.

Ich geb Dir paar Beispiele wo das mit nahen Buswürfeln ohne hängen bleiben des Fahrplans klappt und wo nicht, weil ich vor kurzem da Hand angelegt hatte:

Beispiel 1: Fikcyjny Szczecin Hst. Goclaw

Hier klappts nicht. Das ganze Areal ist ein Kreuzungsobjekt. Fahrplan bleibt aber hängen am vorderen Würfel. KI aber keine Probleme.

Beispiel 2: Fikcyjny Szczecin Hst. Skolwin

Funktioniert, hat aber im Original nicht funktioniert, Fahrplan blieb hängen. Ich glaube hier habe ich nur Würfel etwas hin und her geschoben.

Beispiel 3: Fikcyjny Szczecin Hst. Cmentarz Szczecinska

Funktioniert. Von mir dahingegehend modifiziert, dass vorher die Pause an der Ankunftshaltestelle (nicht im Bild) war. Habe sie aber hierhin verlagert, weil es sonst zu KI-Staus mehrerer Linien kam.

Gerade im letzten Beispiel sieht man wie nah die Würfel sind, aber auf verschiedenen Pfadabschnitten. Verbunden sind sie per StnLink. Hier musste ich einen Spline-Schnitt machen um das so zu haben.

Bei den Fahrplänen ist wie erwähnt letzte Haltestelle des hintere Würfel, der gleichzeitig die erste Haltestelle der Folgetour ist. Der vordere Würfel ist dann die zweite Haltestelle und wäre mit einem DFI verbunden wenn einer dort stehen würde. Bei den Fahrplänen zeigt OMSI auch brav SmartTrans an. Im Original ist das alles aber nicht so, da waren zum Teil Pfade ins nichts und Busse sind verschwunden. Jetzt nicht mehr.

Zitat von der_Nik_

Mir ist eben beim Bearbeiten der HOF-Datei aufgefallen, dass es oft Ziele mit Identischem Namen gibt, die aber verschiedene Zielcodes haben.

Das Mag OMSI nicht wirklich, da OMSI ja meist nur der Zielname gegeben wird (z.B: im Editor), und das Programm dann die Qual der Wahl hat, welches Ziel es nun nimmt. Hatte mich schon gewundert, warum die N14 von Sechelsberg aus zum Altstadtforum "Über Larnhalt, Mühl" (Oder so ähnlich, jedenfalls etwas total unpassendes) geschildert hatte, liegt wohl daran (über die automatische Schilderung).

Mein Vorschlag wäre, die Zielcodes jeweils mit Liniennummern in klammern dahinter zu versehen und die DFI's bei Bedarf so umzuprogrammieren, dass diese die Klammern erkennt und entsprechend weglässt.

Wenn ich mich recht entsinne nimmt OMSI einfach das erste passende Ziel aus der Liste. Einen anderen Nachteil hat es aber nicht. Möchte man wirklich differenzieren muss man tatsächlich was dranhängen. Man braucht aber keine DFIs umzuprogrammieren, sondern einfach ausreichend viele Leerzeichen verwenden, so dass eben das Anhängsel nicht mehr im DFI zu sehen ist.

Etwas blöd ist es dann aber für Busse mit Rollband, da man bei diesen das gleiche Ziel mehrfach auf dem Band haben müsste. Da kann man die HOF dann auch nicht einfach umschreiben, weil man an die Namen der Endhaltestellen gebunden ist. Ich glaube aber dass hier durchaus die Verwendung vom #-Zeichen helfen kann. Wird in Spandau nämlich bei einer Linie angewendet, wo die Matrix verschiedene Ziele anzeigt, die Endhaltestelle aber die gleiche ist, und beim Rollband steigen beim Schildern bei beiden varianten Leute ein, obwohl die RLB Busse das gleiche Zielband ansteuern. Müsste man die Linie 56 studieren, die als Ziel "Hakenfelde" und "Hakenfelde #Golzstrasse" verwendet. Ich vermute dass das Kreuz eine Sonderfunktion hat, und es eventuell schlauer wäre vor der Liniennummer ein Kreuz zu machen.

Zitat von Schleswig-Holstein

Zitat von wurstbrot

Wenn die KI sinnlos spawnt, kann dies auch andere Ursachen haben. Jedenfalls ist mir sowas bei StnLinks nie explizit aufgefallen

Dieses Problem tritt auch beim X10 Addon auf. Ebenso beim Rheinhausen Addon.

Das große Problem an den zig gespawnten Bussen ist einfach, dass irgendwelche Busse mit 1400 Minuten Verspätung gespawnt werden. Und dies tritt immer und immer wieder auf.

Ebenso hat man bei den StnLinks immer dieses Problem mit den 2 Buswürfeln, welche mindestens 60 Meter auseinander sein müssen.
Außerdem finde ich, dass die DFI Anzeigen durch das doppelt und dreifache angeklicke der Buswürfel auch oft nur Mist anzeigen.

Hab ich so auf X10 nicht gesehen, und bin da vor allem früher sehr sehr viel gefahren. Da dort eigentlich auch ein gleichmässige Taktfahrplan herrscht wäre es mir aufgefallen, weil mich sowas für gewöhnlich ziemlich geärgert hätte. Heisst natürlich nicht dass es garnicht vorkommt. Ich meine dass ganz vereinzelt auf Spandau sowas vorkam, aber auch relativ selten, denn dann hätte ich ganz sicher die Fahrpläne auseinander genommen;-D

Bei den 2 Buswürfeln kommt es nicht auf die Entfernung voneinander an, sie können sehr sehr nah beieinander sein. Nur müssen sie auf zwei verschiedenen Pfaden sein. In EInzelfällen kann es Probleme geben mit der Pfadlänge, dann muss man bisschen schieben. Hatte ich vor ein paar Wochen auf einer Karte wo ich deshalb einige Spline Splits machen musste zwischen den Würfeln, was aber gerade wenn man nicht mit Kreuzungsobjekten gearbeitet hat easy ist. Da warebn die Würfel sogar so nah, dass die Busse an den Endstellen sich nicht von der Stelle rührten um von einem zum anderen Würfel zu gelangen, das einzige was halt jemanden dann stören könnte ist das doppelte Tür auf und zu machen. Und wegen den kurzen Pfadlängen muss man halt gucken ob die Busse richtig die Haltestelle anfahren und auch verlassen, ggf wieder schieben. Gleiches gilt für die automatische Weiterschaltung vom Fahrplan von Hin auf Rücktour. Müsste man aber aber Typ 1 Trips auch prüfen, da dort ebenfalls die Pfadlänge einem in die Suppe spucken kann. Natürlich dann bei allen Trips, während bei StnLinks das grundsätzlich bei allen Trips gleich wäre.

Bei den DFIs verstehe ich nicht ganz was Du meinst. Gerade wenn man mit zwei Würfeln arbeitet hat man doch die Ankünfte von den Abfahrten schön getrennt. Der vordere Würfel ist für Abfahrt, der hintere für Ankunft. Der hintere ist letzter Halt im Fahrplan der Hintour und gleichzeitig erster Halt der Rücktour, der vordere dann Haltestelle 2 (wobei im Fahrplan dann der erste der Rücktour durchaus ein "never" im Profil bekommen kann damit das nicht doppelt angezeigt wird). Allerdings haben DFIs ja auch wieder unterschiedliche Scripte, die auch einiges regeln könnten. Eure DFIs fressen aber keine Performance, da würde ich nicht raten noch irgendwas reinzuscrpiten;-D

Da Ihr im Hinblck auf Performance so einiges umkrempelt empfehle ich Euch kurz mal einen Blick auf meinen Beitrag #39 letzter Absatz zu werfen:
Nachladeschluckauf, Direct3D lost & High-DPI

Es geht um das Einsparen von Fahrzeugen vor allem bei Zügen, die streng genommen immer aus mehreren Fahrzeugen bestehen. Durch Teilung der Touren kann man einiges einsparen. Man verliert zwar möglicherweise im Editor den Überblick über den Fahrplan, das kann man aber mit einer recht stumpfen Arbeit in einem Texteditor erledigen. Könnte viel helfen bei Bad Hügelsdorf, da die Karte ja sich in verschiedene Richtungen ausbreitet und man bei einem Linienwechsel unter Umständen ja nicht mehr in den Bereich fährt wo man vorher war. Warum sollte also ein 5-Wagen-Regionalexpress oder ICE im Speicher gehalten werden, bloß weil er gemäß Fahrplan irgendwann wieder kommt, wenn man garnicht mehr in diese Ecke fahren wird. Dann doch lieber 5 Busse spawnen;-D Wobei Speicher da nicht das Problem ist, sondern die Eigenartigkeit von OMSI dass jedes Fahrzeug was ein mal da war und dessen Tour noch nicht zuende ist für die restliche Dauer im Hintergrund ist und weiterhin fps konsumiert. Für reine KI-Linien auch eine Option.

Der Wiki-Link ist leider für mich nicht aufrufbar.

Wenn die KI sinnlos spawnt, kann dies auch andere Ursachen haben. Jedenfalls ist mir sowas bei StnLinks nie explizit aufgefallen, und ich habe sehr viel mit StnLinks gearbeitet. Heisst nicht dass es gar keine Bugs gibt, die gibts bei OMSI überall;-D Wenn Ihr Umstellt macht Ihr Euch unnötig Arbeit und erschafft weitere mögliche Fehlerquellen zum Beispiel allein dadurch dass es zwischen Haltestelle A und B für jede Linie und Variante verschiedene Tracks gibt.

Es kann mir keiner erzählen dass bei Tracks and Trips Busse nicht mehr auch mal über die Wiese fahren. gerade kürzlich sogar auf einer anderen Karte gesehen. Auch hier ist die Ursache eine andere und wird dadurch nicht behoben. Es hat meistens eher was mit der Position des Buswürfels zu tun und der Länge des zugehörigen Pfades, und wird meist zum Problem auf Karten wo es vor allem viele kurze Pfade gibt, weil z.B. nicht mit Kreuzungsobjekten gearbeitet wurde sondern mit Invisible Splines, die zum Teil nicht sauber verlegt wurden. Gleiches gilt für das beschriebene an den Endstellen.

Würde das stimmen dass die StnLinks so viel mehr verbuggt sind und der Grund für die aufgeführten Probleme, dann würde z.B. die Karte X10 schon seit Ewigkeiten nur Probleme machen. Tut sie aber nicht und ist eine der stabilsten und fehlerfreisten Karten die es gibt.

Und für manches kann auch das KI-Verhalten der Busse direkt am Bus liegen, man denke da nur an Hamburg und die ganzen KI-Patches für die HH Citaro etc. Und natürlich auch wie unterschiedlich sich diverse Busse beim Anfahren und verlassen einer Haltestelle verhalten.