Yu-Gi-Oh! Legacy of the Duelist: Link Evolution (Steam version) - YGO_2020.dat

[BattleWarAxe3]

There is already a script for the Switch version of this game on the main site, but I would like to request a script for the Steam version.

[aluigi]

You should provide that dat file for analysis.

[BattleWarAxe3]

Understood. I'll have to provide you with OneDrive links as I perceive the .dat file is too large to attach (it's 1.5 GB, and when I tried to attach, uploading reached 25% and then returned a 500 Internal Server Error. Here you go:

.DAT file
.TOC file

[aluigi]

As far as I can see this script still work well:
http://aluigi.org/bms/other_ocean_interactive.bms

[BattleWarAxe3]

Thanks, and sorry for the late reply; I went out for a bike ride. I have a question, though. It creates a file called "g" in the folder "2020.full.illust_j.jpg.zib" and then creates many, many files with the same name, so it keeps asking if I want to overwrite the "g" file. What should I do?

[BattleWarAxe3]

If I run the script with quickbms_4gb_files.exe, it instead returns a error while running when it reaches the "g" file.

===
Error: incomplete input file 1 <path to .dat file>\YGO_2020.dat
Can't read 524288 bytes from offset 0009ed511611ee09.
coverage file 1, 23%, 370211585, 1570637648 . offset 0009ed511611ee09

Last script line before the error or that produced the error:
40 log NAME OFFSET SIZE 1

[BattleWarAxe3]

Trying to skip the duplicates returns another similar error.

===
Error: incomplete input file 1: <path to .dat file>\YGO_2020.dat
Can't read 495741 bytes from offset 5d9e0750.
coverage file 1, 133%, 2097974452, 1570637648 . offset 5d9e0750

Last script line before the error or that produced the error:
40 log NAME OFFSET SIZE 1

[BattleWarAxe3]

Anyone there? I still need help with the aforementioned errors.

[aluigi]

Script 0.1.1, let me know how it works.

It wasn't a bug in the script but just a different format used for the ZIB files in this specific version of the game, the OFFSET and SIZE fields were 32bit instead of the original 64bit ones.

[BattleWarAxe3]

Sorry, it didn't work. I should elaborate that quickbms.exe returns the error when it hits a file called "000004b6.dat" within the "2020.full_illust_j.jpg.zib" folder

[Mysticus]

Sorry, it didn't work. I should elaborate that quickbms.exe returns the error when it hits a file called "000004b6.dat" within the "2020.full_illust_j.jpg.zib" folder

It worked fine to me but this image resulted badly exported.

[BattleWarAxe3]

It worked fine to me but this image resulted badly exported.

Strange, it works for me too now, but I also face the same problem with 10000.jpg.

Anyways, thanks for your help, aluigi.

[BattleWarAxe3]

It worked fine to me but this image resulted badly exported.

I figured out the problem. Open 10000.jpg in a hex editor (HxD is free, if you don't have one) and change offsets 0x00 and 0x01 from "D8 FF" to "FF D8". The file should now open normally.

[aluigi]

@BattleWarAxe3
I don't know why you got that error during that extraction, and why only once.
Anyway I found a little bug during the parsing of the TOC file ("f movies" instead of "movies") so what you noticed once may have been caused by that bug.
Script fixed.

@Mysticus
I confirm that the first file of the two zib files ever have the OFFSET field plus 1 so I suppose it's a bit meaning something (maybe "first file?")

Code: Select all

00 09 ed 51 00 00 ec 39 31 30 30 30 30 2e 6a 70   ...Q...910000.jp
67 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   g...............
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
00 0a d9 90 00 00 fd 2b 31 30 30 30 31 2e 6a 70   .......+10001.jp
67 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   g...............
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

Script updated to version 0.1.2

[BattleWarAxe3]

Yep, everything seems to be fine now, including the 10000.jpg problem. Thanks again.