= Englisch [EN], 
= Deutsch [DE], 
= Französisch [FR]. Wenn du die angegebene Sprache nicht beherrschst, schreibe auf Englisch! Moin,
ich dachte Mal, ich mache hier einen Thread zum Thema Zugriffsverletzungen, Fehler bei Bereichsprüfungen oder allgemein Fehler in OMSI.
Mich hat es schon länger interessiert, was genau denn jetzt beim Fehler xyz (im Hintergrund) bei OMSI schief gelaufen ist. Vielleicht hat der eine ja Vermutungen, der andere sogar eine feste Antwort. 
Grüße
Also ich bin da auch echt kein Experte, und frage mich das auch schon seit längerem, aber ich glaube, dass zumindest der Fehler bei Bereichsprüfung irgendwas mit einem fehlerhaften Index in einem Script zu tun hat. Da ich aber auch von OMSI-Scripten keine Ahnung habe, keine Garantie für Richtigkeit!
Bei diesem Fehler gibt es glaub ich hunderte verschiedene Varianten. Aber zum sammeln von eventuellen Lösungsansätzen ist so ein Thread bestimmt hilfreich. 
einer dieser beliebten Fehler in der Bereichsprüfung ist mir neulich erst über den Weg gelaufen. Da hab ich ein Chronoevent zum Testen rausgegeben und einmal die Map damit gefüttert ließ sie sich nicht mehr im Editor öffnen. Das wurde mir berichtet mit dem schicken der Logfile (worin nicht ein einziger Error zu finden war 
) aber ziemlich schnell kam ich auf die Lösung des Problems: eine fehlende Kachel in der Global. Ich hab nämlich für die Chrono eine zusätzliche Kachel gesetzt um dort eine Einstiegshaltestelle zu platzieren dass die KI nicht leer ums Eck kommt, die ist auf anderen Rechnern natürlich nicht in der Global hinterlegt
Also ich bin da auch echt kein Experte, und frage mich das auch schon seit längerem, aber ich glaube, dass zumindest der Fehler bei Bereichsprüfung irgendwas mit einem fehlerhaften Index in einem Script zu tun hat. Da ich aber auch von OMSI-Scripten keine Ahnung habe, keine Garantie für Richtigkeit!
Das würde ich jetzt so nicht sagen. Es gibt sehr viele verschiedene Fehler bei Bereichsprüfung. Jeder weist in eine andere Richtung.
Allg beschreibt dieser Fehler eher die Situation, dass OMSI irgendwas nicht korrekt "auslesen" kann. Was ist hier jedesmal was anderes.
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.
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:
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.
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:
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.
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:
Wem die Erklärung immer noch nicht zu technisch war, dem sei auf folgende Seiten verwiesen:
Informatik ist an vielen Universitäten zulassungsfrei. 
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.
da hab ich auch noch was: Ich habe im A23 Beta von der Lion's City Familie die Krüger++ eingebaut, davor war eine Aesys (?) drin.
Scripts, OK
Busdatei, OK
Main.osc, OK
o3d, OK
o3d-Einträge in der cfg, OK
was ich vergessen hatte anzupassen, waren die Script-Texturen im oberen Teil der Modell.cfg. Bekommen habe ich aber nur einen Fehler in der Bereichsprüfung. 
Drum dauert wohl Lotus so lange: Die programmieren was neues, machen einen mini-mini-mini-Fehler und müssen den erstmal finden mit nix-sagenden Logfehlern. 
Da hast du dann ganz offensichtlich in der model.cfg unter einem [matl]-Eintrag eine Textur eingetragen, die in der Modelldatei (sei es eine .x oder .o3d) nicht vorhanden ist. Passiert gerne mal bei Schreibfehlern. Omsi scheint diese Fehler aber auch öfter mal auszuspucken, weils gerade passt.
Kannst du mir sagen was der Fehler bei bereichsprüfung vom Facelift LE von arne j bedeutet den habe ich nähmlich heute neu Insterlliert davor bevor ich ihn gelöscht hatte hat er ohne problem funktioniert
Frage:
Was bedeutet die Fehlermeldung: Fehler bei Bereichsprüfung: map.translate?
Kenne das im Zusammenhang mit beschriebenen Textfeldern, wo der Text zu lang ist.
