Thanks!
My workload was already mostly reduced by Tarvis, FekLeyrTarg, Sekir_Delyn, scotsdezmond, MjrParts, Laserschwert and other kind contributors. Without them, we wouldn't have gone too far.
They have dealt with some of the most time consuming tasks: to infer how many of the original game features work so that we can mimic it.
Tarvis and Laserschwert work on the iMuse system are some of the most impressive stuff I have ever seen, and one of the things that kept me coming to this project even when flooded with work in real life.
Then the amount of reverse engineering done by Sekir_Delyn and others about the internal workings of ship stats, weapons, damage, distances, speed ratings, etc is what allows this mod to get close to feeling like the original X-Wing.

It isn't really coding stuff. But it needs to be done because it's the skeleton of the game, and it is done basically by looking at how the game works, in detail. Or looking at the game files with an hexeditor or some of the old tools created in the 90s that time has almost forgotten. It takes more time and effort than anything else, really. And I am very glad that they have been doing it.
The more help, the better.

They main issue with this mod is that we aren't just "modding" an existing engine to use different resource files (music, 3D models, etc), or tweaking some parameters here and there. We are mostly reimplementing the engine from scratch because the old DOS executable cannot be really adapted to today's resolutions and hardware, and because the later games in the series that could run today (XW98, TF98, XvT, XWA) were severy altered here and there, what makes a faithful port of X-Wing impossible, or at least not close enough.

But we aren't either reusing another, third party, game's engine.
One reason is trademarks ( I don't want to make a copy of X-Wing that gets a Cease and Desist letter from Disney. I want to make an X-Wing mod, where the modded part is the engine executable, but it requires you to have the original game to run, because it uses the original assets. The Disney doesn't loose any money, noone is using their trademarks without permission, and everyone is happy.)

But the main reason is that X-Wing wasn't just a space game about blowing up ships. Every mission was a clockwork puzzle that you had to solve by flying a ship. Little changes on how things behave can send the balance of a mission out of the window. (You can see this in the XW98 edition, or in the many "ports" that have been made to XvT or XWA, or Freespace 2).
That is, in my opinion, the essence of X-Wing (and the whole series). If you loose that, you loose the main point of X-Wing. So it doesn't just work to adapt its missions to another engine and call it a day.

The closest projects I can think of are OpenTTD and OpenXCom (that reimplement Transport Tycoon and X-Com game engines, while using the original resource files).

About the coding work itself, I have not yet uploaded it to the repository in BitBucket.
Mainly because a code repository where several people work on should be something where the fundations of the code are already quite well established, and just more features (and bugfixes) are added over time.
I don't think the mod is in that state yet. I am still quite in an exploration stage where I make huge refactorings to the code when I detect that something is not proper for what it is supposed to do.

For example, just yesterday I noticed that the float type coordinates that are standard in Unity (the engine I am using) works great most of the time... except when you fly many kilometers away from the center of the map. There I started noticing that the targetting computer screen and other instruments in the cockpit start "vibrating" in a strange way. I suspect that is caused by the loss of decimal precission of Float with higher values, and I need to find a way to solve this. It could be something small, or it could suppose having to make huge changes throughout the code. I'm not sure yet.

I've had this happen too. You are right that it is floating point accuracy. I haven't tried fixing it yet as my game stays around the center, but I've read up on it a bit. One way is to make the world move around the player, which got complicated for me. Another is to "reset" everything every so many km's by selecting everything and moving the player back to 0,0,0.

Yes. Developing a game can never go in a straight line, huh? There always have to be lots of bumps and diversions at every step.
I think I will attempt to do what you mentioned last. Fortunately, the gameobjects in my code are separate object from the actual, logical, ships that are simulated independently. A routine of Ship<->GameObject binding occurs every frame, so I guess I could rearrange that to make the player's ship's matching GameObject always stay withing something like 10 square kilometers around the origin of coordinates.
The loss of precision leads to errors in the order of millimeters. It doesn't matter at all for objects of ship size (that measure tens of meters at least). But it does affect smaller objects like the interior of the cockpit and its instruments, where a shift in some few millimeters is totally noticeable as a visible vibration.

