Beiträge von ma7t3

Moin,

leider wird man aus deiner Supportanfrage nicht ganz schlau - zumindest ich kann nicht ganz nachvollziehen, was du wirklich vor hast. Präzisiere deine Frage/dein Problem bitte nochmal etwas.

So ein paar Ideen "ins Blaue geschossen".

Test alles bitte von "oben nach unten" durch.

• Die verwendete String-Variable IBIS_cabindisplayO ist nicht richtig definiert (ich könnte mir vorstellen, dass die Variable tatsächlich IBIS_cabindisplay0 heißt - statt einer "0" könnte dort irgendwie ein ähnlich aussehendes "O" gelandet sein)
• Die verwendete Font Lawo_Innenanz_Schmal existiert nicht.
• Die Fonthöhe in Pixeln ist größer als die des Textfeldes (das sollte eigentlich keinen Syntax-Fehler hervorrufen sondern eher erst später einen Map.Translate-Fehler - aber trotzdem mal checken, wenn die Dinge oben nicht geholfen haben).
• OMSI könnte die Alignment-Einstellungen nicht mögen (probier' mal testweise, die letzten beiden Parameter des Befehls auf 0 zu setzen und schau, ob es dann geht).

Ansonsten musst du bitte dein ganzes Logfile posten.

Ich würde mal behaupten, dass das eingetragen Kollsisionsmesh nicht existiert.

Entferne am besten einfach den [collision_mesh]-Eintrag und füge stattdessen ggf. [nocollision] ein.

Das sollte das Problem lösen.

192 01:11:01 -  -   Error:           In "Sceneryobjects\GhostyMaxim\Static_Facelift_Spiegel.sco" there was an error in line 11!
193 01:11:01 -  -     Warning:       Invalid Object: Sceneryobjects\GhostyMaxim\Static_Facelift_Spiegel.sco"
194 01:11:02 -  -   Error:           In map file "maps\ManningenV2\tile_1_2.map" there was an error in line 11913!

Kannst du mal schauen, was in der Datei Sceneryobjects\GhostyMaxim\Static_Facelift_Spiegel.sco rund um die Zeile 11 steht?

Die VLKS testen Elektrobusse im Überlandbetrieb...

Landkreis Stein V2 (WiP, zusammen mit BSAG_Tramspotter2912) | eCitaro (Hamburg Linie 20)

Wenn du auf Überland stehst, ist auch Tettau in jedem Fall empfehlenswert.

Zwar schon eine ziemlich alte Karte aber dennoch sehr schön gestaltet.

Dort gibt es zwar nur zwei Linien, die jedoch beide relativ lang sind und sehr viel Abwechslung bieten.

Ich bin die Karte in den letzten Tagen nun auch häufiger mal wieder gefahren und es macht echt sehr viel Spaß.

Bist du dir sicher? Installier' ihn sonst einfach nochmal neu. Jedes mal, wenn OMSI (bzw. ein Addon) auf Steam ein Update bekommt, wird der wieder "weggebügelt".

Ansonsten schau mal in den OMSI-Einstellungen, ob du möglicherweise die Option "gesamte Karte laden" aktiviert hast (im Normalfall sollte diese deaktiviert werden).

Unter "Grafik (erweitert)" kannst du außerdem gucken, wieviel Texturspeicher du eingestellt hast.

Dort ist es übrigens auch möglich "0" einzutragen, das wird von OMSI dann als "unbegrenzt" interpretiert.

Texturladen - Direct9 Error: E_OUTOFMEMORY (-2147024882)

Systemfehler.  Code: 8.
Zur Verarbeitung dieses Befehls sind nicht genügend Speicherressourcen verfügbar: AMUAV.CNAVO.MV.U

Hast du den 4GB Patch installiert?

Wenn man keinen freien Platz zum Pause machen findet, muss man eben kreativ werden

Doch noch eine bessere Lücke gefunden

Landkreis Stein V2 (WiP, mit BSAG_Tramspotter2912) | MAN Standardbus SL 202

Wie gesagt, bei mir kam es bisher nie groß zu Kollisionen. Selbst auf Südniedersachsen, wo es mittlerweile auch sehr viele Haltestellen und Ortschaften gibt.

Und wenn doch, dann weicht man halt mal, wie du schon vorgeschlagen hast, auf einen anderen Buchstaben im Wort aus.

Aber wie gesagt: Das Problem tritt echt überraschend selten auf.

Zitat von wurstbrot

Hatte mal ein "_ü" drin für "über" und es gab Probleme.

Deshalb nehme ich "via" bzw. "v" und nicht "über"

Ob man jetzt Groß- oder Kleinbuchstaben nimmt ist meiner Meinung nach Geschmacks- bzw. Gewöhnungssache.

In jedem Fall würde ich aber empfehlen, sich für eins vollständig zu entscheiden. Sonst hat man immer das Problem, I (großes I) und "l" (kleines L) kaum auseinanderhalten zu können.

Zitat von wurstbrot

Wobei ich bei Zielen die etwas Abweiche und nach Möglichkeit den Stadtteil vorziehe mit kleinem Anhängsel falls es da unterschiedliche Endhaltenstellen gibt.

Ich hatte auch immer tendenziell die Angst, dass drei Buchstaben zu wenig sind und es schnell zu Kollisionen zwischen Abkürzungen kommt, das klappt zumindest bei mir bisher erfahrungsgemäß immer ganz gut.

Allerdings bin ich bei der genauen Wahl der Abkürzung dann auch etwas flexibler. Wenn jetzt z.B. "SB", was ich für "Schönberg" genommen hätte, schon durch etwas anderes belegt ist, nehme ich für Schönberg halt "SG" oder "SC". Wichtig ist nur, dass man das einmal dauerhaft festlegt. Wenn man viel damit arbeitet, hat man die meisten Kürzel dann ja so oder so im Kopf.

Zitat von wurstbrot

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;-)

