Beiträge von ma7t3

Nein, richtig.

Ich habe jetzt nicht so viel Erfahrung mit dem Iveco Crossway LE als KI-Fahrzeug, aber es kann gut sein, dass der einfach nicht 100% optimal KI-fähig ist.

Also sogesehen am ehesten die "Schuld" des Erstellers des Fahrzeug.

Zitat von Flo_Gaming

Manchmal "schleichen" KI Busse um einen herum anstatt normal zu fahren. Ist das ein Fehler oder einfach nur, wenn die Busse im Fahrplan zu viel Verfrühung haben, dass sie die auf der Strecke "verlieren" können?

normalerweise nicht.

Der KI-Verkehr fährt immer "normal" unabhängig von der Verfrühung/Verspätung.

Sollten die zu früh sein, wird das normalerweise dadurch kompensiert, dass die halt an der nächsten Haltestelle länger stehen bleiben und warten - das hängt ein wenig davon ab, wie es im Fahrplan eingestellt wurde.

Wenn die sehr langsam fahren, deutet das böse gesagt normalerweise auf Pfusch bei den KI-Scripten hin. - Dass die entweder z.B. die Parkbremse nicht richtig gelöst kriegen, keinen Gang hochschalten oder ähnliches. - Das kann tausend Gründe haben.

Bezüglich der Pausensituation:

Ja, das System mit den "Pausenvertetern" oder Springern, wie du es genannt hast, kenne ich auch, allerdings vor allem aus dem Regionalverkehr.

Im Stadtverkehr sind normalerweise eher Fahrerwechsel geläufig - so meine Erfahrung.

Ich muss zugeben, ich kenne Ebstein garnicht und weiß daher grade garnicht, ob das eher eine Stadt- oder Regionalmap ist.

Außerdem gibt es noch die 1/6-Regelung, die besagt im Prinzip, dass normale Standzeiten an Endhaltestellen ab 10 Minuten (was ja durchaus recht häufig vorkommen kann), als normale, vollwertige Pause zählen kann - vorrausgesetzt, alle dieser Pausen zusammen entsprechen über den ganzen Tag verteilt mindestens 1/6 der Lenkzeit.

Damit kannst du quasi normale Linien den ganzen Tag durchtakten, wenn die konkret z.B. an Endhaltestellen 10 Minuten Pause haben und die Fahrtzeit nicht länger als eine Stunde ist - sollte man natürlich gucken, dass man genug Puffer einplant für Verspätugnen usw. und ob das besonders Fahrerfreundlich ist, solche Dienste zu machen, ist eine andere Frage, aber rein rechtlich wäre das vollkommen okay.

Zitat von Bussgeldkatalog.net

Was ist die 1/6-Regelung?

Bei der 1/6-Regelung handelt es sich um eine weitere Ausnahme bei den Lenk- und Ruhezeiten, die beim Bus im Linienverkehr Anwendung finden kann. Dafür muss der durchschnittliche Abstand zwischen den Haltestellen allerdings weniger als 3 Kilometer betragen. Ist dies der Fall, können planmäßige Standzeiten – etwa Wendezeiten an Endstationen – die mindestens 10 Minuten dauern, als Pausen gelten. Damit dies zulässig ist, muss die Gesamtdauer dieser Pausen allerdings mindestens ein Sechstel der vorgesehenen Lenkzeit entsprechen.

Hallöchen,

Kurz direkt vorweg: Ich habe selbst noch nie versucht, OMSI unter Linux zu installieren, geschweige denn zum Laufen zu bringen, habe mich da aber durchaus auch schon mit auseinander gesetzt, da ich auch teilweise Linux nutze. Zwar Mint, aber das basiert ja auf Debian.

Da ich mir nicht sicher bin, ob ich dein "Problem" jetzt 100% richtig verstanden habe:

Zitat von xTrainSpot_Rx

Per Steam funktioniert dies wunderbar, er hat einmal den Shader-Cache in Vulkan gesetzt und dann startete es.

[...]
Nun bekomme ich die .exe aber weder so gestartet, noch mittels einbinden in Steam.

Er lädt kurz und schließt die Datei direkt wieder.

Also du hast OMSI-Vanilla installiert und es läuft, und nach der Installation von verschiedenen Addons ist das nicht mehr der Fall?

