Beiträge von wurstbrot

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.

Zitat von JediKnight122

Sollte im nächsten Update mit der Umstellung auf Tracks und Trips behoben sein

Umstellung auf das olle Tracks und Trips? Wieso das? Der Bus im Hintergrund fährt offenbar mit falschem Repaint, das ist eher ein Hinweis auf zu wenige Fahrzeuge in der Ailist, da braucht OMSI immer mehr als eigentlich nötig. Sind nicht genügt da, pickt es sich einen Bus mit Standardrepaint aus oder dem nächstbesten. Es gibt keinen Vorteil das alte System zu verwenden, nur Nachteile. Selbst das Anfahren und Verlassen der Haltestellen kann sich dadurch ändern, da die Anlegeentfernung nicht korrekt beim alten System funktioniert. Ganz zu schweigen davon dass es sich dann mit Chrono-Events etc wahrscheinlich erledigt hat, ebenfalls mit eventuell mal die Option car_use zu benutzen. Das alte System taugt eigentlich nur noch für Schienenfahrzeuge, da scheint es stabiler zu laufen beziehungsweise nur so zu funktionieren.

Falls Ihr Euch wirklich dazu entschließt, bitte die StnLinks und Typ2 Trips zusätzlich in einen Ordner packen damit man es auch verwenden kann.

Zitat von Pactain

HST „Auf der Halde“. Wenn man dort 40Min Pause hat und man sich nach ganz hinten stellt fährt der KI Verkehr nicht an einem vorbei. Vllt extra Pausenhaltestelle bauen ?. Ist bei anderen Linien ja vorhanden. Nur dort wäre es sicher auch von Nöten.

Das würde zum Setting dort nicht ganz passen dort eine komplexe Haltestellenanlage zu bauen. Eher sollte man den Fahrplan anpassen und dort nur eine kurze Pause einbauen und die längere auf das andere Ende verschieben. Bis dahin kannst Du dort einfach eine Ehrenrunde drehen wenn ein anderer Bus kommt.

Nach der Erweiterung meiner AI List häuften sich wieder Freezes beim Nachladen gerade zu Spitzenzeiten. Klar ist glaub ich dass das ganze vor allem mit Bussen zu tun hat, weniger mit KI-Autos (außer man würde hier übertreiben). Allerdings ist die AI-Liste die ich hier erweitert habe auf Fikcyjny Szczecin eigentlich recht human: es fahren KI-Versionen der Stadtbus-MANs und M&R MANs rum, die recht bekannt sind dafür gut für den KI-Einsatz zu sein. Dann aber noch z.B. der Solaris II in der PL-Version, in der AI-List allerdings reduziert auf Voith-Varianten, damit ja keine ZF-Scripts noch die fps ruinieren, inklusive eigens reduzierten AI-Sound Configs, wo alles unnötige rausgeflogen ist. Leider ist da Fahrzeug trotzdem nicht ganz sauber, sieht man schön an den ganzen Meldungen in der Log, dass ein Haufen Texturen im Mesh entweder nicht eingetragen sind oder nicht mit der Modelconfig übereinstimmend, was glaube ich schon im Muttermodell "Solaris BVG" von Alterr der Fall ist. Könnte in der Summe nämlich auch OMSI überwordern, wenn z.B. an der Kachelgrenze gleich 4 Fahrzeuge der Sorte geladen werden. Allerdings habe ich im SPielbebetrieb "nolog" aktiv, um in solchen Fällen zumindest die Schreibzugriffe zu begrenzen. Ich weiss noch nicht ob ich mir noch die Mühe machen sollte mit einem Hexeditor in den o3d-Dateien die Texturzuweisung da wo es geht zu korrigieren, oder nicht... Für einen simplen Test ob es was bringt und wenn ja wie viel es bringt ist mir der Aufwand schon zu groß, deshalb würde mich da Eure Erfahrung interessieren. Nur zur Klarstellung: diese Busse spucken in der Log keine Fehler in den Scripts aus, sondern nur das übliche mit den Texturen. Könnte mir vorstellen dass das in der Summe reinhaut. Hier mal ein Beispiel:

274 18:27:41 -  -     Warning:       File Vehicles\Solaris Urbino PL\model\model_Urbino 12_3doorsACTIA.cfg: texture filename 04.dds not found in mesh file Vehicles\Solaris Urbino PL\model\MOKI\dvertca.o3d!
275 18:27:45 -  -     Warning:       File Vehicles\Solaris Urbino PL\model\model_Urbino 12_3doorsACTIA.cfg: texture filename 05.png not found in mesh file Vehicles\Solaris Urbino PL\model\Urbino_12_3doors_MOKI\Tuer_VV.o3d!
276 18:27:45 -  -     Warning:       File Vehicles\Solaris Urbino PL\model\model_Urbino 12_3doorsACTIA.cfg: texture filename 04.dds not found in mesh file Vehicles\Solaris Urbino PL\model\Urbino_12_3doors_MOKI\Tuer_VV.o3d!
277 18:27:45 -  -     Warning:       File Vehicles\Solaris Urbino PL\model\model_Urbino 12_3doorsACTIA.cfg: texture filename 05.png not found in mesh file Vehicles\Solaris Urbino PL\model\Urbino_12_3doors_MOKI\Tuer_VH.o3d!
278 18:27:45 -  -     Warning:       File Vehicles\Solaris Urbino PL\model\model_Urbino 12_3doorsACTIA.cfg: texture filename 04.dds not found in mesh file Vehicles\Solaris Urbino PL\model\Urbino_12_3doors_MOKI\Tuer_VH.o3d!
279 18:27:46 -  -     Warning:       File Vehicles\Solaris Urbino PL\model\model_Urbino 12_3doorsACTIA.cfg: texture filename 05.png not found in mesh file Vehicles\Solaris Urbino PL\model\Urbino_12_3doors_MOKI\Tuer_VV_1.o3d!
280 18:27:46 -  -     Warning:       File Vehicles\Solaris Urbino PL\model\model_Urbino 12_3doorsACTIA.cfg: texture filename 04.dds not found in mesh file Vehicles\Solaris Urbino PL\model\Urbino_12_3doors_MOKI\Tuer_VV_1.o3d!
281 18:27:46 -  -     Warning:       File Vehicles\Solaris Urbino PL\model\model_Urbino 12_3doorsACTIA.cfg: texture filename 05.png not found in mesh file Vehicles\Solaris Urbino PL\model\Urbino_12_3doors_MOKI\Tuer_VH_1.o3d!
282 18:27:46 -  -     Warning:       File Vehicles\Solaris Urbino PL\model\model_Urbino 12_3doorsACTIA.cfg: texture filename 04.dds not found in mesh file Vehicles\Solaris Urbino PL\model\Urbino_12_3doors_MOKI\Tuer_VH_1.o3d!
283 18:27:46 -  -     Warning:       File Vehicles\Solaris Urbino PL\model\model_Urbino 12_3doorsACTIA.cfg: texture filename 05.png not found in mesh file Vehicles\Solaris Urbino PL\model\Urbino_12_3doors_MOKI\Tuer_VV_2.o3d!
284 18:27:46 -  -     Warning:       File Vehicles\Solaris Urbino PL\model\model_Urbino 12_3doorsACTIA.cfg: texture filename 04.dds not found in mesh file Vehicles\Solaris Urbino PL\model\Urbino_12_3doors_MOKI\Tuer_VV_2.o3d!
285 18:27:46 -  -     Warning:       File Vehicles\Solaris Urbino PL\model\model_Urbino 12_3doorsACTIA.cfg: texture filename 05.png not found in mesh file Vehicles\Solaris Urbino PL\model\Urbino_12_3doors_MOKI\Tuer_VH_2.o3d!
286 18:27:46 -  -     Warning:       File Vehicles\Solaris Urbino PL\model\model_Urbino 12_3doorsACTIA.cfg: texture filename 04.dds not found in mesh file Vehicles\Solaris Urbino PL\model\Urbino_12_3doors_MOKI\Tuer_VH_2.o3d!
287 18:27:46 -  -     Warning:       File Vehicles\Solaris Urbino PL\model\model_Urbino 12_3doorsACTIA.cfg: texture filename 05.png not found in mesh file Vehicles\Solaris Urbino PL\model\Urbino_12_3doors_MOKI\Bode_nowe\drzwi0.o3d!
288 18:27:46 -  -     Warning:       File Vehicles\Solaris Urbino PL\model\model_Urbino 12_3doorsACTIA.cfg: texture filename 04.dds not found in mesh file Vehicles\Solaris Urbino PL\model\Urbino_12_3doors_MOKI\Bode_nowe\drzwi0.o3d!
289 18:27:46 -  -     Warning:       File Vehicles\Solaris Urbino PL\model\model_Urbino 12_3doorsACTIA.cfg: texture filename 05.png not found in mesh file Vehicles\Solaris Urbino PL\model\Urbino_12_3doors_MOKI\Bode_nowe\drzwi1.o3d!
290 18:27:46 -  -     Warning:       File Vehicles\Solaris Urbino PL\model\model_Urbino 12_3doorsACTIA.cfg: texture filename 04.dds not found in mesh file Vehicles\Solaris Urbino PL\model\Urbino_12_3doors_MOKI\Bode_nowe\drzwi1.o3d!
291 18:27:46 -  -     Warning:       File Vehicles\Solaris Urbino PL\model\model_Urbino 12_3doorsACTIA.cfg: texture filename 05.png not found in mesh file Vehicles\Solaris Urbino PL\model\Urbino_12_3doors_MOKI\Bode_nowe\drzwi2.o3d!
292 18:27:46 -  -     Warning:       File Vehicles\Solaris Urbino PL\model\model_Urbino 12_3doorsACTIA.cfg: texture filename 04.dds not found in mesh file Vehicles\Solaris Urbino PL\model\Urbino_12_3doors_MOKI\Bode_nowe\drzwi2.o3d!
293 18:27:46 -  -     Warning:       File Vehicles\Solaris Urbino PL\model\model_Urbino 12_3doorsACTIA.cfg: texture filename 05.png not found in mesh file Vehicles\Solaris Urbino PL\model\Urbino_12_3doors_MOKI\Bode_nowe\drzwi3.o3d!
294 18:27:46 -  -     Warning:       File Vehicles\Solaris Urbino PL\model\model_Urbino 12_3doorsACTIA.cfg: texture filename 04.dds not found in mesh file Vehicles\Solaris Urbino PL\model\Urbino_12_3doors_MOKI\Bode_nowe\drzwi3.o3d!
295 18:27:46 -  -     Warning:       File Vehicles\Solaris Urbino PL\model\model_Urbino 12_3doorsACTIA.cfg: texture filename 05.png not found in mesh file Vehicles\Solaris Urbino PL\model\Urbino_12_3doors_MOKI\Bode_nowe\drzwi4.o3d!
296 18:27:46 -  -     Warning:       File Vehicles\Solaris Urbino PL\model\model_Urbino 12_3doorsACTIA.cfg: texture filename 04.dds not found in mesh file Vehicles\Solaris Urbino PL\model\Urbino_12_3doors_MOKI\Bode_nowe\drzwi4.o3d!
297 18:27:46 -  -     Warning:       File Vehicles\Solaris Urbino PL\model\model_Urbino 12_3doorsACTIA.cfg: texture filename 05.png not found in mesh file Vehicles\Solaris Urbino PL\model\Urbino_12_3doors_MOKI\Bode_nowe\drzwi5.o3d!
298 18:27:46 -  -     Warning:       File Vehicles\Solaris Urbino PL\model\model_Urbino 12_3doorsACTIA.cfg: texture filename 04.dds not found in mesh file Vehicles\Solaris Urbino PL\model\Urbino_12_3doors_MOKI\Bode_nowe\drzwi5.o3d!
299 18:27:47 -  -     Warning:       File Vehicles\Solaris Urbino PL\model\model_Urbino 12_3doorsACTIA.cfg: texture filename body_wew.png not found in mesh file Vehicles\Solaris Urbino PL\model\Urbino_12_3doors_MOKI\Interior 2a.o3d!
300 18:27:47 -  -     Warning:       File Vehicles\Solaris Urbino PL\model\model_Urbino 12_3doorsACTIA.cfg: texture filename regen.tga not found in mesh file Vehicles\Solaris Urbino PL\model\Urbino_12_3doors_MOKI\Wagenkasten.o3d!

