Beiträge von wurstbrot

Moin!

Mir ist auf Fikcyjny Szczecin aufgefallen, dass bei Regen, oder besser gesagt bei Nässe, einige Straßenmarkierungen verschwinden. Manche sind ganz weg, und bei manchen sieht man dann anstatt der weissen Farbe die Gras-Textur. Es ist nicht bei allen der Fall, manche funktionieren ganz gut. Ich nehme an dass irgendwas mit den Texturen nicht stimmen oder der Konfiguration dieser Splines. Auf den ersten Blick habe ich schon mal gesehen dass es jpg Texturen sind, da krieg ich sowieso einen Anfall;-D Allerdings gabs auch andere Splines mit jpg Texturen, die blieben zumindest normal sichtbar, da kann ich nur nicht sagen ob sie wirklich "nass" wurden.

Nun die Frage: woran könnte das liegen dass die Markierungen verschwinden? Irgendein fehlender Eintrag oder müssten die Texturen bearbeitet werden? Wenn ja wie?

Und bei der Gelegenheit die Frage warum werden manche Asphalttexturen/Objekte/Splines bei Regen nass und manche nicht? Gibt ja auch einige, und wenn schon dann könnte ich auch diese zumindest zum Teil angehen.

So, ich habe gestern mal den Windows 7 Kompatibilitätsmodus mit Adminrechten ausprobiert und ebenfalls die Sklaierung verboten. WObei letzteres bei mir sicher irrelevant ist, da ich auf dem Desktop auch nicht skaliere sondern 2560x1440 in 100% betreibe. Seit dem hatte ich keinen Device-Verlust gehabt, allerdings schon einen Hänger bis zum Stillstand. Glaube aber dass es insgesamt sich gebessert hat.

Hab auch ein wenig das Ladeverhalten mal im Ressourcenmonitor beobachtet. Dazu vorher meine Vehicles auf eine andere SSD (E:) ausgelagert, und auf eine andere SSD (F:) wiederum SceneryObjects und Splines. Von der M.2 (C) lief also der Rest. Das ganze mit NTFS-Link verknüpft. Interessant war dass bei Fahrt fast nur die das Laufwerk C beansprucht wurde, ganz selten hab ich Spikes auf E und F gesehen. Interessant deshalb weil ich mehr Zugriffe auf die SceneryObjects erwartet hätte beziehungsweise Vehicles, aber beide Laufwerke haben ziemlich viel Däumchen gedreht. An der Performance hat diese Umleitung rein garnix geändert, weder zum positiven noch zum negativem. Hatte noch kleine Hoffnung gehabt dass dadurch dass OMSI so parallel auch über verschiedene Busse zugreifen kann (ein mal PCI Express M.2 mit ca. 1,6 GB/s und dann SATA zusammen 500 MB/s), aber das bestätigt mich mal wieder dass bei OMSI 2 der Flaschenhals im Programm ist. War übrigens bei OMSI 1 nicht so, da hab ich bis zu meiner ersten SSD eine RAM-Disk benutzt und kaum bis gar keine Nachladeruckler. Hab ich dann aber aufgegeben, da die SSD sich nur unwesentlich schlechter verhalten hat. Während der 2.1 Beta zu OMSI 2 gabs kurz ein Build der ebenso geil lief, dafür aber paar andere Böcke gehabt. Nun ja, wir haben nun den Build den wir haben und versuchen das beste draus zu machen. Als nächstes löse ich glaub ich aber wieder den Umleitungskonstrukt auf und werd wohl OMSi auch von der M.2 auf eine der SATAS verschieben, denn großen Unterschied macht das nicht. Vielleicht hätte es sogar den Vorteil dass OMSI dann nicht da drauf wäre wo Windows ist während Phasen wo Windows irgendwas im Hintergrund werkelt. Da aber OMSI kaum die Bandbreite zu nutzen scheint glaube ich dass es keinen Unterschied machen wird.

Ebenfalls keinen Unterschied machte das Hinterfragen und Umstellen von Grafikeinstellungen im Treiber. Ob kein AA, 4x AA, SGSAA oder Transparenz-Supersampling ist Jacke wie Hose für die Frames wie für das Laden. Hatte aber gedacht dass vielleicht durch irgendeine Eigenheit irgendeiner Einstellung da vielleicht irgendwo auch eine Bremse entstehen würde, die vor allem an den Kachelgrenzen eine Rolle spielt, Shadercache oder sowas.

