Oblivion:Häufige Fehler - Versionsgeschichte

Keris am 8. März 2009 um 15:44 Uhr

2009-03-08T15:44:56Z

Keris: /* Vermeiden von PlaceAtMe */

2009-01-08T14:21:44Z

‎Vermeiden von PlaceAtMe

Keris: /* Vermeiden von PlaceAtMe */

2009-01-07T11:42:45Z

‎Vermeiden von PlaceAtMe

Keris: /* Vermeiden von PlaceAtMe */

2009-01-02T12:22:43Z

‎Vermeiden von PlaceAtMe

ThreeD am 22. September 2008 um 07:46 Uhr

2008-09-22T07:46:24Z

ThreeD am 22. September 2008 um 07:45 Uhr

2008-09-22T07:45:08Z

Keris: /* Spieleinstellungen */

2008-09-16T13:41:22Z

‎Spieleinstellungen

Keris am 15. September 2008 um 19:31 Uhr

2008-09-15T19:31:25Z

Lars: /* Vermeiden von PlaceAtMe */

2008-09-15T18:25:08Z

‎Vermeiden von PlaceAtMe

Lars: Übersetzter Text eingefügt

2008-09-15T18:21:48Z

Übersetzter Text eingefügt

Neue Seite

== Einleitung ==

All diese Sachen sollten von einem Modder vermieden werden.

== AddTopic-Problem ==

Obwohl er eigentlich recht bekannt und gut dokumentiert ist, ist der "AddTopic-Bug" ein sehr häufiger Fehler bei Moddern.
Wenn zwei oder mehr Mods versuchen dasselbe [[ob:Topic|Topic]] zu verändern, wird nur das Topic des zuletzt geladenen geändert. Das kann zu schwerwiegenden Problemen führen, da das [[ob:Greeting|GREETING]] von mehreren [[ob:NPC|NPCs]] verwendet wird. Das Problem tritt auch auf, wenn unerwünschte [[ob:Greeting|GREETING]]-Dialoge von einem NPC entfernt wurden.
Motub hat eine ausführliche [[constwiki:Fixing_the_AddTopic_Bug|Anleitung zur Lösung des AddTopic-Problems]] geschrieben.

Außerdem sollte es vermieden werden ein Topic durch ein Script und zusätzlich über die AddTopic-Box hinzuzufügen. Das kann dazu führen, dass NPCs plötzlich aus großer Entfernung, durch Objekte, etc. mit dem Spieler reden, als wenn sie zum Beispiel mit [[ob:StartConversation|StartConversation]] dazu gebracht worden wären.
Das AddTopic aus dem Script des NPCs zu entfernen und in die Result-Box einzufügen, wird den Fehler verhindern.

== Türen ==

Vanilla-Türen sollten nicht bewegt werden, da ihre Position im Savegame gespeichert wird, sobald der Spieler in ihre Nähe kommt. Modder sollten es deshalb vermeiden die originalen Türen zu verschieben.

== Ändern von Script-Variablen ==

