Pretty sure BB made something like this in Python a while back. I think it was even capable of repacking those files, which the older OP2ArtViewer tool didn't properly support.
I was not aware of that. Is the tool or its source available anywhere? What features does it support? I would be most interested with something that supports sprite sheet extraction, along with any associated metadata needed to use the sprite sheets.
BB's Python mission API would be a solution to this. Since it was so far along already, it'd make the most sense to finish that.
I am aware of this. In particular, it seems the one part that was left unfinished is the part I was proposing above. It seems BlackBox has the scripting component largely working, but does not yet have the game listing new file types in the game list dialog boxes. This work could go to support those efforts.
Another discussion I'd like to have concerning that project, is if Python scripting goes far enough. A lot of things, like initial unit placement, and starting colony conditions, can be done with simple data, which would be easier for a map editor to process than generating and interpreting code. This is also what the vast majority of DLL code handles. Having a standard data format for initial unit placement, and starting colony conditions, could eliminate the need for 80% of the DLL code/Python script. Though perhaps that's a discussion for another day. If the Python scripting is working, that's still much better than compiling C++ code, so it's still a big step forward. I'd say work on adding support for new map types, use BlackBox's Python scripting project to implement a new map type, and from there see if it makes sense to extend things with a standard data format for initial level conditions.
I hate to say it, but D is practically just a gimmick. Even though it's relatively new, it's been around long enough that if a strong ecosystem were to develop, it would have started happening by now, yet it hasn't because it really doesn't have any big-league backers, and the prospects of that ever happening looks slim. The few projects I knew that people started in D (such as OpenMW IIRC), they ended up scrapping their code and going back to C++ just because the ecosystem/documentation/etc. is very lacking. Rust would be more promising since it has Mozilla backing it, but even that I have doubts about if it will go anywhere, and I'm not sure I'm a fan of the syntax
A fair concern. That's one reason why I suggested a smaller utility project be written in D, as a way to try it out. D does seem small, and does seem to lack a bit of ecosystem support. In particular, the standard library is not quite as extensive as I'd like, and the Dub package management system and build tool still seems a little rough around the edges. The D ecosystem has in the past been somewhat slow growing. I suspect it took a big hit from the earlier D1/D2 split, and the Phobos/Tango standard library split. That seems to have been resolved long ago, and there seems to be consensus in the D community not to let that happen again. Currently there is growth, and it appears to be accelerating. As for the documentation, I'd say it's actually pretty good. It's also aided by the built in support for documentation with special source comments.
I've been curious about Rust. I heard something about static checks for pointer ownership, which I thought was pretty neat, and something I'd once wished for. Though reading just now, it seems some of the pointer stuff has been removed from the language.