[Bonne6]

Hat für diese Assertion vielleicht jemand eine Lösung oder weiß, woran die liegen kann:

[w] 04:22 Warn: 0 00 23:0050908B (0x008A7618 0x008A757C 0x00000185 0x0135F430) Gothic2.exe, ASSERT_FAIL()+251 byte(s), P:\dev\g2addon\release\ZenGin\_carsten\zWin32.cpp, line 3368+12 byte(s) .... <zError.cpp,#474>
[w] 04:22 Warn: 0 00 23:005FCB4A (0x1E062390 0x00000000 0x0135F954 0x0135F774) Gothic2.exe, zCVertexBufferManager::UnlockOpenVertexBuffers()+282 byte(s), P:\dev\g2addon\release\ZenGin\_dieter\zVertexBuffer.cpp, line 389+184 byte(s) .... <zError.cpp,#474>
[w] 04:22 Warn: 0 00 23:005C9ED1 (0x00000000 0x0135F504 0x0135F514 0x0135F954) Gothic2.exe, zCProgMeshProto::RenderStaticLOD()+161 byte(s), P:\dev\g2addon\release\ZenGin\_dieter\zProgMeshProto.cpp, line 1527 .... <zError.cpp,#474>
[w] 04:22 Warn: 0 00 23:005C9BAF (0x00000000 0x0135F504 0x0135F514 0x00000000) Gothic2.exe, zCProgMeshProto::RenderProgMesh()+1327 byte(s), P:\dev\g2addon\release\ZenGin\_dieter\zProgMeshProto.cpp, line 1405 .... <zError.cpp,#474>
[w] 04:22 Warn: 0 00 23:005C94C4 (0x0135F954 0x0000005B 0x0135F954 0x00000000) Gothic2.exe, zCProgMeshProto::Render()+84 byte(s), P:\dev\g2addon\release\ZenGin\_dieter\zProgMeshProto.cpp, line 1276+22 byte(s) .... <zError.cpp,#474>
[w] 04:22 Warn: 0 00 23:00601A51 (0x00000000 0x1F015568 0x0000003F 0x0000005B) Gothic2.exe, zCVob::Render()+1153 byte(s), P:\dev\g2addon\release\ZenGin\_dieter\zVob.cpp, line 1681+10 byte(s) .... <zError.cpp,#474>
[w] 04:22 Warn: 0 00 23:0077D5DB (0x1D1168E8 0x001C532C 0x12AB11BC 0x00000008) Gothic2.exe, oCVob::Render()+555 byte(s), P:\dev\g2addon\release\Gothic\_ulf\oVob.cpp, line 713 .... <zError.cpp,#474>
[w] 04:22 Warn: 0 00 23:0052DBAF (0x00000001 0x12AB1010 0x15361500 0x00000000) Gothic2.exe, zCBspTree::RenderVobList()+2831 byte(s), P:\dev\g2addon\release\ZenGin\_dieter\zBsp.cpp, line 2342 .... <zError.cpp,#474>
[w] 04:22 Warn: 0 00 23:00530A24 (0x0FF65B50 0x0083C10C 0x002FA3E8 0x00000000) Gothic2.exe, zCBspTree::Render()+2468 byte(s), P:\dev\g2addon\release\ZenGin\_dieter\zBsp.cpp, line 3551 .... <zError.cpp,#474>
[w] 04:22 Warn: 0 00 23:00621835 (0x00000001 0x002FA3E8 0x00000000 0x0135FCA0) Gothic2.exe, zCWorld::Render()+309 byte(s), P:\dev\g2addon\release\ZenGin\_dieter\zWorld.cpp, line 794 .... <zError.cpp,#474>
[w] 04:22 Warn: 0 00 23:006C87EB (0x00400000 0x00252D06 0x0135FEC4 0x7FFDE000) Gothic2.exe, oCGame::Render()+331 byte(s), P:\dev\g2addon\release\Gothic\_ulf\oGame.cpp, line 2658 .... <zError.cpp,#474>
[w] 04:22 Warn: 0 00 23:00425E6E (0x0082F0EC 0x00000006 0x0005020C 0x002FA3E8) Gothic2.exe, CGameManager::Run()+1598 byte(s), P:\dev\g2addon\release\Gothic\_bert\oGameManager.cpp, line 767+47 byte(s) .... <zError.cpp,#474>
[w] 04:22 Warn: 0 00 23:0078188B (0x0000002C 0x005D78E9 0x00000030 0x00000000) Gothic2.exe, MainProg()+75 byte(s), P:\dev\g2addon\release\Gothic\_ulf\Phoenix.cpp, line 111 .... <zError.cpp,#474>
[w] 04:22 Warn: 0 00 23:00503270 (0x00400000 0x00000000 0x00252D06 0x0000000A) Gothic2.exe, HandledWinMain()+928 byte(s), P:\dev\g2addon\release\ZenGin\_carsten\zWin32.cpp, line 1169 .... <zError.cpp,#474>
[w] 04:22 Warn: 0 00 23:00502DFD (0x0135FEC8 0x00000000 0x00252D06 0x0000000A) Gothic2.exe, WinMain()+141 byte(s), P:\dev\g2addon\release\ZenGin\_carsten\zWin32.cpp, line 1054+17 byte(s) .... <zError.cpp,#474>
[w] 04:22 Warn: 0 00 23:007D43F8 (0x00000004 0x0000FFFF 0x000000B8 0x00000000) Gothic2.exe, WinMainCRTStartup()+224 byte(s) .... <zError.cpp,#474>

