Beiträge von Lµkas

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!

    Vielleicht kann ich das "Geheimnis" ein wenig lüften, ich muss aber ein wenig länger ausholen. Ich versuche es mal auf eine weniger technische Art zu erklären.

    Die einfache Erklärung

    Ein Computerprogramm (genauer: ein Prozess) hat immer einen bestimmten definierten Speicher, der ihm zugestanden wird. Das Betriebssystem weist dem jeweiligen Prozess einen gewissen Speicherbereich zu, in diesem Speicherbereich kann das Computerprogramm alle nötigen Daten ablegen.


    Nehmen wir als Beispiel ein sehr einfaches Programm, was eine Liste verwaltet, in etwa so: [ 1, 53, 7, 8, ]. Im Speicher sieht das dann so aus:

    Code
    Platz im Speicher    ...  195  196  197  198  ...
    Inhalt                     1    53   7    8

    Diese Liste hat vier Plätze, die in den Speicherzellen 195-198 liegen. Das Betriebssystem (bzw das Programm) weiß das und weiß auch, dass das Programm genau 4 Speicherplätze belegt. Alle anderen Speicherzellen sind von anderen Programmen oder dem Betriebssystem selbst belegt.


    Ein Programm ist immer eine gewisse Abfolge von Maschinenanweisungen. Im Hintergrund werden stumpf Befehle abgearbeitet und Anweisungen ausgewertet. Wir können nun z.B. folgenden Befehl ausführen: "Gib mir das zweite Element der Liste zurück". Wenn man das äquivalent in eine Programmier-/Maschinensprache umsetzt, wird folgendes dabei herauskommen: "Gib mir die Zahl in der Speicherzelle 196 zurück".


    Was aber, wenn wir folgenden Befehl haben: "Gib mir das fünfte Element der Liste zurück". Das Programm weiß, wo die Liste anfängt und teilt dem Betriebssystem nun mit: "Gib mir die Zahl in der Speicherzelle 199 zurück". Da das Betriebssystem clever ist und auch als eine Art "Wächter" für den Speicher fungiert, merkt es recht schnell, dass da etwas faul ist. "Moooment, Speicherzelle 199 gehört ja gar nicht zu dem Prozess, der gerade anfragt." Dann holt das Betriebssystem die Zugriffsverletzungskeule raus und lässt das Programm abstürzen. Das ist dann die sogenannte Zugriffsverletzung: Ein Prozess will auf einen Speicherbereich zugreifen, der ihm gar nicht gehört.


    In der Regel befindet sich ein (klassisches) Computerprogramm immer in einem wohldefinierten Zustand und man weiß ganz genau, was folgt. Das nennt man "deterministisch": Man weiß stets, an welcher Stelle das Programm gerade ist, welche Parameter gegeben sind, was als nächstes folgt usw. Fehlerzustände kann ein Programm nicht automatisch behandeln, außer der Entwickler kümmert sich aktiv darum. Ergo stürzt es im Fehlerfall einfach ab.

    Es ist komplizierter ...

    In Wirklichkeit gibt es nicht nur das Programm und das Betriebssystem, sondern viele verschiedene Ebenen dazwischengeschaltet (oder eben auch nicht). Das ist auch immer abhängig von der Programmiersprache:

    • C: Hier ist ein Programm nahezu direkt mit dem Controller des Speichersverbunden. Wenn ich jetzt sage "Gib mir das fünfte Element der Liste zurück", merkt niemand den Fehler und du bekommst den Inhalt der Speicherzelle 199 zurück. Das ist übrigens der Grund, wieso C-Entwickler immer höllisch aufpassen müssen und stets auf der Hut vor Speicherfehlern sein müssen: Es fällt einfach nicht auf. Da im Speicher nicht nur Variablen drinstehen, sondern auch Anweisungen kann es leicht passieren, dass man Anweisungen ausführt, die gar nicht mehr zum Programm gehören. An dieser Stelle kann sich dann auch Schadsoftware befinden, die so ausgeführt wird ... Die klassischste Form von Sicherheitslücken durch Code Execution.
    • Java/C#: Hier ist man nahezu immun gegen Speicherfehler. Die Programmiersprache (bzw. die Umgebung, in der die Programme laufen - eine Art "virtueller PC" - in Java die JVM (Java Virtual Machine)) wacht von Haus aus über Speicherfehler (und andere Fehler). Wenn man in Java z.B. auf das nicht-existierende fünfte Element der Liste zugreifen würde, erhielte man eine IndexOutOfBoundsException - Exceptions sind eine Art "Nachrichten", die Fehlerzustände signalisieren.
      Der Programmierer muss sich darum aktiv kümmern, dass solche Exceptions nicht auftreten, dazu hat er folgende Möglichkeiten (s.u.). Tut er dies nicht, wird die Exception weiter "geworfen" und das Programm stürzt ab. In C# ist das dann die sog. "Unbehandelte Ausnahme" (vielleicht kennt der ein oder andere diesen Dialog).


      • Überprüfen vorher: Vor dem Zugriff wird überprüft, ob die Liste tatsächlich so lang ist. Falls nicht, wird entweder eine Fehlermeldung ausgegeben (z.B. in einer Log-Datei) oder einfach irgendein anderer Wert (z.B. -1) zurückgegeben.
      • Exception abfangen: Wir prüfen vorher nicht, sondern tun so als wäre nichts passiert und behandeln die Exception-Nachricht im Nachhinein. Dann können wir z.B. in die Log-Datei eine Fehlermeldung schreiben und den Zugriff irgendwie anders behandeln.

    Natürlich gibt es noch gaaanz viele andere Typen von Exceptions (bspw. eine Datei soll geschrieben werden, die aber schreibgeschützt ist, die 750. Zeile einer Textdatei wird geladen, die aber nur 740 Zeilen hat, eine Variable soll quadriert werden, ist aber eine Zeichenkette und keine Zahl, ...), aber die meisten solcher Art lassen sich technisch auf Speicherfehler zurückführen weil entweder auf eine Speicherstelle zugegriffen wird, die einem nicht gehört oder eine Instruktion ausgeführt wird, die gar nicht mehr zum Programm gehört.

    Was hat das mit OMSI zu tun?

    Delphi/Pascal ist die Programmierumgebung, in der OMSI geschrieben wurde. Nach einigem Googeln stellt sich heraus, dass Meldungen wie "Zugriffsverletzung bei Adresse X in Modul Y" und "Fehler bei Bereichsprüfung" keinesfalls nur in der OMSI-Welt auftauchen, sondern typische Pascal-Fehlermeldungen sind. Ich vermute(!), dass überall dort, wo ein Fehlerzustand eintritt (s.o. - ein Programm weiß nicht, was es im Fehlerfall machen soll. Es stürzt ab - vergleichbar mit den Exceptions oben), der nicht behandelt wurde, eine der zwei Meldungen geworfen wird. Das kann ganz viele Gründe haben:

    • Syntaxfehler in einer Konfigurationsdatei oder in einem Script => OMSI kann nicht wissen, was der Erbauer damit gemeint hat.
    • Eine verwendete Variable ist nicht vorhanden => OMSI weiß nicht, welchen Wert die Variable hat und kann sie somit auch nicht verwenden
    • In der global.cfg fehlt irgendwo ein Kacheleintrag => OMSI weiß nicht, was mit dieser Kachel ist. Ist die gelöscht? Ist die vorhanden? Ist die fehlerhaft? Wurde die vergessen?
    • => Irgendwer hat irgendwas beim Bauen falsch gemacht

    Es ist noch viiiiiieeeeeeel komplizierter ...

    Wem die Erklärung immer noch nicht zu technisch war, dem sei auf folgende Seiten verwiesen:

    Bitte noch mehr!

    Informatik ist an vielen Universitäten zulassungsfrei. :D

    Zusammengefasst

    Wann immer OMSI nicht mehr weiter weiß, weil ein Fehlerzustand eingetreten ist, wird eine der beiden Meldungen geworfen und OMSI stürzt ab weil es nicht weiß, wie es den Fehlerzustand "ausbügeln" kann.


    Dementsprechend ist es sehr schwierig, den genauen Ursachen auf den Grund zu gehen. Alle Fehler eines Entwicklers (im Sinne von unsachgemäß geschriebenen Dateien oder Benutzung des Editors) können eine solche Meldung nach sich ziehen. Im Prinzip alles, was OMSI-seitig nicht vorgesehen und auch nicht abgefangen wird.

    Ich kann auch nur immer dafür werben, Objekte zu bauen. Gerne auch ganze Straßenzüge, so wie in Hamburg.


    Die Vorteile liegen auf der Hand: Man baut sauberere Kreuzungen, muss sich nicht mit Invis-Splines oder Ampel-Workarounds rumschlagen und Kreuzungen in Steigungen mit Neigung sind supereinfach (hier eine kurze Erklärung von Rüdiger, hier ne Kurzanleitung von mir - leider ist shapeloft ja nicht mehr verfügbar... und hier nochmal ne Forensuche zu dem Thema). Damit lassen sich auch Spielereien wie Einfahrten mit abgesenktem Bordstein, kleine Einbuchtungen usw. gut erledigen. Wäre zusätzlich noch ein Realismusbonus (bei vielen Karten die mit Splines gemacht werden gibt's solche Stellen nicht - es läuft einfach entweder geradeaus oder eine Kreuzung). Anfängern würde ich empfehlen, erstmal in OMSI die Splines vorzubauen, dann ne .x-Datei draus zu exportieren anhand derer dann in Blender gebaut wird. Die Neigung kann dann nachher hinzugefügt werden. (nachdem die Pfade usw. verlegt wurden)


    Einziges Manko: KI-Spurwechsel funktioniert auf Objekten nicht. Längere mehrspurige Abschnitte sollten also nach wie vor als Splines ausgeführt werden.

    Die fehlende Objekte Sceneryobjects/YufaObjekte/Depot/pforte2.sco, werk.sco sind in folgendem Download enthalten:


    Das erste Ergebnis verweist auf diesen Thread: Problem mit Installation Städtedreieck V3.2 - Seite 2 - Support für AddOns, Mods, Content und Tools - Marcels OMSI-Forum


    Dort steht in Beitrag Nr. 24:

    Zitat

    Kopiere bitte den Ordner Sceneryobjects/YufaObjekte/Model und Sceneryobjects/YufaObjekte/texture samt Einhalt in den Ordner Sceneryobjects\YufaObjekte\Depot.

    Dies ist in Beitrag Nr. 59 von Karottenphantom erklärt worden.

    bei der Yufa habe ich das genau so gemacht wie es mir gesagt wurde und map tools zeigt auch nichts mehr an also was fehlt

    Stimmt. Aber auch die Map Tools sind nicht allmächtig. In diesem Fall liegt es daran, dass Model-Dateien im falschen Ordner liegen.

    Bei Brücken kann ich mir ja zwei Arten von Kollisionen vorstellen:

    • Der Spieler fährt auf der Brücke => Kollision mit der Oberfläche / der Straße
    • Der Spieler fährt unten durch => Kollision mit dem Mesh (z.B. Brückenpfeiler)

    [joinable] könnte bewirken, dass beides funktioniert. Ist aber nur ne Vermutung.

    Also ich habe gerade mal bei Rumpelhans in die Schilder geschaut und hab die genommen die nur beschriften können da ist als Mesh nur das gesamte Schild festgelegt und womit wird dann festgelegt wo geschrieben wird weil bei einem Straßenschild das hat ja auch noch nen Pfosten woher weiß ich dann das auf dem

    Schild geschrieben wird?

    Ich bin btw Rumpelhans :)

    Meine Verkehrszeichen (die meinst du doch oder?) sind nicht als Textfeld beschriftbar, deswegen hilft die Analogie nur bedingt. Die Beschriftung läuft intern über String-Variablen und Scripttexturen, das ist etwas Anderes als Texttexturen.

    --Kann geschlossen werden--

    Wir schließen hier grundsätzlich keine Support-Threads, damit evtl. User, die das gleiche Problem haben, sich auch noch zu Wort melden können. Um Support-Threads als "erledigt" zu kennzeichnen, kannst du selbst ganz oben doppelt auf den Haken Unerledigt klicken. Damit kennzeichnest du dieses Thema als Erledigt.


    PS: Ich habe die letzten Beiträge mal verschoben in einen neuen Thread damit sich das nicht vermischt. :)


    PS2: Im alten Forum gab's ne kurze Anleitung, die vielleicht dem ein oder anderen noch hilft bezüglich Texttexturen: Flächen zum beschriften erstellen in Blender 2.63 - Allgemeiner Objektbau - Marcels OMSI-Forum

    Lµkas Es gibt viele Karten, die liefern alles Nötige mit


    z.b.?

    Ich habe es gerade selbst getestet. Splines\Yufa\bikeline-einseitig.sli ist definitiv im Download hier drin.


    Da steht das benötigte Zusatzmaterial. Eine Google-Suche liefert für "OMSI" + Name alle entsprechenden Threads im OMSI-Forum. Falls die Downloadlinks nicht gehen, schau mal auf den letzten Seiten nach. Dort sind dann meistens die aktualisierten Downloadlinks zu finden.

    Ich würde euch auch Inkscape an's Herz legen. Als Illustrator-Alternative eignet sich Affinity Designer auch sehr gut (kostet zwar, ist aber ein Einmalkauf und relativ günstig).

    Einsamer_Wolf86 es mag zwar in dem Fall funktioniert haben, aber bei maximaler Zoomstufe von 500% ist ja schon ein deutlicher Unterschied in der Bildqualität zwischen Dir und ma7t3 erkennbar:


    Die Pixelfehler im linken Bild kommen von der Komprimierung des JPG-Formats. Am Besten nimmt man PNG dafür.

    muss das bei Yufa rein? ;(ich habe das immer in die normalen splines gemacht;(

    Das Archiv der Straßenmarkierungen sieht so aus:


    Diese Ordner werden ins OMSI-Hauptverzeichnis entpackt, sodass sich folgende Ordnerstruktur bspw. ergibt:

    OMSI2 -> Splines -> Yufa -> 2_s_line.sli ...