Beiträge von wurstbrot

Jetzt mal nach etwas länger:

Direct3D Device Lost kam nicht mehr vor. Denke das wird am Kompatibilitätsmodus liegen. Längere Freezes gab es schon, ich meine aber dass die KI-Autos hier die Übeltäter waren. Ich hatte in den AI Listen vereinzelte Halycon AI-Pack-Autos drin, aber eigentlich recht sparsam. Sie scheinen aber wirklich zu heavy zu sein für den AI-Betrieb. Die Kombination aus Spandau-Autos und Hamburg-Autos flutscht besser als auch wenn nur ein einziges Halycon-Auto in der Liste ist. Ohne diese kann ich fast die Menge verdoppeln. An manchen Stellen drückte eine Häufung dieser Autos sogar auf die fps um gut ein Drittel, was für mich nicht akzeptabel ist.

Sorgen machen mir noch einige Busse von denen es keine KI-Versionen gibt und Repaints die ganz wild png, jpg oder tga als Format nutzen, obwohl schon seit Jahren bekannt ist dass OMSI einzig und allein das dds Format liebt. Das wird nämlich auch die Engine überlasten, und genau diese Kandidaten sind dann mal eben schwarz aus der Entfernung. Möglicherweise verschluckt sich OMSI beim Laden manchmal auch daran.

Btw: "maximale Anzahl von Bussen" in den Optionen bezieht sich doch im Gegensatz zu den anderen AI Einstellungen auf den gesamten Verkehr auf der ganzen Karte, oder? Wenn ich z.B. 50 einstelle, fährt eben auch nur auf der ganzen Karte max 50 Solo bzw. 25 Gelenkbusse rum? Das ist schon wichtig für flächenmässig große Karten.

Zitat von Lenny21

Ist nämlich falsch. Man kann es "darstellen" bzw. demonstrieren, genau so wie 144 Hz. (In einem Slomo Video)

Und die Kamera mit der das gemacht wird läuft exakt mit der Frequenz wie just in der Millisekunde das abgefilmte? Und das Abspielgerät auf welchem man sich das anschaut auch? ;-D Nein...

Vsync verzögert nur die Bildausgabe um das Tearing zu verhindern. Das funktioniert auch, zulasten eines erheblichen Input Lags und Reduktion der Tatsächlichen Bildraten. Sinkt im 60 Hz Modus die Bildrate unter 30 fps, halbiert sie Vsync defacto auf 30, damit die Bilder wieder übereinstimmen bzw exakt teilbar sind mit der Bildwiederholfrequenz. Dreifach gepuffert ergibt das ein besseres Ergebnis 60->40->20 etc, der Lag wird aber noch größer. Bei Freesync und Gsync gibts das nicht, beziehungsweise erst wenn die fps höher sind als die Monitorfrequenz. Deswegen ist es ratsam dafür zu sorgen hier nicht über diesen Wert zu kommen und knapp drunter in-game zu limitieren.

Tearing ist aber nur das eine was man los wird mit G/Freesync. Die synchronisation der Frames mit der Bildwiederholfrequenz hat zu Folge dass das Bild geschmeidiger ist. Und das kann man eben nicht abfilmen, Tearing schon. Der Monitor läuft dann eins zu eins mit der Grafikkarte mit und ändert seine Frequenz entsprechend dauernd. Deshalb ist das "sync" hier wirklich synonym für synchron, während Vsync nur verzgört. Der Monitor läuft weiter mit der gleichen Frequenz, die Grafikkarte liefert ihm die Bilder so dass er bei voller Freqenz bzw den entsprechenden Teilern gut bedient ist. Mit "synchron" hat das wenig zu tun, ist aber in vielen Situationen besser als nix. Nachteil von Vsync sind auch enorme Sprünge der tatsächlichen Bildraten, die teilweise auch nicht von den Countern angezeigt werden. Sinkt man in einem Spiel von 60 auf 59 fps im Vsync Modus, macht man tatsächlich einen Sprung von 60 auf 30 bzw. 40 dreifach gepuffert. In Omsi sieht man dann zum Beispiel die Autos im KI Verkehr zwischendurch zittern, obwohl die fps augenscheinlich sich kaum geändert haben. Wäre Gync aktiv würde da nix zittern, da die Synchronisation das ausgleicht. Wäre aber ein "echter" enormer Sprung von zum Beispiel von jetzt auf gleich von 60 auf 40, würde man das auch merken. Abhilfe wäre hier OMSI auf einen sinnvollen, aber erreichbaren Wert über der Free/Gsync-Schwelle zu limitieren, z.B. zwischen 35 und 40 fps, je nach Karte. Gegen irgendwelche Mikroruckler die durch Skripte verursacht werden hilft aber alles nix.