Die kommt in XR relativ häufig, scheinbar, laut der Tester, oftmals, wenn ein Riesenkeiler getötet wurde. Der hat eine eigene mds und eigenes Modell, ist aber im Grunde nur ein groß skalierter normaler Keiler. Ist ziemlich lästig und lässt sich auch recht häufig reproduzieren.

[mud-freak]

Hat für diese Assertion vielleicht jemand eine Lösung oder weiß, woran die liegen kann:



Die kommt in XR relativ häufig, scheinbar, laut der Tester, oftmals, wenn ein Riesenkeiler getötet wurde. Der hat eine eigene mds und eigenes Modell, ist aber im Grunde nur ein groß skalierter normaler Keiler. Ist ziemlich lästig und lässt sich auch recht häufig reproduzieren.

Also ich habe mal etwas nachgeforscht.
Wird die gescheiterte Assertion denn überhaupt angezeigt? Laut Engine sollte ein Fenster kommen:

Warning! ASSERT(openVBList[0]->IsLocked()) Failed in P:\dev\g2addon\release\ZenGin\_dieter\zVertexBuffer.cpp (line 389)

Aber in ASSERT_FAIL steht:

xor eax, eax
// ...
mov [eax], eax

Was im übertragenen Sinne so ähnlich ist wie

MEM_WriteByte(0, 0); // Schreibe Null an Adresse Null

Was das soll, weiss ich nicht. Sollte auf jeden Fall eine Access Violation verursachen, wodurch die Assertion-Nachricht nicht mal angezeigt wird.


Zur Assertion selbst, also dem gelockten VertexBuffer, kann ich nicht viel sagen. Damit kenne ich mich nicht aus. Die Assertion setzt voraus, dass der VertexBuffer gelockt ist, ist er hier aber nicht. Das ist merkwürdig, denn zCVertexBufferManager::UnlockOpenVertexBuffers wird von zCProgMeshProto::RenderStaticLOD nur aufgerufen, wenn der VertexBuffer gelockt ist. Nicht 100% sicher, aber das sollte etwa so aussehen (Pseudo-Code):


zCProgMeshProto::RenderStaticLOD

int __fastcall zCProgMeshProto::RenderStaticLOD(struct zTRenderContext& arg_1, int arg_2, struct zCProgMeshProto::zTLODRenderArgs* arg_3, class zCRenderLightContainer* arg_4) {
    // ...
    if (arg_1->???->IsLocked())
        zvertexBufferMan.UnlockOpenVertexBuffers();
    // ...
}

zCVertexBufferManager::UnlockOpenVertexBuffers

void __thiscall zCVertexBufferManager::UnlockOpenVertexBuffers() {
    // ...
    if (!this->???->IsLocked())
         ASSERT_FAIL(...);
    // ...
}

Vielleicht weiss da jemand Bescheid, was es mit dem VertexBuffer auf sich hat (ich weiss nicht was das ist), was das für den Keiler usw. bedeutet und was genau das Problem verursacht. Falls nicht, könntest du notfalls die Assertion überschreiben und die Funktion einfach returnen lassen. Ich bin mir nicht sicher, aber das müsste notfalls funktionieren.

Falls du es schaffst, dass Problem verlässlich zu reproduzieren, könntest du die genannten Enginefunktionen hooken, um heraus zu finden, mit welchem Model das Problem zusammenhängt (ob es wirklich die Keiler sind) und dir die Vertexbuffer-Liste mal anschauen.