Da bin ich mir auch nach wie vor unsicher, wie ich das am besten mache. In jedem Fall nutze ich Steigbezeichnungen auch nur dann, wenn es eben wirklich mehrere mögliche, benannte Steige an der jeweiligen Haltestelle gibt. Eine Zeit lang hatte bei mir dann aber auch ihre Linie ihren "Standardsteig" und nur Abweichungen werden explizit genannt. Das führt allerdings dazu, dass ich erst mal von diversen Linien im Zweifelsfall den Standardsteig im Kopf haben oder nachgucken muss. Mittlerweile versuche ich aber auch, bei Haltestellen, die mehrere Steige haben, den Steig immer anzugeben. Es ist dann doch einfach klarer und einheitlicher.

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.

Jetzt würde ich empfehlen, einfach immer direkte Fahrten ohne diese Angabe zu benennen und bei zusätzlichen Halten diese eben anzugeben - völlig unabhängig davon, was der häufigere Fall ist. Ganz nach dem KISS-Prinzip ("Keep it simple, stupid")

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.

Zitat von wurstbrot

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.

Das ist nämlich der Knackpunkt. Grundsätzlich gibt es immer verschiedene Möglichkeiten und Systeme, die alle ihre Vor- und Nachteile haben und sich nicht absolut "ranken" lassen, da es hier, wie du schon sagst, natürlich auch immer auf die Rahmenbedingungen ankommt.

In jedem Fall ist halt entscheidend, dass man sich für ein System entscheidet, es klar definiert und sich konsequent daran hält und nicht "mal so, mal so macht". Dann gibt es nämlich, sobald das Projekt wächst, ein großes Chaos.

Zitat von wurstbrot

Fakt ist ja auch dass die Trip-Namen nur im Editor eine Rolle spielen [...], außer das Script eines Druckes braucht es für irgendwas. Aber dann ist man eh daran gebunden...

Und selbst das ist ja meines Wissens nach garnicht möglich. Es geht hier eigentlich wirklich nur um die eigene Übersicht.

Aber gerade die ist, wie bereits mehrfach erwähnt, bei großen Projekten und komplexen Linienverläufen von enormer Bedeutung.

Moin zusammen,

wer sich das erste Mal in OMSI mit Fahrplänen auseinandersetzt und Trips erstellt oder an großen Karten mit sehr vielen Trips arbeitet, kennt das Problem sicherlich: Wie benenne ich die Trips am besten?

Schließlich sollten die Trips, um die Übersichtlichkeit zu wahren einer möglichst einheitlichen Nomenklatur folgen, damit sofort klar ist, wie die Trips heißen.

Gleichzeitig ist - gerade bei einer großen Anzahl und verschiedenen Linienwegen - eine hohe Flexibilität notwendig.

Dazu kommt noch, dass die Namen gleichzeitig kurz gehalten werden müssen, da das Dropdown-Menü im Fahrplan-Editor von OMSI, in dem man einen Trip auswählt, verhältnismäßig klein ist - zu lange Trips werden dann abgeschnitten.

Aus diesem Grund habe ich über die Zeit für mich selbst ein klares "Benennungsschema" entwickelt, welches ganz klar festlegt, wie ein Trip-Name aufgebaut ist.

Dieses System vermeidet dabei Mehrdeutigkeit, Redundanzen und "Interpretationsspielraum", was den Workflow - gerade bei sehr großen Projekten - enorm verbessert.

Nun habe ich mich mal dazu entschieden, dieses System kompakt und verständlich aufzuschreiben und mit euch zu teilen. Natürlich gibt es auch andere Ansätze, das hier ist jedoch meine persönliche Empfehlung, die vielleicht auch für andere (neue User) ganz hilfreich ist, beim der Fahrplanerstellung in OMSI einen besseren Überblick zu wahren.

