I don't do mission development from Linux. The main problem is name mangling differences between MSVC and Mingw. I've found Mingw is able to compile a DLL that the game will load as a level, but only an empty level that doesn't do anything. As soon as you try to call any interesting method from the level DLL, you end up with linking problems trying to build the DLL due to name mangling differences. Each compiler has their own way of mangling names, which is partly intentional, since each compiler tends to produce a slightly different and incompatible ABI for C++. It's only really the C ABI that is widely supported by various compilers and languages, not the C++ ABI (which is kind of lacking in standardization).
I've heard that Clang can produce MSVC compatible binaries, with identical name mangling and C++ ABI (or near identical, save some very uncommon corner cases like multiple virtual diamond inheritance or something like that). That may be an option for producing levels from Linux, though I've never tried it. It would require using Clang as a cross compiler from Linux to produce a Windows binary. The toolchain supports this from a capability standpoint, but not so much from a user level standpoint. There's no easy to use packaging to call Clang as a cross compiler. You'd have to do a lot of manual setup yourself. That may mean getting Windows header files from an MSVC install, or whatever else you might need, and configuring all the right options so the compiler knows where to look for platform specific header and library files. It's apparently quite complicated to get working.
If you manage to use Clang as a cross compiler, I'd love to know the details.
----
With that said, you can still run the code through Mingw for static checking purposes. You just won't be able to link the result for anything non-trivial. That can at least help you prevent brain-dead errors when trying to help other people with their code.
You can also use Clang for static checking purposes, but not for code with Windows specific includes, unless you've also figured out a cross compiler setup. Still very useful though, as Clang has some excellent static checking.
Another helpful tool is
AppVeyor. I can make contributions to a project from Linux, statically check the result with Mingw, and push the results to GitHub, which would then run the code through MSVC on AppVeyor. That would catch any compile issues that are a problem for MSVC but not a problem for Mingw.
You can potentially run unit tests on AppVeyor too. That would let you know if the code actually works, as opposed to merely compiles. Though I've never written unit tests for an Outpost 2 mission.
It may also be possible to get AppVeyor to publish the compiled files as a GitHub release. I haven't experimented with that yet, though would love to set that up for a few projects.
----
I've never run OP2Mapper from Linux. I know it uses a few common controls. Maybe if those extra controls are registered it might help. I'm not too sure of the details on doing that.
I wasn't aware of the "winetricks vb6run" part. That's helpful to know. Perhaps I'll experiment a bit.
----
In the SVN, under the OllyDbg folder, there is a folder of text files that describe many Outpost 2 related file formats and in memory structures. It contains near complete info on the map file format. There are some gaps in details for saved games, which is a related format, and shares a lot of code.
The
OP2Utility project on GitHub has code for loading and saving map data. It was used in the
OP2MapImager project, also on GitHub. The methods are pretty raw though. There's no map editing capability around it. You'd have to build your own map editor on top of it if that's what you were looking for.
There's also an older
OP2Editor backend, which the Mapper uses, and was used as the basis for much of the code in OP2Utility. It's much older, and uses COM which has been deprecated by Microsoft.