Beiträge von wurstbrot

Das hinten reinfahren in die Gelenkbusse hängt auch von den Karten ab. Es ist meist immer an den gleichen Stellen. Beispielsweise in Aaachen an der Haltestelle hinter Westbahnhof Richtung Uniklinik. Oder besser gesagt: es hängt vermutlich von den Pfaden ab, irher Länge etc. Man müsste sich das mal anschauen, aber ich könnte mir vorstellen dass an diesen Stellen der Vorderwagen und Nachläufer auf unterschiedlichen Pfadsegmenten stehen, und das Segment mit dem Nachläufer wird als frei von der Ki gewertet. ganz so einfach ist es sicher nicht, denn auf langen Pfadsegmenten können sehr wohl mehrere Fahrzeuge sein, siehe lange kurven, aber es bringt wohl die Erkennung durcheinander. Vermutlich aus gleichem Grund spawnen Busse ineinander an manchen Endstellen, wenn diese dort Pause haben. Hab ich mal beobachtet. Sie erschienen zeitgleich, der Nachläufer wurde völlig ignoriert vom Bus dahinter: Wer sich das genau anschauen möchte um eventuelle Rückschlüsse für den Kartenbau zu ziehen: ALU Updated Derenhofen Markt, Pausen-Hst der 25+811.

Aber wie man es dreht und wendet, es ist verbuggt und ich kann beim Besteln willen nicht mein Fahrverhalten an irgendwelche Pfadsegment-Logiken anpassen. Allerdings kommt Kollisionsabschaltung nicht in Frage, denn da würd ich mit der Zeit mir einen falschen Fahrstil aneignen und z.B. beim Rechtsabbiegen oder Haltestelle anfahren etliche parkende Autos mitnehmen ohne es zu merken. Sieht man ja schön in manchen YouTube Videos wie alles abrasiert wird links und vor allem rechts, und sie merken es nicht mal;-D Dann kann man sich auch gleich den Spiegel abschalten und die Performance sparen.

Zitat von Bamp

Irgendwo habe ich letzens [ai_breakperformance] gesehen (in der .ovh). Vielleicht kann kann damit - oder etwas ähnlichem - das ändern.

Könnte man sich anschauen, finde aber eh auf den letzten Metern das Anhalten oft zu grob. Den Autos fehlt da die Weitsicht, sie müsstene igentlich schon früher vom Gas gehen und dann behutsam abbremsen. Ausser halt der Spieler bremst wirklich abrubt.

Naja, bei einem Solo fährt mir nie jemand hinten rein, die KI hält ausreichend Abstand;-D Bei Gelenkbussen passiert das immer, und lässt sich nicht vermeiden. SOgar beim M&R NG -MAN. So gut scheint also der Sicherheitsabstand nicht ausgemessen worden zu sein, es betrifft ja nicht nur Fremdbusse. Und ich wüsste echt nicht was man tun soll, ausser nicht an Haltestellen zu halten oder an der Ampel;-D

Zitat von Schleswig-Holstein

Nach hinten musst du immer differenzieren, was du gerade für einen Bus fährst.

Die KI nach hinten hält nämlich immer für einen Gelenkbus Abstand. Folglich haben die bei einem Solo mit 12 Meter immer mindestens 6 Meter Abstand.

Das könnte sein... Nicht sehr wirkungsvoll wenn ich mal alle Unfälle zählen würde bei den Gelenkbussen...

Das ist halt die Frage... In Spandau zum Beispiel gibts bei WinterSnowFall-Straßentexturen kein [moisture], nur Slush (8). In der Realität ist ein Schneematsch auch was völlig anderes als eine nasse aber gefrorene Straße. Ich bin nicht ganz sicher wie man das nun am Besten einstellen sollte. Vielleicht mal testen in dem man sich das Wetter präperiert und erstmal schauen ob bei eisigen Temperaturen bei einer normalen nassen Straße ein Rutscheffekt entsteht, und dann wie es im Schneematsch aussieht.

Ohne es jetzt genauer zu wissen, ich denke schon dass das in den Scripten der Fahrzeuge auch eine Rolle spielt. Im Normalfall sicher nicht durch Abfrage der Wettervariablen sondern durch Abfrage der Oberflächen, ähnlich wie Klappersounds bei Kopfsteinpflaster umgesetzt werden.

Technisch gesehen läufts folgendermaßen:

- aktiviert OMSI die WinterSnowFall-Texturen, gibts Schnee auf den Straßen

- aktiviert OMSI die WinterSnow-Texturen, gibts Schnee nur auf den Gehwegen und in der Landschaft.

Erstes passiert erst ab einer gewissen Menge oder Intensität des Schneefalls, fürs zweite reichen geringere Werte. Je nachdem was also die Wetterstation liefert, schaltet OMSI das entsprechend ein. Erfahrunsgemäß ist aber "WinterSnowFall" sehr sehr selten, kommt aber vor.

Jetzt kommt aber hinzu dass das beschriebene Verfahren nur Standard ist. Wenn die Objektersteller da was durcheinander gebracht haben und die Texturen falsch zugeordnet haben, kann es völlig chaotisch werden. Auf ALU zum Beispiel gibts ein Chaos, da die DavidM Texturen das falsch machen. Da sind zum Teil voll verschneite Straßen im WinterSnow-Verzeichnis und im WinterSnowFall gar keine, gemixt mit anderen Splines und Texturen ein völliges Chaos, was man erstmal ordnen muss.