Mit einem Hexeditor und Prüfung der Modelldateien könnte ich da sicher 70-80% von beseitigen...

Das andere was eine Rolle spielen könnte ist die Tatsache dass eigentlich jeder Bus davon eine andere andere Repaint-Textur hat. Vor allem weil in dieser Version sonst keine Wagenummer oder Kennzeichen möglich wären. 4 bis 5 verschiedene Repaints auf einmal an der Kachelgrenze könnten auch für Schluckauf sorgen, selbst wenn die SSD diese eigentlich mit links schafft, und auch wenn sie alle mittlerweile im dds Format vorliegen.

Ein Test mit entrümpeltem Vehicles Ordner brachte übrigens nur ernüchterndes Ergebnis: nach vorübergehendem Rausschmiß von 70-80% des Inhalts verbesserte sich die Situation nur so minimal dass es man es zu Messfehlern zählen könnte. Ich weiss allerdings nicht ob vielleicht das simple Vorhandensein von vielen Repaints bei einem Bus und/oder vielen CTI-Dateien nicht auch eine Rolle spielt. Würd ich vielleicht demnächst testen... Glaub ich aber eher nicht.

Etwas anderes teste ich momentan auch aus, wird aber etwas brauchen bis ich da konkret was zu sagen kann:

Insbesondere wenn auf einer Karte viele Straßenbahnen und Züge zum Einsatz kommen, schnellt irgendwann die Anzahl der Fahrplan-KI nach oben, die dann ja auf die fps drücken. Das kennt ja auch jeder: nach dem Start von OMSI hat man in der ersten Runde gute fps, später wirds dann an gleichen Stellen geringer. Grund ist dass viele Fahrplan-Fahrzeuge in der Zwischenzeit geladen wurden und auch wenn sie nicht mehr zu sehen sind die Gesamtperformance belasten. Man kann das zwar insgesamt in den Optionen begrenzen durch den Regler "maximale Anzahl an Fahrplan-KI", allerdings hätte man je nach Karte unter Umständen irgendwann keine KI mehr die entgegen kommt, denn der große Trugschluss ist hier ja dass sich der Maximalwert auf die aktiven Kacheln bezieht. Tut er nicht, es gilt für die gesamte Karte! Und: ein Gelenkbus zählt doppelt, ein 3-fach-Gelenkbus dreifach und bei Bahnen kann sich nun jeder denken was das bedeutet. Und einmal geladen machen diese Fahrzeuge keinen Platz mehr für weitere, außer deren Tagesfahrplan ist zuende. Jetzt bin ich hingegangen und habe die Fahrpläne für Bahnen aufgeteilt, so dass sie nach einer Runde wirklich weg sind, so dass sie trotz einer Oberbegrenzung Platz machen würden für zig andere Busse. Ich bin mal gespannt... Denn eventuell macht es dann auch Sinn bei Buslinien Touren zu trennen die z.B. einmal morgens rausfahren und dann nachmittags, denn sie würden in der Zwischenzeit nicht gelöscht werden, selbst wenn sie ins Depot fahren. Reine KI-Linien könnte man auch entsprechend behandeln und so wertvollen Platz schaffen. Da muss ich aber noch über die Zeit beobachten.... Fakt ist dass ich normal gerne mal über die grenze von 200 Fahrzeugen geschossen bin, aktuell sind es dadurch um die 100.