Habs eben beim Solaris Urbino PL versucht, kriegs aber nicht hin. Die erste Kamera ist der linke Spiegel, Kamera 4+5 die Überwachungskameras. So wie unten im Code krieg ich den linken Spiegel immer mit 100% Frames gerendert so wie ich es möchte, Allerdings bleibt der Monitor mit Bildern von Kam 4+5 in jeder Ansicht dunkel.

Mache ich nun alles zu _2 rendert der linke SPiegel mit reduzierter Framerate, die Überwachungskamera funktioniert aber. Wenn ich dann die 30 in 0.15 ändere gehen die Überwachungskameras wieder nicht, erst ab etwa 8 fangen sie an wieder zu gehen. Hab dann aber im linken Spiegel reduzierte Framerate in der Hauptsicht, was mich nervt, obwohl keine andere Kamera oder Spiegel im Blickfeld sind. Irgendwas versteh ich da also nicht? Wenn ich beim linken Spiegel aus der 8 z.B. 100 mache ändert sich nichts.

[add_camera_reflexion_2]
-1.377
5.056
2.285
0
52
175
-25
8

[add_camera_reflexion]
1.348
5.924
2.353
0
52
205
-10
0.15

[add_camera_reflexion]
-0.005
5.2
2.576
0
52
195
-22
0.15

    "reflexion3.bmp":

[add_camera_reflexion]
-0.372
0.1
2.793
0
80
45
-40
30

    "reflexion4.bmp":

[add_camera_reflexion]
-0.294
-3.997
2.828
0
80
45
-40
30

    "reflexion5.bmp":

[add_camera_reflexion]
1.084
5.882
2.402
0
70
243
-29
0.15

Sahnehäubchen wär natürlich auch noch wenn der rechte Spiegel mit 100% Frames ginge wenn ich nach rechts schaue, denn dabei hätte ich auch keinen weiteren Spiegel im Sichtfeld, die Fahrgastraum-Kamereas und der Fahrgastraum-Spiegel sind ja weiter oben. Und bei den oberen stört es mich garnicht wenn die mit reduzierter Rate rendern, die nutze ich nur an Haltestellen im Stand.

Ja ich weiss. Bei meiner Methode wurde die letzte Zeile immer ignoriert bei den sonstigen Kameras. Die habe ich aber immer drin gelassen. Und wenn ich mich recht entsinne waren das immer in letzter Zeit Busse mit _2 Cameras und somit 8 Zeilen.

Aaaaah!

Also könnte ich wenn ich wieder meine Busse anpasse den gleichen Effekt erzielen den ich möchte durch Herabsetzung des letzten Wertes anstatt bei den anderen Kameras die _2 wegzumachen?

Bei den von Dir hier gesetzten Werten würde der Spiegel also nur aktiv werden wenn man die Sicht ändern und der Spiegel sichtbar wird?

Wenn ich das also korrekt verstehe könnte ich auf diese Weise dann das haben was ich möchte (Performanceersparnis+immer refreshender linker Spiegel) UND dann müsste es auch keine Probleme mit den Überwachungskameras geben? Das wäre wuasi Perfekt...

Ich hab den eCitaro ja nicht, aber 8 beim linken Spiegel in der untersten Zeile und 0.15 bei den anderen müsste dann auch gut funktionieren?

Jetzt bin ich verwirrt:

Ich mache immer auf den linken Spiegel [add_camera_reflexion_2] und beim Rest [add_camera_reflexion]. Der linke wird dann immer gerendert, die anderen nur wenn sie im Blickfeld sind. Wenn überall eine _2 ist dann würden all diese Spiegel doch dauerhaft refresht werden und gerade das würde auf die Performance schlagen oder dafür sorgen dass auch der wichtige linke mit halber oder viertel Framerate läuft... Nachteil bei meinem Vorgehen ist dass dann aber die Kameraüberwachungen in den Bussen nicht funktioniert, da diese wohl zwingend _2 brauchen, im Gegensatz zu sonstigen Spiegeln.

Mit dem Drucker sollte das alles aber rein garnix zu tun haben...

Daran hab ich ehrlich gesagt nie gedacht... Eben nachgeschaut, bei mir läuft OMSI im "normalen" Modus. Werd ich jetzt mal ändern, und testen, danke!

Was mir aber noch einfällt beim Durchgucken der Optionen im Reiter "Kompatibilität" ist der Punkt "Vollbildoptimierungen deaktivieren". Dunkel erinnere ich mich an einige Spiele wo es empfohlen wurde auch da Häkchen zu setzen. Könnte auch eine Rolle spielen, allerdings könnte es auch sein dass es hier wurscht ist, weil im echten Vollbild läuft OMSI ja nicht wirklich, eher als rahmenloses Fenster.