Let's see how this solution works out.

It worked like a charm!
At the beginning I tried to swap the player back to origin after it got more than 1km away from it.
But then I realized that the computer repositions all graphical game objects every frame anyway, so why not just keep the player always at <0,0,0> and shift all other objects based on that, always?
It's as simple as just subtracting the real position of the player from all the graphical objects. That puts the player cockpit at <0,0,0> while everything else remains at their relative places.
Of course, all vibration has disappeared and I am quite happy about the easy fix.

It took me a while, because I had some things heavily coupled between the "logical" ships and their graphical representation that needed to be put apart in order to make this work.

As an additional product of this, I have figured out that doing this can really simplify some other stuff that is overcomplicated in my code, so I am right now refactoring it a little bit. This will result in faster code, that at the same time is less dependent on the Unity game engine, and more portable.

After this, I will finish the hitpoints and damage routines, and then we will have some real combat that I can share in a demo file.

I'm so excited for this.

Isn't this also the way the DOS-versions of X-Wing and TIE Fighter handle things? I think I remember reading something along these lines.

They did, yes, but I think because of a different reason I suspect.
As you say, in X-Wing and TIE Fighter the player ship was fix and not moving at all, and it was the rest of the "world" that moved and rotated around the player's ship.
Back in the 90's, I remember reading this book as my introduction to 3D graphic programming. That book explains step by step how to create a 3D flight engine for DOS, and they used exactly the same technique of keeping the player's "eyes" fix, and moving and rotating the world around them.

The main reason that they gave for doing so was that the math for translating, rotating, clipping and filling polygons (they had not textures), was quite complex and had to use floating point for the precise placement of the vertices, and most CPUs back then didn't have a "Math coprocessor", that is a piece of hardware specialized on doing complex math operations that otherwise needed to be simulated in software, and be much slower.

It seems that having a camera that can move and rotate itself complicates the math in a great deal, and it would be too slow for those poor 286 and 386 processors out there (I had myself a 386) to perform all those operations by software. So the main approach to solve this problem was to translate just every other object around the player, that is a much "cheaper" alternative.

You can see this very clearly in TIE Fighter, when you open the map. The map is a snapshot of the world in the moment you press the M key, and you can perfectly see how everything is rotated around your ship.

I remember reading from Peter Lincroft (3D programmer of the whole X-Wing series) that they had a hard time when they started with X-Wing versus TIE Fighter, because the multiplayer was totally incompatible with the "playercentrism" of the engine (since there are several players now), and basically needed to put a great effort at redesigning the engine so that the position of the ships would be independent of the point of view of the cameras.
XvT had to wait to 1997, when everyone was having Pentium CPUs and DirectX was established.

You can tell that the move to multiplayer was a significant amount of work by looking at the release dates of the different versions of the flight engine.
1988: Battlehawks
1989: Their Finest Hour (1 year development)
1991: Secret Weapons of the Luftwaffe (2 years development)
1993: X-Wing (2 years development)
1994: TIE Fighter (1 year development)
1997: XvT (3 years development)

That also explains why the X-wing vs Tie Figher presentation was relatively barebones with a lot of missions that had text-only comm chatter, reprogramming the engine must have hit the budget pretty hard.

Most likely. Didn't several games from LucasArts around the same time have a very similar, barebones presentation?
(I think I remember Outlaws having the same sad "datapad" look and feel).
Anyway, this interview is pure gold for those wanting some insight on its development of the flight engine for XvT.

Outlaws is one of the few old Lucasarts titles I haven't played yet.
Uhm, I think it was more a trend than budgetary reasons, Jedi Knight had a barebone interface but also lavish FMV cutscenes, and both Monkey Island 3 and Outlaws had cartoon cutscenes that given the quality they probably weren't cheap.
It's more likely that the data pad was going to be there regardless of budget to be able to seamlessly pass from a side to another (the X-wing Alliance multiplayer interface was following the same template, just with a holosimulator theme), I think the fact that the game doesn't have as many voice overs as Tie Fighter is what hits the presentation harder and may have most likely have been due to budget constraints.