Könnte mir so eigentlich nur vorstellen, dass das an irgendwelchen Plugins ehrlichgesagt liegt, da normalerweilse jegliche Payware- und Freeware-Addons bei OMSI ja normalerweise keine Dateien bereitstellen, die irgendwie direkt vom Betriebssystem ausgeführt werden sollen, sondern alle von OMSI eingelesen werden..

Womit führst du denn OMSI überhaupt aus? Verwendest du Proton?

Ich meine, das müsste man unter Linux in Steam direkt einfach in den Einstellungen irgendwo aktivieren können und dann jedes Windows-Spiel installieren und starten können. Proton bindet dann auch automatisch die DXVK-Libary mit ein usw.

OMSI wird offiziell nicht unterstützt, habe aber immer wieder gelesen, dass es scheinbar trotzdem vom Prinzip her funktioniert.

https://github.com/ValveSoftware/Proton/issues/1440

https://www.protondb.com/app/252530?device=pc

Ansonsten habe ich bei einer kleinen Recherche noch folgendes gefunden:

Zitat von ProtonDB

Das Spiel muss im Moment mit Proton Experimental gestartet werden. In den Startoptionen habe ich "PROTON_FORCE_LARGE_ADDRESS_AWARE=1 %command%" eingefügt.

Außerdem habe ich den 4GB-Patch angewandt, um volle 4 GB RAM zur Verfügung zu haben. Die .exe ist leider unter Linux nicht per GUI bedienbar, Abhilfe schafft das Terminal mit dem Befehl "wine 4gb_patch.exe omsi.exe". Der Patch muss sich dazu im Hauptordner befinden.

Das Spiel läuft sehr flüssig, sogar flüssiger als unter Windows. Hin und wieder gibt es Probleme mit dem 2D-Overlay, die ALT-Taste muss ggf. mehrmals betätigt werden. Aber an sich läuft alles stabil.

Wie gesagt, ich habe es selber nie getestet, mich nur theoretisch auch damit etwas befasst und es scheint vom Prinzip her auf jeden Fall möglich zu sein, OMSI auch unter Linux zum Laufen zu bringen.

Edit: Vielleicht hilft dieses Video auch noch etwas weiter:

Ich kenne es jetzt konkret noch nicht, habe aber mit Linxu Guides DE so recht gute Erfahrungen.

Um welche Karte geht es denn konkret?

Vielleicht fährst du auch mit sehr wenig KI-Verkehr oder hast einfach eine sehr konsistente Fahrweise?

Wie bereits gesagt: Es ist ja durchaus nicht random, wie die Ampeln schalten, sondern immer gleich, von daher ergibt es durchaus Sinn, dass du immer die gleichen Phasen hast.

Aber zumindest ich habe idR. eine so "ungleichmäßige" Fahrweise (und/oder so viel KI-Verkehr) dass ich es kaum wiederholt so genau gleich schaffe, dass sich ein so exaktes Gefühl dafür einschleift, wie du es beschreibst.

Ja, so ist es auch.

Sobald das Objekt geladen wird (und das passiert normalerweise mit dem Laden der Kachel, auf dem es sich befindet), startet die Ampelphase beim Zeitpunkt 0.

wurstbrot ja, theoretisch ist eine Umsetzung einer grünen Welle möglich, klappt in der Praxis meist aber eher doch schlecht, bzw. ist sehr schwierig, da es eben doch auch sehr vom Fahrstil und Verkehrsaufkommen abhängt, wie schnell mal quasi durchkommt. Und insbesondere, wenn sich mein Kreuzungsobjekt aus der Richtung gesehen, aus der ich als User komme, quasi ganz am Ende der Kachel befindet, ist die Distanz natürlich um so größer, da die Phase eben immer mit dem Laden der Kachel startet und sich Objekte Kachelübergreifend eben nicht synchronisieren lassen.

Nur Objekte auf der gleichen Kachel laufen grundsätzlich immer parallel. Aber auch das funktioniert nur solange, wie die gesamte Phasendauer identisch oder zumindest ein vielfaches voneinander ist.

Dazu kommen noch weiter Unbekannte beim Mapbau, wie z.B. die Anzahl der eingestellten Nachbarkacheln, welche somit auch maßgeblich für das Timing der Ampeln entscheidend ist.

Das sind einfach so viele Faktoren, dass es in der Praxis einfach oft enorm schwierig bis unmöglich ist, eine grüne Welle so zu bauen und zu konfigurieren, dass sie über mehrere Kacheln hinweg tatsächlich gut läuft.