Die besondere Kennzeichnung von Schulfahrten (inkl. "Morgens" und "Nachmittags"-Unterscheidung) dient in erster Linie dazu, Trips über verschiedene Busstop-Würfel laufen zu lassen, um ein realistischeres Fahrgastaufkommen umzusetzen (Morgens wollen viele Menschen an einer Schule aussteigen, nachmittags dort einsteigen).

Achso, bevor mir jemand etwas vorwirft: Beim formulieren und formatieren habe ich mir von ChatGPT etwas helfen lassen, da ich selber von mir weiß, das meine eigenen Sätze schnell mal sehr "bandwurmig" und verdreht werden, was das Verständnis seltenst positiv beeinflusst. Von daher ganz offen: Credits auch an die KI dafür.

🚏 OMSI 2 Benennungsschema für Trips

🔹 Allgemeine Struktur:

[Liniennummer]_[Start][Steig]-[Ziel][Steig][_vZwischenhalt][_SM/SN]

• Liniennummer → Immer drei Ziffern (z. B. 270)
• Betriebsfahrten (Leerfahrten ohne Fahrgäste) → Statt einer Liniennummer wird "X" verwendet (X_SEB-SWB)
• Start/Ziel → Dreistellige Haltestellenkürzel
• Steigbezeichnung → Falls nötig, direkt an das Kürzel anhängen (SEW1, RFM2)
• via-Zwischenhalt → Falls alternative Routen existieren, mit _vXXX angeben (z. B. _vSWB)
• Schulfahrten:
  • _SM → Schülerfahrt morgens zur Schule
  • _SN → Schülerfahrt nachmittags von der Schule

🔹 Aufbau der Haltestellenkürzel

Jede Haltestelle hat ein dreistelliges Kürzel, das nach folgendem Schema aufgebaut ist:

🔹 Die ersten zwei Zeichen stehen für die Ortschaft oder den Stadtteil
🔹 Das dritte Zeichen steht für die Haltestelle innerhalb der Ortschaft

🛑 Beispiele für Haltestellenkürzel

Falls eine Haltestelle mehrere Bussteige hat, wird die Steigbezeichnung direkt angehängt:

• Seestedt, Weiher, Steig 1 → SEW1
• Rosenfeld, Markt, Steig 2 → RFM2
• Schönwalde, Bahnhof, Steig 3 → SWB3

Bei großen Projekten mit vielen Haltestellen empfiehlt sich, alle verwendeten Haltestellenkürzel in einer Liste (z.B. als Excel-Tabelle) festzuhalten.

🔹 Beispiele für Trip-Namen:

🚍 Normale Fahrten (ohne Steigangabe, ohne via, ohne Schulbezug)

🚏 Fahrten mit Steigangabe

🛤 Fahrten mit via-Angabe (alternative Streckenführungen)

🏫 Schulfahrten (SM = morgens zur Schule, SN = nachmittags zurück)

🔀 Kombinierte Fahrten (via, Steig & Schulfahrten gleichzeitig)

⚙ Betriebsfahrten (Leerfahrten ohne Fahrgäste)

📌 Zusätzliche Regeln zur Einheitlichkeit:

✔ Alles in Großbuchstaben → Einheitlich und gut lesbar
✔ Keine Leerzeichen oder Sonderzeichen → Kompatibilität mit allen Dateisystemen
✔ Unterstriche _ zur Trennung von Modifikationen
✔ Steigbezeichnungen direkt am Haltestellenkürzel
✔ Betriebsfahrten immer mit "X" als Liniennummer

Dieses "Dokument" findet man auch auf GitHub: https://github.com/ma7t3s-OMSI…nennungsschema-fuer-trips

Heute mal mit einem ganz besonderen Bus ein paar Runden gedreht...

MAN Standardbus SG292 (Stülb) | Landkreis Stein V2 (WiP, mit BSAG_Tramspotter2912)

Kompromiss: Wir machen ein Chronoevent! Früher das alte, später das neue

Wobei ich die Idee, es um 90° zu drehen, auch nicht so schlecht finde.

Naja, mal schauen, das sind ja jetzt doch eher schon Kleinigkeiten

BSAG_Tramspotter2912 hat das Haltestellenhäuschen soeben ausgetauscht:

Wie meinst du das genau?

Wo siehst du die Pfade?

Auch, wenn ich dein Anliegen noch nicht ganz sicher richtig verstehe, vermute es sich, dass es sich um sogenannte "Pfadobjekte" handelt.

Das sind idR. kleine Würfel, die irgendwo an einer Kreuzung stehen und die Pfade enthalten. Der Würfel selbst ist dabei nur im Editor als "Anfasser" sichtbar.