Moin!

Ich wollte mal nachfragen was sich so an Erkenntnissen in den letzten Jahren gesammelt hat bezüglich des leidigen OMSI-Nachladens, verbunden mit dem rausfliegen von Direct3D. Ich halte für gewöhnlich meine AI- und Parklisten sparsam so weit es geht, definiere dort (vor allem in der AI List) wenige Modelle mit größerer Häufigkeit, und ein paar wenige zur Abwechslung mit geringer Häufigkeit. Zusammen mit einem guten Kompromiss bei den Einstellungen erreiche ich wirklich für OMSI-Verhältnisse gute Frameraten: meist liege ich um die 40fps und mehr in unkritischen Bereichen, in kritischen Bereichen geht's bei gutem Wetter kaum unter 25. Natürlich je nach Karte, aber das ist so der grobe Schnitt, z.B. in Bad Hügelsdorf. Im Vanilla-Spandau ist das noch mehr. Also also eigentlich fein. Im groben fahre ich mit einer Nachbarkachel, ökonomischem Reflexionsmodus für Spiegel (und ich modifiziere mir alle Busse so, dass der linke Spiegel immer 100% refresht, Rest in den anderen Sichten ist öko und inaktiv wenn man sie nicht sieht), 400m Sichtweite, max 80 KI-Autos/Menschen @ 100%.

Doch beim Nachladen bleibe ich nicht verschont von Rucklern und Freezes, gerade in "kritischen" Bereichen, bis hin zum Freeze mit dem Abdanken und Wiederherstellen vom Direct3D Device. Nur irgendwie erkenne ich hier kein System: auf gleicher Karte mit gleichen Einstellungen zur gleichen Tageszeit im gleichen Bus an gleicher Stelle kann es auch mal richtig angenehm sein zu fahren, völlig ohne Probleme, trotz gleicher Last. Das was ich aber erkenne ist wenns hackt geht die Auslastung eines einzigen CPU-Threads auf 100% und OMSI scheint sich totzurechnen, während die anderen Threads runter gehen auf 0. Im Normalfall habe ich meist durch OMSI 4-6 Threads unter Last, zwei mit vielleicht 70% und die anderen unter 50. Nun könnte ich annehmen dass irgendwo ein Hitzeproblem oder ähnliches besteht, dem ist aber nicht so. Einen Prime95-Durchlauf mit 100% auf allen Kernen und Threads schafft der Rechner über eine halbe Stunde (noch längeren Test eine Weile nicht gemacht, da dieser sowieso ein Horrorszenario ist fern jeder Praxis, und bei Hitzeproblemen oder CPU/Speicherfehlern schon nach wenigen Minuten ein Crash kommen würde). Nun denn... Also auch DirectX neu installiert, und schon vor Wochen OMSI von SweetFX befreit. Aber irgendwo muss da der Wurm sitzen? Ich glaube mittlerweile nicht mal dass es das Nachladen selbst ist, eher dass in der Situation an Kachelgrenzen OMSI in die Knie geht weil ihn irgendwas im System behindert und es als letztes Mittel das Direct3D-Device neustartet, was manchmal eben fehlschlägt. Irgendwo meinte ich gelesen zu haben dass sogar Spotify dazwischenfunken kann. Kann ich mir ehrlich gesagt nicht vorstellen, und ist bei mir eh vom Autostart ausgeschlossen. Chrome ist bekannt dass es Leistung klaut und vor allem Speicher, auch im Hintergrund. Aber was würde Chrome mit Direct3D wollen?

Mich würde es jetzt mal vor allem interessieren wer denn halbwegs erfolgreich dieses Phänomen beseitigt hat, es also definitiv hatte und dann durch irgendeine Maßnahme, sei es durch vor dem OMSI Start 3 mal im Kreis um den Stuhl laufen, los wurde. Denn wie erwähnt, es gibt auch Sessions da taucht dies garnicht auf, geht also auch ohne.

Vollständigkeitshalber das System: ASUS X350 Prime Pro, Ryzen 7 1700X @3,8 GHz, 32GB RAM DDR4-3000, 512GB M.2 SSD, 512GB SATA SSD, 1TB SATA SSD, Geforce GTX 1080, ASUS Essence STX II Sound, Win 10 Pro.

