Beiträge von wurstbrot

Manchmal kann es ja schon eng werden;-) In dem Beispiel wärs egal, aber hatte genug Fälle wo es schon sehr knapp war. Wegen der Einheitlichkeit mach ich es dann durchgehend aber mit Kleinbuchstaben. Ist aber alles kein Muss. Wenn man zum Beispiel mit echten betrieblichen Kürzeln arbeiten will, dann macht man eben Großbuchstaben. Man muss sie dann halt im Kopf haben und nicht jedes Mal erstmal in eine Liste schauen müssen, denn das würde den Workflow erheblich behindern. Fakt ist ja auch dass die Trip-Namen nur im Editor eine Rolle spielen oder falls man die ttl-Datei selbst editiert. Im Spiel ist das wurscht, außer das Script eines Druckes braucht es für irgendwas. Aber dann ist man eh daran gebunden...

Sehr interessant, fast das gleiche System hab ich auch. Nur tendiere ich da zu Kleinbuchstaben, weil man so mehr Buchstaben in den engen Platz im Dropdown-Menü bekommt. Ansonsten auch wenns geht einheitliche Kürzel mit höchstens 3 Buchstaben. Wobei ich bei Zielen die etwas Abweiche und nach Möglichkeit den Stadtteil vorziehe mit kleinem Anhängsel falls es da unterschiedliche Endhaltenstellen gibt.

Beispiele:

"61_mom-lau_h" Linie 61 von Mombach nach Laubenheim Hans-Zöller-Straße

"61_mom-lau_r" Linie 61 von Mombach nach Laubenheim Riedweg

"61_lau-mom" Linie 61 von Laubenheim "egal wo da" nach Mombach Waldfriedhof (Waldfriedhof nicht gesondert als _w angehängt, da bei dieser Linie dort das einzige Ziel, Starthaltestelle irrelevant für den Trip, da außerhalb der Karte.

Gerade für die Ziele ist das Wichtig es einheitlich zu machen, da man öft bei KI Linien gleiche Trips hat mit unterschiedliche Zielanzeigen.

Aber man muss halt sehen was eben sinnvoll für eine Karte ist. Ziel ist auch dass man sehr schnell erkennt was der Trip darstellt. Und bloss nicht durcheinander kommen mit Leerzeichen, Unterstrichen etc, sonst wird es komisch sortiert. Immer einheitlich bleiben.

Ich würde auch Umlaute in den Bezeichnungen vermeiden, hatte hier und da schon unerklärliche Probleme deswegen.

Betriebsfahrten kennzeichne ich entweder als Linie 77 (aber nur auf der Karte Mainz da dort die 77 Betriebsfahrt oder E ist) oder als "bf_". Bei Bahnlinien ist das dann ähnlich. Wichtig ist sein Konzept auf einer Karte so stur wie möglich durchzuziehen.

Edit:

Steigbezeichnungen nutze ich natürlich auch, aber nur wo nötig, zum Beispiel an einem Hauptbahnhof oder ZOB, aber da auch nur wenn es variiert. Wenn eine Linie immer nur den Gleichen Steig nutzt vermeide ich es zusätzlich zu benennen. Bin aber hier leider recht inkonsequent;-)

So ganz bedingungslos würde ich das nicht mehr empfehlen. Das Lenkrad an sich ist gut, fühlt sich wertig an und macht auch Spaß. Pedale und Gangschaltung ebenso. Eigentlich top für den kleinen Geldbeutel und beengten Raum.

Aber:

Die Software und die Treiber sind mittlerweile eine einzige Katastrophe. Ich hatte kürzlich das "Vergnügen" das System neu zu installieren und habe den GHUB nicht dazu bringen können dass in OMSI die Zentrierfeder aktiv ist. Auch das Force Feedback war schon ab etwa 10 km/h nicht wahrnehmbar. Jegliche Änderungen bei den Einstellungen haben nix gebracht. Erst als ich auf eine Uralt-Version des GHUB zurückgepatcht habe lief es. Erstmal. Ist auch kein reines OMSI-Phänomen, auf der Suche nach Lösungen würde ähnliches zum Beispiel vom Landwirtschaftssimulator berichtet. Das tollste Lenkrad nutzt ja nix wenns nicht korrekt funktioniert.

Tatsächlich wäre da die Logfile wichtig. Die findest Du im OMSI-Hauptverzeichnis. Damit das ganze was nutzt bitte einmal OMSI starten und dann versuchen Mainz zu starten. Dann OMSI beenden und dann die Logfile hier reinposten als Anhang.

