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!

  • Sperren von Pfaden im Chrono-Event

    Moin!

    Mir ging auf ALU der LKW-Unfall im Derenhofener "Tunnel" auf den Senkel, also kam ich auf die Idee diesen einfach in ein Chronoevent zu verschieben, er soll halt nur ab und zu auftauchen und nicht jeden Tag das ganze Jahr. Hat auch prima geklappt, nur irgendwie komme ich durcheinander was nun die Sperrung der besagten Spur betrifft. Wenn ich diese Spur unter Traffic Rules in der Standard-Map freigebe, kann ich diese im Chronoevent nicht mehr sperren. Sie soll ja aktiv sein, nur während des Chronoevents eben schwarz markiert werden bei allen vehicle groups. Wenn ich sie aber mit no traffic überallen mal möchte, funktioniert es aber nicht. Jemand eine Idee ob das nun ein OMSI Bug ist oder ich irgendwas falsch gemacht habe?

  • [TUT] & [MOD] fOcUs04's Tüdelecke [eingestellt / discontinued]

    Genau so mache ich das auch, nur verzichte ich meist auf den Blick auf den rechten Spiegel in der Standard nach-vorne-Sicht. Das würde aber interessant werden falls ich mal einen Monitor mit über 30 Zoll nutze;-D Vermute aber dass es dann zu sehr zu Verzerrungen an den Rändern kommt.


    Fahrgastraum-Spiegel... Ja, der ist für mich am unnötigsten, und ich nutze den meist eh nur an Haltestellen. Der soll möglichst nicht im Blickfeld sein, deshalb mag ich auch eher Busse wo er relativ weit oben ist, damit er auch nicht beim Umschalten der Blickrichtung nach rechts auftaucht.


    Und ich schalte grundsätzlich eventuelle Fahrgastraum-Kameras ab, denn die lassen sich nicht vernünftig steuern mit Typ2-Refklektionen, da die Kamera im Innenraum weit hinten ist (Zeile 8 ist ja die Entfernung zur Kamera, nicht zum Spiegel/Monitor selber). Wenn man nicht auf diese Kamera(s) verzichten kann muss man mit Leistungseinbußen nehmen, da sie immer voll rendern. Im ökonomischen Modus bedeutet das dann zwar keinen großen Einbruch, hat aber den Nachteil dass dann der rechte Spiegel mit halber Bildrate oder weniger läuft, was ich bei Kurvenfahrten sehr störend finde.


    Grundsätzlich fehlt mir aber in der WIki ein Eintrag zu den Spiegeln der das genau erklärt. Die folge sind dann vor allem Payware-Busse, die eine Art Käfig-Sicht haben mit Kinn direkt überm Lenkrad, damit man bloß keine Spiegel sieht, was aber null bringt wenn die Spiegel falsch eingestellt sind. Meist nämlich linker Spiegel als Typ 2 mit astronomisch hohem Wert bei Zeile 8, Rest als Typ 1...

  • [TUT] & [MOD] fOcUs04's Tüdelecke [eingestellt / discontinued]

    Moin!

    Hab gesehen Du hast in Deinem BRT-C2 Mod negative Werte in der 8. Zeile bei den Typ2-Spiegeln. Was hat es damit auf sich? Diese Werte hab ich immer so klein es geht je nach Spiegel gemacht, aber wäre nie auf die Idee gekommen da negative Werte einzustellen. Den Bus habe ich zur Zeit noch nicht, konnte es also auch nicht ausprobieren;-)

  • Omsi+BBS - CPU Auslastung dauerhaft bei 100%

    79% Auslastung auf einem 4-Kerner in OMSi dürfte nicht unnormal sein. OMSI nutzt auch 4 Kerne, einen davon sehr stark und die anderen drei deutlich mässiger. Solange Du nicht mehr als 4 Kerne hast muss sich OMSI alles mit allen anderen Programmen teilen, so auch BBS, und in Deinem Fall anscheinend auch nicht in zu unterschätzendem Ausmaß Discord sowie BBS (Java+omsischnittstelle) Der Rest der Hintergrunddienste summiert sich.


    Erfahrungsgemäß kostet BBS schon ein paar fps, vor allem häufen sich Lese und Schreibzugriffe. Neben der normalen OMSI Log nutzt BBS auch noch eine eigene.


    Fehler in Maps oder Fahrzeugen verursachen natürlich auch fps Einbrüche, zum teil sehr heftige, sind aber ein anderes Thema. Ein sauberes frisches OMSI wird ohne BBS immer besser laufen als mit, der Unterschied wird umso größer ausfallen, wenn man (oder das Betriebssystem) es nicht schafft OMSI wirklich ganz allein auf 4 Kerne zu legen, was überhaupt erst ab 6 Kernen geht, und bis dahin kämpfen dann eben auch Discord, Chrome, Defender und was weiss ich was noch um CPU Zeit.

  • Aachener Ibox und Terminus-Ansagen

    Zitat von O 405

    Gefühlt sollte man das doch mit einem Größenvergleich von GetTTBusstopCount (Anzahl der HST im Fahrplan) und GetTTBusstopIndex (Index der aktuellen HST) hinbekommen, oder täusche ich mich da? Ist jetzt nur eine nicht selbst durchgetestete Vermutung.

    Das ist auch die Richtung in der ich nun weiter denke. Die jetzige Version scheint stabil zu laufen auf anderen Karten, aber noch ohne die Temini. Einziger Unterschied bisher zu Aachen: neben der Liniennummer in der wird in der iBox immer "00" angezeigt, was aber nicht schlimm ist. Logisch, die Aachen-Routen sind ja im Script. Ebenfalls hab ich den Werkstattfahrt nicht für andere Karten aktiviert, wäre meist sinnlos glaub ich. Die Höfe wo ich das so haben will muss ich natürlich in die Scripte eintragen, sonst wird ganz normal der Teil ausgeführt der sonst auch für Nicht-Aachen bestimmt war. Wenn das alles jetzt eine Weile gut läuft versuche ich das mit den Termini.


    Zitat von O 405

    Die Mainzer i.Box damals hat noch die Route aus der Hofdatei geladen und dann mit Biegen und Brechen an den Fahrplan angepasst, da gab es zwar dann dieses Problem nicht, dennoch ist die Lösung mit den Daten direkt aus dem Fahrplan irgendwie eleganter. Wir erinnern uns doch noch alle mit leichtem Gruseln an die Routennummern, die im Fahrplan an die Liniennummern angehängt waren und manchmal auch auf den Außenanzeigen auftauchten, obwohl sie eigentlich unterdrückt werden sollten... ;) (Linie 6872 nach Hochheim!)

    Ich hatte in der Tat sogar ins Script der MANs geschaut, hab aber festgestellt dass da Welten dazwischen sind. Wenn die Mainzer iBox Version 1.0 war, dann ist die Aachener mindestens 8.0;-D Und meine erste Befürchtung bevor ich das ganze angegangen bin war tatsächlich dass die Citaros mir nun auf anderen Karten auch auf der Matrix die Routen anzeigen;-D In Mainz hat aber der Citaro Probleme wenn er eine zweistellige Liniennummer+E schildern soll. Der Font ist dafür bei der seitlichen und hinteren Anzeige nicht ausgelegt und schneidet das E knapp ab. Gleiches wäre vermutlich in Aachen mit "73V" der Fall. Auf anderen ORN-Linien könnte man den Citaro aus gleichem Grund auch nicht einsetzen, wobei ich glaube da gäbe es nicht mal ein passendes Repaint für.

  • Aachener Ibox und Terminus-Ansagen

    Aber die Anzahl der Haltestellen aus dem Fahrplan reicht doch für die Berechnung ob es sich um einen Terminus handelt oder nicht auch aus, oder? Nur irgendwie scheint mir der aktuelle Zähler an welcher Haltestelle man gerade ist in beiden Makros anders zu funktionieren, weshalb ein simples rauskopieren der Zeile 21 und 22 und Einfügen beim oberen Makro nicht funktioniert. Der Knackpunkt scheint mir ibox_routenindex und ibox_busstop zu sein, welche im Aachen-Modus wohl 0 sind.


    Nach Aachen-Art ohne Terminus funktioniert alles prima wenn ich die gewünschten Höfe zu den Abfragen hinzufüge.


    Mir ist natürlich auch klar dass sollte das so hinhauen wie ich mir das vorstelle müsste ich für Aachen von allen potentiellen Endhaltestellen Kopien der wav-Datein anlegen müsste mit dem Terminus-Suffix, aber das wäre verschmerzbar.


    Bei einem Versuch hat bei mir dann die Ibox im Aachen-Modus tatsächlich die Terminus-Ansagen abgespielt, allerdings keine Unterwegs-Haltestellen angesagt;-D

  • Aachener Ibox und Terminus-Ansagen

    Moin!

    Ich versuche der Aachener Ibox beizubringen zwischen normalen Haltestellen und Endhaltestellen zu unterscheiden. Dies geht aber irgendwie nur auf Fremdkarten im manuellem Modus mit Eingabe von Linie/Kurs bei jeder Fahrt. Unpraktisch bei gekoppelten Linien...


    Ich krieg das Script auf Fremdkarten mit automatischer Routenwahl zum laufen, die Ansagen werden dann auch abgespielt, aber beim Terminus eben auch eine "normale" Ansage. Ich krieg aber das Aaachen-Makro nicht modifiziert, denn anscheinend fehlt bei automatischer Auswahl der Wert für die Route, die im manuellen Modus per Hand eingegeben wird und in Aachen vom Script kommt. Versteh ich nicht, denn die korrekte Route wird ja geladen, somit ist doch bekannt wie viele Haltestellen eine Route hat... Am einfachsten wäre es dem Aaachen-Makro eben die Termini beizubringen...


    Hat da jemand ne Idee?


    Hier die beiden Makros:

  • Terrain-Texturen: keine Nässe?

    Ich bin mir nicht sicher ob dem so ist, denn ich habe ja auch schon öfters nasses Gras gesehen. Ich weiss aber auch dass es bei Splines und Objekten immer mal solche Fehler gab die erstmal nicht lösbar erschienen.


    Aber falls es doch keine Lösung gibt: wäre es vielleichta uch ein Weg eine einfache aber unsichtbare Spline oder ein unsichtbares Objekt (beides mit abgeschalteter Kollision) knapp über den Boden zu legen und mit puddles/moisture zu versehen um den Nässe-Effekt zu erzwingen, aber trotzdem die darunter liegenden Objekte oder Terraintexturen sichtbar zu lassen? Oder was wäre wenn man in dem Fall die Kreuzungsobjekte, die dort nur aus Pfaden bestehen eben mit so einer unsichtbaren voll-transparenten Textur versehen würde? Das wäre vielleicht die Königslösung wenn man die Terrain-Texturen nicht nass bekommt... Ich hab allerdings noch keine Ahnung wie ich eine solche unsichtbare Textur erstelle, aber das dürfte dann das kleinste Problem sein.

  • [Sammelthread] Add-On Düsseldorf

    Moin!

    Hatte schon mal wer auf Düsseldorf einen Endlos-Freeze von OMSI mit diesem Fehler am Ende der Logdatei?


    Error: Zugriffsverletzung bei Adresse 004031C1 in Modul 'Omsi.exe'. Lesen von Adresse 41E7FFFC: CMOI.R.3 (vehicles\DUS_ET422\ET-423_4.ovh)


    Denn eigentlich lief der 422 in letzter Zeit bei mir recht stabil im Gegensatz zu vielen anderen Zügen, und hübsch ist er auch.

  • KI-Zug stellt weiche nicht

    Mit einem Geisterzug funktioniert das erstaunlich gut. Nur die einzigen unsichtbaren Fahrzeuge die ich fand waren aus Gladbeck und Ruhr. Da hätte ich dann doch lieber eine Alternative die davon unabhängig ist. Das mit den Ampeln würde ich mir gern trotzdem anschauen. Wo gibts denn Infos dazu wie das genau funktioniert?

  • KI-Zug stellt weiche nicht

    Zitat von Manuel

    Ohne die Weiche zu löschen, kannst du aber auch eine Ampelweiche draus machen, die sich dann von selbst immer stellt.

    Ginge das dann flexibel als Chronoevent? Hätte Ampelweiche nicht den Nachteil dass es den Gegenverkehr behindern würde?

    Die Weiche die verbaut ist, ist eine Standard-Spandau-Weiche aus dem Rüdiger-Verzeichnis.

  • KI-Zug stellt weiche nicht

    Moin!

    Auf ALU Updated wollte ich den Zugverkehr mit neuen Fahrplänen versehen und bin dabei auf ein Problem gestoßen. Es gibt da zwei eingleisige Abschnitte: zwischen dem Bahnhof Derenhofen und Derenhofen Klinikum und dann zwischen Derenhofen Klinikum und der nördlichen Hauptstrecke. Jetzt habe ich gesehen dass Züge die in Derenhofen halten (Fahrtrichtung Klinikum, also zum eingleisigen Abschnitt) nicht in der Lage sind die vor ihnen liegende Weiche zu stellen. Sie legen einen endlosen Halt am Bahnhof ein und warten.... Erst wenn ich per Hand die Weiche selbst stelle (wusste bisher garnicht dass das geht...) fahren sie los. Ich vermute mal dass die Weiche zu weit vor ihnen ist, kann da aber den Haltestellenwürfel nicht weiter vorschieben.


    Was also tun? Ich denke irgendwie muss da gemogelt werden, oder was macht man in solchen Fällen? Im Hinterkopf hätte ich da nur die Idee mit einem geisterzug, der kurz vor den fahrplanmässigen Abfahrten ein paar Pfadpunkte über die Weiche fährt und dann verschwindet. In Gegenrichtung besteht das Problem nicht.


    Ich würde das gerne ohne direkte Eingriffe in de Strecke lösen, würde also nicht da die Schienen neu verlegen oder ähnliches.

  • Terrain-Texturen: keine Nässe?

    Moin!

    Mich hat es auf ALU Updated genervt dass die Straßen zum großteil bei Regen nicht nass wurden, oder eben nur teile davon. Also hab ich mir die Dateien mal angeschaut. Die Straßen um die es hier geht sind eigentlich keine Straßen, sondern eine Asphalt-Textur auf den Boden gepinselt: die eigentlichen Kreuzungen beinhalten nur die Pfade. Speziell sind das die DavidM-Texturen 1asphalt.dds bis 6asphalt.dds im Verzeichnis Texture/DavidM1512.


    Zuerst habe ich gesehen dass die cfg-Datei fehlen, also schnell mal welche erstellt nach dem Schema 1asphalt.dds.cfg bis 6asphalt.dds.cfg mit [moisture] und [puddles] drin, doch das hatte keinen Effekt, sie blieben weiter trocken.


    Dann erinnerte ich mich an ein ähnliches Problem früher auf Hamburg Tag und Nacht, dort war die Lösung dann statt dds -Texturen nur bmp zu verwenden. Also mala lles konvertiert und entsprechend umbenannt, sowie die neuen Endungen in der Texruren-Liste in der global.cfg angepasst. Ebenfalls kein Effekt.


    Das gleiche auch mit Fake-bmp-Texturen versucht, also Endungen bei dds belassen, aber halt eine bmp untergejubelt. Brachte auch nix.


    Wo hängts denn da? Ich glaube ja nicht unbedingt dass Terrain-Texturen nicht nass werdeb können, hab doch schon nasses Gras immer wieder gesehen. Bad Hügelsdorf hat übrigens auch Terrain-Texturen die mit so einer Config versehen sind.... Liegt es vielleicht an den Texturen selber, dass ihnen irgendeine Eigenschaft fehlt?


    Ich finde das ziemlich hässlich bei Nässe zu fahren wenn dann die Markierungen auf den Straßen nass sind, die Straße aber nicht, aber wieder der nächste Straßenabschnitt schon...

  • [Sammelthread] Add-On Kaiserstadt Aachen

    Beim Bus ist mir nun auf einer anderen Karte aufgefallen dass es bei der hinteren Linienanzeige doch ganz schön eng wird wenn diese mal 3 Zeichen darstellen muss. Im konkreten Beispiel passte "E80" nicht mehr ganz drauf. Hat mich schon etwas gewundert, weil es in Aachen ja auch die Kombination aus Liniennummer + E oder V gibt, sowie die 100er Linien. Wobei das mit der 1 am Anfang wohl noch geht, das ist wahrscheinlich schmal genug.


    Edit:

    Das ist keine große Sache mit den Fonts, man kann sie sich relativ leicht stauchen für Versionen der Busse für andere Karten. Wen's interessiert: In den model-Configs im Bereich Seitenmatrix die Breite auf 256 setzen, schon passt alles dreistellige prima.


    Im VDV Display fiel mir nun auf dass dort eigentlich die Innentemperatur angezeigt werden sollte, es wird aber die Außentemperatur angezeigt. Das ist wenig hilfreich, da sich die Außentemperatur bei einer Schicht kaum verändert, die Innentemperatur aber natürlich schon. Außerdem deutet das Icon auf Innentemperatur hin, auch im Cockpit Script erkenne ich eher dass es sich im diese handeln sollte. Ich glaube aber Heizung-Script überschreibt diese Variable mit der Außentemperatur, aber so ganz steige ich da nicht durch;-)


    Edit2:

    Nicht schlecht staunte ich kürzlich auf den Kilometerstand der Busse: etwa 2,6 Mio Kilometer auf dem Buckel... Da muss doch im Script irgendwas falsch laufen, denn als Baujahr ist z.B. bei Solo 2009 angegeben und die jährliche Laufleistung bei 60000. Solch eine Laufleistung dürfte der Bus doch erst um das Jahr 2043 anzeigen... Etwas 700000 würden es 2021 eigentlich sein müssen;-)

  • MB-Schriftzüge per Repaint ein/ausblenden

    Moin!

    Ich habe in meine Aachener Citaros die Mercedes-Sterne und Citaro-Schriftzüge integriert und dachte ich könnte diese realtiv einfach mit [visible] in der Model-Datei per CTI ein oder ausschalten. Leider klappt dies nicht, die Sterne und Schriftzüge sind immer da. Für einige Repaints muss ich diese aber zum Teil abschalten, da es sonst seltsam aussieht.


    Hier mein Code am Beispiel der O530 Model-Datei:


    Wenn ich das richtig verstehe sind die Werte standardmässig auf 0 (=wird angezeigt) und zum Abschalten müssten sie auf 1 gesetzt werden.


    Hier die CTI eines Repaints:

    Die letzten 4 Einträge sollten das doch steuern und in diesem Beispiel nur den vorderen Stern anzeigen, sonst nix. Es wird aber alles angezeigt. Sieht da jemand irgendwo den Fehler?

  • Der allgemeine "Hardware-Kaufberatungs"-Thread

    Die Grafikkarten-Frage entscheidet sich nicht über OMSI sondern über die anderen Spiele. Eine 1050Ti sollte locker für OMSI OMSI reichen. Und sie darf bis zum Anschlag laufen. Wenn sie sagen wir mal meist bei 80-90% liegt dann scheint sie perfekt zu sein. Exakte 100% wären ein Anzeichen dafür dass sie zu schwach ist. Und selbst vor paar Jahren meine 560Ti und 970er liefen kaum über 50%. Nur wenn ich da noch SGSSAA verwendet habe und so Späße dann hatte sie mehr zu tun. Die aktuelle 1080 krieg ich hingegen nie in den Bereich über 50... Nicht bei OMSI, anderswo schon;-D


    Schlechtes Wetter ist an sich auch kein Problem für die Grafikkarte. Was hier reinknallt sind die Reflexionen auf den nassen Straßen, und auch die berechnet in OMSI wohl leider die CPU. Das heisst also: egal welche CPU man hat: es wird immer einen fps Drop geben bei Nässe der erheblich ist. Aber mit guter CPU bekommt man dafür mehr Luft. Deshalb teste ich auch Performance am liebsten bei Regen, um zu schauen wie tief es dann geht, damit eine Situation wie Innenstadt + Hauptverkehrszeit + Regen keine Spaßbremse wird.


    Notfalls kann man auch die Reflexionen auf den Straßen abschalten. Ich finde aber dass dann viel vom Flair flöten geht.

  • Spiegel Einträge in der Busdatei Erklärung benötigt (für was ist welcher eintrag da)

    Kleine Anmerkung:

    Wenn es sich bei einem Eintrag um eine Fahrgastraum-Kamera und nicht um einen Spiegel handelt, muss diese immer gerendert werden damit sie funktioniert. Oby Reflexions Typ 1 oder 2 spielt dabei keine Rolle, weil die Kamera sich ja im inneren des Fahrgastraums befindet, und man somit selber immer weit weg von ihr ist. Das hat die Folge das dann die Performance arg drunter leidet, vor allem weil manche Busse dann auch noch gerne 4 Bilder von 4 Kameras darstellen... Da ich gesehen habe dass es sich beim Bus um den DD handelt fiel mir das ein, denn bei diesem fressen die Monitore unglaublich viel Leistung in der Innenansicht, sodass ich diese lieber abschalte, weil sie mir keinen Mehrwert geben.


    Ansonsten kann man mit den richtigen Werten schön was an Performance rausholen, indem man die Spiegel so seinen Bedürfnissen nach konfiguriert, dass sie nur berechnet werden wenn man auch drauf guckt. Das macht man mit Typ "_2" Reflexionen, indem man die letzte Zeile so niedrig einstellt, dass sie der Spiegel nur aktiv ist beim hinschauen. Ist etwas fummelig, weil jeder Bus anders ist, aber es lohnt sich. "Letzte Zeile": die gibt es nur bei [add_camera_reflexion_2]. In Deinem Beispiel Zeile 9. [add_camera_reflexion] ohne die _2 haben diese Zeile nicht, und wenn doch, wird diese ignoriert. So ist es auch im Beispiel von Dir.

  • [Sammelthread] Add-On Kaiserstadt Aachen

    Ich erinnere mich da hatte ich mal den Fall dass die Classenstraße-Chrono bei mir auch zerschossen war. Ich habe vor einer Weile den ganzen Fahrplan-Ordner aus einem Backup (in dem aber die aktuelle Aachen-Version war) zurückgespielt in die OMSI-Installation und wunderte mich dann dass auch nichts auswählbar war, die Log ebenfalls ähnliche Meldungen ausgab. Der Grund fürs Wiedereinspielen der Backups war dass ich vorher mit car_use experimentiert habe, das Ergebnis mir aber nicht gefiel, und der einfachste Weg war eben auf das Backup zurückzugreifen. Nur irgendwie hat das erstmal nicht geklappt, hat sich aber dann schnell erledigt mit einfach in den Editor gehen und Karte einmal abspeichern. Aber ich weiss bis jetzt nicht warum was da los war und warum das die Lösung war.


    Wichtig zu wissen ist für Deinen Fall dass die relevanten Fahrpläne, auch für die KI, in besagter Classenstraße-Chrono stecken.