Input-Lag bei OMSI:

Man könnte meinen bei OMSI spielt er keine Rolle. Tut er aber doch. Wenn man halbwegs Bildraten erreicht jenseits der 30 fps und das Spiel konstant läuft merkt man den Unterschied beim Fahren schon sehr, insbesondere in Gefahrensituationen wo schnelle Reaktion gefragt ist. Bei aktiven Vsync hat man das Gefühl der Bus würde einen Tick zu träge reagieren. Tearing hab ich im übrigen in OMSI seltenst gesehen, weshalb ich auf den Einsatz von Vsync in OMSI auch ohne G/Freesync verzichten würde. Vielleicht hat man welches wenn man öfters die Aussenansicht verwendet, keine Ahnung... Bei anderen Spielen ist Tearing ganz schön übel.

Zitat von Lenny21

Wenn man das Bild freezt, kann man es manchmal erkennen.

Wenn sich Deine Aussage auf Gsync oder Freesync bezieht: nein, auch dann nicht. Denn erstens ist die Aufnahme mit einer festen Bildwiederholrate und zweitens spielt es Dein Monitor ebenfalls mit einer festen ab. Du würdest keinen Unterschied sehen, auch nicht im Standbild. Es geht quasi nur mit eigenen Augen vor einem solchen Gerät. Wenn Du jetzt aber zum Beispiel in ein Geschäft gehst und es Dir zeigen lässt, musst Du schon sehr kompetente Verkäufer haben dass die Dir echt was präsentieren können z.B. einen mit / ohne Vergleich.

Übrigens geht der Effekt natürlich etwas flöten je höher die Bildwiederholrate ist. Bei 144 fps / Hz ist es natürlich weniger wahrnehmbar als bei 30 bis 60. Allerdings finde ich diese Technik perfekt eben für diesen Bereich, und finde es eigentlich sogar schade dass es nicht schon ab 20 greift.

Das hatte ich auch vor einer Weile nach einer längeren OMSI-Pause, bei mir scherte aber der Bus irgendwie dann immer etwas nach links beim aktivieren der Maussteuerung (bei mir mit Leertaste). Lösung war banal: im Alt-Menü rechts unten auf Steuerungen gehen und dort schauen dass keine andere Steuerungsart aktiv ist. Einfach da rumprobieren, dann sollte beim aktivieren der Maussteuerung über den Hotkey nicht diese seltsame Neuausrichtung passieren, die für das Problem sorgt, sondern der Stand von vorher beibehalten werden.

Doch, bei Office merkt man auch einen Unterschied, aber sicher nicht zwischen 60 und 75 Hz. Aber zwischen 60 und 120 oder 144. Vor allem beim Scrollen von Texten oder Verschieben von Fenstern etc.

In OMSI bringen mehr als 60 Hz nix, da OMSI in den allerwenigsten Fällen über 60 fps kommt. Dafür also einen Monitor anzuschaffen mit viel Hz bringt nicht viel. Allerdings bringt es schon was auf Gsync oder Freesync zu achten. Hier wird die Bildwiederholrate mit der Framerate synchronisiert und das macht einen spürbaren Unterschied, mal unabhängig davon dass dann Phänomene wie Tearing der Vergangenheit angehören. Allerdings ist hier darauf zu achten ab wie viel Hz/fps der Modus überhaupt greift. Meist ab 30 bei Gsync und ab etwa 40 bei Freesync. Je niedriger der unterste Wert ist wäre hier besser, da wir uns in diesen Bereichen meistens bewegen. Man muss dann auch dafür sorgen dass OMSI aber mindestens diese 30 fps liefert (oder wo auch immer die untere Grenze beim gekauftem Modell ist). Und wenn man nie Gsync oder Freesync in Anwendung gesehen hat, der kann es direkt sein lassen nach Videos zu suchen die das demonstrieren, denn es geht nicht, kann man nur direkt am Gerät sehen (oder besser gesagt fühlen). Im Falle von OMSI würde ich sagen man merkt es vor allem am viel geschmeidiger vorbei fahrenden Autos. Oder wenn die fps-Rate dann mal von 30 auf 29 springt und man wieder im normalen asynchronen Modus ist wie ohne diese Technik.