Eine Installation der erwähnten OMSI Tools ist auch sehr empfehlenswert, denn dann findet man besser raus was fehlt. Ich nehme ganz stark an dass das so ein Problem ist, dass irgendeine Abhängigkeit fehlt oder unvollständig ist. Alles aber hinkriegbar, nur Geduld.

In dieser Sache eine Beobachtung die ich gemacht habe aufgrund eines kleinen Versuchs. Bei der Ausstiegshaltestelle "Klein-Winternheim Bahnhof" auf Mainz kam es immer vor dass die Fahrgäste kreuz und quer und wieder durch den Bus liefen beim Aussteigen. Ihr Ziel war aber relativ klar eine Stelle des Bahnsteig-Splines gut 50-100m weiter (anstatt des Pfades bei der Haltestelle). Ich hab mir dann mal gedacht was wenn da kein Pfad wäre - und hab die Spline durch eine Pfad-lose Variante mal ersetzt. Und siehe da, nun gehen sie brav auf den Pfad neben der Haltestelle. Ich denke da bin ich nun dem Grund für diese Lauferei näher und kann das genauer untersuchen. Die Spline war auch recht lang, vielleicht mag das OMSI nicht. Also werde ich sie als nächstes unterteilen, kürzen usw.

Wer auch solche Stellen hat: schaut Euch mal an wohin die Leute laufen, also an welcher Stelle sie dann dem Pfad folgen. Und mit diesem Pfad dann Versuche machen. Eventuell ist dann die Lösung ganz banal.

Zitat von Hildesheimer

Interessante Idee.

Da sich in der Realität von hundert Fahrern vielleicht einer an das Stoppschild hält, habe ich den Aufwand in OMSI für mich privat immer für unverhältnismäßig angesehen.

Umso schöner zu sehen, dass sich einige Omsianer auch um solche Details kümmern!

Den Fall dass sich nicht alle dran halten habe ich auch überlegt. Ich glaube mit "unperfekten" Phasen könnte man das hinbekommen dass sich nicht alle dran halten.

Zitat von IREgio612

Schau mal auf Gerolstein. Ich meine, dass bei der einen Kreuzung vorm Rathaus (nicht Richtung Kreisverkehr, sondern andere Richtung) das entsprechend umgesetzt wurde.

Danke für den Tipp. Habe Gerolstein derzeit nicht drauf und das dauert noch etwas bis ich das installieren würde, da eventuell ein Mainboard-Wechsel ansteht mit den bekannten Unannehmlichkeiten;-D Da wurschtel ich nicht zu sehr in meiner OMSI Installation rum vorher. Aber ich merks mir, bzw es steht ja dann hier da;-)

Ich werde das mal an einer Stelle demnächst ausprobieren, so hab ich mir das ja auch vorgestellt. Dann zeigt es sich obs den Aufwand lohnt. Aber wenn man eh schon eine Kreuzung hat und sich mal so eine Ampelphase definiert und getestet hat sollte das bei den nächsten Implementierungen weniger problematisch sein.

Daran auch eine "echte" Ampel irgendwo zu verbauen hätte ich garnicht gedacht. Dachte das funktioniert auch so. Seltsam dass OMSI das prüft;-D

Moin!

Hat schon jemand versucht das Anhalten der KI an Stopp-Schildern hinzukriegen? Klar, wenn Verkehr kommt und die KI keine Vorfahrt hat dann sollte sie anhalten, wird dies allerdings nicht tun wenn nichts kommt. Bei einem Stopp-Schild sollte sie das aber. Ich denke das könnte man mit einer unsichtbaren Anforderungsampel lösen, die relativ kurz getaktet ist. Hat da jemand Erfahrungen mit? Mich würde da konkret der Ampelzyklus interessieren, der diesen Effekt auslöst.

Zitat von Avalarion

Ich hatte früher auch keine Probleme mit denen, erst nach einer Neuinstallation von OMSI mit direktem Download der Masten aus der WebDisk hatte ich Probleme.

Würde mal schätzen, das irgendeine Map vielleicht mal gefixte Versionen der Masten mitgeliefert hatte. Das wäre meine Erklärung, warum manche Probleme haben und manche nicht.

