Beiträge von wurstbrot

Zitat von fLoMsi

Also von der Performance her ist die Karte ja die reinste Katastrophe!! Da können meine Einstellungen noch so sinnvoll und meine neue Festplatte noch so schnell sein. Außerhalb vom Zentrum gehts ja noch aber innerhalb und vor allem Nachts (Beleuchtungen ziehen ja auch nochmal Performance) tun einem schon echt die Augen weh.

Ich glaube die Night-Texturen sind nicht optimal. Ich hab da vor langer Zeit mal Hand angelegt und es hat einiges gebracht. Wenn ich mich recht entsinne habe ich die Auflösung der Night-Texturen auf die Hälfte reduziert, außer da wo Schaufenster sind. Es gab aber auch einige sehr unoptimale. Ich weiss abe rheute nicht mehr ob die auf meiner Platte aus einem Update stammen oder meine Varianten sind.

Und ich nehme mal an Du meinst nicht Festplatte sondern SSD. Allerdings braucht man sich keine Illusionen zu machen, fast jede heutige SATA-SSD ist für OMSI ausreichend. Der Flaschenhals ist mittlerweile OMSI selbst. Daher verbessert sich das Nachladen nur noch mit schnelleren Prozessoren. Dass die SSD ins Schwitzen käme dazu müsste man erstmal eine so schnelle CPU finden oder OMSI umprogrammieren;-D

Moin!

Da ich mein System neu installieren musste hatte ich das zweifelhafte Vergnügen mich mit der GHUB-Software wieder rumzuschlagen. Der erste Versuch brachte das Ergebnis dass mein G29 in OMSI die Zentrierfeder nicht angesprochen hat und nur ein Mini-Force Feedback geliefert hatte, und das egal bei welcher Einstellung sowohl in OMSO als auch im GHUB. Es war immer das gleiche: im GHUB war das Lenkrad manchmal so fest wie ein Stein, im OMSI dann total ohne irgendwelche Kräfte. Unspielbar.

Hab dann auf eine ältere Version des GHUB gewechselt, hier ging es dann. Hab ein gutes Force Feedback und die Zurückstellung des Lenkrads klappt auch. Das Lenken ist mir aber hier noch etwas zu hart. Dummerweise ist es auch hier so dass jegliche Einstellungen in OMSI dazu nichts verändern, ebenso nicht die Eistellungen der GHUB Software. Ob 10 oder 100%, ob Häkchen gesetzt oder nicht, nichts verändert sich. Somit funktioniert auch diese Version des GHUB nicht korrekt, wenn auch besser als die neuste. Einfach für die Tonne diese Software.

Die Idee wäre nun die alte "Logitech Gaming Software" zu installieren und den GHUB rauszuschmeißen. Aus Erinnerung habe ich aber im Kopf dass diese Software das Steuerkreuz des Lenkrads nicht erkannt hat Vielleicht kann ich das aber mit JouToKey ansteuern. Ich meine mich aber zu erinnern dass auf meinem vorherigen Rechner die OMSI-Einstellungen sehr wohl Auswirkung hatten auf die Kräfte.

Daher würde mich mal interessieren ob jemand mit dem G29 in OMSI mit der alten Logitech Gaming Software unter Windows 11 fährt und wie es sich da so verhält. Funktioniert da auch das Steuerkreuz?

Zitat von ma7t3

Ein Ähnliches Problem sehe ich auch noch bei den Linienwegangaben ("via xy").

Grundsätzlich versuche ich eben immer, dass die meist vorkommende "Standardroute" einen möglichst kurzen Namen hat. Wenn beispielsweise im Normalfall ein direkter Linienweg gefahren wird und nur zeitweilig noch ein Schlenker mitgenommen wird, ist es recht klar. Da heißt die Hauptfahrt dann einfach 001_AAA-BBB und die mit Schlenker 001_AAA-BBB_vCCC.

Ein Problem hat man dann allerdings, wenn die Schlenkervariante die Standardfahrt ist.

Ich erinnere mich, mal einen Trip 21_NSW-KSM_oHTS genannt zu haben, für "von Nordspitze, Warthersee nach Kaisersee, Markt aber ohne (bzw. "nicht über" Herzt, Schule), da die Fahrt über die Schule eigentlich der Standardfall war und diese kleine Stichfahrt nur spätabends weggelassen wurde. Ich halte es rückblickend aber auch eher für verwirrend und würde es jetzt so nicht mehr machen.

Da hast Du recht. Auch hier muss man je nach Karte entscheiden was mehr Sinn ergibt. Ich tendiere es bei Abweichungen vom Standard anzugeben, würde aber bei fest eingetakteten Varianten tagsüber das vielleicht grundsätzlich dann angeben. Da hatte ich übrigens gelernt Umlaute zu meiden. Hatte mal ein "_ü" drin für "über" und es gab Probleme. Heute vermute ich aber dass sich da die .ttl Datei einfach von ANSI auf UTF8 umgestellt hat und da kriegt OMSI Schluckauf.

Zitat von ma7t3

Für Außenstehende mag diese ganze Diskussion und diese Überlegungen eh etwas absurd klingen, da kann ich mich aber wirklich extrem hieinsteigern, wenn ich will.

Ja. Wer aber jemals was umfangreicheres an Fahrplänen gebaut hat oder gar Trips und Tracks erstellt hat der wird Dir bei fast jedem Punkt zustimmen. Ebenso wenn man als Team mal an etwas gemeinsam geschafft hat. Wenn man alleine für sich nur eine Linie bei einer Karte wie Grundorf einrichtet dann ist das alles tatsächlich irrelevant.

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?