Achja, als Virenschutz hatte ich früher Norton Security genutzt und die OMSI-Folder exkludiert, heute nutze ich den Windows Defender, ebenfalls mit Ausnahmen für OMSI. Unter Norton wars aber nicht anders, dennoch können ja auch Virenscanner ihren Beitrag zu sowas leisten.

Eigentlich ist es ja ein schöner Bus, aber was sich die Scripter gedacht haben dabei weiss ich nicht so recht. Da hat man einigen Firlefanz eingescripter, wichtiges aber entweder geändert oder aus den copy-and-paste-und-dann-umwurschteln Scruipten entfernt. Bevor ich mich angefangen habe aufzuregen über die vertauschten oder gelöschten Trigger für die Türsteuerung hab ich ins Script geschaut und zumindest die vertauschten Doorfront-Trigger geändert, damit an gewohnter Stelle zumindest Tür 2 bis 4 belegt sind. Allerdings scheint der Trigger für Tür 1 (also Doorfront0) komplett weg zu sein, sodass ich mir da nur getrennt Tasten auf öffnen/schließen legen kann. Da hätte ich aber gerne Standard-Trigger die wie die anderen funktionieren, also eine Taste fürs öffnen und schließen. Da komme ich aber mit meinem Scriptwissen nicht weiter, und habe auch keinen Mod dafür gefunden. Ziel wäre es also ins Türscript einen Trigger einzubauen, der auf Doorfront0 so anspricht wie bei anderen Bussen auch (oder den anderen Türen) und somit die oberen beiden Türtaster steuert. Jemand eine Idee?

Die andere Sache sind die Steckschilder... Schöne Sache, aber funktioniert wieder nicht so wie man es denken würde, zum Beispiel wie in den M&R Bussen oder im O305 von Rolf. Man muss also über das hässliche Alt-Menü schildern. Ich würde gerne hier zumindest per Tastaturtrigger durchschalten können (vor und zurück), allerdings hat man aus dem Rollband-Script entsprechendes entfernt, dies auch so im Kommentar vermerkt. Warum und wieso weiss nur der Autor... Reste sind noch drin, beim Linienschild kann man zumindest über den normalen Rollband-ab Trigger die Nummer runterschalten, nicht aber rauf, und nicht das Ziel. Hat irgendwer das sich vielleicht entsprechend im 260 oder 280 umgeschrieben?

Ganz fein wäre natürlich eine Lösung, wo die Schilder oben vorne, an der Seite und hinten sich quasi wie Rollbänder durchschalten lassen, bei aktivem Zusatzschild unten rechts hinter der Windschutzscheibe diese aber durch dessen Ziel überschrieben werden würden, also wie bei den Steckschildern von M&R und im O305. Hintergedanke dahinter ist die übliche Praxis in den 80ern dass man sich zum Beispiel für Betriebsfahrten eben nicht die Mühe machen wollte alle Schilder zu tauschen oder zu entfernen, sondern einfach vorne ein zusätzliches Schild hingeklatscht hat.

Es ist sehr schade dass die von M&R 2013 eingeführten Steckschilder und deren Funktionsweise nahezu von 99% der Busse nicht angewendet wird, mit Ausnahme von Rolfs Bussen.

Mein Vorschlag wäre wenn man die Fahrzeiten eh anpasst, dass man direkt das Fahrplankonzept überdenkt. Finde auch dass der Dinopark durchaus oft bedient werden kann am Wochenende, aber ob auch da 10 Minuten sein müssen weiss ich nicht so recht. In der Realität würde man eher größere Busse einsetzen, dafür seltener und auf die Abfahrten/Ankünfte der Bahn abgestimmt. Und wie erwähnt: es ist quatsch dass die 304 manchmal gebrochen ist am Hauptbahnhof, zu Zeiten wo 2 Minuten nach Ankunft der andere Kurzläufer startet. Ergäbe nur Sinn wenn die Linie immer gebrochen wäre oder eigenständig wegen unterschiedlichem Fahrzeugeinsatz.