Zitat von NickNick

Ich hoffe, das war einigermaßen verständlich und nicht zu fachlich ausgedrückt

Geht so. Ich bin auf dem Gebiet leider absolut kein Experte, aber dann werde ich mal gucken, ob ich mich da bisschen reinfuchsen kann.

Wäre ja vertretbar, ich behaupte mal, 90% aller OMSI-Maps spielen ja in Europa, die meisten davon sogar in Deutschland.

Dass ich auch Werte am Äquator und überall auf der Welt genommen habe, war natürlich zum "Grenzen austesten". In der Praxis kommt das warscheinlich kaum vor, daher kann man das - würde ich behaupten - unter'n Tisch fallen lassen, wenn man eine Methode gibt, die zumindest innerhalb von Europa halwegs zuverlässig funktioniert.

Ich frage mich derzeit, was die Kachelkoordinaten bei realen Karten genau bedeuten.

Wenn man eine neue, "normale" Karte anlegt, ist die Startkachel ja normalerweise 0/0, nutzt man jedoch die World Coordniates tauchen dort teilweise sehr hohe Zahlen auf, diese scheinen die Längen- und Breitengrade wiederzuspiegeln.

Die Frage ist nur, wie man konkret umrechnen könnte von Kachelkoordinate in Breitengrad usw. Einen einfachen Faktor scheint es nicht zu geben, ich habe dazu mal einige Regionen auf der Welt getestet und bin zu folgendem Ergebnis gekommen:

Wie man hier sieht ist erkennbar, dass X-Kachel-Koordinate den Breitengrad und Y den Längengrad widerspiegelt, da beides jeweils gemeinsam 0 wird.

Allerdings tritt eben beim Teilen der Werte durcheinander kein konstanter Wert auf (wobei es bei Kenia und Spitzbergen überraschenderweise annährend hinkommt).

Weiß da jemand vielleicht mehr und kann mir ganz konkret sagen, wie ich aus den Kachelkoordinaten die Längen- und Breitengrade bestimmen könnte?

Ich hatte kürzlich ähnliche Probleme.

Zusätzlich von der bereits genannten 24er-Bittiefe, kann es - so zumindest meine Erfahrungen - auch hilfreich sein, beim Export keine Farbraum-Informationen zu speichern.

Hier meine Einstellungen, wie ich in GIMP immer meine BMPs exportiere.

Ob es diese Option auch in Paint.net gibt, weiß ich leider grade nicht.

Aber wie bereits gesagt wurde, 24 Bit ist erstmal wichtig.

Zitat von TobiB

V.a. bei der Linie 854 wurde fahrplantechnisch nie angesprochen, dass die Fahrzeiten da zu eng seien.

Echt? Ich erinnere mich eigentlich recht gut, das die Fahrtzeiten auch in der Beta-Phase schon ein großes Problem waren. Ich war gegen ende ja nicht mehr so aktiv selbst dabei, weil ich grade einen neuen Pc hatte, der noch kein OMSI installiert hatte, ich habe daher jetzt ehrlichgesagt nicht so im Blick, ob und was da angepasst wurde, aber, dass nie angespruchen wurde, dass die Fahrtzeiten zu eng sein, wage ich zu bezweifeln...

Ja, das ist mir auch aufgefallen.

Zufällig habe ich grade gestern Abend/Nacht (?!) mit Bamp genau darüber gesprochen. Das "Problem" ist hier eigentlich nur, dass das verwendete Framework "Qt" plattformübergreifend arbeitet (theoretisch könnte man OMSI-Tools auch recht unkompliziert für macOS oder Linux kompilizeren).

Jedes andere Betriebssystem außer Windows arbeitet ja mit "normalen" Slashes und nicht mit Backslashes. Daher arbeitet Qt dort auch standardmäßig immer mit /. Technisch sollte es ja aber auch kein Problem sein, das bei der Anzeige im UI zu ersetzen. Aber das muss ja logischerweise Bamp sagen. Ich entwickle ja nicht am Tool mit. Aber dieser "Hintergrund" erklärt vielleicht, warum OMSI-Tools überhaupt mit normalen Slashes arbeitet.

Edit: grade durch Zufall bemerkt: in früheren Versionen wurden scheinbar tatsächlich Backslashes angezeigt. Dann hat das vielleicht doch einen tieferen Sinn.

Lass mich verstehen, warum du verschiedene Ziele hast. Sind diese jeweils für verschiedene Linien?

