diff tool for IE formats?

[lynx]

memory is not really a constraint for such a simple use, so feel free to change that.

[critto]

These are a few meaningful changes that I've made that could be pushed into master repo right now, I think.

 

As for the code generator itself, do you think iesh needs that sort of tool? It diffs two files and makes a straightforward patch sequence that is not specifically human-friendly. I have it as a stand-alone right now (it works only for item files and not written in Python), but I can certainly adapt. I'd need to consult you first though to figure how it would fit best into the package.

 

However, I had some plans to try and make a more intelligent piece of software that creates an understandable diff, but it requires more time and thinking. It is not as straight-forward as parsing a diff output and adding or deleting a few extra bytes.

 

I am trying to hack it together for spell files at the moment. This something that could definitely be built on top of iesh, since it already parses the file and prepares its structure in memory. I am not sure yet, how exactly, but such tool would need to be able compare files between themselves. Or, at least be able to generate WeiDU code blocks that could later be used by modders or 3rd-party tools.

 

BTW, iesh and ielister are already great when it comes to reverse-engineering the changes applied to IE formats. I've used them to convert a manually prepared modification of a vanilla area into a sequence of weidu-style patches.

 

But it would be awesome to teach iesh how to generate pieces of WeiDU code. It was painful to prepare sequences for adding vertexes by hand

 

patch.txt

[lynx]

Hey, I'm back from my ambassadoring — great to see so much activity in the meantime! We'll probably move the repo to github to make it easier to contribute (allura has some basics for pull requests too though). But that's a better fit for the other thread.

 

As for the generator, I do think it would fit in. I like it standalone, so one would just pipe iediff into it, but perhaps that would limit windows users? In that case a switch/mode for iediff would be better (or calling it internally), but I just remembered that it's a bash script itself. So forget all I said. What did you write the wrapper in?

 

For the smarter thing, you want it to have more contextual awareness, so you could use other weidu functions besides trivial byte/... patching?

[critto]

Yeah. I left a ton of messages in another thread about all the other patches I've made, just waiting for github to proceed with pull requests.

 

My wrapper was written in PHP. But it's a messy thing and I am not sure if it's a good addition to the whole toolkit. I did some testing in the last two weeks: a straight-forward approach is simple, but too error-prone. Everything that was adapted for EE version does not install on ToB due to differences in files and so forth. If one needs a solution of this type, he or she could make it with weidu (--cmp-from + --cmp-to makes a sequence of write_byte-style patches that could be further filtered with iediff). So, overall, I don't think we need to clutter iesh with this.

 

For the smarter thing, you want it to have more contextual awareness, so you could use other weidu functions besides trivial byte/... patching?

 

Yes. Contextual awareness is needed, but it is a much more fearsome task. I am making some drafts of comparison right now, but it's not easy. Too many gotchas. For instance, you might have three effects with the same opcode, but only one needs patching (if parameter2 equals some value, update parameter1 to something else). WeiDU does not have built-in capabilities for this via pre-defined patch or action functions. These situations need to be detected and resolved with straight-forward patching or providing our own pre-defined set of functions.

 

For now, I decided to make something simpler and teach iesh to do printme() in various formats, including weidu-style patches with extra possibility of printing out a weidu-style code for a specific part of a file (e.g., a single effect or an extended header). This looks like more manageable task that would allow a mod developer to do a quick diff between files via iediff, generate a code snippet and insert it into his mod.

 

While not as intelligent, I think it would allow to speed up development considerably. I have some other ideas as well.

 

For instance, I would like iesh to have some sort of "mod development" mode that would allow to browse and apply changes to files both in the override and your particular mod directory. I found that it takes too much time prepping a file in NI, saving it to override then exporting or manually transferring to your mod folder especially when you're applying numerous changes while testing something. These things could be optimized and allow for much faster workflow. But this is just an idea, I don't have any specific concept or implementation in mind right now.

[lynx]

it's up, but I'm still in the process of migrating the remaining changes:

https://github.com/gemrb/iesh