Beiträge von wurstbrot

Heute war ich bei einer Runde Fahren echt baff. Ich teste mein Rollband für den O405 und merkte das beim Durchlauf an der Endhaltestelle Leute schon vorher in den Bus stiegen noch bevor das eigentliche Ziel erreicht war. Ich habe aber nicht darauf geachtet ab welchem Ziel. Beim nächsten Mal das gleiche. Definiert ist per Trip dass hier "Mainz Hbf" das Ziel ist, aber exakt ab "Hauptbahnhof" fing das Volk an einzusteigen. Gigts doch garnicht, beide Ziele haben andere ID's im ersten String, das dürfte also eben nicht funktionieren wie im Thread ja auch erörtert. Nächste Situation an anderer Endhaltestelle. Ich schilderte absichtlich falsch "Hochheim über Dresdener Ring" obwohl der Bus da nicht lang fährt sondern direkt fährt. Sie steigen wieder ein:

An anderen Haltestellen ebenso:

AUf der Rückfahrt schilderte ich dann zunächst "Hauptbahnhof" (was laut Trip falsch wäre) und hatte Fahrgäste, dann schilderte ich unterwegs kurz auf was völlig falsches um zu schauen ob sie nicht einfach immer einsteigen, aber tun sie nicht:

Dann wieder umgeschildert auf das "falsche" Hauptbahnhof und es wird eingestiegen:

Jetzt beachte man jeweils "Ziel" in der roten Schrift. Ich verwende da ein System mit vielen Leerzeichen dazwischen, eigentlich wegen den DFIs, weil die die ersten Zeichen anzeigen. Alles für die DFIs nicht relevante soll also später sein. Es fällt also auf dass die Namen der Ziele sich bei den ersten Zeichen gleichen und erst nach X Zeichen unterschiedlich sind. Ich habs nicht abgezählt, das ist Pi mal Daumen um sicher zu gehen dass der Rest nicht im DFI erscheint.

Annahme:

OMSI beachtet nur die ersten X Zeichen und der Rest ist egal. "Hauptbahnhof" und "Hauptbahnhof Mainz" sind also für die Fahrgäste das gleiche Ziel, nicht aber für die KI welche aus der Hof-Datei das Richtige Ziel saugt. Müsste jetzt noch auf anderen Karten und anderen Fahrzeugen bestätigt werden ob das allgemeingültig ist. Wenn ja, wäre es super.

Some weeks ago I tried the light mod you mentioned, but it did not do what I was expecting. After a while were the changes worked and I had no errors in the log the cars behaved in Grundorf like always: when I changed the time they all switched the lights on or off in the same moment, and weather changes had no influence. It was just like before, and not liked showed in the example video, so I did not follow this any more because I would never find the error... This would be the luxury solution with the weather and lights not switching in the same second on or off.

Okay, dann wohl doch über das Modell einfacher;-D

Ja, so ginge es. Aber wäre es nicht irgendwie einfacher über die Model Cfg?

Moin!

Ich versuche die KI-Versionen der C2 von MX200 noch weiter zu entschlacken und alles überflüssige zu reduzieren bzw rauszuwerfen. Hintergrund ist der dass ich das Fahrzeug im KI-Einsatz habe, nach einer Weile (zuletzt 2 Stunden) fliegt mir aber mangels Speicher DX3D um die Ohren, da die Texturen offenbar die 32 Bit Grenze dann erreichen. Irgendwann nutzt ja auch der 4GB Patch nix mehr. Das Fahrzeug ist halt sehr Texturlastig. Ich habe schon etliches reduziert, fast alles ins dds Format gebracht, aber einige überflüssige Keulen sind noch da. Beispielsweise der Boden: den will ich hochauflösend in der User-Version haben, nicht aber bei der KI. Reduktion der Textur würde sich auf beides auswirken. Aber um Himmelsweisen soll die KI keinen 2048er Boden haben...

Jetzt seh ich in den Modeldateien dass die Einträge dafür keinen Textur-Eintrag haben. Denn eigentlich würde ich dann auf eine stark reduzierte KI-Version der Textur verweisen. Da steht aber nur:

[mesh]

C2_E6_12m_Gn_main\Boden_EN_BVG_Leasing_1.o3d

[illumination_interior]

0

1

2

3

kein [matl] mit Textur. Füge ich das dann einfach hinzu oder muss ich eine Kopie des Objektes machen und dann dort in Blender auf die KI-Textur verweisen?

Hab mir schon gedacht dass man das für Busse und Autos getrennt machen muss. Allerdings meine ich mich zu erinnern dass eine Änderung irgendwo reichte um das Dauer-Licht des Enviroment-DLC abzustellen, und das betraf dann glaub ich Busse und Autos. Ist ja eine ähnliche Stellschraube gewesen...

Ich hatte in den letzten Wochen zig mal Regen und kein einziges Auto machte das Licht an, außer wenn es eben Abend wurde...

Moin!

Ich würde ja gerne dem AI-Verkehr (egal ob Bus oder Autos) beibringen bei schlechtem Wetter das Licht anzumachen. Es müsste ja gehen, immerhin gibt es ja auch Mods die den AI Verkehr zwingen tagsüber mit Licht zu fahren. Das möchte ich nun nicht, aber bei Regen wäre es schon nicht schlecht.

Bei der Gelegenheit würde ich die AI-Busse gerne etwas in der Beschleunigung drosseln. Ich finde es ultra unrealistisch wie die von einer Haltestelle wie eine Rakete los fahren. Da hier ausnahmslos alle Busse von betroffen sind nehme ich mal an dass es auch über ein globales AI Script läuft, oder von jedem Busersteller blind von M&R kopiert wurde.

Ideen?

Für 1500-2000 kriegst du auf jeden Fall was brauchbares. Schau aber mal wo genau gamig-technisch die Schwerpunkte sind, denn wenn es dann darum geht das Budget einzuhalten muss man sehen ob man eher Richtung CPU investiert oder Richtung GPU. Ist zum Beispiel OMSI sehr wichtig, dann ganz klar Richtung CPU, da wäre es fast egal welche Grafikkarte. Man nimmt dann halt eine die auch sonst brauchbar ist für aktuelle Spiele aber eben kein Top-Modell und steckt das gesparte in die CPU. Hier halte ich grundsätzlich die Ryzens X3D CPUs für optimal beim Schwerpunkt OMSI, würde aber die non-3D Chips bevorzugen wenn man auch von mehr Kernen profitieren möchte. Ich zum Beispiel hab lange überlegt ob ein 8-Kerner mit 3D Cache oder 12-Kerner ohne, etwa gleiche Preislage und hab mich für letzteres entschieden. Kostet mich in OMSI sicher ein paar wenige fps, aber sei es drum, hab eh in OMSI nun mehr als doppelt so viele fps wie früher, wenn nicht gar das dreifache (früher Rathaus Spandau mit Mühe und Not 25 fps, heute locker 70 bei gleichen Einstellungen).

Bei der Wahl der Grafikkarte würde ich aber auf jeden Fall auf die 4000er Reihe von NVidia setzen oder eben die aktuelle AMD Generation. Vor allem wegen DLSS 3 bzw. dem AMD Pendant. ob dann 4060, 4070, 4080 etc hängt dann eher von dem vorhin erwähnten Schwerpunkt ab in Abwägung mit der CPU.

Hauptspeicher ganz klar heutzutage 32 GB, SSD nach Bedarf aber unbedingt M.2 (außer für Daten, da kann man durchaus eine SATA nehmen). Netzteil hängt dann vor allem von der Kombination aus CPU+GPU ab, aber hier unbedingt auf ein qualitativ hochwertiges setzen, welches ausreichend dimensioniert ist. Spart jede Menge Ärger und vermeidet unerklärliche Abstürze etc.

An die Getriebeexperten: ich bin jetzt den E5 Gelenkbus öfter gefahren mit ZF-Getriebe aufgrund eines Soundmods (der aber am Getriebe selbst nix macht). Mir fiel auf dass das Getriebe beim Beschleunigen manchmal ziemlich wild schaltet, anstatt gleichmässig. Es fühlt sich so an dass manchmal beim Gas geben der Bus kaum beschleunigt, auch der Drehzahlmesser zeigt kaum Veränderung an, und plötzlich dann geht der ab. Das ist doch kein normales Verhalten bei ZF? Ich fahre eigentlich eher Voith, hab also wenig Ahnung von ZF, aber stimmt hier vielleicht irgendwas nicht?

Dir fehlt einiges. Spline-Texturen und auch beim Bus. Letzteres sehr verwunderlich, da die Busse alle in einem Pack sind. Was sagt die Log?

Das mit den Pfaden hab ich nun wie es aussieht gefixt. Statt Pfadpunkt 25 hab ich Pfadpunkt 5 im E5 Solo und G für den Entwerter eingetragen, also selben Punkt wie das kassieren. Wird für die anderen Modelle wohl ähnlich sein und kein Hexenwerk.

Die festgesetzte Bremse nervt noch tierisch nach dem Neuladen. Ich blicke da noch nicht ganz welches Türskript da was macht und welche denn davon überhaupt betroffen wären. Muss da aber eh mal ran, denn der E5 Solo hat seltsamerweise die zweite Tür als Automatik UND Manuellsteuerung, und die Automatik würde ich da gerne abschalten, und bei den G's ein Piepen bei den hinteren Türen aktivieren.

Was mich noch nervt sind die Spiegel. Ich nutze ja Auxi's Funktion dass die Sicht beim Lenken etwas mitgeht, und beim Steuern nach rechts gibt es einen Bereich wo der linke Spiegel kurz in den Öko-Modus geht und nicht mehr 1:1 refresht. Ich habe alle Spiegel auf Typ 2 mit minimalen Werten in den letzten Zeilen (0.01-0.1...) und trotzdem bin ich dabei zu früh im Sichtbereich von irgendeinem Spiegel. Da ich bei den geringen Werten zum Teil sehe wie sich der rechte Spiegel einschaltet und ich vorher schon im linken den Öko-Modus sehe vermute ich mal dass da auch die Spiegel die man nicht sieht mit reinpfuschen. Der Bus hat ja für den rechten Spiegel 2 Typen die per Repaint gesteuert werden, und ich glaube selbst wenn man sie nicht sieht rendern sie. Das erklärt auch warum ich beim Blick nach rechts von 60 auf 20 fps falle wenn ich in den Optionen alle Spiegel voll rendern lasse, denn der Leistunsgverlust wäre geringer wenn nur das sichtbare rendern würde.

Ich hatte kurz das "LS"-Lenkrad im Set samt Pedalen und Seitenkonsole, weiss nicht mehr wie es genau hieß. Lenkrad und Pedale waren absolut nicht zu gebrauchen, haben sich total nach billigem Plastik-Spielzeug angefühlt. Und beim Lenken war das Ding ungenau wie sonst was, da es irgendwie digital stufenweise die SIgnale übertragen hat. Das Seit ging dann schneller zurück als es gekommen ist, und hab dann die Seitenkonsole einteln bestellt und ein G29 samt Pedalen. Überhaupt kein Vergleich... Und ich denke von den Videos her was ich von dem hier gesehen habe geht es genau in diese Richtung... Solange das solches Plastikzeug ist wird es definitiv nicht gekauft. Für ein gutes wäre ich bereit was auszugeben, aber nicht sowas.

1. Ja, Gelenkbus. Vermute auch dass das mit der Hst-Bremse zusammenhängt. Jetzt hatte ich aber einige Male wo es in Ordnung war...

2. Genau, nur wird sie von den meisten Bussen ignoriert;-D Ich glaube sogar bei M&R funktioniert das nicht hundertprozentig.

Zur Zeit teste ich den MX 200 C2, um später zu entscheiden ob ich diesen als C2 oder den kommerziellen verwende. Zwei Probleme haben sich dabei herausgestellt:

1. Gas nach Neuladen der Situation

Wenn ich eine gespeicherte Situation neu lade ist das Gaspedal blockiert. Weder das Pedal reagiert beim drücken, noch Gas geben per Maussteuerung. Das ganze im Leerlauf, bei eingelegtem Gang und natürlich bei erneutem betätigen von Haltestellenbremsen, Türfreigaben oder Feststellbremsen. Geht einfach nix, ist blockiert... Was ist da das Problem? Wobei ich bei erneutem Laden mal wie aus dem nichts das Pedal wieder betätigen konnte, aber sagen wir mal zu 90% kriegt man die Karre nicht vom Fleck. Da es aber auch kurz mal ging glaube ich dass es vielleicht eine Lösung dafür gibt. Hatte ich auch schon mal in irgendeinem anderen Bus, weiss leider nicht mehr wo...

2. Kollisionen

Es ist ganz nett dass es der erste Bus gefühlt seit 10 Jahren ist der die Reparaturfunktion von OMSI irgendwie nutzt, im Sinne von "warten Sie 10 Minuten weil nicht im Depot, und dann noch mal 15 Minuten fürs reparieren".... Normallerweise beim Klick auf dem Reparatur-Button fand in anderen Bussen eine Instant-Reparatur statt;-D Naja, aber weil OMSI eben OMSI ist und einem auf eigentlich immer mal wer irgendwo in den Bus reinfährt nervt das gewaltig wenn man bei jeder Tour dann wegen sowas +45 min hat. Daher würde ich das ganze gerne abstellen und hätte gerne meine Instant-Reparatur da wieder. Erstmal habe ich das collision-Script samt Var und Const entfernt, aber irgendwas davon wird wohl in anderen Scripts gebraucht, es gab zumindest eine Fehlermeldung. Muss ich also anders ran. Jemand ne Idee? Gerne auch mit einer Karten-Blacklist, denn es gibt durchaus Karten auf den man damit spielen könnte.

