I'll likely add the mineSet to the base layouts exactly as you've mentioned. That was an edit I was planning on but forgot about.
Changing the comments for the tech ID enum to make the level easier to read sounds good.
I can't really think of a better name for the OP2Helper stuff. There is no real set criterion for what functions go into that set of files. Like the main header files, it's being broken up into seperate sections. I'd like to have more added someday but for the moment I can't think what extra functionality we really need. (Probably some AI related stuff will find it's way in there someday.) The idea behind the helper files was just a set of functions, which you're not required to use, that can make it easier to make levels. They should be general enough that many levels can make use of them without any edits to them. If we find we have more common needs then we should be throwing more functions in there to handle them. I kinda want to keep one generic header file that includes all the other ones as they are added. That way you only need to worry about including that one file to make use of anything in the helper section. I would like to sectionalize things a little so you can also pick and choose what sections to include, if so desired.
The InitResources I sometimes question being in there, but it is very useful for testing. I think what I should do is extend the idea to setup resources for different game types. Multiplayer starting resources seems like the most important.
As for Eddy's code, that might be a good candidate to stick in there. I don't know though since I've never seen it and don't know exactly what it does, but it sounds like it may be useful generic code for making campaign missions. Of couse I'd like code to be largely stable before being placed in the helper files and I'm wondering about that. Is it generic enough that it won't need changes or does it just save whatever seemed useful at the time? Certainly the idea seems like a good one.
Levi: I think the idea behind that code was to save data while switching from one mission to the next. I can't see it having any real use outside of that. Save game files already have a system for saving DLL specific data to saved game files. Granted, it is a bit lacking in some ways so this may be useful, but there is still the issue of the level not being informed when a game is saved or loaded.
That mapstring idea also might be nice to include in the helper section.
A few enums will have further name changes. I think prefixes need to be added to names in the enums to prevent naming collisions. That is currently an issue with two enums in the project.
I'm also slightly tempted to throw the techID enum into the map_id enum since the wreckage function implies the techIDs were defined in the map_id enum. However I'd rather not do this since many people seem to like editing the techtree and those values won't necessarily be valid values for a new techtree. There can also be new techs added that aren't listed in the enum. I'd say we just stick with a new enum and type cast for that one function. Mind you, there is a similar issue with the SongIds enum and repacking the music file. But I'd suggest leaving the SongIds enum as is. Repacking that file is a global effect whereas the tech trees can be renamed for a more local effect. Plus, I don't want the SongIds enum to be left empty since it is exported by Outpost2.exe. Anyways, if we really wanted to add more songs, we could always add them at the end of the file. (Oh, and the map_id enum is huge enough as it is, and doesn't need to be bigger from merging it with another huge enum.)