Speziell im Fall der 304 hatte ich es schon mal angesprochen: für die Linie reicht ein 30 Minuten-Takt zwischen Sechelsberg und Hbf, auch werktags. Morgens und Nachmittags zur HVZ einzelne Verstärkerwagen, alle Stunde weiter zum Sportflugplatz. Da die RB in Sechelsberg jede Stunde fährt und nur alle halbe Stunde verstärkt wird in der HVZ sollten sich die Abfahrtzeiten auch daran orientieren. Somit hätte man eh eigentlich nru die Wahl zwischen zwischen 15 oder 30 Min Takt (letzteres ist sinnvoller und realer), da ein 20 Min Takt die Anschlüsse verschlechtern würde. Ob die Linie nun über die Landstraße oder den Ort fährt würd ich abhängig von der Tageszeit machen, z.B. morgens immer durch den Ort in Richtung Bad Hügelsdorf, Nachmittags umgekehrt (Annahme: es gibt in der jeweiligen Richtung mehr Bedarf), Stündlich könnte es aber trotzdem eine Art Grundabdeckung geben. Ganz früh morgens (vor der HVZ und Sonntags vormittags) und Abends grundsätzlich nur über die Landstraße (da vielleicht die RB aussetzen). Also Zeitabhängig und nicht Abhängig ob Kurzläufer/Langläufer. Man könnte auch überlegen ob die Abendkurse über die Landstraße nicht stündlich auch in den Ort fahren und an der Alten Dorfstraße enden: also Bad Hügelsdorf, dann über Landstraße und Bahnhof zur Endhaltestelle Dortstraße, zurück über Buchenhain und Schleife über Bahnhof. Ähnliche Überlegung für den Nachtbus.

Auch der 10 Minuten takt der 301 erscheint mir für diesen Ort als zuviel des Guten. Hier würde ich auf einen 20 Minuten takt setzen Mo-Fr, 30 Min früh morgens, abends und am Sonntag. Das ganze anständig vertaktet mit der 306 dürfte völlig ausreichend sein. Es gibt da ja auch noch die KI-Linie... Kurzläufer der 306 nur in der HVZ und hauptsächlich in Lastrichtung.

314/316:

316 entkoppeln von der 301, zumindest Mo-Fr, da es Sinn macht Mo-Fr auf der 301 Gelenkbusse einzusetzen, auf der 316 aber nicht. Bedienung von Großweier und Altes Schloß ausdünnen, ist irgendwie auch zu viel. Bei Veranstaltungen im Alten Schloß (Chrono?) zusätzliche Fahrten ohne Schleifen über Malg, Kleingartensiedlung. Morgens einige wenige Verstärkerfahrten über Einsteingymnasium von den Dörfern in die Stadt, Nachmittags zum Schulschluß in Gegenrichtung. Könnten mit anderen Verstärkern verknüpft und durchgebunden werden. Gibt ja noch die Grundschule in Malg und die Fachhochschule in Mühl. Zwischen Malg und Bad Hügelsdorf könnte die 316 alle halbe Stunde fahren.

Wenn die 307 als Grundtakt alle 30 Minuten fährt, die 314 und 316 je alle 60 Minuten in die Dörfer, so ergibt das bei vernünftiger Vertaktung Bedienung alle 15 Minuten des Abschnittes Waldsee-Königsring, was auch ordentlich wäre für so eine kleine Stadt.

Etwas Mau ist/wäre aber die Bedienung über "Haus des Intendanten". Vielleicht würde eine zusätzliche Linie SInn machen, die Augustaplatz und Stadttheater direkt verbindet, zumal die touristisch auch interessanter wäre. Dafür könnte man die 314 zum Schweigrotherplatz führen und zur HVZ weiter bis Hauptbahnhof.

Das Nachtnetz ist weitgehend okay, hab mir aber die Taktungen noch nicht genau angeschaut. Angebracht wäre 30 Min Takt auf N1, 60 Min Takt auf den übrigen Linien. Letzte Abfahrt Sonntag bis Donnerstag um 1, Freitag bis Samstag durchgängig. Bei N1 wäre auch ein 15-Min Takt am Wochenende zu überlegen, vielleicht bis 1/2 Uhr.

N7 vielleicht Schleife über Malg, nur Stadtauswärts, Stadteinwärts nur Samstag/Sonntag ganz früh morgens.

Was mir auch noch auffällt ist dass ich glaube der Bus selbst ist nicht allzu wendig im Vergleich zu anderen Fahrzeugen. Mir scheint es manchmal so dass der Wendekreis eingeschränkt ist. Vielleicht können hier aber andere was dazu sagen, die viel mehr Busse nutzen. Bei mir ist es nur so ein Eindruck, weil ich mich schon öfters gewundert habe warum mir auch manchmal ein Abbiegen links mit diesem Fahrzeug schwer fällt, und ich rede hier nur vom 12m MAN.

Zitat von kocki

Zitat von DocOmsi