Die Methode wird beim Mapbau oft verwendet um Pfade als Objekt zu platzieren (was einige Vorteile ggü. Invis-Splines bringt) ohne jedoch eine ganze Kreuzung in Blender bauen zu müssen.

So kann man z.B. die Pfade einfacher mit Vorfahrtsregeln, Blinkereinstellungen und Ampelphasen ausstatten und dennoch die Kreuzungsgestaltung komplett im Editor mithilfe von Splines und somit ohne tiefere Blender-Kenntnisse vornehmen.

Interessant, ich habe das gerade einfach mal mit Bamp mit einem einfachen Test-Soundwürfel ausprobiert. Hier die zugehörige Sound-cfg:

(NightLightA nur als Testvariable, weil ich kein Bock hatte, eine Varlist anzulegen und diese Variable vordefiniert ist)

Strassenmusiker1.wav habe ich auf die schnelle durch einen Sinuston ersetzt, damit man optimal das Verhalten beobachten kann.

[loopsound]
Strassenmusiker1.wav
44100
NightLightA
1
0.90

[3d]
0
0
0
2

[volcurve]
-1

[pnt]
0
0

[pnt]
1
1

Die Erwartung wäre jetzt gewesen, dass der Sound beim Spawnen (?) über eine Sekunde einfadet. (siehe Beitrag von Theproloser) Das war hier jedoch nicht der Fall. Ich habe auch testweise die ganze Volcurve auskommentiert. Dabei war kein Unterschied zu hören.

Allerdings erzeugt das auch keinen Fehler im Logfile. Omsi scheint es also schon irgendwie zu "verstehen".

Eine normale, vordefinierte Variable scheint "-1" jedoch auch nicht zu sein: Versucht man nämlich, im Rahmen eines Scriptes diese mit (L.L.-1) aufzurufen und zuverwenden, kriegt man im Logfile den üblichen "unbekannter Variablenname"-Fehler.

Vielleicht ist es also doch einfach nur eine Art "Ersatzauskommentierung". Jedenfalls scheint OMSI bzgl. dessen, was man tatsächlich hören kann, die Volcurve einfach zu ignorieren ohne dabei einen Fehler zu schmeißen.

Mir fiel noch ein, dass es ja bei einigen Fehlern auch (ganz bewusst dokumentiert) die Möglichkeit gibt, einen Variablennamen wegzulassen bzw. einen ungültigen zu hinterlegen. Bei [matl_light gibt man ja auch z.B. eine Variable an, um die Lichttextur ein- und auszuschalten. Allerdings kann man sie auch weglassen oder etwas ungültiges dort eintragen um sie dauerhaft zu aktivieren.

Das scheint hier bei der volcurve nicht so zu sein. "Einmal auf die Tastatur hauen" führt in diesem Fall zu Zugriffsverletzungen. Andere Integer-Werte gehen aber. "-2" interessanterweise führt dazu, dass der Sound garnicht hörbar ist, wirft aber auch keinen Fehler.

Also alles sehr merkwürdig.

Ich konnte das Geheimnis jetzt leider nicht lüften, aber vielleicht ein paar interessante "Versuchsergebnisse" präsentieren.

Diverse Tools, die du meist auch nutzt, um herauszufinden, welche Objekte für eine installierte Map fehlen (Bluesky, OMSI-Tools, ...) zeigen normalerweise auch gleich alle verbauten Objekte und Splines an und sind dabei noch erheblich schneller als der OMSI-Editor.

Außerdem verweise ich an der Stelle auch gerne nochmal auf den folgenden Artikel: Klick

Da kann man nochmal sehr gut nachgucken, welche Objekte und Splines tatsächlich Standard-Content sind (d.h. dass definitiv jeder diese hat bzw. haben sollte).

Aber wie BusfahrerP schon richtig sagte: Du darfst nicht einfach so irgendwelche Objekte, die du verbaut hast, hochladen, es sei denn, sie stammen von dir selbst. Die Lizenz muss das erlauben.

Viele Objektpakete (die man z.B. hier in der WebDisk herunterlädt) oder die bei anderen Maps dabei sind, erlauben zwar einen Reupload im Zusammenhang mit einer Map, wo diese verbaut sind, aber das gilt nicht grundsätzlich, das solltest du für jedes Objekt bzw. Objektpaket sicherstellen, dass das so ist.

Erlaubt die Lizenz das nicht, darfst du es nicht hochladen. Du müsstest dann im Download darauf hinweisen, dass es ebenfalls notwendig ist und von den Spielern zusätzlich heruntergeladen und installiert werden musst.

Beim NewLionsCity sind "von Haus aus" Krefrath-Repaints (SWK und Besenhol) dabei