NXPatcher - Create your own pre-patcher & list of Maple FTPs

Find msvcr110.dll online, download it, and put it in your NXPatcher directory.

If it's really saying that, then it might be that the download is corrupted. Try downloading it again.

In doing some more research on the patch format, I have discovered that Nexon's patching algorithm has a small mistake in it. It's very, very rare that this mistake might actually come to fruition, but it is possible.

Programmers, Try to see if you can catch the mistake. I've labeled it in the spoiler.

This is the file rebuilding algorithm ripped straight from patcher.exe:

Code:

for(Command = GetInt(&zlibBlock); Command != 0x00000000; Command = GetInt(&zlibBlock))
{
    if((Command & 0xC0000000) == 0xC0000000)
    {
          //This is a repeat block. It's essentially run length encoding.
          repeatedByte = Command & 0x000000FF
          lengthOfBlock = (Command & 0x3FFFFF00) >> 8;
          //use memset in C to write to a buffer containing the repeatedByte for lengthOfBlock number of bytes, then write it to the file.
    }
    else if((Command & 0x80000000) == 0x80000000)
    {
          // This is a direct write block. The bytes to be written are contained directly in the zlib stream. Simply write these bytes out to the file.
          lengthOfBlock = Command & 0x7FFFFFFF;
    }

    else
    {
          //This means we take from the old file and write to the new file.
          lengthOfBlock = Command
          oldFileOffset = GetInt(&zlibBlock);
          //So open the old file, seek to the oldFileOffset, read lengthOfBlock number of bytes, then write those bytes to the new file.
    }
}

 Mistake

The mistake can occur in the case where a 0x80000000 block contains more than 0x40000000 number of bytes. In this extremely unlikely event, the wrong kind of block will get parsed (0xC0000000 - a repeat block) and the resulting file will be wrong and the file block will become corrupted - generating bad commands for the rebuild process.

To fix this, the lengthOfBlock should be "Command & 0x3FFFFFFF" and Nexon should fix this in their patch builder.

I need to learn C# for work, and what better way to do that than to fix NXPatcher?

Currently I'm working on NXPatcher Advanced. Here are the following features I'm adding:

- Complete rewrite in a different language.
- Patching DLL created in C# to allow others to do whatever they want to with patch files.
- NXPatcher logic and patch logic are now separate.
- No more running out of realloc space. The C# garbage collector will use swap space instead of running out of RAM.

I do not plan on rewriting NXPatcher Lite because it already does everything I need it to do.

Here's an example of the code I'm working with to apply a patch file to a directory.

Code:

namespace NXPatcherCS
{
    class Program
    {
        static void Main(string[] args)
        {
            var accessor = new PatchAccessor(@"H:\Maplestory\GMS\00155to00159.patch");
            accessor.ValidateCRC();

            // DumpDeflateStream returns an emitter, which is a dumb, low level accessor for the unpacked patch file. It only fetches the bytes and doesn't do any interpretation.
            var dumpPatchEmitter = accessor.DumpDeflateStream();

            // Setup where the dump file is, where all of the original files are, and where all of the new files will go.
            var dirName = Path.GetDirectoryName(dumpPath);
            var outDir = Path.Combine(dirName, "patcher");

            // Let's patch, baby!
            var dpa = new DumpPatchApplier(dumpPatchEmitter, dirName, outDir);
            dpa.ApplyPatch();
        }
    }
}

I tested this code on a 600 MB patch file. While there was a performance penalty for using C# instead of C/C++, at least it will patch now. For some reason, my algorithm soaks up RAM worse than Chrome when patching sound.wz. I will need to profile my code to figure out what's taking up gobs of RAM.

Already written features:
- Access patches, check CRCs/headers, and dump the patch file
- Read the dumped patch files
- Apply the dumped patch files
- Accessor for patch EXE files
- Writer for patch EXE files

Still need to write:
- NXPatcher Advanced logic
- WZ version checking

Thanks [MENTION=1]Fiel[/MENTION];! I'm happy you still develop nxpatcher, I still use it over Nexons most of the time ^^ especially when their patcher fails.

I still use it over Nexons most of the time ^^ especially when their patcher fails.

I use [MENTION=1]Fiel[/MENTION]'s patcher almost exclusively, lol. I'm glad he's still working on it as well!

I use Fiel's patcher almost exclusively, lol. I'm glad he's still working on it as well!

Much appreciated.

I will be leaving on business to London in a week, then from there flying to Wisconsin for a few weeks to be with family. I'll try to get as much done on this as I can before I fly out.

Much appreciated.

I will be leaving on business to London in a week, then from there flying to Wisconsin for a few weeks to be with family. I'll try to get as much done on this as I can before I fly out.

F3 If you ever hit up Dallas again, let me know. I'll take you out for dinner. ^^

Little bit of a dev blog here.

Now that vacation and thanksgiving are over and I'm finally caught up at work from being gone for so long, I thought I'd finish this up.

NXPatcher Advanced Logic - 75%
WZ Version checking - 50%
INI file reading - 0%
EXE Reading/Writing - 100%
Patch Reading/Applying - 100%


I'm currently struggling with the INI file that NXPatcher Advanced uses. C# doesn't like using INI files by default. I've tried using the app.config, but it's far too clunky for my tastes as it doesn't allow for hierarchical nesting (everything needs to be in the same xml depth). Pretty sure I can find an open source implementation of this.

I committed the code that I have so far. This code will not compile, but it's mostly complete.

https://github.com/mechpaul/WzPatch

Is it just me or did the links stop working?

Is it just me or did the links stop working?

it's just you

Has anyone figured out how the new patching system works? In GMS, the CustomPatch***to***.exe exists from 147to148 until 187to188. 188to189 appears to have been deleted. The .patch files ended with 182to183.

Nexon Launcher now downloads one or more .diff files for each file requiring patching in the patch directory. I wonder if they have the same sort of structure, and if the download directory is somewhere within the current ftp. It's kinda weird because every other region seems to have retained their .patch files for patching except GMS.

Are they any different than a standard binary delta?

https://github.com/jmacd/xdelta

This thread was updated to show the new version 2 of the patch file format. I'm currently working on creating a new patcher that will support both versions 1 and 2. Coming soon.

The chinchilla lives! Huzzah!