3. Pfade:

Der Entwerter ist irgendwie an den falschen Pfadpunkt gehängt oder der Pfad selbst ist blöde. Zumindest scheint es so dass die Leute aus etwas Entfernung stempeln, danach aber zum Entwerter laufen und umkehren. Hab aber keinen Mod diesbezüglich gesehen. Hat da einer vielleicht schon Hand angelegt?

Das ist wohl bei allen Spielen so und nicht OMSI-spezifisch. Da fällt es nur auf weil massenhaft gemoddet wird. Wer sein OMSI so spielt wie ausgeliefert, dem dürfte das auch kaum auffallen. Über die Zeit ändern sich aber die Algorithmen bei Steam auch mal, sodass die Problematik durchaus mal mehr mal weniger eine Rolle spielt.

Zitat von Perotinus

Zu den zerschossenen Mods kommen aber nach einer Überprüfung noch andere Unnanehmlichkeiten: Die gespeicherten Situationen auf Addonkarten sind wieder auf "Werkszustand", also Uhrzeit und aktives Fahrzeug, der 4GB-Patch muss neu angewandt werden, bei mir sind auch immer irgendwelche Einstellungen verschoben. Und nicht zuletzt braucht es Zeit, die Überprüfung durchzuführen. Gestern kam mir das zwischen meine Soundabstimmungen, als ich mal eben schnell den neuen Halycon-Bus installieren wollte und dann für ne ganze Zeit OMSI nicht starten konnte.

Ich habe OMSI übrigens auf einer SSD laufen, um die Statistik auch noch zu füttern.

Mitten in der Arbeit ist das natürlich total blöde, kein Mensch macht ja jede Stunde ein Backup.

Das ist halt eben die Krux, entweder verschiedene Ziele (intern und verschiedene Codes) oder überall das gleiche. Ich hätte das gerne deshalb, weil ich auf der Mainz-Map nicht in den Gemeinden außerhalb der Stadt "Hauptbahnhof" schildern will. In Hochheim dürfte das verwirrend sein denn in der Realität kämen gleich zwei Hauptbahnhöfe in Frage die es sein könnten... Bei einem Kurzläufer aber durchaus schon. Und dann gibt es ja noch die "Campuslinie", die zum Hauptbahnhof führt, und da nervt es mich auch dass ich mich festlegen muss.

Ich dachte halt es gäbe dann den Trick mit dem #-Zeichen, der die Ziele unterscheidet aber anderseits halt gleich behandelt.

Klar, man kann das bestimmt fest reinscripten vor allem unter Nutzung der Liniennummer. Wüsste selber jetzt nicht wie, aber an sich dachte ich das vielleicht auf normaler Ebene lösen zu können. Da ich gerade die Hofdatei überarbeite um sie flexibel auch für Rollbänder und Krüger++ zu machen und eh auch noch die KI-Fahrpläne überarbeite hätte ich das eben gerne im Hinblick auf die Ziele gleich mit erledigt.

Ich glaube mit SSDs oder HDDs hat das nichts zu tun, da Steam ganz normal auf der Dateisystem Ebene da zugreift, nicht aber tiefer. Da kümmert sich das Bertriebssystem drum ob da nun Blöcke fehlerhaft sind oder verlegt werden müssen. Was Steam macht ist sicher die Dateien untersuchen und abgleichen mit Prüfsummen, sodass es nicht nur fehlende sondern auch veränderte Dateien erkennt. Und diese ersetzt es bei der Prüfung dann. So kann es passieren dass zum Beispiel ein Script ersetzt wird, weil es als als verändert erkannt wurde, eine Kopie des Scripts aber bleibt.

Am wenigsten Arbeit hätte man wenn man jegliche Modifikationen als neue Dateien anlegt und diese dann zum Beispiel in der .bus Datei verlinkt. Das ist aber sehr mühselig und zum Teil unpraktisch, daher hilft nichts besser als wirklich regelmäßige Backups zu machen. Kann man automatisiert machen lassen oder halt per Hand.

So wars eigentlich gedacht, icons_2007, icons_2010 usw da rein. Klappt beim anderen Bus auch. Ich werde aber mal mit einem Ordner das ausprobieren.