Beiträge von ma7t3

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

Ein bisschen unterwegs mit dem Iveco...

Landkreis Stein V2 (WiP, zusammen mit BSAG_Tramspotter2912) | Iveco Crowssway LE

Wähle das Mesh, in dem der Almex mit "drinne hängt" aus und drücke Tab, um in den Edit Mode zu gelangen.

Wählen dann alle einzelnen Flächen (Faces) aus, die zum Drucker gehören. Dazu kannst du im einfachsten Fall alle einzelnen Flächen mit Rechts- oder Linksklick (je nach Blender-Version und -Einstellung) auswählen, wenn du dabei Shift gedrückt hältst.

Über die Tasten "B" und "C" gelangst du in die Rechteck- bzw. "Pinselauswahl", mit der es möglich ist, viele Flächen auf einem Haufen auf einmal auszuwählen.

Zuletzt ist die Taste "L" (select linked) auch noch sehr hilfreich. Sie erlaubt dir, wenn du deine Maus über ein Mesh bewegst, und dann L drückst, alles auszuwählen, dass mit dem Face an der Mausposition verbunden ist.

Wenn du dann den ganzen Drucker fertig ausgewählt hast, drücke einfach "P" und dann "Selection" um die Auswahl vom bisherigen Mesh zu trennen und zu einem eigenen Mesh zu machen.

Moin,

ich habe das noch nie selber ausprobiert, hatte aber auch eine ähnliche Idee. Man muss halt am Stopschild/Haltelinie eine Ampelschaltung definieren, die eine Anforderung hat. Die Anforderungsdistanz würde ich da auch sehr kurz (0-1 m) halten. Es ist ja nur für die KI relevant.

Ich würde sagen, dass die Phase bei Anforderung halt startet bzw. fortgesetzt wird und dann nach 1-2 Sekunden auf grün springt. Sobald die KI angefahren ist und einmal die Haltelinie überfahren hat, kann/bzw. sollte es für das nächste Auto ja direkt wieder rot werden.

Also mein ungetesteter Vorschlag für die Phase wäre jetzt:

2 Sekunden grün

1 Sekunde rot

Und dann eben eine Anforderung bei "0", die pausiert, wenn keine Anforderung besteht.

Damit das ganze funktioniert, ist noch wichtig, dass man mindestens ein Ampelobjekt dennoch tatsächlich auf der Map platziert und mit der Kreuzung verbindet, da die Autos es sonst ignorieren.

Man kann die Ampel dann ja unter der Erde oder im Busch verstecken.

Probier mal, alle .prt-Dateien in deinem Map-Ordner zu löschen.

Die funktionieren wie eine Art Cache für Kollisionen.

In den meisten Fällen dürfte das relativ unproblematisch sein, solange sich nicht zwei Objekte mit der gleichen ID auf der gleichen Kachel befinden (ich wüsste aber auch gerade nicht, wie so etwas technisch passieren kann).

Die doppelten IDs entstehen meistens dadurch, dass verschiedene Karten bzw. verschiedene Kacheln von verschiedenen Karten oder Entwicklungsständen der Karte einfach zusammengefügt wurden.

Gerade wenn man zwei völlig separate quasi fertige Karten zusammenfügt, entstehen typischerweise haufenweise doppelte IDs.

Ich würde mal ganz simpel sagen: Solange du im Spiel keine Probleme hast oder Fehler auftreten, die möglicherweise auf doppelte IDs zurückzuführen sind, kannst du es einfach ignorieren.

Wenn man es doch beheben will, wäre wahrscheinlich die sicherste Möglichkeit, ein betreffendes Objekt zu löschen und neu zu platzieren. Dann kriegt es eine neue, noch freie ID.

Wenn du weißt, was du tust, kannst du die ID-Codes auch direkt in der map-Datei einsehen und ändern.

Sie stehen sowohl bei Objekten als auch Splines als dritter Parameter (nach dem Dateipfad dort).

[spline]
0
Splines\ma7t3\Landkreis_Stein_V2\str_Ueberland_2spur_8m_01.sli
38768
0
0
250.604332334973
-3.72529004940362E-8
62.8984835079143
269.999992326849
174.53293674011
-199.99999686135
0
0
0
0
0
0
0

Diesen Wert kannst du prinzipiell einfach ändern, musst aber dann darauf achten, ob die ID nochmal woanders referenziert wird, z.B. beim var-parent von einem Objekt (das ist quasi das, wenn z.B. eine Ampel mit ihrer Kreuzung verbunden wird oder eine DFI mit ihrer Haltestelle).

Die Referenz muss dann in dem Fall natürlich auch angepasst werden.

Hm, das kommt so ein bisschen auf die genaue Situation an...

Hast du ein komplettes Kreuzungsobjekt?

Bei klassischen "Hubbeln" würde mir spontan einfallen, das ganze über ein Hightdeform-Mesh zu lösen.

Also quasi ein Mesh, was grundsätzlich komplett flach ist ist, den Hubbel aber beinhaltet. Du musst es dann nur in der sco richtig eintragen.

Dann kannst du die Pfade quasi gerade durch legen (musst sie nur im Bereich der Unebenheit in relativ kurzen Abständen oft teilen, damit das ganze sauber wird).

Die KI-Autos sollten dann relativ gut da rüber fahren.

Wenn der Unterschied sehr klein ist (z.B. bei einem teilweise abgesenkten Bordstein sind es vielleicht 2-3 cm), würde ich tatsächlich einfach eine kleine "Schrägung" einbauen oder die Autos das kleine Stück "hochspringen" lassen, indem man den Pfad einfach entsprechend höher setzt. Das fällt im Spiel tatsächlich meist kaum auf.

Den Fehler hatte ich auch. Du findest den "Lierach-Ordner" unter OMSI 2\Sceneryobjects\Ahlheim4_Objekte\Lierach_Objects.

Kopiere diesen Ordner einfach eine Ebene nach oben in den globalen "Sceneryobjects"-Ordner, dann sollte er alles finden.

Ansonsten nochmal mit OMSI-Tools scannen, dann siehst du, was eventuell noch fehlt.