Wie DerErzbusfahrer schon richtig erklärte: Die Fahrgäste steigen nur ein, wenn der Name des geschilderten Ziels exakt mit dem Übereinstimmt, was im Trip im Editor hinterlegt ist. Das gilt erstmal so für KI-Busse, wie auch für den Spieler.

Zusätzlich nutzen die KI-Busse das Feld aus dem Editor natürlich auch, um überhaupt das richtige Ziel zu finden. Wenn sie das aber nicht finden, weil es falsch geschrieben ist oder nicht existiert, steigen auch in KI-Bussen keine Fahrgäste ein.

Wenn es tatsächlich so ist, dass eben für verschiedene Linien/Routen die verschiedenen Ziele zum Einsatz kommen, dann weise das doch auch einfach so im Editor entsprechend zu. Dann schildern die KI-Busse richtig und die Fahrgäste steigen ein.

"Nachteil" ist natürlich, dass du als Spieler immer genau das jeweilige Ziel benutzen musst und die anderen nicht akzeptiert werden. Mehrere verschiedene Ziele, die alle gleichberechtigt funktionieren, sind tatsächlich recht schwierig, weil OMSI so eben einfach nicht "denkt". Insbesondere, wenn die KI-Busse eben dennoch dazwischen unterscheiden sollen.

Deshalb mein Vorschlag, wo das dann ja technisch alles seperate Ziele wären, die erstmal so nix miteinander zu tun haben. Ob das was für dich ist, kommt eben drauf an, wozu du überhaupt verschiedene Ziele benötigst.

Um nochmal etwas abszuschweifen: Nichts ist unmöglich. Man könnte z.B. über ein eigenes Matrix-Script die vom KI-Bus geschilderte Liniennummer (wird ja ebenso im Editor einfach eingetragen) auslesen, und anhand dieser dann ein bestimmtes Ziel aus der Hofdatei per Index aufrufen. Das sollte trotz gleicher Bezeichnungen funktionieren.

Die Lösung erfordet natürlich Kenntnisse im OMSI-Scriptsystem und wäre dann eben sehr eng auf genau die Map (bzw. Hofdatei) abgestimmt und nicht wirklich "allgemein Funktionsfähig"

Aber Projekte wie die Hamburger Payware-Busse oder die IVU zeigen, was in OMSI scripttechnisch alles möglich ist. Ist halt nur sehr viel Aufwand und erfordert je nach Vorkenntnissen viel Einarbeitungszeit, Frust und Nerven.

Edit: Ich hätte mir vorher mal bisschen genau den Thread hier durchlesen sollen, mein zweiten Vorschlag hat DerErzbusfahrer ja auch schon erleutert, sorry.

Zitat von Belad

Statt einem Hotel-Shuttle könnte es ja auch einzelne Stichfahrten einer regulären Linie geben, die während der Sommerferien einen Umweg über ein Hotel machen. Es könnte eine Art Wanderbuslinie geben, die nur saisonal fährt. Auf den Verstärkerfahrten zum Meer könnten vielleicht auch Museumsbusse eingesetzt werden.

Joa, das kann man mal schauen. Behalte ich auf jeden Fall im Hinterkopf.

Zitat von Belad

Und nochmal ein anderes Thema: Sind Schulbusse, Schwimmfahrten oder dergleichen auch geplant?

Ja.

Hallo,

wie schon gesagt, spielt die Karte in Schleswig-Holstein. Vorbild ist der Kreis Plön, welcher östlich der Landeshauptstadt Kiel liegt. Die Map hat konkrete Vorbilder aus Lütjenburg, Schönberg oder Hohwacht.

Tatsächlich ist mir in der Region in der Realität soweit kein so großes Hotel bekannt, dass sich ein Hotel-Shuttle oder dergl. lohnen würde.

Geplant ist allerdings ein Strand der Ostseeküste, wo es dann auch eine Linie geben wird, die von Stein direkt bis an den Strand fährt.

Dort denke ich auch an beispielsweise Verstärkerfahrten zur Saision.

"die Fenster gelöscht" heißt, sie sind dann komplett transparent?

Mit welcher DDS-Einstellung speicherst du? Wenn deine Grafik Teiltransparenzen enthält, was bei Busscheiben ja normalerweise der Fall ist, solltest du BC3-DXT5 verwenden.

Zitat von Bamp