dds ist glaube ich sowieso aus den unterschiedlichsten Gründen das beste Format für Omsi, wenn ich da hand anlege würde ich das am liebsten dann direkt auch in dds umwandeln. Allerdings wie schon erwähnt, selbst beim löschen der bmps bleibt das Ergebnis das gleiche. Muss mal schauen, vielleicht fehlt da (dann bei der TGA...) der Alphakanal, aber ich glaube in dem Fall würde das doch auch ohne Nässe seltsam aussehen?

Interessant ist auch dass manche Markierungen bei Nässe ganz fehlen, andere wie hier die Gras-Textur haben (was wohl eher Durchsichtigkeit bis zum Boden ist...)

Gibt ein paar, aber erstmal teste ich das an folgender:

/Splines/Linie_poziome/P-10-6m_v2.sli

Gibt auch das gleiche als /Splines/Lodz/Linie_poziome/P-10-6m_v2.sli, aber im konkreten Fall wird auf die oben genannte zugegriffen.

Ist wohl irgendeine Kopie+Modifikation aus SimpleStreets schätze ich.

Wenn ich die bmp's umbenenne, also als Endung .bak mache, in der SLI weiterhin auf die TGA verwiesen wird, ist das Ergebnis optisch gleich. Allerdings lasse ich mir im Spiel im Debug Fenster alle Texturen auflisten taucht auf einmal tatsächlich die 1-1.bmp als "failed" auf. Wie gesagt, optisch kein Unterschied, und mache ich Regen weg taucht sie auch wieder auf. Aber irgendwie versucht er dann doch auf die bmp zuzugreifen, sonst gäbts die Meldung in der Texturliste nicht. Und irgendwas wird dann wohl mit der BMP nicht stimmen, oder?

Zitat von fOcUs04

Das liegt meisst an den .cfg-Dateien:

Beispiel asphalt2.dds.cfg

[moisture]

[puddles]

Wenn zu der betreffenden Spline diese cfg-Datei fehlt, oder den falschen Namen (in diesem Fall jetzt die dds) hat, wird das wohl nicht geladen.

Da müsste man jetzt die betreffenden Spline-Ordner duchschauen, welche Texturen mit welcher Endung da sind und ob die dazu passende cfg-Datei vorhanden ist.

Sprich: Wenn jpg-Textur müsste die Datei asphalt2.jpg.cfg und so weiter heissen.

mfg

Daniel

Alles anzeigen

Da kommen wir der Sache näher...

Hab mir eben einen Zebrastreifen rausgesucht der grün wird bei Regen.

in der SLI-Datei dazu steht folgendes:

[texture]
1-1.tga

[matl_alpha]
1

Im Texture-Ordner gibts folgende Dateien:

1-1.bmp

1-1.bmp.cfg

1-1.tga

1-1.tga.cfg

Die cfg Dateien enthalten jeweils wie Du im Beispiel angeführt hast auch das folgende:

[moisture]
[puddles]

Also an sich stimmts doch: die SLI greift auf die TGA zu und die ist wie es aussieht für Regen dann richtig konfiguriert. Und trotzdem verschwindet die Textur und wird erst sichtbar wenn man Nässe von den Straßen wegmacht. Spaßeshalber werde ich testweise in der SLI mal das hin zur BMP leiten und schauen was dann passiert...

Edit: leite ich zur BMP um, sind nicht nur die weissen Streifen des Zebrastreifens bei Nässe grün, sondern die gesamte Fläche der Textur;-D

Naja es kann sein dass bei der Installation ich was überschrieben habe, da mir anfangs Objekte und Splines gefehlt haben. Selber hab ich da nicht rumgefriemeltnur Kollisionen entfernt bei polnischen Gebüschen. Ich denke mal die Splines bzw Objekte sind eben so, nicht jeder Objektersteller nimmt es so genau mit sowas.

Ich weiss aber nicht genau was Du mit einem Unterordner "Rain" meinst. Wenn ich mir zum Beispiel Marcels Straßensplines angucke, sehe ich da auch nur im Texturordner welche mit "Winter" und "WinterSnowFall", und da sie OMSI-Vanilla sind funktionieren die ja astrein bei Regen.

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.