Beiträge von ma7t3

Willkommen in der OMSI-WebDisk!
Als Gast kannst du nur Inhalte in deiner ausgewählten Sprache sehen. Registrierte Nutzer können die Sichtbarkeit anderer Sprachen in ihrem Kontrollzentrum aktivieren, weitere Infos hier.
Alle Themen sind in den Foren mit einer Sprachflagge gekennzeichnet: = Englisch [EN], = Deutsch [DE], = Französisch [FR]. Wenn du die angegebene Sprache nicht beherrschst, schreibe auf Englisch!

    Mit dem Plugin als .o3d exportierte DInge haben bei mir ein Problem mit der (Sonnen-)beleuchtung. Daher als .x exportieren und converten :)

    Kann ich so nicht bestätigen, ich arbeite schon seit Ewigkeiten ausschließlich mit der stetig aktuellsten Blender-Version und exportiere immer als o3d-Datei. Das klappt bei mir perfekt.

    Wichtig ist nur, dass man immer den Edge-Split-Modifier aktiviert, damit keine komischen Schatteneffekte entstehen. Der o3d-Converter aus dem SDK macht das quasi automatisch, daher kann man sich diesen Schritt in Blender sparen. Das o3d-Plugin (zumindest das, was ich verwende) tut das standardmäßig nicht.

    Ansonsten finde ich das noch viel einfacher als immer den Zwischenschritt über den DirectX-Export und dann die Umwandlung in o3d.

    Blender 2.79 habe ich eigentlich nur noch auf dem System, um x-Dateien zu importieren (z.B. von Spline-Exports für Kreuzungen). Die kann ich dann sogar per Copy-Paste direkt aus der 2.79 in die 4.0 rüberholen.

    Aber naja, egal, das hier soll keine ausufernde Diskussion zu dem Thema werden.

    Solange jede:r einen passenden Workflow hat, der funktioniert, ist ja alles gut. :)

    Moin, leider verstehe ich das Problem noch nicht so ganz.

    Kannst du das irgendwie mithilfe eines Screenshots besser visualisieren?

    Grundsätzlich docken Splines und Objekte ja immer über Pfade aneinander an. Allgemein gesagt kannst du ja einfach temporär einen Pfad platzieren, dann richtig daran andocken und diesen Pfad dann wieder löschen.

    Wobei mir eben grade nicht ganz klar ist, ob das in deiner konkreten Situation in irgendeiner Weise hilfreich ist. :"D

    Joa mit dem Kran mal gucken, den habe ich tatsächlich nur so irgendwo "rausgezogen" beim Sammeln, welche Objekte man alle verbauen könnte.


    Das Depot ist tatäschlich ursprünglich eine Feuerwache, die ich zwar nicht 100% real nachgebaut, aber mich habe inspirieren lassen. Nachträglich haben wir sie dann als Bus-Abstellhalle umgewidmet :D

    Ja, die Tore sind funktionsfähig, mit den kleinen roten Knöpfen daneben, die du auf dem Bild erkennen kannst, kann man sie öffnen und schließen. :)

    Region Südniedersachsen (WiP)

    Update #29 vom 04.02.2024

    Die Linie 36 gehörte bereits zu den längsten, wichtigsten und meist-frequentiertesten Linien, da sie aus dem Westen das Heideviertel, wo viele Studenten wohnen, mit dem Nordviertel und den Hauptbahnhof verbindet. In die andere richtung führt sie über das Südviertel (Göteborger Straße) und Triesdorf tagsüber bis nach Haine zum Park&Ride-Parkplatz und ist somit auch in diese Richtung eine wichtige Linie für Pendler. Jetzt wird sie noch um einige Haltestellen in ein neues Gewerbegebiet erweitert.

    Dorthin wird auch der Betrieb "Graf-Reisen" (ehemals BBE), welche auf im Auftrag der Grundorfer Verkehrsbetriebe fährt, seinen neuen Betriebshof haben, von dem wir in den nächsten Bildern etwas sehen.

    Wir hoffen, euch gefallen die Bilder und freuen uns natürlich wie immer auf eure Kommentare

    Moin zusammen,

    ich habe gerade eine kleine Betriebshof-Halle erstellt, in der Busse abgestellt werden sollen. Damit es nachts nicht so dunkel ist, hat das ganze Ding natürlich auch etwas Licht bekommen. Den Lichtschein, den die Lampen am Objekt aussenden, habe ich direkt mit auf die Lightmap des Objektes gelegt. Ich habe dazu in Blender Lampen mit entsprechender Emission erzeugt und das ganze gebaked, weil ich so mehr Kontrolle darüber habe, was beleuchtet wird, und das ganze einfach vom Lichtverhalten deutlich realistischer rüberkommt (siehe Screenshot aus Blender:)


    Jetzt habe ich bloß das Problem, dass, wenn ich jetzt mit dem Bus dort hinein fahre, dieser natürlich nicht angeleuchtet wird und komplett dunkel ist, weil ich in OMSI keine Lichtquelle definiert habe, liegt ja alles auf der Lightmap.

    Heißt, ich brauche jetzt eine Lichtquelle, die andere Objekte und insbesondere Fahrzeuge anleuchtet, nicht aber das eigene Objekt selber, weil das ja sonst sogesehen doppelt beleuchtet wäre.

    Ist sowas in OMSI technisch möglich, und wenn ja, wie?

    Ich bin leider absolut kein Licht-Experte, deshalb steh ich an dem Punkt grade etwas auf dem Schlauch....


    Ich bedanke mich im Vorfeld für eure (hoffentlich hilfreichen) Antworten!

    Hab mal eine Feuerwerwache nach realem Vorbild gebaut, werde die jetzt aber als Betriebshofhalle umfunktionieren.

    Dabei hab ich mich mal bisschen in Blender ausgetobt und mit Materialien und Beleuchtung experimentiert:



    Vorbild (Freiwillige Feuerwehr Kiel-Dietrichsdorf):


    Und in OMSI wurde sie auch schon getestet:

    (Die Materialien, Nightmap usw. sind natürlich alle gebaked)

    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.

    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. :"D


    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.


    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:

    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:

    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.

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

    Geht so. :"D 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.

    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... :"D

    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. :"D