EDIT: Ich habe gerade erst gesehen, dass auf der vorherigen Seite dieses Threads schon einiges dazu gesagt wurde (verwandtes Problem auch mit dem VertexBuffer). Konntest du das Problem, das du dort hattest beheben?
Gottfried schlägt dort auch vor es einmal mit einzelnen LeGo Paketen zu probieren. Dazu müsstest du es natürlich erst einmal verlässlich reproduzieren können. Wäre natürlich nützlich zu wissen, ob es auf LeGo zurück zu führen ist.

[Bonne6]

Also ich habe mal etwas nachgeforscht.
Wird die gescheiterte Assertion denn überhaupt angezeigt? Laut Engine sollte ein Fenster kommen:

Warning! ASSERT(openVBList[0]->IsLocked()) Failed in P:\dev\g2addon\release\ZenGin\_dieter\zVertexBuffer.cpp (line 389)

Aber in ASSERT_FAIL steht:

xor eax, eax
// ...
mov [eax], eax

Was im übertragenen Sinne so ähnlich ist wie

MEM_WriteByte(0, 0); // Schreibe Null an Adresse Null

Was das soll, weiss ich nicht. Sollte auf jeden Fall eine Access Violation verursachen, wodurch die Assertion-Nachricht nicht mal angezeigt wird.


Zur Assertion selbst, also dem gelockten VertexBuffer, kann ich nicht viel sagen. Damit kenne ich mich nicht aus. Die Assertion setzt voraus, dass der VertexBuffer gelockt ist, ist er hier aber nicht. Das ist merkwürdig, denn zCVertexBufferManager::UnlockOpenVertexBuffers wird von zCProgMeshProto::RenderStaticLOD nur aufgerufen, wenn der VertexBuffer gelockt ist. Nicht 100% sicher, aber das sollte etwa so aussehen (Pseudo-Code):


zCProgMeshProto::RenderStaticLOD

int __fastcall zCProgMeshProto::RenderStaticLOD(struct zTRenderContext& arg_1, int arg_2, struct zCProgMeshProto::zTLODRenderArgs* arg_3, class zCRenderLightContainer* arg_4) {
    // ...
    if (arg_1->???->IsLocked())
        zvertexBufferMan.UnlockOpenVertexBuffers();
    // ...
}

zCVertexBufferManager::UnlockOpenVertexBuffers

void __thiscall zCVertexBufferManager::UnlockOpenVertexBuffers() {
    // ...
    if (!this->???->IsLocked())
         ASSERT_FAIL(...);
    // ...
}

Vielleicht weiss da jemand Bescheid, was es mit dem VertexBuffer auf sich hat (ich weiss nicht was das ist), was das für den Keiler usw. bedeutet und was genau das Problem verursacht. Falls nicht, könntest du notfalls die Assertion überschreiben und die Funktion einfach returnen lassen. Ich bin mir nicht sicher, aber das müsste notfalls funktionieren.

Falls du es schaffst, dass Problem verlässlich zu reproduzieren, könntest du die genannten Enginefunktionen hooken, um heraus zu finden, mit welchem Model das Problem zusammenhängt (ob es wirklich die Keiler sind) und dir die Vertexbuffer-Liste mal anschauen.




EDIT: Ich habe gerade erst gesehen, dass auf der vorherigen Seite dieses Threads schon einiges dazu gesagt wurde (verwandtes Problem auch mit dem VertexBuffer). Konntest du das Problem, das du dort hattest beheben?
Gottfried schlägt dort auch vor es einmal mit einzelnen LeGo Paketen zu probieren. Dazu müsstest du es natürlich erst einmal verlässlich reproduzieren können. Wäre natürlich nützlich zu wissen, ob es auf LeGo zurück zu führen ist.

Danke für die Analyse und den Hinweis, dass ich es bereits in MEINEM Thread gepostet hatte... peinlich ^^ Werd mal schauen, ist halt schon lästig. Konnte es aber mit Save von Testern in ca. 50% der Fälle reproduzieren, also nicht optimal, aber gut genug, um ein was rauszufinden.

Das Assert überspringen ist halt unter Umständen keine gute Idee, wird ja nicht grundlos da sein.

EDIT: Also bis auf HookEngine alle LeGo-Module alle LeGo-Module deaktiviert, passiert trotzdem noch. Ohne HookEngine crasht es direkt beim Start. Es ist jetzt 2x bei einem Save passiert, das kurz vor einem Schattenläufer ist. Schattenläufer killen und sobald ich ihn looten will crasht es. Also quasi auf Knopfdruck. Muss mal sehen, ob das jetzt nur am Timing lag.

EDIT2: Okay, hab einen Hook beim Öffnen des Inventars... evtl. hängt es damit zusammen?

EDIT3: Hm, jetzt ist es beim Laden des Saves passiert, nachdem es 2x geklappt hatte. Hatte den Hook auskommentiert fürs Inventar öffnen/schließen.

[mud-freak]

Dass es scheinbar nichts mit LeGo zu tun hat, ist natürlich gut, bzw. eben nicht.

Benutzt du/deine Tester das Systempack? Dort wird der VertexBuffer im Zusammenhang mit NVidia Grafikkarten genannt:

For Nvidia cards the flag WRITEONLY has now been deleted by default when creating the vertex buffer [...]. You can enable or disable the flag WRITEONLY via file (SystemPack.ini option disable_D3DVBCAPS_WRITEONLY)

Das könnte verwandt sein, denn der VertexBuffer scheint bei deinem Crash ja nicht freigegeben zu sein. Die Option im Systempack könntest du mal einschalten.


EDIT: Bevor ich dich hier falsch verstehe: Du hast geschrieben, dass das Spiel ohne alle LeGo Pakete (auch ohne HookEngine) direkt beim Start crasht. Ist das der selbe crash wie immer - also lässt sich LeGo komplett ausschliessen?

EDIT2: Da es mit LOD zusammenhängt, könntest du es auch einmal mit dem Systempack deaktivieren (heisst glaube ich disableLOD oder so).

[Bonne6]

Dass es scheinbar nichts mit LeGo zu tun hat, ist natürlich gut, bzw. eben nicht.

Benutzt du/deine Tester das Systempack? Dort wird der VertexBuffer im Zusammenhang mit NVidia Grafikkarten genannt:



Das könnte verwandt sein, denn der VertexBuffer scheint bei deinem Crash ja nicht freigegeben zu sein. Die Option im Systempack könntest du mal einschalten.


EDIT: Bevor ich dich hier falsch verstehe: Du hast geschrieben, dass das Spiel ohne alle LeGo Pakete (auch ohne HookEngine) direkt beim Start crasht. Ist das der selbe crash wie immer - also lässt sich LeGo komplett ausschliessen?

EDIT2: Da es mit LOD zusammenhängt, könntest du es auch einmal mit dem Systempack deaktivieren (heisst glaube ich disableLOD oder so).

Systempack ist bei mir mittlerweile immer an (zumindest wenn ich über Spine starte), die Tester haben es denk ich auch alle aktiv.
Die Option ist schon an, DisableLOD aktivier ich mal noch und teste das.

Der Crash beim Deaktivieren von HookEngine ist ein anderer und passiert direkt beim Laden des Saves. Weiß nicht, ob HookEngine-Aufrufe erwarten, dass HookEngine initialisiert ist, oder ob da eine Sicherheitsüberprüfung drin ist. Kann im Zweifelsfall noch alle HookEngine-Aufrufe selbst ausbauen. Teste jetzt aber erstmal ohne LOD.

EDIT: Also ich kann's grad sogar in 100% aller Fälle reproduzieren, Systempack-Einstellungen haben schonmal nichts gebracht.

EDIT2: Ah, Crash lag daran, dass durch das fehlende LeGo_Init kein Ikarus-Init mehr da war

EDIT3: Hm, ne doch nicht, bzw. nicht nur, krieg's ohne HookEngine nicht zum Laufen. Ist natürlich auch suboptimal mit einem bestehenden Save, aber ohne krieg ich den Crash wieder nicht reproduziert. Hast du zufällig die Adresse zur Hand von dem ASSERT_FAIL, dann würde ich das mal versuchen zu überspringen. Wobei ein ret vermutlich nicht so einfach ist, oder? Wer kümmert sich um das Aufräumen vom Stack?

[Lehona]

HookEngine funktioniert auch ohne Initialisierung (die Initialisierung ist genau genommen ein No-op). Wenn du dann in den Funktionen LeGo-Code ausführst, crasht der natürlich ohne Initialisierung

Edit: Um den Stack aufzuräumen gibt es auch die retn Instruction (poppt noch n Bytes vom Stack). In IDA kannst du in den Optionen den local stackpointer einschalten, dann siehst du wie groß der Stackframe momentan ist.