Dieses Problem ist am besten beschrieben in Wryes Thread [http://www.elderscrolls.com/forums/index.php?showtopic=625194 Overriding Scripts and CTDs] basierend auf einer Diskussion von MentalElf mit dem Titel ''In desparate need of a save game editor''. Trotzdem ist ein kurzer Überblick an dieser Stelle wohl sinnvoll.
Das Problem beim Ändern von Script-Variablen ist nicht, welche Mod dabei in bestimmten Konfigurationen gewinnt, sondern dass sich dies mit der Zeit ändern kann. Mann stelle sich vor, jemand nutzt eine BaseModA.esm, welche MyScript mit den Variablen VarA, VarB und VarC definiert.Diese Variablen bekommen die Indexe 1, 2 und 3. Das Savegame wird nur folgende Information enthalten:

<tesscript> script FormID = xxxxxx
value for variable index 1 = x
value for variable index 2 = y
value for variable index 3 = z</tesscript>

Mit anderen Worten: Nur die Position der Variable wird gespeichert.

Wenn der Spieler also nun nach einiger Zeit entscheidet die AddOnB.esp hinzuzufügen und diese kleine Änderungen an MyScript vornimmt, hat es zwar immer noch die Variablen VarA, VarB, and VarC, aber sie haben nun die Indexe 3, 2, 1. Wenn das Savegame also nun geladen wird, erkennt es, dass sich die FormID des Scripts nicht geändert hat und lädt also 1 für VarC, 2 für VarB, und 3 für VarA. Je nach Bedeutung der Variablen können un ernsthafte Probleme auftreten.

Schlimmer wird es noch, wenn VarA eine ref-Variable und VarC eine float-Variable ist. Du hast also nun das Binäre der float-Variable in der ref-Variable und den Inhalt der ref-Variable in der float-Variable. Absolutes Chaos!

Der einzige Weg das zu ändern ist, das Savegame ohne jegliche Mods zu laden, die etwas an dieser FormID ändern, zu speichern, die Dateien in korrekter Reihenfolge hinzuzufügen, und neu zu starten. Leider funktioniert dies nicht für Scripts aus der originalen Oblivion.esm.

Obwohl dies ein schwerwiegender Fehler ist, der einige CTDs verursachen kann, scheinen viele Leute nicht darüber informiert zu sein.

== Überfüllen von Savegames ==

Das Savegame enthält Informationen über Änderungen an der Spielwelt. Umso mehr verändert wird, desto mehr muss im Savegame gespeichert werden und desto größer wird dies.
Ein großer Faktor dafür ist die [[ob:PlaceAtMe|PlaceAtMe-Funktion]]. Neue Objekte, die mit [[ob:PlaceAtMe|PlaceAtMe]] erschaffen wurden, verschwinden nie. Dieses Problem tritt auf, wenn unsichtbare [[ob:Activator|Activators]] zum Beispiel Zauber auf den Spieler werfen - das Resultat sind unzählige ungenutzte [[ob:Activator|Activators]], die dennoch weiterhin im Savgame gespeichert bleiben.

Auch Gegenstände im Inventar können zu Problemen werden, zum Beispiel durch den Bug der negativen Gegenstandsanzahl(siehe unten).

=== Vermeiden von PlaceAtMe ===

Frühe Versionen des bekannten Tutorials [[constwiki:Casting_Spells_From_An_Activator|Casting Spells From An Activator] benutzten PlaceAtMe sehr häufig, was einen großen Fehler darstellte, da die Script-Beispiele viel Müll im Savegame hinterließen. Als das Tutorial geschrieben wurde, ging man noch davon aus, dass PlaceAtMe ordnungsgemäß funktionieren würde.Mittlerweile wurde es aktualisiert und nutzt nun [[ob:MoveTo|MoveTo]], allerdings wurden dennoch sehr viele Mods mit PlaceAtMe erstellt.

Leider entfernt [[ob:disable|disable]] nicht den Eintrag im Savegame. Dieses Problem wird zwar angesprochen, allerdings ist die Warnung sehr schwach ausgefallen:
... avoid using PlaceAtMe to create new copies of an object when you could simply use MoveTo on an existing object.
''(deutsche Übersetzung: ... vermeide PlaceAtMe um Kopien eines Objektes zu erstellen, wenn du auch MoveTo verwenden könntest)''

Die [[ob:PlaceAtMe|PlaceAtMe-Seite]] enthält zwar Hinweise und die [constwiki:Talk:PlaceAtMe|Diskussions-Seite] enthält zusätzliche Informationen, allerdings wird es nicht dort erwähnt, wo Modder normalerweise nachsehen(z.B. Tutorials), also bin ich nicht davon überzeugt, dass es so nützlich ist.

Viele Mods verwenden trotz allem noch immer die veraltete Methode und platzieren unsichtbare Activators nahe dem Spieler, obwohl MoveTo ebenso funktionieren würde.

Der Grund, warum das Thema nicht so weit verbreitet ist, ist vielleicht die Tatsache, dass sich MoveTo nicht so einfach verwenden lässt wie PlaceAtMe. Es wird zwar auf der Diskussions-Seite behandelt, dort ist es aber nicht sehr ausführlich beschrieben.

Es wird deswegen dringend ein gutes Tutorial diesbezüglich benötigt!

Eines der Hauptprobleme mit MoveTo ist, dass die Collision nicht immer mit bewegt wird. Disable nach MoveTo zu verwenden und dann enable einen Frame später, könnte dieses Problem lösen.

Das Überfüllen des Savegames durch PlaceAtMe ist zwar vielleicht nicht so schwerwiegend wie einige andere Fehler, aber eine einzige Mod, die diese veraltete Methode nutzt, kann einem Savegame schnell mehrere Megabyte hinzufügen. Wenn es nun mehr als nur eine Mod sind, wächst das Savegame doch recht gut an.

=== Vermeiden von DuplicateAllItems auf einem Begleiter ===

[[ob:DuplicateAllItems|DuplicateAllItems]] scheint für das Überfüllen der Savegames bei Weitem am schwerwiegendsten verantwortlich zu sein.

Einige Begleiter-Mods haben die Savegames unglaublich vergrößert, indem häufig [[ob:DuplicateAllItems|DuplicateAllItems]] verwendet wurde. Das gewöhnlichste Beispiel ist eine Mod, die [[ob:DuplicateAllItems|DuplicateAllItems]] verwendet (um sie auf ein Duplikat des [[ob:NPC|NPCs]] zu duplizieren) um die Belastung zu berechnen und anzuzeigen. Falls einige der Gegenstände des NPCs gescriptete Objekte sind, werden sie permament dupliziert (und unmöglich zu entfernen) jedes Mal, wenn das DuplicateAllItems ausgeführt wird. Da dies jeden Frame geschieht, so lange das Inventar des Begleiters geöffnet ist, wird das Savegame ziemlich schnell überfüllt(dutzende Megabyte in wenigen Sekunden).

Statt die Items zu duplizieren, kann besser [[ob:RemoveAllItems|RemoveAllItems]] verwendet werden, um die Gegenstände auf den Begleitern zu übertragen und danach wieder zurück. Das behebt zwar den ursprünglichen Fehler (gescriptete Objekte überfüllen das Savegame nicht mehr), aber es lässt den Fehler der negativen Gegenstandsanzahl(siehe unten) über.

=== Vermeiden von RemoveAllItems auf einem Begleiter ===

Dies kann zwar auch zu Überfüllungen des Savegames führen, es lässt sich aber leichter vermeiden als DuplicateAllItems.

Das Benutzen von [[ob:RemoveAllItems|RemoveAllItems]] auf einem [[ob:Actor|Actor]] oder [[ob:Container|Container]] mit einer negativen Gegenstandsanzahl bei einem oder mehreren Gegeständen wird diese duplizieren. Eine negative Anzahl bedeutet, dass ein Gegenstand aufgestockt wird, sobald er entfernt wird.

Dieses Problem lässt sich vermeiden, indem man dem Begleiter keine negativen Gegenstände gibt.
Also sollte vermieden werden

<tesscript>NPC.RemoveAllItems NewContainer</tesscript>

dann

<tesscript>Newcontainer.RemoveAllItems NPC</tesscript>

auf einem NPC mit negativer Gegenstandszahl. Das wird nämlich die Items jedes Mal duplizieren, wenn du etwas mit deinem Begleiter teilst. Das bedeutet der NPC hat 65536 Gegenstände nach dem 16. Mal, 16777216 Gegenstände nach dem 24. Mal und 4.2 Milliarden nach dem 32. Mal.

Beträchtliches Savegame-Wachstum!

== Vermeide diese Punkte ==

Hier ist eine Liste der Punkte, die sonst noch zu vermeiden sind:

* Klicke niemals den Button "Recompile All"
* Aktiviere niemals "Generate All" für [[ob:Pathgrids|Pathgrids]] oder "Generate Entire World"
* Versuche niemals Items einer ESP in eine andere ESP zu kopieren, wenn sie nicht aus der Oblivion.esm stammen
* Verändere keine Zellen der Oblivion.esm mit einer anderen Master-Datei.
* Verändere Zellen nicht ausversehen. Zellen die nicht direkt von deiner Mod verändert werden, haben auch kein Sternchen(benutze [http://www.elderscrolls.com/forums/index.php?showtopic=619318 TES4Gecko] um deine Mod vor dem Release zu säubern)
* Benutze keine Unterstriche in primären Ressourcen-Dateinamen. Unterstriche sind vom Spiel genutzt um diverse Dateitypen, wie Normal Maps (xxx_n.dds), Glow Maps (xxx_g.dds), etc. zu finden.
* Benutze keine vollständigen Pfade für Retexturierungen. Texturpfade müssen relativ zum Data-Ordner sein, nicht höher (nicht C:\Programme\...). Du kannst NIBlE's "Strip Texture paths"-Funktion nutzen um dies zu umgehen.
* Verändere nicht den Besitzer eines Items im CS. Falls du einen Besitzer ändern musst, mache das Item persistent und verändere ihn per Script. Das verhindert einen Bug, bei dem Gegenstände nicht korrekt entfernt werden. Ignoriere dies, wenn du viele Besitzer von Gegenständen ändern musst - der Frame-Verlust, der dadurch entstehen würde ist es nicht wert.

== Tipps ==

* Packe Mods so, dass sie direkt ohne Unterordner in den Data-Ordner entzippt werden können.
* Die README sollte ModName-README.txt genannt werden, um keine bestehenden READMEs zu überschreiben.
* .7z (7-zip) ist das gängigste Format zum Packen von Mods.

== Vermeide gewöhnliche IDs zu nutzen ==

Obwohl dies in Oblivion weniger ein Problem ist als in Morrowind, sollte es erwähnt werden.

Erstelle keine Objekte oder Variablen mit gewöhnlichen Namen wie "GEHEIMEREINGANG". Benutze ein einzigartiges Prä- oder Suffix um deine IDs zu kennzeichnen, wie zum Beispiel: "IchininGEHEIMEREINGANG".

Dies wird deine Mod nicht so schnell mit anderen Mods in Konflikt kommen lassen.

== Verschwindende Landschaft in Tamriel ==

Dieses Problem ist auch unter den Häufigen Fehlern gelistet, weil es entstehen kann, wenn der aktuelle Modindex sich vom Modindex während der Erstellung des Plugins unterscheidet. Es tritt in diesem Fall auf, wenn du mit einer Master-Datei eine andere Master(wie die Oblivion.esm) veränderst.

Die einfachste Lösung?. Nutze niemals eine Master-Datei um eine andere Master-Datei zu verändern. Die Lösung ist in einem alten Tutorial zur [http://www.bethsoft.com/bgsforums/index.php?showtopic=603415 Erstellung sauberer Mater-Dateien] näher erläutert.

Glücklicherweise lässt sich das nun einfach erledigen, indem man mit TES4Gecko ein Plugin in seine esm- und esp-Komponenten aufteilt.

== Spieleinstellungen ==

Einstellungen sind nicht wie die [[ob:Variablen|globalen Variablen]]. Falls du

<tesscript>set SomeVar to fiSomeGameSetting</tesscript>

benutzt, wird dein Script gespeichert, aber nicht im Spiel ausgeführt. Du musst die [[ob:GameSetting|GameSetting-Funktion]] nutzen:

<tesscript>set SomeVar to (GetGameSetting fiSomeGameSetting)</tesscript>

== Häufige MessageBox-Fehler ==

# Das Script muss jeden Frame ausgeführt werden um das Klicken des Buttons mitzubekommen. Für [[ob:persistent|persistente]] Objekte([[ob:Activator|Activator]], [[ob:Container|Container]], etc.) bedeutet das, dass sie erst in den Speicher geladen werden müssen(z.B. in die selbe Zelle wie der Spieler). Für Quests heißt das, dass [[ob:fQuestDelayTime|fQuestDelayTime]] auf einen niedrigen Wert, wie .001 gesetzt werden muss. Für alle gültigt ist, dass der Code in einen Block gesetzt wird, der jeden Frame ausgeführt wird (z.B. [[ob:GameMode|GameMode]], [[ob:MenuMode|MenuMode]])
# Falls mehrere Menüs dargestellt werden sollen, wird eine Variable benötigt, die angibt in welchem Menü der Spieler sich grade befindent. Mache zum Beispiel eine short MenuShowing-Variable und setze den Wert auf 1 für das erste Menü, 2 für das zweite Menü und so weiter.
# Falls irgendwelcher Code nach dem Button-Teil (also nach if (Button > -1)) jeden Frame ausgeführt werden muss, musst du deinen Code so gestalten, dass die Button-Variable jeden Frame gesetzt wird:

<tesscript>...
if (MenuShowing == -1)
MessageBox ...
set MenuShowing to 1
elseif (MenuShowing == 1)
set Button to GetButtonPressed
if (Button > -1)
if (Button == 0)
...</tesscript>

dann musst du es so ändern, dass der Button nach dem Anzeigen des Menüs zurückgesetzt wird:

<tesscript>...
if (MenuShowing == -1)
MessageBox ...
set MenuShowing to 1
set Button to GetButtonPressed
elseif (MenuShowing == 1)
if (Button == -1)
set Button to GetButtonPressed
return
elseif (Button == 0)
...</tesscript>

# Falls du einen gescripteten Magie-Effekt für deine MessageBox verwendest stelle sicher, dass er (mindestens) einige Sekunden anhält. Es wird allerdings dringend empfohlen eine andere Methode zu nutzen. Du kannst den Effekt mit einer Quest starten lassen, oder mittels eines [[ob:Activator|Activators]], oder füge dem Spieler einfach ein Token hinzu und lasse die Messagebox darüber laufen.

[[Kategorie:Tutorials|Häufige Fehler]]

← Nächstältere Version		Version vom 8. März 2009, 15:44 Uhr
Zeile 179:		Zeile 179:


−	[[Kategorie:~~Tutorials~~\|Häufige Fehler]]	+	[[Kategorie:Scripterstellung\|Häufige Fehler]]
		+	[[Kategorie:Modding-Grundlagen\|Häufige Fehler]]
		+	[[Kategorie:Mod-Editor\|Häufige Fehler]]

@@ Zeile 56: / Zeile 56: @@
 ''(deutsche Übersetzung: ... vermeide [[ob:PlaceAtMe|PlaceAtMe]] , um Kopien eines Objektes zu erstellen, wenn du auch [[ob:MoveTo|MoveTo]] verwenden könntest)''
-Die [[ob:PlaceAtMe|PlaceAtMe-Seite]] enthält zwar Hinweise und die [constwiki:Talk:PlaceAtMe|Diskussions-Seite] enthält zusätzliche Informationen, allerdings wird es nicht dort erwähnt, wo Modder normalerweise nachsehen (z.B. Tutorials), also bin ich nicht davon überzeugt, dass es so nützlich ist.
+Die [[ob:PlaceAtMe|PlaceAtMe-Seite]] enthält zwar Hinweise und die [[constwiki:Talk:PlaceAtMe|Diskussions-Seite]] enthält zusätzliche Informationen, allerdings wird es nicht dort erwähnt, wo Modder normalerweise nachsehen (z.B. Tutorials), also bin ich nicht davon überzeugt, dass es so nützlich ist.
 Viele Mods verwenden trotz allem noch immer die veraltete Methode und platzieren unsichtbare Activators nahe dem Spieler, obwohl [[ob:MoveTo|MoveTo]] ebenso funktionieren würde.

@@ Zeile 52: / Zeile 52: @@
 Leider entfernt [[ob:disable|disable]] nicht den Eintrag im Savegame. Dieses Problem wird zwar angesprochen, allerdings ist die Warnung sehr schwach ausgefallen:
-<code>avoid using [[ob:PlaceAtMe|PlaceAtMe]] to create new copies of an object when you could simply use [[ob:MoveTo|MoveTo]] on an existing object.</code>
+ avoid using [[ob:PlaceAtMe|PlaceAtMe]] to create new copies of an object
 ''(deutsche Übersetzung: ... vermeide [[ob:PlaceAtMe|PlaceAtMe]] , um Kopien eines Objektes zu erstellen, wenn du auch [[ob:MoveTo|MoveTo]] verwenden könntest)''
@@ Zeile 63: / Zeile 64: @@
 Es wird deswegen dringend ein gutes Tutorial diesbezüglich benötigt!
-Eines der Hauptprobleme mit [[ob:MoveTo|MoveTo]] ist, dass die Collision nicht immer mit bewegt wird. [[ob:Disable|Disable]] nach [[ob:MoveTo|MoveTo]] zu verwenden und dann [[ob:Enable|Enable]]einen Frame später, könnte dieses Problem lösen.
+Eines der Hauptprobleme mit [[ob:MoveTo|MoveTo]] ist, dass die Collision nicht immer mit bewegt wird. [[ob:Disable|Disable]] nach [[ob:MoveTo|MoveTo]] zu verwenden und dann [[ob:Enable|Enable]] einen Frame später, könnte dieses Problem lösen.
 Das Überfüllen des Savegames durch [[ob:PlaceAtMe|PlaceAtMe]] ist zwar vielleicht nicht so schwerwiegend wie einige andere Fehler, aber eine einzige Mod, die diese veraltete Methode nutzt, kann einem Savegame schnell mehrere Megabyte hinzufügen. Wenn es nun mehr als nur eine Mod sind, wächst das Savegame doch recht gut an.

@@ Zeile 49: / Zeile 49: @@
 === Vermeiden von PlaceAtMe ===
-Frühe Versionen des bekannten Tutorials [[constwiki:Casting_Spells_From_An_Activator|Casting Spells From An Activator]] benutzten PlaceAtMe sehr häufig, was einen großen Fehler darstellte, da die Script-Beispiele viel Müll im Savegame hinterließen. Als das Tutorial geschrieben wurde, ging man noch davon aus, dass PlaceAtMe ordnungsgemäß funktionieren würde. Mittlerweile wurde es aktualisiert und nutzt nun [[ob:MoveTo|MoveTo]], allerdings wurden dennoch sehr viele Mods mit PlaceAtMe erstellt.
+Frühe Versionen des bekannten Tutorials [[constwiki:Casting_Spells_From_An_Activator|Casting Spells From An Activator]] benutzten [[ob:PlaceAtMe|PlaceAtMe]] sehr häufig, was einen großen Fehler darstellte, da die Script-Beispiele viel Müll im Savegame hinterließen. Als das Tutorial geschrieben wurde, ging man noch davon aus, dass [[ob:PlaceAtMe|PlaceAtMe]] ordnungsgemäß funktionieren würde. Mittlerweile wurde es aktualisiert und nutzt nun [[ob:MoveTo|MoveTo]], allerdings wurden dennoch sehr viele Mods mit [[ob:PlaceAtMe|PlaceAtMe]] erstellt.
 Leider entfernt [[ob:disable|disable]] nicht den Eintrag im Savegame. Dieses Problem wird zwar angesprochen, allerdings ist die Warnung sehr schwach ausgefallen:
-        ... avoid using PlaceAtMe to create new copies of an object when you could simply use MoveTo on an existing object.
+<code>avoid using [[ob:PlaceAtMe|PlaceAtMe]] to create new copies of an object when you could simply use [[ob:MoveTo|MoveTo]] on an existing object.</code>
-''(deutsche Übersetzung: ... vermeide PlaceAtMe um Kopien eines Objektes zu erstellen, wenn du auch MoveTo verwenden könntest)''
+''(deutsche Übersetzung: ... vermeide [[ob:PlaceAtMe|PlaceAtMe]] , um Kopien eines Objektes zu erstellen, wenn du auch [[ob:MoveTo|MoveTo]] verwenden könntest)''
 Die [[ob:PlaceAtMe|PlaceAtMe-Seite]] enthält zwar Hinweise und die [constwiki:Talk:PlaceAtMe|Diskussions-Seite] enthält zusätzliche Informationen, allerdings wird es nicht dort erwähnt, wo Modder normalerweise nachsehen (z.B. Tutorials), also bin ich nicht davon überzeugt, dass es so nützlich ist.
-Viele Mods verwenden trotz allem noch immer die veraltete Methode und platzieren unsichtbare Activators nahe dem Spieler, obwohl MoveTo ebenso funktionieren würde.
+Viele Mods verwenden trotz allem noch immer die veraltete Methode und platzieren unsichtbare Activators nahe dem Spieler, obwohl [[ob:MoveTo|MoveTo]] ebenso funktionieren würde.
-Der Grund, warum das Thema nicht so weit verbreitet ist, ist vielleicht die Tatsache, dass sich MoveTo nicht so einfach verwenden lässt wie PlaceAtMe. Es wird zwar auf der Diskussions-Seite behandelt, dort ist es aber nicht sehr ausführlich beschrieben.
+Der Grund, warum das Thema nicht so weit verbreitet ist, ist vielleicht die Tatsache, dass sich [[ob:MoveTo|MoveTo]] nicht so einfach verwenden lässt wie [[ob:PlaceAtMe|PlaceAtMe]]. Es wird zwar auf der Diskussions-Seite behandelt, dort ist es aber nicht sehr ausführlich beschrieben.
 Es wird deswegen dringend ein gutes Tutorial diesbezüglich benötigt!
-Eines der Hauptprobleme mit MoveTo ist, dass die Collision nicht immer mit bewegt wird. Disable nach MoveTo zu verwenden und dann enable einen Frame später, könnte dieses Problem lösen.
+Eines der Hauptprobleme mit [[ob:MoveTo|MoveTo]] ist, dass die Collision nicht immer mit bewegt wird. [[ob:Disable|Disable]] nach [[ob:MoveTo|MoveTo]] zu verwenden und dann [[ob:Enable|Enable]]einen Frame später, könnte dieses Problem lösen.
 === Vermeiden von DuplicateAllItems auf einem Begleiter ===

@@ Zeile 150: / Zeile 150: @@
 # Das Script muss jeden Frame ausgeführt werden, um das Klicken des Buttons mitzubekommen. Für [[ob:persistent|persistente]] Objekte ([[ob:Activator|Activator]], [[ob:Container|Container]] etc.) bedeutet das, dass sie erst in den Speicher geladen werden müssen (z.B. in die selbe Zelle wie der Spieler). Für Quests heißt das, dass [[ob:fQuestDelayTime|fQuestDelayTime]] auf einen niedrigen Wert, wie .001 gesetzt werden muss. Für alle gültig ist, dass der Code in einen Block gesetzt wird, der jeden Frame ausgeführt wird (z.B. [[ob:GameMode|GameMode]], [[ob:MenuMode|MenuMode]])
 # Falls mehrere Menüs dargestellt werden sollen, wird eine Variable benötigt, die angibt in welchem Menü der Spieler sich grade befindet. Mache zum Beispiel eine short MenuShowing-Variable und setze den Wert auf 1 für das erste Menü, 2 für das zweite Menü und so weiter.
 # Falls irgendwelcher Code nach dem Button-Teil (also nach if (Button > -1)) jeden Frame ausgeführt werden muss, musst du deinen Code so gestalten, dass die Button-Variable jeden Frame gesetzt wird:
@@ Zeile 175: / Zeile 176: @@
    elseif (Button == 0)
 ...</tesscript>
 [[Kategorie:Tutorials|Häufige Fehler]]

@@ Zeile 1: / Zeile 1: @@
 == Einleitung ==
-All diese Sachen sollten von einem Modder vermieden werden.
+All diese Sachen sollten von einem Modder vermieden werden:
 == AddTopic-Problem ==
@@ Zeile 9: / Zeile 9: @@
 Motub hat eine ausführliche [[constwiki:Fixing_the_AddTopic_Bug|Anleitung zur Lösung des AddTopic-Problems]] geschrieben.
-Außerdem sollte es vermieden werden, ein Topic durch ein Script und zusätzlich über die AddTopic-Box hinzuzufügen. Das kann dazu führen, dass NPCs plötzlich aus großer Entfernung, durch Objekte, etc. mit dem Spieler reden, als wenn sie zum Beispiel mit [[ob:StartConversation|StartConversation]] dazu gebracht worden wären.
+Außerdem sollte es vermieden werden, ein Topic durch ein Script und zusätzlich über die AddTopic-Box hinzuzufügen. Das kann dazu führen, dass NPCs plötzlich aus großer Entfernung, durch Objekte etc. mit dem Spieler reden, als wenn sie zum Beispiel mit [[ob:StartConversation|StartConversation]] dazu gebracht worden wären.
 Das AddTopic aus dem Script des NPCs zu entfernen und in die Result-Box einzufügen, wird den Fehler verhindern.
@@ Zeile 21: / Zeile 21: @@
 Dieses Problem ist am besten beschrieben in Wryes Thread [http://www.elderscrolls.com/forums/index.php?showtopic=625194 Overriding Scripts and CTDs] basierend auf einer Diskussion von MentalElf mit dem Titel ''In desparate need of a save game editor''. Trotzdem ist ein kurzer Überblick an dieser Stelle wohl sinnvoll.
-Das Problem beim Ändern von Script-Variablen ist nicht, welche Mod dabei in bestimmten Konfigurationen gewinnt, sondern dass sich dies mit der Zeit ändern kann. Mann stelle sich vor, jemand nutzt eine BaseModA.esm, welche MyScript mit den Variablen VarA, VarB und VarC definiert.Diese Variablen bekommen die Indexe 1, 2 und 3. Das Savegame wird nur folgende Information enthalten:
+Das Problem beim Ändern von Script-[[ob:variablen|Variablen]] ist nicht, welche Mod dabei in bestimmten Konfigurationen gewinnt, sondern dass sich dies mit der Zeit ändern kann. Mann stelle sich vor, jemand nutzt eine BaseModA.esm, welche MyScript mit den Variablen VarA, VarB und VarC definiert.Diese Variablen bekommen die Indexe 1, 2 und 3. Das Savegame wird nur folgende Information enthalten:
 <tesscript>  script FormID = xxxxxx
@@ Zeile 30: / Zeile 30: @@
 Mit anderen Worten: Nur die Position der Variable wird gespeichert.
-Wenn der Spieler also nun nach einiger Zeit entscheidet die AddOnB.esp hinzuzufügen und diese kleine Änderungen an MyScript vornimmt, hat es zwar immer noch die Variablen VarA, VarB, and VarC, aber sie haben nun die Indexe 3, 2, 1. Wenn das Savegame also nun geladen wird, erkennt es, dass sich die FormID des Scripts nicht geändert hat und lädt also 1 für VarC, 2 für VarB, und 3 für VarA. Je nach Bedeutung der Variablen können un ernsthafte Probleme auftreten.
+Wenn der Spieler also nun nach einiger Zeit entscheidet die AddOnB.esp hinzuzufügen und diese kleine Änderungen an MyScript vornimmt, hat es zwar immer noch die Variablen VarA, VarB und VarC, aber sie haben nun die Indexe 3, 2, 1. Wenn das Savegame also nun geladen wird, erkennt es, dass sich die FormID des Scripts nicht geändert hat und lädt also 1 für VarC, 2 für VarB, und 3 für VarA. Je nach Bedeutung der Variablen können nun ernsthafte Probleme auftreten.
 Schlimmer wird es noch, wenn VarA eine ref-Variable und VarC eine float-Variable ist. Du hast also nun das Binäre der float-Variable in der ref-Variable und den Inhalt der ref-Variable in der float-Variable. Absolutes Chaos!
-Der einzige Weg das zu ändern, ist das Savegame ohne jegliche Mods zu laden, die etwas an dieser FormID ändern, zu speichern, die Dateien in korrekter Reihenfolge hinzuzufügen, und neu zu starten. Leider funktioniert dies nicht für Scripts aus der originalen Oblivion.esm.
+Der einzige Weg, das zu ändern, ist das Savegame ohne jegliche Mods zu laden, die etwas an dieser FormID ändern, zu speichern, die Dateien in korrekter Reihenfolge hinzuzufügen und neu zu starten. Leider funktioniert dies nicht für Scripts aus der originalen Oblivion.esm.
 Obwohl dies ein schwerwiegender Fehler ist, der einige CTDs verursachen kann, scheinen viele Leute nicht darüber informiert zu sein.
@@ Zeile 44: / Zeile 44: @@
 Ein großer Faktor dafür ist die [[ob:PlaceAtMe|PlaceAtMe-Funktion]]. Neue Objekte, die mit [[ob:PlaceAtMe|PlaceAtMe]] erschaffen wurden, verschwinden nie. Dieses Problem tritt auf, wenn unsichtbare [[ob:Activator|Activators]] zum Beispiel Zauber auf den Spieler werfen - das Resultat sind unzählige ungenutzte [[ob:Activator|Activators]], die dennoch weiterhin im Savgame gespeichert bleiben.
-Auch Gegenstände im Inventar können zu Problemen werden, zum Beispiel durch den Bug der negativen Gegenstandsanzahl(siehe unten).
+Auch Gegenstände im Inventar können zu Problemen werden, zum Beispiel durch den Bug der negativen Gegenstandsanzahl (siehe unten).
 === Vermeiden von PlaceAtMe ===
-Frühe Versionen des bekannten Tutorials [[constwiki:Casting_Spells_From_An_Activator|Casting Spells From An Activator]] benutzten PlaceAtMe sehr häufig, was einen großen Fehler darstellte, da die Script-Beispiele viel Müll im Savegame hinterließen. Als das Tutorial geschrieben wurde, ging man noch davon aus, dass PlaceAtMe ordnungsgemäß funktionieren würde.Mittlerweile wurde es aktualisiert und nutzt nun [[ob:MoveTo|MoveTo]], allerdings wurden dennoch sehr viele Mods mit PlaceAtMe erstellt.
+Frühe Versionen des bekannten Tutorials [[constwiki:Casting_Spells_From_An_Activator|Casting Spells From An Activator]] benutzten PlaceAtMe sehr häufig, was einen großen Fehler darstellte, da die Script-Beispiele viel Müll im Savegame hinterließen. Als das Tutorial geschrieben wurde, ging man noch davon aus, dass PlaceAtMe ordnungsgemäß funktionieren würde. Mittlerweile wurde es aktualisiert und nutzt nun [[ob:MoveTo|MoveTo]], allerdings wurden dennoch sehr viele Mods mit PlaceAtMe erstellt.
 Leider entfernt [[ob:disable|disable]] nicht den Eintrag im Savegame. Dieses Problem wird zwar angesprochen, allerdings ist die Warnung sehr schwach ausgefallen:
@@ Zeile 55: / Zeile 55: @@
 ''(deutsche Übersetzung: ... vermeide PlaceAtMe um Kopien eines Objektes zu erstellen, wenn du auch MoveTo verwenden könntest)''
-Die [[ob:PlaceAtMe|PlaceAtMe-Seite]] enthält zwar Hinweise und die [constwiki:Talk:PlaceAtMe|Diskussions-Seite] enthält zusätzliche Informationen, allerdings wird es nicht dort erwähnt, wo Modder normalerweise nachsehen(z.B. Tutorials), also bin ich nicht davon überzeugt, dass es so nützlich ist.
+Die [[ob:PlaceAtMe|PlaceAtMe-Seite]] enthält zwar Hinweise und die [constwiki:Talk:PlaceAtMe|Diskussions-Seite] enthält zusätzliche Informationen, allerdings wird es nicht dort erwähnt, wo Modder normalerweise nachsehen (z.B. Tutorials), also bin ich nicht davon überzeugt, dass es so nützlich ist.
 Viele Mods verwenden trotz allem noch immer die veraltete Methode und platzieren unsichtbare Activators nahe dem Spieler, obwohl MoveTo ebenso funktionieren würde.
@@ Zeile 70: / Zeile 70: @@
 === Vermeiden von DuplicateAllItems auf einem Begleiter ===
-[[ob:DuplicateAllItems|DuplicateAllItems]] scheint für das Überfüllen der Savegames bei Weitem am schwerwiegendsten verantwortlich zu sein.
+[[ob:DuplicateAllItems|DuplicateAllItems]] scheint für das Überfüllen der Savegames bei Weitem am Schwerwiegendsten verantwortlich zu sein.
-Einige Begleiter-Mods haben die Savegames unglaublich vergrößert, indem häufig [[ob:DuplicateAllItems|DuplicateAllItems]] verwendet wurde. Das gewöhnlichste Beispiel ist eine Mod, die [[ob:DuplicateAllItems|DuplicateAllItems]] verwendet (um sie auf ein Duplikat des [[ob:NPC|NPCs]] zu duplizieren) um die Belastung zu berechnen und anzuzeigen. Falls einige der Gegenstände des NPCs gescriptete Objekte sind, werden sie permament dupliziert (und unmöglich zu entfernen) jedes Mal, wenn das DuplicateAllItems ausgeführt wird. Da dies jeden Frame geschieht, so lange das Inventar des Begleiters geöffnet ist, wird das Savegame ziemlich schnell überfüllt(dutzende Megabyte in wenigen Sekunden).
+Einige Begleiter-Mods haben die Savegames unglaublich vergrößert, indem häufig [[ob:DuplicateAllItems|DuplicateAllItems]] verwendet wurde. Das gewöhnlichste Beispiel ist eine Mod, die [[ob:DuplicateAllItems|DuplicateAllItems]] verwendet, (um sie auf ein Duplikat des [[ob:NPC|NPCs]] zu duplizieren) um die Belastung zu berechnen und anzuzeigen. Falls einige der Gegenstände des NPCs gescriptete Objekte sind, werden sie permanent dupliziert (und unmöglich zu entfernen), jedes Mal, wenn das DuplicateAllItems ausgeführt wird. Da dies jeden Frame geschieht, so lange das Inventar des Begleiters geöffnet ist, wird das Savegame ziemlich schnell überfüllt (dutzende Megabyte in wenigen Sekunden).
 Statt die Items zu duplizieren, kann besser [[ob:RemoveAllItems|RemoveAllItems]] verwendet werden, um die Gegenstände auf den Begleitern zu übertragen und danach wieder zurück. Das behebt zwar den ursprünglichen Fehler (gescriptete Objekte überfüllen das Savegame nicht mehr), aber führt zum Fehler der negativen Gegenstandsanzahl(siehe unten) .
@@ Zeile 104: / Zeile 104: @@
 * Aktiviere niemals "Generate All" für [[ob:Pathgrids|Pathgrids]] oder "Generate Entire World"
 * Versuche niemals Items einer ESP in eine andere ESP zu kopieren, wenn sie nicht aus der Oblivion.esm stammen
-* Verändere keine Zellen der Oblivion.esm mit einer anderen Master-Datei.
+* Verändere keine [[ob:cell|Zellen]] der Oblivion.esm mit einer anderen Master-Datei.
-* Verändere Zellen nicht aus Versehen. Zellen, die nicht direkt von deiner Mod verändert werden, haben auch kein Sternchen (benutze [http://www.elderscrolls.com/forums/index.php?showtopic=619318 TES4Gecko] um deine Mod vor dem Release zu säubern)
+* Verändere Zellen nicht aus Versehen. Zellen, die nicht direkt von deiner Mod verändert werden, haben auch kein Sternchen (benutze [http://www.elderscrolls.com/forums/index.php?showtopic=619318 TES4Gecko], um deine Mod vor dem Release zu säubern). Besser wäre aber Tes4Edit (Tes4View) (TES4Gecko hat hier Fehler!).
-* Benutze keine Unterstriche in primären Ressourcen-Dateinamen. Unterstriche sind vom Spiel genutzt, um diverse Dateitypen, wie Normal Maps (xxx_n.dds), Glow Maps (xxx_g.dds), etc. zu finden.
+* Benutze keine Unterstriche in primären Ressourcen-Dateinamen. Unterstriche sind vom Spiel genutzt, um diverse Dateitypen, wie Normal Maps (xxx_n.dds), Glow Maps (xxx_g.dds) etc. zu finden.
 * Benutze keine vollständigen Pfade für Retexturierungen. Texturpfade müssen relativ zum Data-Ordner sein, nicht höher (nicht C:\Programme\...). Du kannst NIBlE's "Strip Texture paths"-Funktion nutzen, um dies zu umgehen.
 * Verändere nicht den Besitzer eines Items im CS. Falls du einen Besitzer ändern musst, mache das Item persistent und verändere ihn per Script. Das verhindert einen Bug, bei dem Gegenstände nicht korrekt entfernt werden. Ignoriere dies, wenn du viele Besitzer von Gegenständen ändern musst - der Frame-Verlust, der dadurch entstehen würde, ist es nicht wert.
@@ Zeile 129: / Zeile 129: @@
 == Verschwindende Landschaft in Tamriel ==
-Dieses Problem ist auch unter den Häufigen Fehlern gelistet, weil es entstehen kann, wenn der aktuelle Modindex sich vom Modindex während der Erstellung des Plugins unterscheidet. Es tritt in diesem Fall auf, wenn du mit einer Master-Datei eine andere Master(wie die Oblivion.esm) veränderst.
+Dieses Problem ist auch unter den Häufigen Fehlern gelistet, weil es entstehen kann, wenn der aktuelle Modindex sich vom Modindex während der Erstellung des Plugins unterscheidet. Es tritt in diesem Fall auf, wenn du mit einer Master-Datei einen anderen Master (wie die Oblivion.esm) veränderst.
 Die einfachste Lösung?. Nutze niemals eine Master-Datei, um eine andere Master-Datei zu verändern. Die Lösung ist in einem alten Tutorial zur [http://www.bethsoft.com/bgsforums/index.php?showtopic=603415 Erstellung sauberer Mater-Dateien] näher erläutert.
@@ Zeile 148: / Zeile 148: @@
 == Häufige MessageBox-Fehler ==
-# Das Script muss jeden Frame ausgeführt werden um das Klicken des Buttons mitzubekommen. Für [[ob:persistent|persistente]] Objekte([[ob:Activator|Activator]], [[ob:Container|Container]], etc.) bedeutet das, dass sie erst in den Speicher geladen werden müssen (z.B. in die selbe Zelle wie der Spieler). Für Quests heißt das, dass [[ob:fQuestDelayTime|fQuestDelayTime]] auf einen niedrigen Wert, wie .001 gesetzt werden muss. Für alle gültig ist, dass der Code in einen Block gesetzt wird, der jeden Frame ausgeführt wird (z.B. [[ob:GameMode|GameMode]], [[ob:MenuMode|MenuMode]])
+# Das Script muss jeden Frame ausgeführt werden, um das Klicken des Buttons mitzubekommen. Für [[ob:persistent|persistente]] Objekte ([[ob:Activator|Activator]], [[ob:Container|Container]] etc.) bedeutet das, dass sie erst in den Speicher geladen werden müssen (z.B. in die selbe Zelle wie der Spieler). Für Quests heißt das, dass [[ob:fQuestDelayTime|fQuestDelayTime]] auf einen niedrigen Wert, wie .001 gesetzt werden muss. Für alle gültig ist, dass der Code in einen Block gesetzt wird, der jeden Frame ausgeführt wird (z.B. [[ob:GameMode|GameMode]], [[ob:MenuMode|MenuMode]])
-# Falls mehrere Menüs dargestellt werden sollen, wird eine Variable benötigt, die angibt in welchem Menü der Spieler sich grade befindent. Mache zum Beispiel eine short MenuShowing-Variable und setze den Wert auf 1 für das erste Menü, 2 für das zweite Menü und so weiter.
+# Falls mehrere Menüs dargestellt werden sollen, wird eine Variable benötigt, die angibt in welchem Menü der Spieler sich grade befindet. Mache zum Beispiel eine short MenuShowing-Variable und setze den Wert auf 1 für das erste Menü, 2 für das zweite Menü und so weiter.
 # Falls irgendwelcher Code nach dem Button-Teil (also nach if (Button > -1)) jeden Frame ausgeführt werden muss, musst du deinen Code so gestalten, dass die Button-Variable jeden Frame gesetzt wird:
@@ Zeile 176: / Zeile 176: @@
 ...</tesscript>
-# Falls du einen gescripteten Magie-Effekt für deine MessageBox verwendest stelle sicher, dass er (mindestens) einige Sekunden anhält. Es wird allerdings dringend empfohlen eine andere Methode zu nutzen. Du kannst den Effekt mit einer Quest starten lassen, oder mittels eines [[ob:Activator|Activators]], oder füge dem Spieler einfach ein Token hinzu und lasse die Messagebox darüber laufen.
+# Falls du einen gescripteten Magie-Effekt für deine MessageBox verwendest, stelle sicher, dass er (mindestens) einige Sekunden anhält. Es wird allerdings dringend empfohlen, eine andere Methode zu nutzen. Du kannst den Effekt mit einer Quest starten lassen oder mittels eines [[ob:Activator|Activators]] oder füge dem Spieler einfach ein Token hinzu und lasse die Messagebox darüber laufen.

@@ Zeile 142: / Zeile 142: @@
 <tesscript>set SomeVar to fiSomeGameSetting</tesscript>
-benutzt, wird dein Script gespeichert, aber nicht im Spiel ausgeführt. Du musst die [[ob:GameSetting|GameSetting-Funktion]] nutzen:
+benutzt, wird dein Script gespeichert, aber nicht im Spiel ausgeführt. Du musst die Funktion [[ob:GetGameSetting|GetGameSetting ]] nutzen:
 <tesscript>set SomeVar to (GetGameSetting fiSomeGameSetting)</tesscript>
 == Häufige MessageBox-Fehler ==

@@ Zeile 6: / Zeile 6: @@
 Obwohl er eigentlich recht bekannt und gut dokumentiert ist, ist der "AddTopic-Bug" ein sehr häufiger Fehler bei Moddern.
-Wenn zwei oder mehr Mods versuchen dasselbe [[ob:Topic|Topic]] zu verändern, wird nur das Topic des zuletzt geladenen geändert. Das kann zu schwerwiegenden Problemen führen, da das [[ob:Greeting|GREETING]] von mehreren [[ob:NPC|NPCs]] verwendet wird. Das Problem tritt auch auf, wenn unerwünschte [[ob:Greeting|GREETING]]-Dialoge von einem NPC entfernt wurden.
+Wenn zwei oder mehr Mods versuchen, das selbe [[ob:Topic|Topic]] zu verändern, wird nur das Topic des zuletzt geladenen geändert. Das kann zu schwerwiegenden Problemen führen, da das [[ob:Greeting|GREETING]] von mehreren [[ob:NPC|NPCs]] verwendet wird. Das Problem tritt auch auf, wenn unerwünschte [[ob:Greeting|GREETING]]-Dialoge von einem NPC entfernt wurden.
 Motub hat eine ausführliche [[constwiki:Fixing_the_AddTopic_Bug|Anleitung zur Lösung des AddTopic-Problems]] geschrieben.
-Außerdem sollte es vermieden werden ein Topic durch ein Script und zusätzlich über die AddTopic-Box hinzuzufügen. Das kann dazu führen, dass NPCs plötzlich aus großer Entfernung, durch Objekte, etc. mit dem Spieler reden, als wenn sie zum Beispiel mit [[ob:StartConversation|StartConversation]] dazu gebracht worden wären.
+Außerdem sollte es vermieden werden, ein Topic durch ein Script und zusätzlich über die AddTopic-Box hinzuzufügen. Das kann dazu führen, dass NPCs plötzlich aus großer Entfernung, durch Objekte, etc. mit dem Spieler reden, als wenn sie zum Beispiel mit [[ob:StartConversation|StartConversation]] dazu gebracht worden wären.
 Das AddTopic aus dem Script des NPCs zu entfernen und in die Result-Box einzufügen, wird den Fehler verhindern.
 == Türen ==
 Vanilla-Türen sollten nicht bewegt werden, da ihre Position im Savegame gespeichert wird, sobald der Spieler in ihre Nähe kommt. Modder sollten es deshalb vermeiden die originalen Türen zu verschieben.
 == Ändern von Script-Variablen ==
@@ Zeile 32: / Zeile 34: @@
 Schlimmer wird es noch, wenn VarA eine ref-Variable und VarC eine float-Variable ist. Du hast also nun das Binäre der float-Variable in der ref-Variable und den Inhalt der ref-Variable in der float-Variable. Absolutes Chaos!
-Der einzige Weg das zu ändern ist, das Savegame ohne jegliche Mods zu laden, die etwas an dieser FormID ändern, zu speichern, die Dateien in korrekter Reihenfolge hinzuzufügen, und neu zu starten. Leider funktioniert dies nicht für Scripts aus der originalen Oblivion.esm.
+Der einzige Weg das zu ändern, ist das Savegame ohne jegliche Mods zu laden, die etwas an dieser FormID ändern, zu speichern, die Dateien in korrekter Reihenfolge hinzuzufügen, und neu zu starten. Leider funktioniert dies nicht für Scripts aus der originalen Oblivion.esm.
 Obwohl dies ein schwerwiegender Fehler ist, der einige CTDs verursachen kann, scheinen viele Leute nicht darüber informiert zu sein.
 == Überfüllen von Savegames ==
@@ Zeile 42: / Zeile 45: @@
 Auch Gegenstände im Inventar können zu Problemen werden, zum Beispiel durch den Bug der negativen Gegenstandsanzahl(siehe unten).
 === Vermeiden von PlaceAtMe ===
@@ Zeile 62: / Zeile 66: @@
 Das Überfüllen des Savegames durch PlaceAtMe ist zwar vielleicht nicht so schwerwiegend wie einige andere Fehler, aber eine einzige Mod, die diese veraltete Methode nutzt, kann einem Savegame schnell mehrere Megabyte hinzufügen. Wenn es nun mehr als nur eine Mod sind, wächst das Savegame doch recht gut an.
 === Vermeiden von DuplicateAllItems auf einem Begleiter ===
@@ Zeile 69: / Zeile 74: @@
 Einige Begleiter-Mods haben die Savegames unglaublich vergrößert, indem häufig [[ob:DuplicateAllItems|DuplicateAllItems]] verwendet wurde. Das gewöhnlichste Beispiel ist eine Mod, die [[ob:DuplicateAllItems|DuplicateAllItems]] verwendet (um sie auf ein Duplikat des [[ob:NPC|NPCs]] zu duplizieren) um die Belastung zu berechnen und anzuzeigen. Falls einige der Gegenstände des NPCs gescriptete Objekte sind, werden sie permament dupliziert (und unmöglich zu entfernen) jedes Mal, wenn das DuplicateAllItems ausgeführt wird. Da dies jeden Frame geschieht, so lange das Inventar des Begleiters geöffnet ist, wird das Savegame ziemlich schnell überfüllt(dutzende Megabyte in wenigen Sekunden).
-Statt die Items zu duplizieren, kann besser [[ob:RemoveAllItems|RemoveAllItems]] verwendet werden, um die Gegenstände auf den Begleitern zu übertragen und danach wieder zurück. Das behebt zwar den ursprünglichen Fehler (gescriptete Objekte überfüllen das Savegame nicht mehr), aber es lässt den Fehler der negativen Gegenstandsanzahl(siehe unten) über.
+Statt die Items zu duplizieren, kann besser [[ob:RemoveAllItems|RemoveAllItems]] verwendet werden, um die Gegenstände auf den Begleitern zu übertragen und danach wieder zurück. Das behebt zwar den ursprünglichen Fehler (gescriptete Objekte überfüllen das Savegame nicht mehr), aber führt zum Fehler der negativen Gegenstandsanzahl(siehe unten) .
 === Vermeiden von RemoveAllItems auf einem Begleiter ===
@@ Zeile 75: / Zeile 81: @@
 Dies kann zwar auch zu Überfüllungen des Savegames führen, es lässt sich aber leichter vermeiden als DuplicateAllItems.
-Das Benutzen von [[ob:RemoveAllItems|RemoveAllItems]] auf einem [[ob:Actor|Actor]] oder [[ob:Container|Container]] mit einer negativen Gegenstandsanzahl bei einem oder mehreren Gegeständen wird diese duplizieren. Eine negative Anzahl bedeutet, dass ein Gegenstand aufgestockt wird, sobald er entfernt wird.
+Das Benutzen von [[ob:RemoveAllItems|RemoveAllItems]] auf einem [[ob:Actor|Actor]] oder [[ob:Container|Container]] mit einer negativen Gegenstandsanzahl bei einem oder mehreren Gegenständen wird diese duplizieren. Eine negative Anzahl bedeutet, dass ein Gegenstand aufgestockt wird, sobald er entfernt wird.
 Dieses Problem lässt sich vermeiden, indem man dem Begleiter keine negativen Gegenstände gibt.
@@ Zeile 89: / Zeile 95: @@
 Beträchtliches Savegame-Wachstum!
 == Vermeide diese Punkte ==
@@ Zeile 98: / Zeile 105: @@
 * Versuche niemals Items einer ESP in eine andere ESP zu kopieren, wenn sie nicht aus der Oblivion.esm stammen
 * Verändere keine Zellen der Oblivion.esm mit einer anderen Master-Datei.
-* Verändere Zellen nicht ausversehen. Zellen die nicht direkt von deiner Mod verändert werden, haben auch kein Sternchen(benutze [http://www.elderscrolls.com/forums/index.php?showtopic=619318 TES4Gecko] um deine Mod vor dem Release zu säubern)
+* Verändere Zellen nicht aus Versehen. Zellen, die nicht direkt von deiner Mod verändert werden, haben auch kein Sternchen (benutze [http://www.elderscrolls.com/forums/index.php?showtopic=619318 TES4Gecko] um deine Mod vor dem Release zu säubern)
-* Benutze keine Unterstriche in primären Ressourcen-Dateinamen. Unterstriche sind vom Spiel genutzt um diverse Dateitypen, wie Normal Maps (xxx_n.dds), Glow Maps (xxx_g.dds), etc. zu finden.
+* Benutze keine Unterstriche in primären Ressourcen-Dateinamen. Unterstriche sind vom Spiel genutzt, um diverse Dateitypen, wie Normal Maps (xxx_n.dds), Glow Maps (xxx_g.dds), etc. zu finden.
-* Benutze keine vollständigen Pfade für Retexturierungen. Texturpfade müssen relativ zum Data-Ordner sein, nicht höher (nicht C:\Programme\...). Du kannst NIBlE's "Strip Texture paths"-Funktion nutzen um dies zu umgehen.
+* Benutze keine vollständigen Pfade für Retexturierungen. Texturpfade müssen relativ zum Data-Ordner sein, nicht höher (nicht C:\Programme\...). Du kannst NIBlE's "Strip Texture paths"-Funktion nutzen, um dies zu umgehen.
-* Verändere nicht den Besitzer eines Items im CS. Falls du einen Besitzer ändern musst, mache das Item persistent und verändere ihn per Script. Das verhindert einen Bug, bei dem Gegenstände nicht korrekt entfernt werden. Ignoriere dies, wenn du viele Besitzer von Gegenständen ändern musst - der Frame-Verlust, der dadurch entstehen würde ist es nicht wert.
+* Verändere nicht den Besitzer eines Items im CS. Falls du einen Besitzer ändern musst, mache das Item persistent und verändere ihn per Script. Das verhindert einen Bug, bei dem Gegenstände nicht korrekt entfernt werden. Ignoriere dies, wenn du viele Besitzer von Gegenständen ändern musst - der Frame-Verlust, der dadurch entstehen würde, ist es nicht wert.
 == Tipps ==
@@ Zeile 108: / Zeile 116: @@
 * Die README sollte ModName-README.txt genannt werden, um keine bestehenden READMEs zu überschreiben.
 * .7z (7-zip) ist das gängigste Format zum Packen von Mods.
 == Vermeide gewöhnliche IDs zu nutzen ==
@@ Zeile 113: / Zeile 122: @@
 Obwohl dies in Oblivion weniger ein Problem ist als in Morrowind, sollte es erwähnt werden.
-Erstelle keine Objekte oder Variablen mit gewöhnlichen Namen wie "GEHEIMEREINGANG". Benutze ein einzigartiges Prä- oder Suffix um deine IDs zu kennzeichnen, wie zum Beispiel: "IchininGEHEIMEREINGANG".
+Erstelle keine Objekte oder Variablen mit gewöhnlichen Namen wie "GEHEIMEREINGANG". Benutze ein einzigartiges Prä- oder Suffix, um deine IDs zu kennzeichnen, wie zum Beispiel: "IchininGEHEIMEREINGANG".
 Dies wird deine Mod nicht so schnell mit anderen Mods in Konflikt kommen lassen.
 == Verschwindende Landschaft in Tamriel ==
@@ Zeile 121: / Zeile 131: @@
 Dieses Problem ist auch unter den Häufigen Fehlern gelistet, weil es entstehen kann, wenn der aktuelle Modindex sich vom Modindex während der Erstellung des Plugins unterscheidet. Es tritt in diesem Fall auf, wenn du mit einer Master-Datei eine andere Master(wie die Oblivion.esm) veränderst.
-Die einfachste Lösung?. Nutze niemals eine Master-Datei um eine andere Master-Datei zu verändern. Die Lösung ist in einem alten Tutorial zur [http://www.bethsoft.com/bgsforums/index.php?showtopic=603415 Erstellung sauberer Mater-Dateien] näher erläutert.
+Die einfachste Lösung?. Nutze niemals eine Master-Datei, um eine andere Master-Datei zu verändern. Die Lösung ist in einem alten Tutorial zur [http://www.bethsoft.com/bgsforums/index.php?showtopic=603415 Erstellung sauberer Mater-Dateien] näher erläutert.
 Glücklicherweise lässt sich das nun einfach erledigen, indem man mit TES4Gecko ein Plugin in seine esm- und esp-Komponenten aufteilt.
 == Spieleinstellungen ==
@@ Zeile 134: / Zeile 145: @@
 <tesscript>set SomeVar to (GetGameSetting fiSomeGameSetting)</tesscript>
 == Häufige MessageBox-Fehler ==
-# Das Script muss jeden Frame ausgeführt werden um das Klicken des Buttons mitzubekommen. Für [[ob:persistent|persistente]] Objekte([[ob:Activator|Activator]], [[ob:Container|Container]], etc.) bedeutet das, dass sie erst in den Speicher geladen werden müssen(z.B. in die selbe Zelle wie der Spieler). Für Quests heißt das, dass [[ob:fQuestDelayTime|fQuestDelayTime]] auf einen niedrigen Wert, wie .001 gesetzt werden muss. Für alle gültigt ist, dass der Code in einen Block gesetzt wird, der jeden Frame ausgeführt wird (z.B. [[ob:GameMode|GameMode]], [[ob:MenuMode|MenuMode]])
+# Das Script muss jeden Frame ausgeführt werden um das Klicken des Buttons mitzubekommen. Für [[ob:persistent|persistente]] Objekte([[ob:Activator|Activator]], [[ob:Container|Container]], etc.) bedeutet das, dass sie erst in den Speicher geladen werden müssen (z.B. in die selbe Zelle wie der Spieler). Für Quests heißt das, dass [[ob:fQuestDelayTime|fQuestDelayTime]] auf einen niedrigen Wert, wie .001 gesetzt werden muss. Für alle gültig ist, dass der Code in einen Block gesetzt wird, der jeden Frame ausgeführt wird (z.B. [[ob:GameMode|GameMode]], [[ob:MenuMode|MenuMode]])
 # Falls mehrere Menüs dargestellt werden sollen, wird eine Variable benötigt, die angibt in welchem Menü der Spieler sich grade befindent. Mache zum Beispiel eine short MenuShowing-Variable und setze den Wert auf 1 für das erste Menü, 2 für das zweite Menü und so weiter.
 # Falls irgendwelcher Code nach dem Button-Teil (also nach if (Button > -1)) jeden Frame ausgeführt werden muss, musst du deinen Code so gestalten, dass die Button-Variable jeden Frame gesetzt wird: