Import/Export text from msg/*.bar files as XML or YAML

[Vladabdf]

This would be helpful with going through backups. Perhaps when showing two files being compared, only list strings that are different between the two.

[Xeeynamo]

Can be a very good idea. I look forward to implement it at some point

[GovanifY]

I was looking at the repo and saw this issue and was wondering: why do we need this feature?
There is already a ton of well working diff tools on both windows and linux that can find any difference between text files, heck, git is built on this principle!

I would believe exporting the files as actual text files and using a specialized tool for diffing revisions would be the smartest way to implement that, unless there is something that I don't get in your Text Editor architecture.

[Xeeynamo]

You just read in my mind!

What the editor is missing is an import/export feature to a plain text file. Without it, it is not possible to merge or compare messages. There is an importer and exporter to/from XML, but it's only available as library and not as a command line tool.

It is not official, but I was thinking to let parse and export game files as YAML content as long as GUI (or cross-compatible GUIs) are not there for some file formats (2dd, I am looking at you)

[GovanifY]

For the latter part I'd encourage you to keep an internal infrastructure that still allows for YAML handling long after the GUIs are done.

Let's put it this way: you extract your KH2FM iso, whose files are then parsed by appropriate tools in human editable formats: ie BGM+WD= a folder containing a MIDI, an SF2 and a YAML. Same would go for models and all. That was what I planned to do with my old kh2 projects that never caught on fwiw.

I think the first state toward this would be to define a common file structure format library that would be common across all tools such that you can write your parser in Kaitai, make the application to handle the data itself while using the internal data representation library.

This would not only reduce long-term the cost of developping parsers(you would end up writing kaitai parsers) but also exporters, importers, and the documentation itself, as you could document the Kaitai formats and make markdown generators automatically. The only piece that needs to be defined in this chain programmatically per filetype would be the conversion per se if you get my drift.

That's very far off of course, but I believe it would be as good as it gets architecturally wise. Any thoughts?

[Vladabdf]

I'm 100% fine with exporting as plaintext, XML, or YAML as well. I only suggested the built-in comparison because it was the first thing to come to mind, but the import/export function would be far superior, I agree. Anybody who would be comparing text would already be taking advantage of such a function, so that would be the route to go.

[kenjiuno]

@Vladabdf I have written 4 text exporters.
Please check preferred format from sample output: al.zip

[Vladabdf]

It's beautiful! Thank you so much for the contribution! Plaintext, XML, YAML, and CSV? You really went all out and made it as accessible as possible. I tested it a number of times for various files in both English and Japanese and it works beautifully. Thanks again!