Auch sind bei manchen Splines und Objekten die WinterSnow-Texturen nass, was sie im Standard eigentlich nicht sind. So nass sieht Schnee eigentlich nicht aus. Da würde ich mir echt wünschen dass sich da alle an einen Standard halten und es durchgezogen wird.

Was ich mich aber frage ist wann komme ich (technisch gesehen) mit dem Bus ins rutschen? Wenn eine Straße nass ist und eine bestimmte Temperatur unterschritten wird, oder erst wenn "WinterSnowFall" Texturen aktiviert werden und zum Beispiel als Surface den Matsch eingetragen haben?

Moin!

Mir ist in letzter Zeit aufgefallen, dass die KI-Fahrzeuge großen Abstand zu meinem Bus halten, beispielsweise wenn ich an der Haltestelle stehe, oder an einer Ampel. Das kommt mir etwas seltsam vor, war ja von früher eher gewohnt dass die einem manchmal hinten reinkrachen, vor allem bei Gelenkbussen. Allerdings habe ich irgendwann vor zig Monaten den Rowdy-Faktor bei allen Fahrzeugen von den üblichen ich glaube -0.5 - 1.0 auf -1 bis 0.25. Ich weiss nicht ob das damit zusammenhängt, oder von anderen Faktoren abhängt, fand es jedenfalls seltsam dass die Autos hinten gut eine PKW-Länge im Stau Abstand halten, und manchmal in Kurven sich auch nicht auf die Nachbarspur trauen, obwohl ausreichend Platz wäre. Dass es mit dem Rowdy-Faktor zusammenhängt glaube ich eigentlich nicht, ähnliches auch an Haltestellen gesehen wo sich KI-Busse nicht zu nah hinten an mich trauten, während sie anderen KIs durchaus Stoßstange an Stoßstange kleben. Und natürlich auch verschiedene Busse ausprobiert;-) Der Bus war übrigens ein Solo, beim Gelenkbussen ist das ja bekanntlich ziemlich verbuggt von Hause aus. Der KI-Verkehr bestand aus Aachen-PKWs, X10-Sprintern/VW-Bussen, einigen Halycon Vol 4 Autos und dem ollen MB Sprinter aus Spandau, sehe da aber keine Unterschiede.

Oder ist das normal und meine Erinnerung trügt mich einfach und es war immer schon so?

Da gibt es gar keine fahrenden LKWs. Nach und nach füge ich diese nun auch selbst hinzu für die Hauptstraßen, Gewerbegebiete etc. Leider muss man da auch die Pfade per Hand aktivieren, denn wenn man es umgekehrt machen würde, dann würden sie in jeder Gasse rumfahren.

Shift wäre quatsch, das dient ja zum zurücksetzen auf standard. Aber klar, habs trotzdem probiert und auch mit Strg.

Da würde ein Screen nicht viel helfen, eher ein Video...

Das Vorgehen wäre folgendes:

- Ich lade die Karte, wo im Standard-Event die Spur auf Standard ist, also freigegeben

- ich wähle das Unfall-Event aus

- ich klicke auf Traffic Rules, dann auf no unscheduled traffic

-> ich versuche die Spur nun schwarz zu markieren mit einem klick drauf. Wenn die Maus über der Spur ist wird die Spur schwarz angezeigt, ein anklicken der Spur bringt aber keine Änderung, die Spur bleibt in der Standard-Farbe.

Ich habe da als ich das gemacht habe nicht extra zwischengespeichert, da ich das nicht für nötig hielt. Mittlerweile ist es aber ja ein alter Save. Wenns also damit zusammenhing müsste das ab dem zweiten Laden ja klappen, tut es aber nicht.

Im Unfall-Event sind auch nur Objekte drin, die Pfade sind weiter natürlich weiter aus dem Standard-Event.

An anderen Stellen klappt es übrigens prima in einem Event Pfade zu markieren, beispielsweise um die Verkehrsdichte zu ändern.

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?

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

Ja, da stand nur nix von negativen Werten, weil es den Abstand zur Kamera beschreibt, wenn ich das Richtig im Kopf habe. Gemerkt habe ich mir mir aber nur "so klein es eben geht";-)

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

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.

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.

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:

{macro:Haltestellenansage_Aachen}
    (L.L.schedule_active) 1 =
    {if}
        (L.$.Yard) "Aachen" $=
        (L.$.Yard) "Aachen 2015" $= ||
        {if}
            "..\..\Announcements\" 0 (M.V.GetDepotStringGlobal) "\" $+ $+ 
            (M.V.GetTTBusstopIndex) (M.V.GetTTBusstopName) $+
            ".wav" $+ (T.F.ev_IBIS_Ansagen)
        {else}
            (M.L.Haltestellenansage)
        {endif}
    {endif}
{end}

{macro:Haltestellenansage}
    (L.L.ibox_busstop) 0 >
    {if}
        "..\..\Announcements\" 0 (M.V.GetDepotStringGlobal) "\" $+ $+ 
        (L.L.ibox_routenindex) (L.L.ibox_busstop) (M.V.GetRouteBusstopIdent) $+
        (L.L.ibox_routenindex) (M.V.GetBusstopCount) 1 - (L.L.ibox_busstop) <= {if} "_#terminus" $+ {endif}
        ".wav" $+ (T.F.ev_IBIS_Ansagen)
    {endif}
{end}

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?