... weiß ja nicht, was ma7t3 da für Ultra-4K Texturen verbaut hat, aber eventuell kann es dort ja auch performancestarke Bereiche geben, dass der Arbeitsspeicher da dann noch ausgelastet ist. Aber ich kenne die Karte nicht (so gut)...

Ich habe da wenig selbst verbaut.

Lenn hast du mal ne sehr sparsame AI-List mit nur Spandauer MAN als KI verwendet? Tritt das Problem dann immernoch auf?

Welche Fehlermeldung bekommst du denn genau?

Hi zusammen,

in letzter Zeit habe ich immer wieder das Problem, dass Blender bei meinen Objekten das Mapping "zerstört" und ich alles neu Mappen muss.

Hier mal ein Beispiel (ich denke, dass klar ist, dass es so nicht aussehen sollte):

Hierbei handelt es sich nun um ein importieres Objekt, welches frei im Internet zu Verfügung steht, das gleiche Problem tritt aber auch immer bei von mir komplett selbst erstellten Meshs auf.

Eigentlich immer, wenn ich das ganze regulär als blend-Datei speichere und später wieder öffne, ist danach das Mapping kaputt.

Manchmal passiert das auch (aus meiner Sicht ohne erkennbares Muster) manchmal beim wechsel vom Objekt in den Edit Mode, dass er plötzlich umspringt und alle Texturen verzerrt sind.

Das lässt sich übrigens über "STRG + Z" nicht rückgängig machen. Alle anderen Änderungen, die ich vorgenommen habe, werden ordnungsgemäß rückgängig gemacht, aber das Mapping bleibt so.

Hier nochmal zwei weitere Bilder von einem selbst erstellten Kreuzungsobjekt.

Dort sieht man ganz gut, dass Blender scheinbar grundlos alle Flächen auf dem Mapping jeweils um 90° gedreht hat. Aber halt nicht das ganze Mapping, sondern jede Fläche für sich unter Beibehaltung des relativen Seitenverhältnises.

Das war, als das das erste mal aufgetreten ist. Da dachte ich noch, ich hätte versehentlich eine falsche Taste gedrückt, aber in letzter Zeit tritt das immer wieder (und eben besonders oft direkt beim Öffnen einer blend-Datei) auf, defintiv, ohne, dass ich irgendwas gedrückt habe.

Hat jemand eine Idee, was da los ist, bzw. ein ähnliches Problem schonmal gehabt? Ich bin da grade sehr aufgeschmissen.

Übrigens: Ich nutze Blender 3.6 und habe es bereits komplett neu installiert. Als ich das das erste mal hatte, war das sogar noch auf nem ganz anderen Pc und dementsprechende auch ne völlig seperate Installation.

Es handelt sich also - behaupte ich mal - entweder um einen Bedienerfehler meinerseits (da würde mich mal interessieren, was ich plötzlich immer falsch mache) oder um einen sehr ungünstigen Blender-Bug...

Edit: Hier nochmal ein anderes Beispiel (auch grade direkt nach dem Öffnen der Datei), da sieht man eigentlich auch recht offentsichtlich, dass jedes einzelne Face auf dem Mapping um 90° verdreht ist:

(Lasst euch nicht von der dunklen Textur verwirren, dass "soll in diesem Fall tatsächlich so").

Das sollte nicht so sein, behaupte ich einfach mal.

Sieht ja fast aus, wie eine Lochfolientextur, zumal ja auch nur genau in dem Bereich der Heckscheibe.

Bei anderen Dateien tritt das dann warscheinlich nicht auf, richtig?

Ich würd mal sicherstellen, dass die Punkte vielleicht irgendwo auf einer Ebene sind, die du gerade übersiehst.

Ich wüsste sonst nicht, wie Paint.net auf die Idee kommen sollte, genau in dem Bereich so ein regelmäßiges Muster hinzuzuerfinden, wobei man bei dem Programm nie so ganz weiß, was es genau macht.

Vielleicht sind die in Wirklichkeit auch fast transparent und werden durch den Export deutlicher sichtbar? DDS komprimiert ja recht stark, da gibt es auch Voreinstellungen (ich glaube DTX1 ist das), die nur sehr eingeschränkt Transparenz haben.

Andererseits tritt das laut dir ja scheinbar selbst beim (unkomprimierten) TGA auf....

Wenn du es aktiviert hast, kommt es immer, sobald du irgendeine seite der WebDisk öffnest und eine ungelesene Konversation hast.