Naja SSD sind bei OMSI trotzdem grundsätzlich besser als HDD.^^ Den unterschied merkst du glaub mal.^^

Ich hatte mit meiner SSD mehr Probleme in Omsi als mit meiner HDD

Dann stimmt was mit der SSD nicht (Konfiguration?). Eine SSD ist schon von ihrer Art her besser geeignet für das was bei OMSI gefragt ist, da die Zugriffszeiten zig hundert mal höher sind, und auf diese kommt es an, nicht so sehr die Transferrate. Es werden zig tausende kleine verteilte Dateien geladen, das ist ein Horror für jede Festplatte. Schon mal Miniruckler bemerkt beim Blinker setzen oder oder Bremsen? Auch die Sounds dafür werden fast on the fly geladen und eine SSD kann das zig mal schneller. Trotzdem ist der größte Flaschenhals OMSI selber. Ein optimiertes OMSI würde auf HDD besser laufen als das jetzige auf SSD.

Um das Laden zu entlasten sollte man es auch nicht übertreiben mit der Sichtweite für die Objektentfernung. Hier ist auch Potential um das Nachladeruckeln für sich etwas zu verbessern.

Manni ist also Fahrschullehrer... Das erklärt einiges;-D

Zitat von INVG

Ich weiß das ist wirklich sehr kleinlich, aber man fährt direkt drauf zu. Kurz vor dem Landwirtschaftsmuseum

So ein Thread dient ja zum Sammeln von Meldungen. Ich denke da ist nichts kleinlich, jeder achtet auch auf andere Dinge. Die Entwickler priorisieren dann die Meldungen, denn oft macht es gar keinen Sinn bestimmte Sachen anzugehen wenn sie in gewisserweise von anderen Baustellen abhängig sind.

Ganz allgemein zu Fahrplänen:

Ich finde die müssten wirklich allgemein mehr Puffer bekommen. Das ist keine Map zum durchrasen, und man kann nun mal nicht mit 70 in die Serpentinen reinfahren. Auch bedarf das Fahren in den Dörfern äusserste Vorsicht beim Einbiegen. Ohne alle Spiegel zu kontrollieren und Schritttempo geht das nicht. Ich glaube gerade hier sammeln sich die meisten Verspätungen an, während auf der Nord-Süd Hauptachse es eigentlich gehen dürfte. Allerdings sind auch einfach Abschnitte noch zu knapp, z.B. Hbf - Dinopark, nicht nur wegen dem schwierigen Ein- oder Ausfahren am Dinopark (Stichwort Gegen-KI).

Allerdings finde ich auch dass eine Anpassung der Fahrpläne zum Schluss kommen sollte. Es macht mehr Sinn wenn erstmal die ganzen Geschichten mit Vorfahrt etc im griff sind, denn auch das Einfluss auf die Fahrzeit. Die Performance ebenso, denn wenn's zu oft stockt verbringt man auch länger an Kreuzungen mit links/rechts schauen, was man bei guter Performance mit kurzem Ändern der Sicht und auch der Wahrnehmung von Verkehr aus den Augenwinkeln erledigen würde. Die Idee die Nachtumläufe in die Tagespläne zu integrieren finde ich gut, das spart auch (Spieler/KI-) Leerfahrten ein.

Zitat von JediKnight122

Zitat von hajo

Das Schloss werde ich mir mal ansehen. Es ist aber tatsächlich an einigen Haltestellen so gedacht, dass sie etwas "unwegsam" sind

Mit welchen Bussen habt Ihr die Karte getestet? Ehrlich gesagt habe ich mich mit einem Gelenkbus noch nicht auf die Karte getraut, denn schon mit dem "kleinen" 12m MAN ist es an vielen Stellen schwierig. Ich habe die Kiste z.B. um die Schleife auf der 318 nicht ein mal ohne zurückzusetzen bekommen... Dabei sieht die eigentlich garnicht so eng aus.

Zitat von Stringbean

Can the A.I traffic be fixed? They are turning in front of me at junctions,

This will be very difficult to fix. It would need at least the paths to be redone, if not even the whole junctions. Maybe something for the time when the other problems are fixed. A workaround would be to reduce the traffic in these areas, especially for turning in directions which are bad for our routes.

Performance-Optimierung:

Man glaubt's ja garnicht wie viel parkende Autos an Frames wegnehmen können... Es gibt auf der Karte einige sehr große Parkplatzbereiche, zum Beispiel am Hauptbahnhof, am Dinopark, im Gewerbegebiet... Es wäre sehr Hilfreich wenn für die dort stehenden Autos eine separate Parklist angelegt werden würde. Da man in diese Bereiche nicht so genau einsieht könnte diese noch deutlich reduziertere KI-Modelle beinhalten als bei den am Straßenrand parkenden Autos. Zumindest wäre man deutlich flexibler bei den Einstellungen für parkende Autos, beziehungsweise könnte sich für die Standardparkplätze etwas bessere Modelle gönnen und auf den großen sparsamer sein mit Poly-Schleudern. Denn leider lädt OMSI diese Autos schon sehr früh und auch wenn man sie nicht sieht schlagen sie hart auf die Performance wenn man auf diese zufährt. Und pauschal die Einstellungen runterschrauben auf z.B. 10-20% würde den Straßenrand dann doch sehr langweilig erscheinen lassen. So hätte jeder die Wahl und mehr Möglichkeiten zum Optimieren.

Apropos KI-Autos: die bremsen doch ganz schön hart kurz vor dem Halt. Sieht ziemlich doof aus und gefühlt ist es von 20 auf 0 in Millisekunden. Schön bei Staus zu beobachten. Etwas Feintuning wäre hier für die Optik fein.

Bei der Fahrt aus Sechelsberg Richtung Stadt muss in der Kurve kurz vor Haltestelle Bildeiche irgendwas sein, denn die Passagiere meckern da immer. Selbst wenn man mit recht gemütlichem Tempo dort unterwegs ist und nirgends aneckt. Ähnliches gibts auf der dreispurigen Straße zwischen Gewerbegebiet und der folgenden Ampelkreuzung. Sowas ähnliches kam nach dem Bahnübergang am Militärmuseum beim rechts abbiegen Richtung Bad Hügelsdorf, wurde aber mit dem letzten Patch beseitigt. Vielleicht ähnliche Ursache...

Am besagten Bahnübergang kam mir 13:55 etwa aus Richtung Stadt eine Bahn angefahren, verschwand aber mitten auf dem Bahnübergang. Kurz danach folge gleich eine weitere Bahn die nicht verschwand. Ähnliches hatte ich schon mal in Gegenrichtung beobachtet, allerdings ohne dass noch eine Bahn kam. Kürzlich fuhr die Bahn aber korrekt rüber...

304er KI Busse zwischen Gewerbegebiet und Bad Hügelsdorf nehmen übrigens auf der dreispurigen Straße immer die linke Spur. Da würde ich eher im entsprechenden StationLink sie über die rechte Spur führen und vor der Kreuzung dann auf die linke Spur fahren lassen.

Ein großes Ärgernis sind finde ich immer noch an vielen Kreuzungen das notorische nicht-beachten der Verkehrsregeln seitens der KI. Dan donnert einem schon mal von der Seite hinten mit großer Geschwindigkeit die KI rein, manchmal so stark dass eine Weiterfahrt nicht mehr möglich ist. Gutes Beispiel dafür ist die Kreuzung nach der Haltestelle Mozartstraße (wo übrigens NIE jemand einsteigt...) in Richtung Kirchplatz. Ich komme ja von der Vorfahrtstraße... Auffällig finde ich das solche Situationen meist an recht einfachen Kreuzungen passieren, nicht an komplizierten. Ich bin mir nicht ganz sicher, aber kann es sein dass diese aus Splines sind uind nicht aus einem Kreuzungsobjekt? Das würde einiges erklären, denn dann kann man sich auch das Eintragen der Prioritäten sparen, es wird nicht viel nutzen. Die KI würde da immer grundsätzlich zum letzten Splineabschnitt vorziehen. Könnte man eigentlich nur durch backen dieser Splines lösen.

Nach der Haltestelle Käferklub kommt ja irgendwann die T-Kreuzung wo es geradeaus zur Autobahn gehen soll und rechts Richtung Sechelsberg. Ich kann mir nicht vorstellen dass hier Rechts vor Links gelten soll, aber es fehlt jede Beschilderung. Es würde Sinn machen hier die Vorfahrt für Stadt <-> Autobahn zu beschildern und die Prioritäten entsprechend einzustellen.

Am Hauptbahnhof versuchen PKWs in den Busbereich einzufahren, verschwinden dann kurz darauf. Grund ist dass ein ganz winziger Pfad nicht für PKWs gesperrt ist auf der Hauptstraße, der aber die PKWs zum Bahnhofsplatz führt. Er befindet sich zwischen den beiden Pfadbögen zur Ein- und Ausfahrt.

