xml2gff not included in xoreos-tools-0.0.5 release? about xoreos-tools HOT 7 CLOSED

Yes, the 0.0.5 release predates the xml2gff tool. See also #51. It will be included in the next release, 0.0.6 (which will release together with xoreos proper and Phaethon).

Unfortunately, RL kinda shredded my plans to do a new release that month (March). The only thing I can say is "soon"; I'm working on it.

From the code side, a new release is mostly ready to go:

• Checked that the code compiles with all my (cross-)compilers (for Windows, macOS and Linux)
• Fixed up all Coverity Scan issues
• Fixed missing distribution files
• Checked that the Debian Linux builds run through and is lintian clean
• Checked the new manpages for consistensy
• Updated the ChangeLogs
• Updated the NEWS files (not yet public)

Things left to do:

• Check that the Arch Linux builds run through
• Check that the Gentoo Linux builds run through
• Check that the Fedora Linux builds run through
• Write a news blog post
• Create the distribution packages and upload them

Writing the news blog post is the only big task left. I've got some bullet points, but I didn't yet have the time to actually write something coherent. I also might still try to capture some KotOR footage for xoreos.

I don't want to really put a deadline on it (considering I've already blown a few of them), but hopefully, I can pull this off next month.

from xoreos-tools.

Thanks for the quick update, it's very much appreciated. Someone was kind enough to send me a copy of it they have, and (in case it helps - you might be well past that by now) I'm having an issue with it that can be reproduced as follows:

1. Run gff2xml on the file "tar02_carth022.dlg" from KOTOR 1. It creates an XML file, but I can't say whether the XML is correct or not
2. Run xml2gff on the output from that file - it creates an empty file.

I've zipped and uploaded the generated XML file ("tmp.xml") and the subsequently generated GFF file ("out.dlg"), in case it helps. On that note, I'd be happy to write some unit tests for you that would e.g. cycle through gff2xml and then xml2gff again, and ensure the outputs are consistent with the original input (I could write them in Python - I know you use C++ here but I'm an AI researcher so Python's my hammer and the world's my nail :p).

Thanks,

Lachlan

out.zip

(Edit: apologies for not seeing the prior issue; also, thanks again for all the hard work you put into Xoreos and Xoreos-tools - it's a great project).

from xoreos-tools.

Thanks, I'll take a look. Or maybe @Nostritius, if you have time?

We already have a few tests for our GFF3 reader and writer classes (though I've apparently forgotten to up the gff3writer test into xoreos-tools as well), but maybe they're missing some edge cases. And yes, they're written in C++, using the Google Test framework. You can find them here: https://github.com/xoreos/xoreos-tools/tree/master/tests

from xoreos-tools.

But yeah, we also have no unit tests that call the tools, only the underlying classes. We don't really want to have to call any binaries there, that just breaks cross-compilation.

But maybe we should add another optional level of unit tests for that? Those could also run during CI, that could be useful. Need to think about how to do this. Probably something for after the new release.

from xoreos-tools.

Got that error of yours fixed in the current main branch.

Also did a testrun over some files and fixed a few other bugs. There's still at least one bug prevelant in some NWN files; I need to have a better look at that later.

from xoreos-tools.

Thanks for the (super quick!) fix :)

from xoreos-tools.

I've fixed a few more bugs with the tool, and opened two more issues that are still open: #54 and #55.

#54 is only relevant to you if you're creating GFF files with LocStrings that have strings in them (instead of just a strref) and those strings have characters outside the ASCII plane.

#55 is only relevant to you if you've got LocStrings with strings that contain color codes.

from xoreos-tools.