Ich hatte sie nicht installiert gehabt vorher und vor garnicht langer Zeit selber aus der Webdisk runtergeladen und installiert. Sicher nicht vor mehr als 2 Monaten. Und wie gesagt keine Probleme. Es ist auch ausgeschlossen dass eine Map da was überschrieben hat denn ich hatte keine Maps außer Payware seit langem installiert. Das heißt ich beziehe mich definitiv auf die aktuellste hier erhältliche Version.

Welche Masten sind es denn genau die diese Kollisionen verursachen? Ich habe bei mir die grauen verbaut in den 3m / 5m und auch 8m Varianten und es ist mir nichts derartiges aufgefallen.

Ich war mal wieder etwas erstaunt über das Verhalten der Heizung. Bei etwa -2 Grad Außentemperatur heizte sich mein O530G E3 bei ausgeschalteter Heizung im Fahrgastraum und beim Frontheizgerät auf 0 Umdrehungen kontinuierlich auf. Dann fiel mir auf dass der Temperatur-Regler des Frontheizgeräts auf Voll war. Drehte ich ihn runter kühlte sich der Bus ab. Das kann so nicht gewollt sein, denn dieser Regler regelt normal nur die Temperatur des Frontheizgeräts und macht auch nur Sinn in Kombination mit einem sich drehendem Lüfter. Ist dieser aus müsste die Heizwirkung gleich 0 sein. Korrigiere mich jemand wenn dem nicht so ist. Aber dann bitte jemand der so ein Gerät in echt auch schon bedient hat;-)

Und mal unabhängig davon ist das Frontheizgerät laut Const stärker als die eigentlich Heizung. Klar kann man jetzt in OMSI nicht simulieren dass es zum Beispiel in der Fahrerkabine warm ist und im Fahrgastraum kalt, aber zumindest anteilig sollte es umgekehrt sein.

Edit:
Nun muss ich dazu anmerken dass bei einer anderen fahrt mit gleichem Bus dieses Verhalten sich NICHT gezeigt hat, es war eher so wie ich es erwartet hätte. Kann also gut sein dass hier irgendwas beim Zwischenspeichern nicht mitgespeichert wird oder da irgendwo ein Fehler passiert. Denn irgendwann anders kam mir schon mal bei der Heizung was komisch vor nach dem erneutem Laden der Situation, konnte das aber nicht wirklich einordnen.

Gibt es eigentlich Möglichkeiten ohne Tricksereien mit Unterstrichen bei den Zielen in der Hofdatei die Normalschrift oder die Fettschrift in der Matrix zu erzwingen? Sowas wie bei anderen Bussen über *B oder *K. Das R&G Script ist da ziemlich willkürlich bzw nicht ganz sinnvoll in der automatischen Entscheidung ob Fett oder nicht.

Ich hab jetzt auch an einigen Stellen die Masten in verschiedenen Varianten verbaut und konnte bisher keine Probleme mit Kollisionen feststellen. Könnte also tatsächlich was mit den prt-Dateien zu tun haben.

Im Moment besteht der Hubbel optisch aus Splines und war platziert mitten auf einer Spline-Straße. Mittlerweile ist die Straßenspline auch nur rein optisch, die Pfade sind weg und vorübergehend durch Invisible Pfade ersetzt als Vorstufe zum Export auf ein Objekt. Das mache ich aber um den auf dem Hubbel sich befindenden Fußgängerüberweg funktionabel zu machen. Bei der Gelegenheit wollte ich halt die Pfade "schön" über den Hubbel legen wo ich eh schon dran bin. Denn später wird das noch schwieriger;-) Wenn ich mich nicht irre ist die Höhe 15 cm, also zu viel schon um es zu ignorieren. Geschnitten wird der Pfad auch noch genauer um da eine Reduktion der Geschwindigkeit noch einzubauen damit die KI da auch abbremst.

Naja Physik und The Bus sollte man sich nicht zu sehr anschauen oder für OMSI wünschen. Das ganze Gewackel da hat recht wenig mit Physik zu tun, auch wenn ich glaube dass die Funktion in der Engine grob genau so funktioniert. Somit würde da die Hubbel-Situation bei der KI durchaus einfacher umzusetzen sein. Dafür glaub ich dass dann der Bus dabei eventuell umkippt

Ich habs nun mit verschiedenen Gradienten probiert auf dem 0,9 m Steigungsstück: 16,7 + 16,7 und 0 + 33 und 33 + 0 bringen jeweils ein noch seltsameres Gehüpfe als ganz übergangslos das Pfadstück um 0,15 anzuheben. Seltsam;-D

Bus: KJ3D O530Ü E3

