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!

    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

    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:

    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.

    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.

    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?

    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.

    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.

    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...

    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;-)

    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?

    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.

    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.

    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.

    Welchen neuen Abschnitt meinst Du?`Willi-Brand-Platz ist bei Fahrt mit aktuellem Datum Montags bis Freitags bei der Linie 73 drin, den Grabenring kannst Du Montags bis Freitags garnicht befahren, sondern nur in den Nächten von Freitag auf Samstag und auf Sonntag mit der N4, sowie mit dem Grabenring-Express tagsüber nur an Samstagen.


    Sollte die 73 bei Dir trotz aktuellem Datum nicht über den Willi-Brand-Platz gehen oder die N4 am Theater wenden, dann stimmt was mit den Chronos nicht, und dann würde ich eine Neuinstallation des Addons erwägen.


    Und in wie weit die aktuellen Fahrpläne überhaupt im BBS sind weiss ich nicht. Wenn sie das nicht extra upgedatet haben, dann sind sie nicht auswählbar.

    Ist im Grunde richtig. Die durchschnittlichen fps sind nur ein guter Anhaltspunkt dafür obs gut läuft oder nicht. Gute Frametimes bei niedrigen fps fühlen sich immer besser an als schlechte Frametimes bei hohen fps. Aber halt auch nur solange die fps über einem erträglichen Minimum sind: bei 16-20 fps ist es selbst bei guten Frametimes alles andere als gut. Zumindest in Simulationen: in Cities Skylines habe ich oft nicht schlecht gestaunt wie flüssig es sich anfühlte obwohl der Zähler bei bestimmten Blickwinkeln unter 20 war. Allerdings kommt in Simulationen noch ein wichtiger Aspekt dazu: mit geringeren fps sinkt die Reaktionszeit beziehungsweise die Latenz erhöht sich. unschön z.B. bei Gefahrenbremsungen oder plötzlichen Ausweichmanövern. Da ist selbst in OMSI der Unterschied zwischen 20, 30 und 40 fps krass fühlbar, vor allem dann wenn man auf Latenzerhöhende Einstellungen wie Vsync verzichtet und somit nicht dauerhaft übertrieben hohe Latenzen hat. In einem Rennspiel wäre das noch krasser wahrnehmbar. Flugsimulatoren sind da wieder ein anderer Fall: trotz der hohen Geschwindigkeit ist man meist weit weg vom Boden, und daher sind da auch um die 30 fps völlig okay. Wenn man allerdings landet wendet sich das Blatt wieder, da sollte man wieder im höheren Bereich sein.


    Aber wie auch immer, so als absolutes Minimum was gehalten werden kann sollte in einer Simulation schon 30 fps sein bei guten Frametimes, also ohne die ganzen nervigen Spikes und ohne Nachladeruckler. Auf guten Rechnern mehr, aber dann ist es auch egal ob man an die 60 oder 100 kommt. Für mich persönlich reichen in OMSI 40 fps, Nachladen mal völlig aussen vor gelassen, in Lotus ist das Nachladen zwar etwas besser aber weit weg von dem was ich erwarte, und beim Fahren mit 50 fps fühlt es sich auch ausserhalb des Nachladens noch zu holprig an. Das geht ja schon los wenn ich in D-Lörick die Schleife verlasse, der fps Zähler zwar nie unter 30 fällt und sich meist zwischen 40 und 50 bewegt, das aber gefühlt noch sehr unsauber ist, was an den erwähnten Frametimes liegt.

    Wenns um OMSI geht nicht so viel Kopf um die Grafikkarte machen, lieber schauen dass man die beste (min 6 Core bei Ryzen über 2000er Serie, bei 1000er 8 Core) CPU für sein Geldbeutel kriegt kombiniert mit optimal taktendem Speicher. Das stimmt, bei Ryzen sollte man schon schauen mit den Teilern, das variiert auch von Generation zu Generation. Und es kann schon gute 10 oder mehr Prozent ausmachen wenn der Speicher entweder zu langsam ist oder aufgrund des Teilers ungünstig betrieben wird.


    Und da gibts noch unterschiede zwischen Sigle Sided und Double Sided Modulen. Letztere waren meist schneller bei gleichem Takt, es gab aber je nach Board Einschränkungen. Das ist nun wohl viel besser geworden, aber ich würde zur Sicherheit immer die RAM-Kompatibilitäts-Liste des Board-Herstellers checken. Dort ist genau aufgeführt mit welchem Takt welche RAM Module betrieben werden können. Das spart unter Umständen viel Ärger, weil es immer mal Boards gibt die dann halt mit Modul X oder Y eben nicht so klarkommen oder nur bei niedrigerem Takt, oder nur bei einer bestimmten Gesamtspeichergröße... Ich hatte damals echt Mühe zwei 16GB Module zu finden die perfekt waren. Und die die ich dann hatte waren nicht perfekt: es sind 3000er, laufen aber leider nur mit 2666 stabil. Bei 2x 8 GB hätte ich mehr Glück gehabt, aber zu dem Zeitpunkt war das alles etwas tricky. Ist heute einfacher, aber es lohnt sich da nicht ein Glücksspiel draus zu machen.

    Aber eines ist mir aufgefallen im Dunkel, man kann zwar Lichthupe beim eingeschalten Abblendlicht geben, aber hat keine Auswirkung auf den KI-Verkehr. Für die Auswirkung muss man weiterhin auf Standlicht oder komplett aus (Die Beleuchtung) umschalten.

    So ist es. Wobei ich glaube bei manchen Bussen wenn man es schaffte kurz genug das Fernlicht einzuschalten, hat es manchmal geklappt. War mir aber zu mühselig. Die Lösung aus dem Solaris PL fand ich dann nahezu perfekt. Ich weiss nicht wie genau OMSI Lichthupe triggert, aber ich glaube es geht um die Kürze der Zeit, und das ist fast im Milisekundenbereich.

    Lotus ist kein Ersatz für Zugsimulationen. Es kann zwar Zug, aber die Sinnhaftigkeit wird irgendwo im Regionalverkehr aufhören.

    Ich meine mal gehört zu haben, dass man sich auch auf den Regionalverkehr beschränken möchte. Im Entwicklungsfortschritt ist jedenfalls die S-Bahn-Linie Spandau-Lichtenberg genannt.

    Genau, und ich würd fast sagen eine typische S-Bahn, wovon es in Deutschland eigentlich nur eine in Hamburg und Berlin gibt, ist genau die grenze des sinnvollen. Klar würde man die Zugsicherungssysteme etc so hinkriegen dass auch absolut vorbildgerechter Fernverkehr möglich wäre, aber ich glaube bei der Engine muss man sich entscheiden wo man den Fokus legt. Deswegen verstehe ich auch bis heute nicht warum man sich ausgerechnet an die Luftfahrt noch wagen möchte. Da seh ich viel mehr Sinn drin z.B. etwas Binnenschiffahrt einzubauen z.B. für Fährverkehr, wobei das wieder aufgrund ganz anderer Physik auch grenzwertig wäre. Aber immerhin eine unbesetzte Marktlücke.


    Und ob nun externe oder interne Engine spielt meiner Meinung nach keine Rolle, es zählt das was kann man am Besten mit welchem Mittel erlauben. Eine UE Engine bietet grafisch zwar mehr, hat aber seine Tücken. Sie scheint nicht wirklich auf das simulieren ausgelegt zu sein, und hat extrem große Schwächen in Sachen wie Editor bereit stellen etc. Firmen wie DTG haben dies sogar wohl als Vorteil gesehen: je weniger Leute basteln können, desto mehr wird gekauft. So zumindest das Kalkül anfangs, auch wenn sie das so nie sagen würden.