Der Entrypoint im Betriebshof der VBBH ist auch etwas ungünstig. Startet man dort zu einer ungünstigen Zeit fährt einem direkt ein KI Bus hinten rein. Folge: Reparaturzeit 75 Minuten. Guter Start in den Tag;-D

Den Tankbereich im Betriebshof hätte ich mir aber nicht in der Halle gewünscht, sondern an einer Zapfsäule draussen auf dem Betriebsgelände.

Mittlerweile finde ich die Zuweisung der Linien zu "Montag bis Freitag", "Samstag" und "Sonntag" nicht mehr günstig. Das schränkt doch sehr ein wenn man die [car_use} Funktion nutzen möchte, die am meisten was bringt wenn man linienbezogen sie nutzt. Da würde ich mir eine Aufteilung wünschen hin zu einer Gruppierung in Linien. Gebündelte Linien natürlich zusammen, aber die Wochentage können da ruhig den Linien(gruppen) untergeordnet werden. Hätte auch Vorteile für zukünftige Chrono-Ereignisse, denn dann müsste man nicht gleich alle Linien deaktivieren und in der Chrono wieder hinzufügen, sondern nur die die man wirklich braucht. Im Falle des Unwetters zum Beispiel nicht "Montag bis Freitag" sondern nur 304. Solche Fehler wie mit dieser Dopplung der Kurse wären dann vielleicht auch leichter zu finden und zu beheben.

Gerade den Fahrplan der 304 finde ich irgendwie unpraktisch bzw. unlogisch, mal unabhängig davon dass es immer noch ein Gehetze ist, was gerade BBS Fahrer ärgern dürfte. Unlogisch aus vielerlei Hinsicht: zum Beispiel die gebrochenen Kurse. Ein "Kurzläufer" kommt vom Dinopark am HBF an, zwei Minuten später ist Abfahrt der Kurzläufers nach Sechelsberg. Das wären durchgebundene Fahrten eigentlich.... Und da die Kurzläufer mit den Langläufern verknüpft sind kann man auch nicht wirklich im Fahrzeugeinsatz differenzieren, denn jeder Kurs fährt alles. Auch dass in Sechelsberg tagsüber beide varianten gemischt gefahren werden verursacht mir etwas Kopfkratzen;-) Würds ja verstehen wenn zum Beispiel Abends alle Kurse über die Landstraße wären, aber tagsüber ist es halb-halb. Auch würde ich verstehen wenn man differenzieren würde dass beispielsweise morgens in die eine Richtung durch den Ort gefahren werden würde und Nachmittags in die andere. So ist es aber ein Kuddelmuddel, und ein 15-Min Takt sowieso etwas too much für diesen Ort, der ja auch noch Bahnanschluß hat. Wie wäre es beim nächsten Fahrplanwechsel die Äste zu tauschen und Sechelsberg bis Sportflugplatz durchzubinden und den Dinopark nur vom Hauptbahnhof aus zu bedienen? Grundtakt 30 Minuten mit einigen Verstärkern morgens und Nachmittags, eventuell mit Durchbindung von/zu den Schulen. südwärts oder als Variante zum Gewerbegebiet Hohenlohe über Schlesier Straße.

Was mich am Bus sehr stört ist der Font bei der Verspätungsanzeige. Das hätte ich schon gerne im Blick sichtbar, ist aber ohne die Sicht zu ändern und zu zoomen leider kaum zu entziffern. Die Farbe hilft da nicht viel, ich glaube erst bei 3 Min Differenz gilt Verspätung oder Verfrühung. Und Platz wäre in dem Feld das deutlich zu vergrößern. Übrigens wäre es auch sehr praktisch im Verkaufsmenü zu sehen wie man zeitlich liegt, denn das ist ja das Standardmenü an den Haltestellen.

Da ich kein Freund der OMSI-Statusleiste bin (siehe oben) wäre auch die Anzeige der Innentemperatur im VDV Display schön. Aussentemperatur ist ja drin, und die Innentemperatur kann man leider nicht fühlen;-D

Die Oma wollte doch tatsächlich letztens ein Touri-Ticket... Blieb aber natürlich stumm weil es für sie keine Hügelsdorf-Sprachdateien gibt. Könnte man aber sicher im Ticketpack mit einer Alterseinschränkung umgehen, oder neuen Sprachdateien. Ich hoffe ja dass es Hügelsdorf bald auch in ein Update der Halycon-Menschen-Ki-Packs schafft.