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!

  • AddOn Citybus o530

    Der Bus scheint eh Probleme zu haben mit Buchstaben. Hab testweise über das OMSI-Menü "E" und "10E" schildern wollen, das hat garnicht geklappt. Das heißt logischerweise auch dass KI-Busse auch daran scheitern werden.

  • [SUPPORTTHREAD] IVU.ticket.box CE70 mobil

    Hab die IVU Box in den neuen Citybus O530 eingebaut. Läuft, hab aber das Problem dass die Matrix auf Ziele aus der IVU zwar reagiert aber nicht die Liniennummer angezeigt wird, nur das Ziel. Das Display Innen krieg ich irgendwie auch noch nicht zum laufen, versuche da vor allem IVU_freier_Port_01 zuzuweisen, klappt aber nicht wie bei anderen Bussen. Hat es jemand schon geschafft? Eventuell Erfahrung mit dem 628 und der IVU? Dürfte ja ähnlich laufen.


    Hier die Texttextures die in Frage kommen:

    8+9 sind für diese "Ersatztafel" als Steckschild, ab 10 müsste es die Matrix sein und 23-25 die Innenanzeige. Hab bisher nur geschafft die vond er IVU auf dieses Steckschild die Anzeige zu leiten, das brauch ich aber nicht unbedingt...

  • AddOn Citybus o530

    OMSI stürzt ab beim Schließen wenn man irgendwas mit dem Bus gemacht hat oder er auf der Karte war. Gleiches Phänomen wie beim C2 von MX200, soll ja an langen Scripten liegen. Nervt trotzdem, weil man aus versehen gerne beim nächsten Start dann das Multithreading abschaltet...

  • AddOn Citybus o530

    Der Matrix-Font kann wohl kein "ß" darstellen, die anderen Umlaute gehen aber anscheinend.


    An sich sind die Matrix-Varianten gut gelungen, nur das Flip-Dot in grün wirkt sehr sehr dunkel und unleserlich. So schlecht waren die Flip Dots nun auch nicht...

  • AddOn Citybus o530

    Bevor ich die ersten Runden gedreht habe wurde ein wenig repainted. Super Templates und super Handhabe. Das macht echt Spaß.



    Wie man sieht ist der Kennzeichen-Font etwas schmal, dürfte insbesondere für Hamburg problematisch sein. oder man streckt das Kennzeichen...

  • AddOn Citybus o530

    Zitat von flOmsi

    Bei allem Respekt und vielen Dank an Alterr für seine O530er aber dieser hier ist meiner Meinung nach ein würdiger Nachfolger und in einigen Punkten besser!

    Der hat ja schon einige Jahre auf dem Buckel. Ich erinnere mich dass da gerade Hamburg Linie 109 für OMSI 2 rauskam und ich den damals rauf und runter gefahren bin drauf. Aber heute wirkt er unter den anderen Bussen wie von gestern. Daher sehr schön dass es einen guten Nachfolger gibt, und das schmälert ja auch nicht die Leistung von Alterr damals.

  • [SUPPORTTHREAD] IVU.ticket.box CE70 mobil

    Ja, die Position ist halt aufgrund der Bauweise ungünstig. Habe es ja in zwei grundverschiedene Bustypen verbaut und bei beiden ist das eine riesige Fummelei mit der Außenansicht nur um eine Fahrkarte abzureissen. Nur wenn der Drucker in irgendeinem Bus sehr Tief sitzt dann könnte man aus einer der Fahrersichten den Klickpunkt erreichen. Da rächt es sich direkt dass es in vielen Bussen nicht mehr diese eigentlich eigenartige "Panel-Sicht" von oben gibt... Aber ein Trigger würde es zur Not auch tun.

  • [SUPPORTTHREAD] IVU.ticket.box CE70 mobil

    Was wenn sich der Kommentar nicht auf jemand bestimmtes bezieht? Bist Du Moderator um mir zu sagen was ich wo zu schreiben habe? Nein? Dann kannst Du ja gerne meinen ach so schlimmen Beitrag melden. Bis dahin entscheide ich aber wie und was ich wo poste.


    Ich weiß auch nicht was an einem recht einfachen Satz nicht zu verstehen ist.:"D

  • Unbekannte Fehlermeldung bei KI-Bus

    Zitat von fOcUs04

    Error: Fahrzeug mit Ident 29432 (Vehicles\MB_O530_Facelift\MB_O530G Facelift_3-Doors Main_k++_ki.bus) hat mit ung ltiger HDG versucht, eine Belegung zu erzeugen!


    Explizit wird nur dieser eine Bus mit der Fzg-Nummer 29432 bemängelt.

    Genau um diesen Fehler geht es mir ja, das mit den Unscheduled AIs ist was anderes, die prüfe ich auch gerade. Ich habe den Halycon -Gliederzug im Verdacht, da fehlt eine Datei die nicht mitgeliefert wurde.


    Eine Fahrzeug-Nummer 29432 hab ich nicht, die sind Drestellig. Das muss irgendeine Interne ID sein? Der Bus läuft immer noch tadellos auf Grundorf...

  • Unbekannte Fehlermeldung bei KI-Bus

    Das ist die Log von gestern: logfile.txt


    Da haben aber auch ein Halycon-KI-LKW was rumgespukt und seltsamerweise auch der Aachen-Atego. Das mit dem unscheduled bezieht sich dann glaube ich auf diese und nicht auf den Bus. Daher prüf ich das gesondert auf Grundorf.


    Trotzdem hier mal der Unscheduled-Ausschnitt aus der AI-List von gestern:

    Zitat

    Die Tabs werden aber hier zu Leerzeichen konvertiert...

  • Unbekannte Fehlermeldung bei KI-Bus

    Moin!

    Ich habe im Logfile von gestern gesehen dass mein O530G Facelift in einer von mir angepassten KI-Version Fehlermeldungen ausgespuckt hat in der Log die ich so noch nie gesehen habe:


    7057 01:35:16 - - Error: Fahrzeug mit Ident 29432 (Vehicles\MB_O530_Facelift\MB_O530G Facelift_3-Doors Main_k++_ki.bus) hat mit ungültiger HDG versucht, eine Belegung zu erzeugen!


    Das kam dann zig mal untereinander, der Bus hat aber augenscheinlich funktioniert. Vor diesen Meldungen gab es das:

    Die Bereichsprüfungen könnten damit zusammenhängen.


    ABER:


    Eben als einzigen Bus auf Grundorf in die KI gesetzt und das Ding fährt normal rum, zickt nicht und die Log liefert nur das hier:

    Das weist auf die K++ Matrix hin, hat aber glaub ich wiederum nix mit dem obigen Fehler zu tun.


    Versteh das also nicht ganz: Gestern trotz der Sachen in der Log ist mir der Bus mehrfach begegnet und jetzt auf Grundorf auch alles astrein. Müsste doch hier auch den Bereichsprüfungs-Kram bekommen?

  • [TUT] Speicher sparen durch Fahrpläne

    Hallöchen!

    Wer kennt das nicht, die lästigen weißen oder durchsichtigen Autos und dann geht irgendwann gar nichts mehr und man muss neu starten. 4GB Pacth installiert? Ja. Irgendwann ist man mit dem Latein am Ende. Entweder man lebt also damit oder reduziert radikal seine AI-Liste, versucht die Texturlast einzugrenzen oder führt diverse OMSI-esotherische Maßnahmen durch. Auch dieses Tutorial löst das Problem leider nicht ganz, es hilft aber es einzudämmen und richtet sich vor allem an die Fahrplanersteller, denn da geht was. Aber der Reihe nach.


    Einleitung:

    Die Ursache für die weißen Autos (und auch andere Objekte) ist Speichermangel. Die Texturen können nicht mehr in den Speicher geladen werden, also fahren neu geladene Autos und Busse ohne Textur durch die Gegend (weiss oder durchsichtig, manchmal auch schwarz), und dann erwischt es auch noch Objekte der Scenery. Wir wissen ja dass OMSI ein 32 Bit Programm ist und somit eine Adressgrenze von etwa 2 GB hat, die man mittels "4GB Patch" auf etwa 4 GB verschieben kann. Man muss bedenken: die maximalen 4GB umfassen sowohl den RAM (Hauptspeicher) als auch den VideoRAm (Grafikspeicher). Das heraufsetzen des Videospeichers auf 4 GB zählt dann zu den OMSI-esotherischen Maßnahmen;-) Auch die alte 2/3-Regel würd ich heutzutage in Frage stellen, stammt sie doch aus einer Zeit wo man es mit deutlich weniger Speicher zu tun hatte als heute. Also ist halt irgendwann Sense, auch dank der schönen Busse in der AI-List, überdimensionalen und schlecht proportionierten Texturen beim Mobilien und Immobilien. Alles hat meist Optimierungspotential, und man sollte es ausschöpfen: KI-Versionen verwenden, nicht übertreiben, Repaint-Anzahl gering halten usw. Hilft aber auch nicht ganz, kann aber manchmal den Unterschied machen.


    Mein Ansatz baut an einer anderen Stelle auf. Es ist Euch vielleicht aufgefallen dass die OMSI.exe größer wird je länger das Spiel läuft und sich selten bis gar nicht verkleinert. Bei etwa 3,2 GB Größe knallen dann die Texturen durch. Logisch: 3,2 GB plus Texturen im Video-RAM ergeben 4 GB. Nicht nur dass OMSI nur 32 Bittig ist, nein, es ist nicht gerade schonend mit dem Speicher. Es hält unnötige und zweitweise nicht mehr gebrauchte Dinge im Speicher und stößt dann eben irgendwann an die Grenze. So werden anscheinend Daten von Bussen die auf die Karte gespawnt wurden die ganze Zeit vorgehalten, selbst wenn dieser Bus die Karte und erst recht den sichtbaren Bereich wieder verlassen hat. Kleines Beispiel:

    Wir haben einen KI-Kurs morgens um 7:30 mit Schülern zur Schule und um 13:30 Uhr zurück, dazwischen verlässt der Bus die Karte. Wenn die Vormittags- und Nachmittagsfahrt in einem Umlauf sind, dann bleibt der Bus im Speicher wenn man ihm morgens begegnet ist bis Nachmittags wo er die Karte wieder verlässt und der Umlauf endet. Und jetzt mal überlegen was passiert wenn dies 20 KI-Linien sind? Die Antwort liegt auf der Hand... Man muss die KI-Kurse also am Besten dazu kriegen zu verschwinden sobald sie nicht mehr gebraucht werden, und dazu würde auch die Zeit zwischen Vormittag und Mittag in unserem Beispiel zählen. Hier wäre die Abhilfe schonmal den Umlauf in 2 Umläufe aufzuteilen. Eine Linie wird jetzt nicht viel ausmachen, aber 20 schon.


    Abhilfe:

    Wir splitten also die Umläufe auf und teilen sie in mehrere. Das machen wir per Hand mit Texteditor an den ttl-Dateien der Linien, da es im OMSI-Editor unglaublich kompliziert und unübersichtlich wäre. Hier ein kleines Vorher Nachher Beispiel


    Vorher:


    nachher:


    (Fast) jede fahrt ist also intern zu einem "Umlauf" geworden. Der Bus wird also erscheinen und nach der Fahrt wieder verschwinden. Und: er wird den Speicher freigeben! Das Editieren war simples (aber mühseliges) Copy and Paste. Zwischen jede Fahrt wurde ein [newtour]-Bereich reinkopiert mit der alten Umlaufbezeichnung samt neuem Suffix, aus "Mo-Do 1" wurde "Mo-Do 1-1", "Mo-Do 1-2" usw. Für die Abendkurse hab ich mir das gespart, aber dazu später mehr


    Um mal zu zeigen wie viel das bringt:

    Vorher war mit meiner AI-Liste nach einer Fahrt im privat gemoddetem Mainz in der HVZ Schluss, da ich da mit der OMSI.exe bereits bei 3,1GB war. Jetzt hatte diese Grenze erst gegen Ende der Rückfahrt erreicht. Am Ende der Hinfahrt war die EXE bei 2,4 GB statt 3,1 GB. Mit gleichen Settings, gleicher AI-Liste. Dabei waren bei weitem nicht alle KI-Linien umgestellt auf dieses System, vielleicht nur etwas mehr als die hälfte. Viel Luft nach oben und mal gucken wie es aussieht wenn alles umgestellt ist;-)


    Anwendungsbereiche:
    Wo kann man dieses Prinzip anwenden? Es hängt ganz stark von der Art der Linien ab die eine Karte hat. Grundsätzlich bringt es viel bei Karten die viele KI-Linien haben, die auch die Karte verlassen. Ganz wichtig: KI-Linien. Keine vom Spieler fahrbaren Linien! Da würde zum Beispiel eine Karte wie ALU schonmal nicht in Frage kommen für diese Maßnahme (außer bei den Zügen!). Aber Karten wie Spandau, X10/BRT, Hamburg wären perfekt mit viel Potential bei den KI-Linien sowohl bei Bus als auch Zug, Allerdings wo keine Not da auch keine Mühe notwendig. So kann man sich das bei Abendfahrplänen oder fürs Wochenende vielleicht sparen. Kommt eben auf die Karte an. KI-Linien die auf der Karte enden und im sichtbaren Bereich Pause machen würde ich immer beim verlassen der Karte splitten, da also jede zweite Tour. Dennoch würde ich schonmal auf jeder Karte den gesamten Zugverkehr auf diese Weise regeln.


    Nachteile:

    Als erstes werden die Fahrpläne natürlich furchtbar unübersichtlich fürs spätere Bearbeiten. Also immer dafür eine Kopie bereithalten. Dann ist es natürlich so dass so einen Umlauf immer ein anderer Bus fahren wird und nicht der gleiche wie vorher, denn technisch sind es ja verschiedene Umläufe. ist blöd, ja, aber beim Neuladen des Spielstands würden die Fahrzeuge sowieso wieder neu zugeteilt werden mit gleichem Effekt. Deshalb würde ich aber KI-Linien die zum Beispiel an der gleichen Endstelle wie der Spieler Pause machen von diesem System rausnehmen. Als Beispiel sei hier Spandau mit der KI-Linie 94 genannt die am Reimerweg endet oder die 56 in Ruhleben. Bei Verwendung von StnLinks werden manchmal Busse auch nicht gelöscht, Beim alten T&T System funktioniert das aber recht zuverlässig. Aber vielleicht lassen sich so auch besser "Geisterbusse" mit +1000min Verspätung finden bei StnLinks die dann auch den Speicher unnötig vollstopfen;-)


    Ausblick:

    Ich hoffe das probiert der ein oder andere aus und noch mehr hoffe ich dass jemand ein Tool schreibt welches diese Prozedur irgendwie automatisiert.

  • Add-on MAN Standardbus II

    In der Tat kenne ich mich da nicht genug aus, sonst wärs mir egal und ich würd mir sowas zurechtmodden wie ich es brauche;-D Ich seh nur die Busse die es gibt oder gab und sehe die Gemeinsamkeiten und ich seh auch oft genug Skriptreste um erahnen zu können was die Eltern oder Großeltern des Scripts sind (dabei frage ich mich schon wie das denn so mit dem Copyright da ist...) Ich seh zum Beispiel eine SD83_Rollband.osc samt Varlist im O405/Scripts VerzeichnisXD


    Der Kunde darf erwarten was im Vorfeld als Funktionen ihm ausgewiesen wurde, nicht was das Fahrzeug eventuell könnte oder wofür es theoretisch vorbereitet ist. Ich erwarte auch kein Rollband-Update. Wenn Du es wegen irgendwelcher technischer Schwierigkeiten canceln würdest, dann ist es halt so. Dann wird der Bus eben mit Matrix genutzt;-D Aber natürlich würd ich mich freuen wenn die technischen Hürden gemeistert werden und das Ding schön vor sich hin rolltXD

  • Add-on MAN Standardbus II

    Zitat von Chrizzly92

    Der Plan sieht vor, ähnlich wie auch jetzt sowohl für die Front als auch für die Seiten getrennte Rollbandtexturen zu verwenden. Ist in der Hofdatei keine für die Seite eingetragen, wird die für die Front gewählt. sind beide nicht eingetragen, wird das Rollband aus den anderen Strings für den jeweiligen Terminus generiert. Das an und für sich ist kein Problem, allerdings wirds zu einem, wenn das ganze dann noch dynamisch eine drehanimation haben soll, sowohl beim Zieltext als auch bei der Liniennummer.

    Das klingt doch gut. Die Animation wäre ja nur relevant für das Spielerfahrzeug und eigentlich auch kein Novum in OMSI. Die alten SDs konnten das, der O305, O405 usw. Das Prinzip ist denk ich mal das gleiche bei allen? Und sogar die Scripte sind doch eigentlich da zum Beispiel beim SD 83.


    Es ist zwar schön dass der Bus die Rollbänder generieren kann für Karten wo der Kartenersteller es nicht vorgesehen hat, aber diese Karten sind auch aus anderen Ären. Wenn ein Kunde dann verlangt "ich will überall Rollbänder haben out of the box" nun ja selbst schuld. Streng genommen passt der SG ja auch nur auf vielleicht 5% der Karten, da es kaum historische gibt. Perfekt ist natürlich Spandau, und da gibt es die Rollbänder. Es ist dann ja auch Sache der Community eine Funktion wie diese aufzugreifen und mit Inhalten zu befüllen. Klappt ja gut sogar bei Sonderformaten wie beim O307 /407, warum nicht hier auch, erst recht wenn eine gewisse Verwandtschaft zum O405 besteht vom Format her;-) Ich für meinen Teil werde sobald die Mainz-Rollbänder sortiert sind sie veröffentlichen und gegebenfalls falls nötig auch an den SG anpassen. Da kannst Du gerne schon vorab die Spezifikationen durchgeben;-D