Es gibt bei DDS mehrere Varianten: DXT1 mit und ohne Alpha, DXT3, DXT5... Bin mir nicht sicher, aber ich glaube für OMSI kommt DXT1 ohne Alpha für alle Dinge eben ohne Alpha in Frage, vor allem Innenraumkrempel. DXT5 ist wohl einfach ein besseres (?) DXT3 und kann auch mehrbittige Alphas. Gut geeignet für Außentexturen mit Alpha wo man sonst TGA genommen hat. Für Transparenzen mit einigen wenigen Decals könnte weiterhin TGA besser sein, da die Dateien um ein vielfaches kleiner sind. Und Busse mit diesen fliegen komischerweise auch nie einem um die Ohren.

Zur Qualität der Komprimierung muss man auch sagen dass das natürlich davon abhängt was man vor hat. Man sollte aber immer vor Augen haben dass die Busse auch mal vielfach in AI Listen auftauchen, und da kann schnell eben die Wahl des falschen Texturformats zu schwarzen Fahrzeugen führen, und schwarz sieht nun mal immer schlechter aus als eine Textur etwas minderer Qualität. Kann übrigens auch dem Spielerbus passieren... Allerdings tragen auch die Tools zur Erstellung bzw. Konvertierung der DDS Dateien, bzw. die Plugins zur Qualität bei. Da gibt es Unterschiede und die Meinungen gehen wohl weit auseinander was das beste Ergebnis liefert.

Hab schon genug "unter 2K" PNG Texturen gesehen die aber sowas von schnell schwarz wurden, z.B. beim SolarisBVG und seinen Varianten.

Zitat von Tabley-Kun

Nur ist der Speicherplatz immer zu beachten, nicht dass der Grafikspeicher der GPU nur mit dem Bus vollläuft und man dann nichts mehr von den restlichen Fahrzeugen und Objekten hat!

Eine TGA und PNG wird komprimiert geladen, im Speicher aber Pixel für Pixel unkomprimiert gehalten, wie eine BMP. DDS ist das einzige Format was im Grafikspeicher auch komprimiert gehalten wird. Es ist auch das Format mit dem OMSI neben BMP am Besten klar kommt und es sogar bevorzugt: findet OMSI eine gleichnamige dds Datei, wird diese allen Formaten gegenüber bevorzugt geladen, völlig egal welche Endung im Modell oder in den Configs/CTI's eingetragen ist.

Diesen ganzen Ärger mit schwarzen/durchsichtigen Fahrzeugen gibts eigentlich nur bei allen anderen Formaten ausser BMP und DDS. War schon bei OMSI 1 so, nur da wurden die Autos weiss;-D.

PNGs neigen definitiv sehr dazu schwarz zu werden nach einer Weile. Seitdem ich sie durch dds-Dateien ersetzt habe ist davon keins mehr schwarz geworden. Bei TGA kann dies auch passieren, aber wohl weniger häufig. Bei Fahrzeugen die nur dds verwenden ist es mir noch nie untergekommen: noch nie wurden HH Hafencity Autos bei mir schwarz, auf keiner Karte. Genau deshalb sind es meine Standard-Autos.

Zitat von NahverkehrSW

Ich habe das Problem nur beim Morphi Solaris II, auch mit ausgeschalteter Kopfbewegung.

Die Scrips von Morphi simulieren viel genauer, deshalb gibts bei fast allen Bussen die z.B. mit seinem ZF Script ausgestattet sind Performance-Nachteile. Man merkt sie zum Teil leider auch bei sehr hohen FPS. Ich weiss nicht ob sie sich dann nicht sogar aufsummieren wenn besagte Busse im KI-Verkehr unterwegs sind. Dass es gerade beim Bremsen vorkommt wundert mich nicht, da dort auch der Retarder greift.

An und für sich verbraucht jedes Bremsscript Leistung, vor allem beim Bremsen selbst. Ist aber bei den Standard-Scripten weniger auffällig. Wenn man genau drauf achtet wird man es aber auch beim M&R GN92 bemerken.

Das prinzipielle Bremsruckeln beim Urbino 2 ist bekannt, Kopfbewegungen abschalten hilft wie gesagt. Ist für mich aber auch keine Alternative, weshalb bei mir der Bus deshalb leider nur noch in der KI unterwegs ist bis es einen Patch oder ein Workaround gibt.

Stimmt, wäre aber sehr unflexibel für simple Ziele. Stell Dir mal vor das würdest Du bei deutschen Ü's und Ö's machen müssen. Muss doch irgendwie über die Fonts oder Script gehen, wie beim modifizierten BVG Urbino III...

Moin!

Da ich die M&R MAN's (NL+NG) sowie die Stadtbus-MANs vor allem gerne als KI einsetze würde ich gerne deren Matrix nun so modifizieren, dass sie in der Lage sind auch auf polnischen Karten die polnischen Umlaute anzuzeigen- Allein durch die entsprechende HOF Datei ist es ja leider nicht getan. Ich habe allerdings keine Ahnung ob ich dazu nun einen anderen Font bräuchte, oder eine Scriptmodifikation, oder gar beides. Da habe ich leider keine Ahnung von, würde aber gerne das Problem lösen, am Besten ohne dass dabei z.B. die deutschen Umlaute flöten gehen.

Wenn das gelöst ist würde ich mich dem Urbino II der Stadtbusfamilie annehmen sowie dem Urbino IV (Ruhr), ich denke der Weg wird ähnlich sein.

Jemand eine Idee?

Mainz ist meiner Meinung nach immer noch eines der besten Freeware-Karten. Kaum eine Karte bietet solch ein hohes Wiedererkennungs- und Detailniveau. Sie hat aber im Werkszustand einige Tücken, die aber durchaus überarbeitbar wären. Man könnte beispielsweise die ganzen invisible Splines zu größeren Kreuzungen " backen" und hätte eine echt gute Grundlage. Objekte etc sind ja da und in prima Qualität. Ich würde die Karte dann auch für Payware-tauglich halten wenn man zum Beispiel noch die Abschnitte Hbf - Bismarkplatz - Straßenbahnamt und vielleicht Straßenbahnamt - Schloßtor wegen dem Betriebshof zumindest semi-real anbinden würde. Da wäre zwar keine neue ganze Linie drin, aber sicherlich einige E-Kurse und Ein/Ausrücker. Auf den heutigen Zustand mit Straßenbahn zum Lerchenberg halte ich die Karte nicht für umbaubar, zumindest wäre der Aufwand irrsinnig und die Linienführungen sind ja mittlerweile auch ganz anders.

Mainz war glaub ich in OMSI auch die erste Karte die vernünftigen KI-Straßenbahnverkehr hatte.

Zitat von Tatra

Folgendes passiert beim Spiegelmodus:

- Im Öko-Modus:

Es "sollte" nur ein Spiegel mit dem Suffix _2 geben. Alle anderen Spiegel werden als zweitrangig behandelt.

- im Vollmodus

Es ist egal, ob ein oder mehrere Spiegel mit Suffix geschrieben wurden oder keiner, da alle Spiegel gerendert werden.

Daher kannst du den Suffix rauslassen, wenn du den Spiegelmodus auf Voll stellst.

Alles anzeigen

Ich habe bis vor einer Woche vielleicht immer den Öko-Modus in den Optionen eingeschaltet gehabt. Jetzt nicht mehr, und mit großem erstaunen festgetellt dass zumindest wenn die anderen Spiegel das _2 Suffix haben, und die Werte vernünftig eingestellt sind, dass dann eben nicht alle Spiegel gerendert werden. In meiner Hauptsicht habe ich die gleichen fps wie wie sonst. Nur in der Sicht wo ich 2 Spiegel im Blick habe gehts runter, beim Blick auf den rechten wieder normale fps. Der Vollmodus kann also sehr ökonomisch sein bei Werten die sich nicht "überschneiden". Der Effekt ist dann praktisch dass man keinen fps-Einbruch durch Spiegel hat und trotzdem keine halbierte oder gedrittelte Framerate bei den Spiegeln selbst. Ohne Suffixe ginge das wohl nicht, weil dann für die letzte Zeile wohl ein irgendwie verallgemeineter Standardwert genommen wird.

Insbesondere in der Ansicht wo ich den Fahrgastspiegel und den rechten Spiegel sehe habe ich des öfteren schon gemerkt dass tatsächlich nur bei draufsicht gerendet wird. Denn blickte ich mal länger nicht drauf, zuckelte dieser erstmal kurz. Auch hatte ich mal mir eine Sicht zusammengefriemelt auf den rechten Spiegel wo der Fahrgastraumspiegel nur zum Teil sichtbar war, aber genug um zum Beispiel zu erkennen ob der rendert oder nicht. Das öffnen der vorderen Tür ist dort nämöich sichtbar, war es aber in dieser Testsicht nicht, der Spiegel war also eingefroren und hat sich wieder aktiviert bei der Sicht wo er das auch soll. Wohlgemerkt im Vollmodus.

Je nach Bus kann man also ein wesentlich besseres Ergebnis erreichen ohne Frames zu verlieren. Im Umkehrschluss könnte also ein Busersteller auch die Sichten so einstellen dass in der Standardsicht gar kein Spiegel gerendert wird. Das wäre aber eine ziemlich eingepferchte Sicht wo man das Kinn fast auf dem Lenkrad hat.

Es ist wohl alles nur eine Frage der Werte für die letzte Zeile, also der Entfernung. Der Wert muss gerade mal so sein dass in der gewünschten Sicht der Spiegel gerendert wird, unter Berücksichtigung der Kopfbewegungen beim Fahren. Und man muss auf Fahrgastraum-Kameras verzichten. Diese sind einfach zu weit weg, und würden erst rendern bei Werten die sich dann mit allen anderen Spiegeln überschneiden. Im Öko-Modus hätte das sehr niedrige Frames für die anderen Spiegel zu folge und im Vollmodus einen massiven Einbruch.

Ich bin momentan echt begeistert von diesen Einstellungen, es macht wahnsinnig viel aus. Natürlich sind die Frames nun niedriger wenn ich rauf zum Fahrgastraumspiegel schaue, das passiert aber meist nur an den Haltestellen. Und für den Fall dass ich da echt mal unter 30 fps insgesamt rutschen sollte habe ich den erzwungenen Öko-Modus eingestellt, dass er sich dann einschaltet und bei höheren Frames dann auch wieder abschaltet.

Zitat von Jessi99