[mud-freak]

Hast du zufällig die Adresse zur Hand von dem ASSERT_FAIL, dann würde ich das mal versuchen zu überspringen. Wobei ein ret vermutlich nicht so einfach ist, oder? Wer kümmert sich um das Aufräumen vom Stack?

Also aus der ASSERT_FAIL funktion würde ich nicht herausspringen. Ich hatte daran gedacht, den Aufruf davon in zCVertexBufferManager::UnlockOpenVertexBuffers zu überspringen. Ich kann das jetzt nicht testen, (weil der Fehler bei mir ja nicht auftritt), aber damit sollte das gehen:

MemoryProtectionOverride(/*0x5FCAA3*/ 6277795, 5);

MEM_WriteByte(/*0x5FCAA3*/ 6277795,   ASMINT_OP_jmp);
MEM_WriteInt (/*0x5FCAA3*/ 6277795+1, /*0x5FCB71-0x5FCAA3-5*/ 6278001-6277795-5);

Nach der Abfrage, die zum Aufruf von ASSERT_FAIL führt, wird ein Jump gesetzt. Der überspringt den Inhalt des if-Blocks, so wie auch einen Aufruf von zCVertexBuffer::Unlock (weil der VertexBuffer in dem Szenario ja schon unlocked ist. Ist der VertexBuffer aber wie erwartet gelockt, wird in der Ausführung nicht eingegriffen.) und führt die Funktion weiter aus.

[Bonne6]

Also aus der ASSERT_FAIL funktion würde ich nicht herausspringen. Ich hatte daran gedacht, den Aufruf davon in zCVertexBufferManager::UnlockOpenVertexBuffers zu überspringen. Ich kann das jetzt nicht testen, (weil der Fehler bei mir ja nicht auftritt), aber damit sollte das gehen:

MemoryProtectionOverride(/*0x5FCAA3*/ 6277795, 5);

MEM_WriteByte(/*0x5FCAA3*/ 6277795,   ASMINT_OP_jmp);
MEM_WriteInt (/*0x5FCAA3*/ 6277795+1, /*0x5FCB71-0x5FCAA3-5*/ 6278001-6277795-5);

Nach der Abfrage, die zum Aufruf von ASSERT_FAIL führt, wird ein Jump gesetzt. Der überspringt den Inhalt des if-Blocks, so wie auch einen Aufruf von zCVertexBuffer::Unlock (weil der VertexBuffer in dem Szenario ja schon unlocked ist. Ist der VertexBuffer aber wie erwartet gelockt, wird in der Ausführung nicht eingegriffen.) und führt die Funktion weiter aus.

Paar Mal getestet mit dem Override und nichts gecrasht bisher Bin guter Dinge

[mud-freak]

Paar Mal getestet mit dem Override und nichts gecrasht bisher Bin guter Dinge

Sehr gut. Hier noch einmal eine übersichtlichere Erklärung was das Überschreiben tut. Daran kannst du dann entscheiden, ob du es beibehalten willst (vorausgesetzt es kommt verlässlich nicht mehr zu einem Crash):

VORHER:

unlockAllOpenVertexBuffers()
{
  foreach vertexBuffer in allOpenVertexBuffers
  {

    if (!vertexBuffer.isLocked())
      ASSERT_FAIL(...) // Ein bisschen streng: Wenn schon offen, ist doch kein Problem?!

    vertexBuffer.unlock()
    vertexBuffer.optimize()
    ...

  }
}

NACHHER:

unlockAllOpenVertexBuffers()
{
  foreach vertexBuffer in allOpenVertexBuffers
  {

    if (vertexBuffer.isLocked()) // If-Struktur wird umgedreht.
      vertexBuffer.unlock()      // Wie gehabt, aber nur wenn gelocked

    vertexBuffer.optimize()
    ...

  }
}

Wenn man sich das so anguckt, spricht ja nichts dagegen, es ohne Konsequenzen zu übernehmen. Allerdings bleibt immer noch die Frage, warum zCVertexBufferManager::UnlockOpenVertexBuffers überhaupt aufgerufen wird, bzw. warum die Abfrage in zCProgMeshProto::RenderStaticLOD ob die VertexBuffer bereits offen sind FALSE zurückgibt.
Wenn es bei dir klappt und du mit dem Fix zufrieden bist, sollte es wahrscheinlich noch ordentlich von ein paar Testern getestet werden.