Map: Mainz

Moin!

Wie verlegt Ihr sauber KI-Pfade über Hubbel in verkehrsberuhigten Bereichen oder bei Überwindung eines Bordsteins? Einen harten Übergang bei dem die Autos springen würde ich gerne vermeiden, ebenso wie lange Rampen, Die Fahrzeuge sollten da halbwegs sauber den kleinen Höhenunterschied überwinden. Was hat sich da bewährt?

Ich weiss jetzt nicht in wie weit sich die simulierte IVU Box von der realen unterscheidet und was für Unterschiede da nun die Versionen haben. Habe aber in der Realität einen Unterschied gesehen der deutlich war. Mir ist es in OMSI nie möglich gewesen ohne eine hinterlegte Route samt Fahrplan als Liniennummer irgendwas anderes als eine Nummer zu schildern. Suffixe, Prefixe etc gingen nur mit Datenroute, keine Chance auf manuelle Eingabe oder Überschreiben. Am Samstag fuhr ich aber mit einem Bus der offensichtlich nicht mit aktiver Fahrplanroute fuhr, d.h. es gab weder Durchsagen noch wurde irgendwas außer Linie und Ziel auf den FIS-Bildschirmen angezeigt. Es handelte sich um die 68E von Hochheim zur Mainzer Arena. Da es diese Fahrt nur an Spieltagen gibt kann ich mir vorstellen dass die im System gar nicht drin ist. Aber irgendwie muss der Fahrer das System trotzdem dazu gebracht haben das E zu schildern;-)

Dass es so massenhaft auftritt ist ja nicht normal. Ein paar solcher Meldungen untereinander hat man aber gerne mal beim Bus auf die Karte setzen oder Situation laden. Hier ist es zu viel, und spontan würd ich sagen der NLC ist da entweder kaputt, oder die OMSI Physik setzt aus ("Hüpfen"...), aber auch da behebt eine Abschaltung der Kollisionen nicht das Problem.

Zitat von Theproloser

Hast du de n 4GB Patch installiert?

Stell mal in "Einstellungen -> System -> Bildschirm -> Grafik" OMSI 2 (Omsi.exe) auf "Höchstleistung". Sollte es nicht in der Liste erscheinen, unter "App hinzufügen" auf Druchsuchen klicken und die Omsi.exe aus dem Omsi installationspfad hinzufügen.

Ist die RAM-Geschwindigkeit im BIOS richtig eingestellt? Nach BIOS Updates hat sich das bei mir gerne mal zurückgesetzt.

Ist HAG (Hardware beschleunigte GPU Planung) aktiviert? ("Einstellungen -> System -> Bildschirm -> Grafik ->Standardgrafik-Einstellungen"). Wenn nicht, aktivier es mal, wenn ja, schalt es aus (Je nach System kann das zu Problemen führen ODER die Performance ins positive verbessern).

Wie ist deine "Energiestatus" Einstellung unter "System -> Leistung"? Wenns nicht eingestellt ist, stell das mal auf "Beste Leistung".

Ist die Grafikkarte bzw CPU in den AMD Treibern ordentlich eingestellt?

Ist Multithreading in den OMSI Einstellungen aktiviert? Wenn nicht, mach das mal.

Schalte mal ALLE Kollisionen aus! Das hier:

"Information: Crash: Vehicle 4694 (vehicles\MAN_NewLionsCity\MAN_18C_4door_trail_ZF.bus) was crashed and left its path"

hat bei mir auch schon extem häufig bei unterschiedlichsten Karten zu massiven Performanceproblemen geführt, ausschließlich beim NLC allerdings.

Alles anzeigen

Da ist der Wurm etwas tiefer drin. Mit seinen Komponenten müsste OMSI recht gut laufen. All die ganzen Spielereien mit Energiestatus etc hätten nur kleinen EInfluss auf die Performance. 4 GB Patch hat auch nix mit der Performance zu tun und die Kollisionen auch nicht. Gelenkbusse verursachen sehr gerne diese Meldungen.

Wenn andere Spiele flüssig laufen würde ich eher eine OMSI Neuinstallation probieren unter Auslassung aller DLCs und erst recht Freeware, und dann auf Spandau mal testen. Bus hinstellen am Rathaus Spandau und dort etwas hin und her fahren und beobachten. Rein von den fps her müsste das mit einer Nachbarkachel gut und gerne beid er Hardware 40 bis 70 fps ergeben mit moderaten Rucklern.