It could be a combination of different reasons. As you say, a trend among LucasArts games to develop one unified common datapad-style "frontend" for most their games, more or less independent from the gameplay engine of every game, but that would share some software like netcode or settings.
Perhaps this was caused by Edward Kilham leaving Totally Games after TIE Fighter was developed.
Kilham was the "brain" behind the cutscene and concourse systems in both X-Wing and TIE Fighter. The concourse frontends in these games are basically a looping interactive cutscene with actors, animations and iMuse events.
Kilham leaving would surely push them into using a more boring frontend, and it seems that they just cobbled something together or grabbed the one that was being developed for other games at LucasArts.

Other games at lucasarts had very different interfaces however, the interface for XvT has a very different layout with the icons on top and left which wasn't used in any other Lucasarts game, they all tendend to use a main menu not unlike what you'd see on a console, and the graphic adventures always had a simple menu accessed by pressing ESC or F1.

I went and checked some Outlaws videos in YouTube and you are right. It looks totally different from what I remembered.
The only thing I can say is that perhaps I only saw a demo version that had that simplified menu style. Or some weird edition. I am puzzled now...

Progress update:
So far, flightgroups popped out from thin air (or thin vacuum) when they needed to spawn. Yesterday I finished the "Launch from Hangar" AI Task for those ships that come into the game launched from a mothership.
This requires two points defined in the mothership: a hangar point and a rally point. Ships launching from a mothership spawn at "hangar point", looking at the "rally point"'s direction, then they beeline in formation at full throttle to the position in space where the "rally point" was when they spawned (because the mothership could be moving).
Once they reach the rally point, they carry out their normal orders.

This all is working pretty fine, but I have some dark spots still on the whole picture of this. Perhaps you people can contribute your observations:

- Where are the Hangar Point and Rally Point defined? In the ship model file? (I think XvT and XWA do this, and these points are defined in the models OPT files) Is it perhaps defined also in BFLIGHT.OVL like all other hardpoint positions and types? So far I have hacked a couple of points in the Unity prefab I use for the frigate Vehemence in Rescue Ackbar mission I am using as template for building the flight engine. But I suspect this should be read from somewhere else?

- What happens if flightgroup T/F Gamma wants to spawn and it has assigned as a mothership not one single ship, but a flightgroup of ships? For example, a flightgroup of two frigates. From which ship in the mothership flightgroup are they supposed to spawn? And what happens if that ship is destroyed? Do they keep spawning from another mothership in the flightgroup?

Another week, another update:
I am in the middle of implementing the damage system so that we can finally blow up some TIE Fighters (and be blown up by them).
This is a screenshot of the current build.

Latest addtions are:
- The iMuse system reacts to events ingame. It changes theme based on the presence and distance of enemies or neutrals, targetted ship on the reticle, and the "new enemy craft" musical events.
- Forward and rear radar scopes added. As you can see in the screenshot, instead of dots, I am using the ship icons, that provide extra information like what ship type it is, and their movement direction in respect to the players ship. I think that alone justifies the replacement of the dots for the icons. But also, I must say it looks really cool in movement. It reminds a little bit to the targetting computers in ANH when those TIE Fighters icons move and spin like little evil things. :)
- As mentioned in a previous mail, all vibration in the instruments has disappeared thanks to the fix to the float coordinates inherent imprecission.
- Added the mission message log as a screen on the right side of the cockpit. I would like to know what you think, but I kind of like that the useless parts of the dashboard are given some use. Also, the message log doesn't obscure the viewport (as it usually did in XvT or XWA), affecting the dogfighting and immersion. If you like it there, we could think on building some 3D monitor to encase it, just like the one of the targeting computer, for the looks.
- The mission timer to the left of the targeting computer is also added new. It counts up, instead of down, yet. But that is easy to change. Also, it kind of makes sense for knowing how long ago an event was registered in the message log, right?

I can't wait to get my hands on this once it is finished. :)

Would you be interested in having an unfinished A-Wing cockpit as placeholder?
http://p3d.in/5tvwQ

And I'd be happy to provide you some target reticules as well. :)