[Lehona]

Zu deinem Kommentar: Ich glaube der Vertexbuffer liegt einfach hinter einem Mutex, d.h. wenn der noch unlocked ist heißt das, dass irgendein anderer Thread da gerade drin rumschreibt (oder rumschreiben könnte).
Was schlimmeres als Crashes oder Grafikfehler sollten dabei aber dennoch nicht auftreffen, also wenn's hilft

[mud-freak]

Zu deinem Kommentar: Ich glaube der Vertexbuffer liegt einfach hinter einem Mutex, d.h. wenn der noch unlocked ist heißt das, dass irgendein anderer Thread da gerade drin rumschreibt (oder rumschreiben könnte).

Ah, okay. Ich habe überhaupt nicht drüber nachgedacht, was locked und unlocked in diesem Fall überhaupt bedeuten könnte.


Ich habe die gleiche Änderungen noch einmal für den Crash auf der ersten Seite dieses Threads (gleiche Ursache allerdings in der Funktion zCVertexBufferManager::AcquireVertexBuffer). Ich weiss nicht, ob dieser Crash bei dir noch aktuell ist. Dort ist der Kontext etwas heikler. Es kann also sein, dass es trotzdem zu einem Crash kommt.

MemoryProtectionOverride(/*0x5FC638*/ 6276664, 5);

MEM_WriteByte(/*0x5FC638*/ 6276664,   ASMINT_OP_jmp);
MEM_WriteInt (/*0x5FC638*/ 6276664+1, /*0x5FC6E3-0x5FC638-5*/ 6276835-6276664-5);

[Bonne6]

Wenn es bei dir klappt und du mit dem Fix zufrieden bist, sollte es wahrscheinlich noch ordentlich von ein paar Testern getestet werden.

Werd das morgen mal in die aktuelle Testversion einbauen, dann wird es gleich mitgetestet. Mal sehen, ob es jetzt nur Glück war oder auch bei den Testern klappt... Und ob es irgendwelche Nebenwirkungen gibt.

[Bonne6]

Gibt es für bik Videos in Gothic irgendwelche Limitierungen? Hab grad das Problem, dass ein altes (glaub 800x600 Auflösung) funktioniert, die neueren in FullHD allerdings nicht angezeigt werden...

[Dada]

Ich meine mich zu entsinnen, dass es ein Problem mit Breitbild-Auflösungen gab. 800x600 war kein Problem, afair 1024x768 und aufwärts auch nicht.

[mud-freak]

Randnotiz für Gothic 1.

[Bonne6]

Mit den 104 scheint es zu klappen, auch wenn ich Skalierung umstelle. Jetzt versuch ich grad die gleiche Konvertierung mit Default-Settings und Skalierung von FullHD auf FullHD. Evtl. wird nur eine Property nicht gesetzt... wenn das klappt muss nur sehen, wie ich das in die command line krieg...

EDIT: So klappt es über Commandline:

"C:\Program Files (x86)\RADVideo\binkc.exe" Credits.mov Credits.bik /v100 /d0 /m3.0 /l4 /p8 /w1920 /h1080 /(1920 /)1080

[Milky-Way]

Das scheint mir auch mit der Auflösung, die der Spieler bei sich eingestellt hat, zusammenzuhängen.

Und dann gibt es auch noch das Problem, dass unter neueren Windowsversionen manchmal Videos nicht angezeigt werden. Das soll meines Wissens vom Systempack behoben werden.

[Bonne6]

Gibt es eine maximale Dateigröße/Dateianzahl für .mod Dateien? Nur so aus Interesse wegen der Sprachausgabe

[Lehona]

Ich würde die "üblichen Verdächtigen" erwarten: Vielleicht 65k Dateien, maximale Größe 4GiB? Kann aber natürlich auch sein, dass die Grenzen höher (und damit effektiv nicht vorhanden) sind.

[Bonne6]

Ich würde die "üblichen Verdächtigen" erwarten: Vielleicht 65k Dateien, maximale Größe 4GiB? Kann aber natürlich auch sein, dass die Grenzen höher (und damit effektiv nicht vorhanden) sind.

Hm, da wäre ich drunter. Ich frag mich halt, weil bei Odyssee z.B. haben sie die Sprachausgabe in zwei Dateien aufgesplittet und wäre insgesamt auch nicht drüber gewesen. Ich schreib mal blackpirate, ob es dafür einen Grund gab.