Beiträge von wurstbrot

Willkommen in der OMSI-WebDisk!
Als Gast kannst du nur Inhalte in deiner ausgewählten Sprache sehen. Registrierte Nutzer können die Sichtbarkeit anderer Sprachen in ihrem Kontrollzentrum aktivieren, weitere Infos hier.
Alle Themen sind in den Foren mit einer Sprachflagge gekennzeichnet: = Englisch [EN], = Deutsch [DE], = Französisch [FR]. Wenn du die angegebene Sprache nicht beherrschst, schreibe auf Englisch!

  • Nachladeschluckauf, Direct3D lost & High-DPI

    Zitat von Maerkertram

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


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

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


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

  • [Sammelthread] Add-On Bad Hügelsdorf 2020

    Zitat von Maerkertram

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

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



    Zitat von Maerkertram

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

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

  • [Sammelthread] Add-On Bad Hügelsdorf 2020

    Zitat von Schleswig-Holstein

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

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


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

  • [Sammelthread] Add-On Bad Hügelsdorf 2020

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


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


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

  • [Sammelthread] Add-On Bad Hügelsdorf 2020

    Zitat von Schleswig-Holstein

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

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

  • [Sammelthread] Add-On Bad Hügelsdorf 2020

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


    Beispiel 1: Fikcyjny Szczecin Hst. Goclaw

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



    Beispiel 2: Fikcyjny Szczecin Hst. Skolwin

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



    Beispiel 3: Fikcyjny Szczecin Hst. Cmentarz Szczecinska

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


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


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

  • [Sammelthread] Add-On Bad Hügelsdorf 2020

    Zitat von der_Nik_

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

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


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

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


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

  • [Sammelthread] Add-On Bad Hügelsdorf 2020

    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.

  • [Sammelthread] Add-On Bad Hügelsdorf 2020

    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.

  • [Sammelthread] Add-On Bad Hügelsdorf 2020

    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.

  • [Sammelthread] Add-On Bad Hügelsdorf 2020

    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.

  • Nachladeschluckauf, Direct3D lost & High-DPI

    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:


    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.

  • Welche Dateitypen sind für Texturen in OMSI sinvoll?

    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.

  • Welche Dateitypen sind für Texturen in OMSI sinvoll?

    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.

  • Welche Dateitypen sind für Texturen in OMSI sinvoll?

    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.

  • Urbino II Bremsruckeln

    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.

  • polnische Umlaute in Matrix-Anzeigen M&R NL/NG + Stadtbus-MAN

    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 Linie Ibis

    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.

  • an die Spiegel-Experten: Typ 2 Reflexionen korrekt einsetzen

    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.