RockPatch -> Ares Migration Assistance

[Renegade]

It's less the amount of hate making a book necessary, it's the number of things wrong with NPatch

If NPatch is well-documented, then it should be easy for you to write replacement logic. Ultimately, it'll be nothing more than simple instructions along the lines of "if you find this flag, change it to this and place the value there".
I don't know what kind of format I'll give the file yet, but it looks like wxWidgets comes with classes to parse XML documents, so it may end up something like this:

Code:

<old flag="Foo" values="2" seperator=",">
    <new flag="Bar">$1</new>
    <new flag="Baz">$2</new>
</old>

to change

Code:

Foo=42,69

to

Code:

Bar=42
Baz=69

I totally just made that up as I went, so it's absolutely not fixed, I don't even know what kind of reformatting options I'll need to have in place, since I still don't know which flags are translatable in the first place, but it's one way I could imagine it to work, and it should be easy enough for you to adapt for NPatch.

In general RockPatch to Ares INI Converter news, since "RockPatch to Ares INI Converter" is a mouthful, I have found myself adopting "Arpytuares" inside the source and as the binary filename. So if I talk about that, I mean the converter.
I had the thing as far as loading INIs, displaying them, and showing a progress bar while it loaded, but I refactored the code so the working logic wasn't in the GUI event handlers, and am currently having a segmentation fault somewhere. I'm pretty sure I know where and why, though >_> so that should not be a big obstacle.
Something more concerning is execution time. The most convenient way to step through the INI wxW offers is a TextFile handler that allows me to go through text files line by line. It works as expected, it's easy to use, and I'm very sure it'll make the actual conversion very easy to write.
The problem?
The virgin rules I have here are 31068 lines long, Tesla's RP rules have 35593.
That takes....long, to put it mildly.
I'll have to check whether the displaying code is what slows it down, or whether that's just the way the handler is. If it's just the displaying, I can let it work without outputting the code and do that later, but if the handler itself is that slow, you'll have to test whether the speed is acceptable for a one-time or infrequent conversion, or if I have to rewrite it to use a different handler.

I'll keep you posted.