da der abschaltbare Spiegel in der Bus Datei eingetragen sein muss, wird der wohl doch mitberechnet. So versteh ich das zumindest.

Grüsse

Jess

Ja, allerdings könnte es auch so sein dass es eben nicht der Fall ist. Es werden ja auch nicht Objekte gerendert die mit dem dem [visible] Flag versehen sind und nur dargestellt werden unter den eingetragenen Bedingungen (geladen werden sie schon, nur nicht dargestellt und berechnet), und es könnte bei den CTI Variablen ähnlich sein.

Danke für die genaue Ausführung. Ich habe noch garnix im Modell selbst gemacht, nur in der .bus Datei. Mit dem Spiegel rechts war das auch eine Annahme, aber ich habe das Gefühl dass der erste Spiegel, also der linke immer bevorzugt wird und anders verarbeitet wird als der Rest, vor allem im Öko-Modus. Ich habe nämlich vergessen zu erwähnen dass in den Optionen der "normale" Öko-Modus eingestellt ist, und auf den bezieht sich das ganze.

Zu meinem Erstaunen stellte ich aber nun fest dass wenn ich dort vom Öko-Modus auf Voll umstelle, das ganze genau so funktioniert wie ich es möchte: Linker Spiegel rendert sowohl in der Hauptsicht, wo er nur ausschnittsweise zu sehen ist, natürlich dann auch in den Sichten nach links. Kein Frameratenverlust im Vergleich zur vorherigen Einstellung. Bei Verwendung von _2 bei erstem Spiegel und ohne _2 bei den restlichen gab es im Voll-Modus immer massiven Frameratenverlust. Und jetzt kommts: in der "Fahrplansicht", was bei mir so ein Blick nach oben-leicht-rechts" ist werden nun der Fahrgastraum-Spiegel und der rechte Spiegel voll gerendert, mit leichtem Framerateneinbruch. Aber kein Vergleich zum Voll-Modus mit Verwendung von Typ 1 und Typ 2 Kameras. Und der Blick rechts wo nur der Aussenspiegel zu sehen ist, der relevant für mich ist beim Rechtsabbiegen rendert nun auch voll mit leichtem Framerateverlust, was aber nicht schlimm ist. Es ist ein Unterschied wie Tag und Nacht, man nimmt nun weniger Bordsteine mit als bei dem Gezuckel vorher. In der Hauptansicht null Frameratenverlust! Als Bonbon oben drauf habe ich nun auch einen Fahrgastraumspiegel der schön mit voller Rate rendert. Abgesichert ist das ganze für Fälle wo vielleicht doch die Framerate zu niedrig ist mit dynamischem Öko-Modus, der unter 31 fps einschaltet und bei 40 etwa wieder abschaltet.

Die Überwachungskameras lasse ich nun aus, die würden auf jeden Fall das ganze vermasseln wegen des Abstands.

Ja, man muss das wohl feintunen, und die Werte scheinen zumindest für diesen Bus perfekt getroffen zu sein. Andere Busse bedürften dann ebenfalls so eine Behandlung. Aber die Haupterkenntnis ist wohl dass man mit Typ 2 das viel besser hinkriegt als Stumpf die erste Kamera auf Typ 2 zu setzen und die anderen nicht.

Bei Aussenschwenktüren fänd ich das garnicht schlimm dass der ins Sichtfeld kommt und somit bei offenen Türen sich die Lage ändert, denn das passiert ja nur im Stand.

Zum Schluss noch eine Verständnisfrage: ein per CTI abgeschalteter Spiegel ist also auch nicht da und wird in keinem Szenario doch im Hintergrund gerendert?

Moin!

Mein Vorgehen bei den meisten Bussen war es bisher den linken Spiegel auf Typ 2 zu setzen, und die restlichen Spiegel als typ 1 rendern zu lassen. Ziel war es immer dass der linke Spiegel mit voller Framerate refresht, und nur die anderen Spiegel reduziert werden. Nun habe ich aber in Erfahrung gebracht dass das viel geschickter geht, nämlich wenn man nur Typ 2 Reflexionen einsetzt, dort aber geschickt die letzten Zeilen setzt. So sollen die Spiegel auch nur dann voll gerendert werden wenn der Blick auf sie gerichtet wird. Der letzte Wert regelt dann den Toleranzbereich.

Hier mal als Beispiel mein aktueller Test aus dem Solaris Urbino PL:

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

[add_camera_reflexion_2]
1.348
5.924
2.353
0
52
205
-10
0.10

[add_camera_reflexion_2]
-0.005
5.2
2.576
0
52
195
-22
0.01

    "reflexion3.bmp":

[add_camera_reflexion_2]
-0.372
0.1
2.793
0
80
45
-40
0.001

    "reflexion4.bmp":

[add_camera_reflexion_2]
-0.294
-3.997
2.828
0
80
45
-40
0.001

    "reflexion5.bmp":

[add_camera_reflexion_2]
1.084
5.882
2.402
0
70
243
-29
0.001

Vorher war nur der erste Spiegel Typ 2 und Rest ohne das _2. Effekt war der gleiche. Aktuell wird der linke Spiegel voll gerendert, die anderen reduziert oder garnicht. Schön udn gut, nur kam ich jetzt mit der Typ 2 Methode auf die Idee auch den linken Aussenspiegel bei Sicht auf diesen auch voll rendern zu lassen, und das klappt leider nicht. Meine Sichten sind so dass in der Standard-Sicht nur der linke Spiegel zum Teil zu sehen sind, beim Blick schräg nach links ebenso, beim ersten Blick richtung rechts ist nur der rechte Spiegel zu sehen, und über die schedule-Sicht habe ich Sicht auf Fahrgastraum-Spiegel, zwei Überwachungskameras und den rechten Spiegel. In der schedule-Sicht hätte ich also sowieso reduziertes Rendern, da hier grundsätzlich mehrere Spiegel sichtbar wären. In der Sicht nach rechts allerdings nur einer. Und egal wie hoch ich da den letzten Wert setze, er rendert beim blick drauf immer reduziert. Hab sogar überprüft ob da nicht der Fahrgastraum-Spiegel aktiv ist, ist er aber definitiv nicht. Bin also etwas ratlos, warum hier das in der Praxis nicht funktioniert.

Der Bus hat noch einen Spiegel: für die Sicht vorne nach unten (weiss nicht wie der sich nennt...) Der ist aber per CTI nicht eingeschaltet und hier bei den Kameras auch eigentlich ausgestellt. Ebenso sind die Überwachungskameras aus, da diese das sowieso unmöglich machen würden aufgrund der nötigen Extremwerte in der letzten Zeile. Kann es sein dass der rechte Spiegel irgendwie doppelt ausgeführt ist und deshalb da eigentlich sich immer zwei Spiegel (mit den gleichen Werten) befinden? Denn in der CTI kann ich für eben diesen einen geteilten Spiegel einstellen, finde aber diesen aber in der Busdatei nicht als Extra-Spiegel. Der hätte aber eine andere Krümmung, aber könnte ja auch durch anderes Mapping entstehen...

Die Frage wäre ob meine Vermutung richtig ist mit dem "Doppelspiegel" und generell. Und ob ich diesen Spiegel irgendwo in der Modeldatei eventuell entfernen kann, da ich ihn für Unnütz halte. Der würde für mich erst Sinn ergeben wenn ich in 4K fahren würde und dann auch noch die Spiegelauflösung von 1024 auf das doppelte oder vierfache hochdrehen würde. So aber definitiv nicht.

Bei den Überwachungskameras habe ich aufgegeben, denn ich bin mir mittlerweile Sicher dass eine Aktivierung auch nur einer davon sofort alle Spiegel (also auch den wichtigsten linken) in den Ökomodus versetzen würde. Einfach aus dem Grund weil man dort nicht die Entfernung zum Bildschirm eintragen muss sondern zur Kamera (!), und diese ist ja Meterweit von mir entfernt. Der Schwellwert liegt hier bei etwa 5-8, eine der Kameras befindet sich ja auch gegenüber Tür 2, was diese Annahme stützt.

Der Standarddepot-Eintrag ist mir bekannt, und ich frage mich immer warum er in 99% der Karten (auch kommerzielle) falsch ist. Dort steht oft einfach nur der Mapname, obwohl das nix mit einem Depot zu tun hat. Dieser Eintrag ist ja essentiell für das Feld mit der Zufallsauswahl und die Bindung der Nummern an dazugehörige Repaints. Leider filtert er aber nicht die Busse selbst;-D

Die AI-Versionen sind ja reduzierter und oft daraufhin optimiert zwar von aussen gut auszusehen, aber ohne alle unnötigen Dinge für den AI-Betrieb. Dazu können auch Scripte zählen, denn die können in der Menge dann zum Teil erheblich auf die Performance drücken. Es gibt zwar den [visible] Flag in den Modelldateien wo man einstellen kann wo was erscheint wenn es sich um ein Spielerfahrzeug handelt oder AI, meiner Erfahrung nach aber wird das Fahrzeug trotzdem immer mit "allem" geladen beim spawnen. Die unsichtbaren Modelle werden also geladen, nur nicht angezeigt. Hat positiven Einfluss auf die Framerate (wieder in der Summe, ein einzelnes Fahrzeug macht selbst als Poly-Schleuder nicht viel aus), beim Nachladen an den Kachelgrenzen ist es aber genauso schlecht wie wenn alles auf visible wäre. Das vermeiden die AI-Versionen, zusätzlich kommt noch die Reduzierung bei den Scripten hinzu.

Also so wie ich es überblicke würde es die besagten Dopplungen dann geben. Nun denn... Dann wäre es also schlau das in Kauf zu nehmen, die drei Höfe auf nach Möglichkeit reinen AI-Betrieb umzustellen, und das gleiche dann nochmal als Spieler-Hof zusammenzufassen und diesen als Standarddepot einzutragen. Die Begegnung mit dem Clon wird mit der Anzahl der Fahrzeug ja zumindest antiproportional.

Edit:

Gutes Beispiel für AI-Versionen sind z.B. die MANs der Stadtbusfamilie. Nutzt man sie nicht und hat viele in der Liste merkt man schon den Unterschied beim Laden finde ich. Nur irgendwie habe ich bei diesen den Eindruck dass die AI-Versionen einen kleinen Bug haben: fährt so ein AI-MAN an mir vorbei, verschwindet irgendwie sein "Hintern" sobald die Mitte des Busses aus meinem Blickfeld ist. Im Rückspiegel ist er aber noch zu sehen. Betrifft glaub ich aber nur die Solobusse.

Zitat von Schleswig-Holstein

Seit OMSI 2 brauchst du das eig nicht mehr, da OMSI sich über die "unsched_trafficdens" selbst definiert, wann WE etc. ist. zu OMSI 1 Zeiten war das noch anders.

Das gilt nur für Verkehr, nicht für das Fahrgastaufkommen. Das ist an jedem Wochentag gleich.

Moin!

Ich lasse in meinen AI Listen gerne AI-Versionen von Fahrzeugen fahren, nutze aber auch gerne die Zufallsauswahl von Fahrzeugen sowie die Beschränkung auf Zuweisung der Nummern für Spielerfahrzeuge auf nur die im Hof zugelassenen. Es ist nicht ganz einfach beides hinzukriegen, da ja AI-Versionen eine andere .bus Einträge benötigen als Spielerfahrzeuge.. Jetzt kam mir die Idee einfach alle Fahrzeuge die zum beispiel für die drei Höfe einer Karte vorgesehen sind zusammenzufassen zu einem "Spieler-Hof" ohne AI-Versionen, und bei den AI-Höfen dann eben die AI-Versionen einzutragen. Diesen Spieler-Hof dann als Standard-Depot festlegen (bei den AI-Höfen werden ja eh die Nummern entsprechend den Einträgen genommen).

Dann hätte man aber theoretisch jede Wagenummer und jedes Kennzeichen zwei mal in der AI-Liste, jeweils in einem der AI-Höfe und einmal im Spieler-Hof. Die Frage wäre nun wie geht OMSI eigentlich damit um wenn ich also zum Beispiel Wagen 200 wähle: eigentlich müsste Wagen 200 bei aktiviertem Häkchen "nur zum Hof zugehörige Nummern" nur auswählbar sein wenn er nicht schon als AI unterwegs ist. Umgekehrt dürfte Wagen 200 nicht spawnen wenn ich schon Wagen 200 fahre, selbst wenn es ein anderer Hof ist? Oder wird das ignoriert und es gibt dann zwei mal den Wagen? Ich denke das Nummernsystem soll doch auch sowas verhindern.

Anderer Grund für diese Aufteilung wäre auch dass ich mir nicht mehrere global.cfg Dateien bereithalten möchte wegen jeweils anderem Standardhof. Ich hab schon mehrere global.cfg wegen unterchiedlichem Fahrgastaufkommen an Wochentagen, das reicht schon... Noch ein Grund wäre dass ich bei manchen Fahrzeugen mit Kopien der .bus Dateien für Spielerbusse arbeiten würde da ich gerade auf halbwegs realen Karten nicht immer den Überblick habe welche Version des Busses nun zu welcher Nummer zugehört, was schnell vorkommt wenn man mit nicht zwischen Euro 4 bis 6 und verschiedenen Motoren samt verschiedenen Getriebetypen wählen kann. Umgekehrt könnte ich bei den AI-Höfen die Varianten dann einschränken.

Aber meinen Clon unterwegs zu treffen würde mich schon nerven;-D

Nein, denn das wäre ja die Skalierung, und die betrifft in OMSI dann das ganze Bild. Leider hat damals keiner daran gedacht dass man die UI-Größe von der sonstigen Darstellung entkoppeln muss. Ein großes Problem bei älteren Spielen.

Der nur geringe fps Verlust wundert mich garnicht. Ich bekomme fast gar keinen Unterschied wenn ich diverse Antialiasing-Geschichten einstelle. Ich glaube nur bei 2x2 Supersampling habe ich was gemerkt, was in etwa der gleichen Pixelmenge dann entspricht. War nicht viel, aber da es "nur" AA war war der kleine fps-Verlust in keinem Verhältnis zum Ertag, da ich mit anderen AA-Modi bei 0% Leistungsverlust ähnlich gute Ergebnisse erzielt habe. Bei nativen 4K ist der Mehrwert am Bild aber höher.

Weiter zum Nachladen:

Wieder habe ich den Framelimiter in OMSI rauf gesetzt, diesmal auf 41 oder gar 45 fps. Je mehr fps, desto erträglicher das Nachladen, da offenbar OMSI dann das gleiche zwischen den Frames geladen kriegt, bei mehr fps sind aber die Abstände natürlich deutlich kürzer. Die Limitierung auf klapp über 30 hat zwar so manchen Frameratensprung verhindert, aber wohl auch das Nachladen ausgebremst. Da ich Gsync einsetze sind aber Frameratensprünge fast irrelevant und nicht wahrnehmbar, ausser sie sind sehr hoch, daher ist glaub ich nun das Limit bei über 40 sinnvoller. Nebenbei fährt es sich mit 40 einfach viel besser als mit um die 30.

Da bei mir auf machen Karten mangels Material leider keine AI-Varianten fahren können: wäre es nicht machbar in diesen Bussen statt z.B. Morphys ZF/Voith Sounds für den AI-Sound aus anderen Bussen Sound-Configs zu verwenden die "Leichter" sind? Ich meine unter sound_ai was einzutragen aus einem anderen Fahrzeug, also auch ohne den ganzen Krempel zu kopieren. Oder muss das immer im gleichen Ordner des Busses sein? Das könnte auch für Entlastung sorgen.