Hi, new user on the board, just saw the youtube vid for this project a little bit ago and dug into the thread to see what was going on and had some ideas...
First of all, the limited craft selection issue that was brought up in the last couple of pages:
IIRC, the core problem is not that there are limited craft, the true problem is that the original game engine and the mission file format uses a unique identifier for each ship type, the data type for which is kind of small. I don't remember exactly what the number was, but it might have been something silly like six bits (64 possible ship types) in X-wing. (it's been a long time since I tried building missions for that game. A very, very long time).
Which means that without modifying the file format for the missions, there's no way to add more than whatever the highest valid value for the "ship type" variable is... as long as the executable uses the same behavior as the original.
IIRC, the original executable had an internal list (or was that a central external list, don't remember) of what ship went with which number - 1 for X-wing, 2 for Y-wing, etc (probably completely wrong, but you get the idea), so it would know what to load when it parsed the mission file. What you could possibly do to fix the issue of limited craft selection though is make individual lists for each battle or even mission, and then make the game check whether there was one of those before deciding which resources to load.
The end result would be that the original mission files are unchanged (yay!), but creators of custom missions would have access to any 64 or 128 or whatever ship types available to the client - which is more than the number of flight groups the game engine allowed you to spawn in the original game in the first place, if I remember correctly.
If you make the custom craft lists point directly to filenames for individual craft, you have basically infinite available ship designs, and you wouldn't get stuck with incompatible addon ships trying to use the same ID in the central ship list.
(This is the kind of thing that can only be done when you're writing a new executable file, but it's a thing that *can* be done while writing a new executable...)
Internally, XWVM will identify ships not by number but by ID. This ID will be a string. For example, the X-wing will have ID "xwing".
This removes any limitation and incompatibility and makes it future proof.
When reading the original mission files, we translate their format on the fly to our internal one, so it doesn't really matter much to how many different ships the original game was limited to.
We aren't limited by their file format in that sense.
Of course, if we eventually add a Mission Editor to the game, we cannot use the XWI/BRF original file formats, but our own (that will be probably XML or JSON based).
That means that in a possible
future, XWVM will be able to read and "play" mission from X-Wing or from TIE Fighter, even when those formats were totally incompatible between each other and ships had different identifiers (for example, the B-wing is ship 18 in X-Wing, but ship 4 in TIE Fighter, and the Advanced TIE existed in X-Wing but not in TIE Fighter).
Apart from this, there are some "world settings" that are different between games, and that could be made also configurable depending on the mission loaded.
For example, laser and ion speeds in X-Wing are much slower than in TIE Fighter. When loading a XWI/BRF mission file, the XWVM engine would load the X-Wing world settings. However, when loading a TIE mission file, it would load the TIE Fighter world settings.
For custom XWVM-made missions, we would either let the creator choose between both (if you have player the Super Mario Maker game in WIi U or 3DS, you wil immediately understand this), or fine tune them to their taste.