Issues with Retrieving Version from the Executable

[genment]

Getting MapleStory version from exe IMO is not a good idea.

1. Finding the version from the exe on disk is probably slower than doing a few hundred in-memory loop iterations. When parsing a WZ file, whether brute-forcing or reading from the exe, the cost of figuring out the client version is negligible either way.
2. This can lead to incorrect version detection. For example, if I have a client with two data folders (e.g., Data_250 contains older client files for backup), it’ll detect the version as 251 and won't be able to open the files in Data_250.

MapleStory.exe

Data
+---String
|       String.ini
|       String.wz
|       String_000.wz
|
\---UI
    |   UI.ini
    |   UI.wz
    |   UI_000.wz
    |
    \---_Canvas
            _Canvas.ini
            _Canvas.wz
            _Canvas_000.wz

Data_250
+---String
|       String.ini
|       String.wz
|       String_000.wz
|
\---UI
    |   UI.ini
    |   UI.wz
    |   UI_000.wz
    |
    \---_Canvas
            _Canvas.ini
            _Canvas.wz
            _Canvas_000.wz

MapleLib/MapleLib/WzLib/WzFile.cs

Lines 268 to 283 in bc8b456

	// Attempt to get version from MapleStory.exe first
	short maplestoryVerDetectedFromClient = GetMapleStoryVerFromExe(this.path, out this.mapleLocaleVersion);
	// this step is actually not needed if we know the maplestory patch version (the client .exe), but since we dont..
	// we'll need a bruteforce way around it.
	const short MAX_PATCH_VERSION = 2000; // wont be reached for the forseeable future.
	for (int j = maplestoryVerDetectedFromClient; j < MAX_PATCH_VERSION; j++)
	{
	//Debug.WriteLine("Try decode 1 with maplestory ver: " + j);
	if (TryDecodeWithWZVersionNumber(reader, wzVersionHeader, j, lazyParse))
	{
	return WzFileParseStatus.Success;
	}
	}

[lastbattle]

Its a tricky situation, as most users typically wouldn't have a different version of MapleStory.exe and .wz files in a single folder.
And also the added complexity of having it work across beta, pre-bb, post-bb, post-5th job, and 64-bit update.

I'll check on the speed of acquiring the version number from the client, relative to bruteforce method again.

[genment]

My suggestion is to simply remove it.

MapleLib, as a library, should be general-purpose and able to open, read, and parse any given WZ file without concern for the directory structure, as each WZ file is standalone and does not depend on any other files.

What do you think?

[lastbattle]

Yes maybe separate, as only part of HaCreator.

[genment]

Oh, I see the problem now. I was only focusing on HaRepacker and overlooked that HaCreator also depends on MapleLib.

Here is my suggestion:
When launching HaCreator, users need to select the game folder and load the WZ files from it. We can detect the version once at that point and store it in WzFileManager. Afterward, we can use new WzFile(string filePath, short gameVersion, WzMapleVersion version) in WzFileManager.LoadWzFile() to completely bypass the version detection process every time a WZ file is loaded.

By doing so, GetMapleStoryVerFromExe can be moved to HaCreator, allowing MapleLib to remain simple and speeding up the loading process.

[lastbattle]

I was thinking of developing data packaging for HaCreator.

On the initial HaCreator launch, the user will be prompted to select the MapleStory directory, specifically Base.wz.
The system will detect the Wz version once, extract the data, and store it as .img files in the filesystem. ('de-compliation'/ 'unpack')
These files will only be converted back to .wz format during the 'compilation' process. You could select pre-bb, post-bb, or any other WZ format from the raw .imgs to build from.

This approach allows for quick data imports via simple file copying and pasting, while also enabling version control of wz changes using git.

This solution eliminates the need for HaCreator to repeatedly detect the version on each run and fully separates this functionality from MapleLib.
It's the same process used by Nexon currently on their end.