Thinking further about this...
What would be a suitable realistic distance between planets?
Surely in real life two planets next to each other would have catastrophic consequences. Our moon is small and quite far away, and still produces tides. Surely, two planets need to be really far apart or their gravitational interactions would make the whole thing unstable...
Although this is StarWars...

Anyway, I don't know if the original game limits the amount of planets present on a mission somehow. Can we add 10 planets to a mission and they all appear on screen?
I guess a way to solve this would be not to allow planets to be at the same distance from the camera, even when we let them be at the same "angle".
Since in the original, there was no representation of different distances for the planet sprites, we could make the closest planet to the center in the mission map be also the closest one ingame. Then any other planet in the mission would be placed ingame a bit further away.
In the case that someone places a lot of planets in a big clump, the result in game would be something like a planetary alignment, with the first planets eclipsing the later ones.

I completely agree that planets being placed too close together stretches believability - the only way it works is if one is much smaller than the other and so becomes a moon of sorts.

As for the original game, I'm not sure, but I'll try and test on Sunday if I get some time - it shouldn't be too hard to set up a test mission with 10+ planets in different vectors relative to 0,0 to see what happens.

Your proposed solution of keeping the distances separate sounds good, and seems a straightforward way to prevent much weirdness.

--
Thinking about special cases around the death star in TOD3 (firmly in the "nice to have" category):
- In the comm sat mission, being able to see the Death Star and Yavin at the same time would be cool - especially if the relative scales were at play.

- In the two death star surface missions, also being able to see Yavin in the sky would be visually stunning (or even if it was just on one of the missions, explained by both missions taking place on different parts of the surface).

I've not looked at the mission files for these missions so I'm not sure, but I seem to remember a planet representing Yavin being included in the comm sat mission - not sure about the others. If they aren't in the vanilla files, and if we did want to implement this, it might mean having to resort to some kind of override (based on mission name/number combo perhaps?)

Since you can't see Yavin in either the original X-Wing game OR A New Hope, I'm gonna go out on a limb and say that Yavin happens to be on the other side of the Death Star, eclipsed by its size. I think having the giant planet looming in the background during the trench run would be distracting. That said, in the mission before the surface? Definitely would be awesome.

I have been playing the test mission on X-Wing DOS and X-Wing 98 in particular in order to check how did they deal with the higher resolution and planet backdrops (they just look smaller), but I noticed something else.
While in the mission file it specifies a "Ring world", in the game it doesn't look at all like a planet with rings. Instead, it's more like a brownish planet with two smaller dark moons nearby.
I don't know if it's a case of art mismatch or what. I think we will need to test will all possible planets.

About the Death Star surface missions, they are still far in the horizon.
They are kind of special, and use all kind of stuff not used in the rest of the game:
- A terrain with lots of details.
- The terrain is procedurally generated, and virtually infinite in any direction. However, it wraps around itself after some distance, at list horizontally (you can test this by going invulnerable on the trench towards the wrong direction. After many minutes, you encounter the exhaust port's from behind).
- It has procedurally generated turrets that aim and shoot. Technically, an infinite amount of them, but they are always at the same places.
- It has a trench that is visible from regardless how many kilometers away. You can always distinguish the dark grey line crossing the surface if you look at its direction.
- Buildings and turrets, even when they are infinite, can be destroyed, and the game remembers which ones are destroyed and which ones aren't.
- There is a goal to destroy all turrets within certain distance from a point.
- The trench has a boost effect on the player.
- The exhaust port cannot be tartgeted or destoyed, however it can detect if hit by a torpedo at the right angle.

Overall, these stages are like a game within a game.
It's also interesting to observe that even when Totally Games had this part of the game developed already, they didn't revisit it at any point of the series. Not in TIE Fighter, XvT, or XWA.
Not that they would have you destroying the Death Star again in every game. But having some atmospheric missions with terrain and buildings on some planets. Having done the Death Star, I cannot see why wouldn't they just reuse what they did changing the graphics to something else.

About seeing Yavin from the Death Star surface, I don't think it would be so distracting. Especially when you are flying around turrets and buildings.

Progress update:
Lately I have been working on the mission goals and mission state.
Currently, I have kind of finished the code that checks every mission goal and determines if it is completed or failed.
There are very few different mission goals in X-Wing, compared to any other later game in the series.
They are:
- At least one ship of Flight Group must arrive.
- (100%, or 50%, or the special ship) of Flight Group must ...
+ ... be destroyed
+ ... be captured
+ ... be boarded
+ ... be identified
+ ... complete its mission
- Mines destroyed
- Satellites destroyed
- Probes destroyed
- All Death Star surface turrets within certain distance of a point destroyed
- Death Star exhaust port destroyed

And that is about it. I'd say, 95% of the missions in game ignore the last 5 ones.

At this point, the program can tell whether a goal is achieved, failed, or is yet unresolved. However, it only checks whether it has failed by accounting only for the current state of the related flight group, not other flight groups.

That means that if one of the mission goals is to destroy 50% of transport group Omega, and 51% of them manage to escape, the goal is considered failed.
But it doesn't check whether the goal has any chance to be accomplished at all anymore.

For example, let's say that Shuttle group Uno comes into the mission after one minute from the start and leaves a while after. They must be destroyed for cruiser Maximus to arrive.
That cruiser Maximus arrives is a mission goal. So to complete the mission, you obviously need to destroy shuttle group Uno for that to happen. But that shuttle group Uno is destroyed isn't a mission goal by itself. Only the requirement for another flight group to arrive.

Then what would happen if one of shuttle Uno escapes into hyperspace before destruction?
There is no goal requiring all of Uno to be destroyed, so the mission will not fail.
However, because not all of Uno have been destroyed, CRS Maximus won't arrive, so the mission won't get to be completed either.

X-Wing is famous for it's lack of "Mission Failed" message, that caused to much annoyance to players, that were left in "walking dead" situations when they missed one requirement and the mission wouldn't tell. I wonder if this is the cause of it.
Missions that have "goal" flight groups depending on the behavior of other flight groups that aren't goals themselves, but that can fail to do something that needs to be done for the real goal to be achieved.

It is not as simple as saying "Just check deeply everything".
Imagine that you are in a mission on an X-Wing.
There is a rebel transport called A that needs to come from hyperspace, board another transport B, then depart. This is the mission goal. "TRN A must complete mission". That is it.
Now, that other transport B needs to be disabled for A to arrive.
For it to be disabled, Y-W group Blue needs to come from hyperspace and disable it.
For Y-W group Blue to come from hyperspace, all of T/A Alpha need to be destroyed.

What if any of T/A Alpha escape into hyperspace? It's not a mission goal that T/A Alpha must be destroyed, but it will prevent a chain of events from unfolding that would lead to the completion of the actual mission goal.

If the program needs to check everything, then it would start by the actual mission goal (Transport A must complete mission) and check if it can actually complete it still has a chance to complete its mission, that is to board Transport B.
Transport B is around, alive, so then it needs to check if there is a chance for anyone to still disable it.
Y-W Blue is not around, so it needs to check if there is a chance that Y-W Blue can arrive.
That is, it needs to check that all of T/A Alpha can be destroyed.
et cetera

This can lead to a lot of check at different levels of recursion that could really complicate the programming, but also lead to scenarios of infinite checks in case someone makes a mission with circular goal requirements and wants to test it. That would make the game hang, or I would need to detect and prevent cycles in the requirements by creating a requirement graph and running a cycle detection routine on it.
It starts sounding too complex for a Star Wars game, doesn't it?

I am trying to remember if this situation happens in any of the later games in the series.
Did TIE Fighter have anything like this scenario in any mission? I just want to know if those games spent more time deeply checking all possible causes that could render a goal as failed, or the mission designers just were more careful to mark all requirements for a "goal flightgroup" also as goals.

TIE Fighter definitely has better goals checking, e.g. if a transport that needs to be disabled escapes into hyperspace, the mission fails immediately. I very much doubt (though have not tested) that it would check for circular logic failures though.

As you mentioned, a requirements graph is a potential solution. Thinking out loud, using the mission goals as a starting point, building a list of mission crifitical craft, and then checking spawn conditions against all flightgroups and graphing the results might go some way to implementing this, with circular logic detection.

In the event of circular logic, what would be the best way to handle it? Display a message before mission start saying that the mission is uncompletable, and starting the mission anyway in a fail state? Or refusing to load the mission at all?

What I have programmed also accounts for simple things like that, when a transport that needs to be disabled escapes to hyperspace, it is easy to detect.
What is not so easy are those, more complex, examples I described in my previous post.
For example, when a transport needs to be disabled, but the only ship that can disable it is destroyed. If the mission goal list only accounts for "Transport needs to be disabled" and not for "Y-Wing Blue needs to complete mission", then the destruction of the Y-Wing leads to a not easy to detect walking dead situation, where the mission is at the same time not failed, but not completable.

A requirement graph is easier said that done, though. It can be done, but my first attempts to model it showed deeper implications.
My initial solution was an algorithm involving hidden goals. A hidden goal is a goal that counts for the failure or success of the mission, but is not shown to the player.
1 - For every goal in the mission, inspect the related flight group's arrival condition. If the arrival of the flight group depends on another flight group meeting some condition, add that condition as a hidden goal.
2 - Repeat 1 for every hidden goal added.
3 - Repeat 2 until there are no more hidden goals added.

That would solve the case of flight groups that have goals attached not arriving because some other flight group never meets their arrival condition. And so on and on.
A quick cycle detection mechanism would be as simple as checking that you aren't adding a goal that is already on the goal list.

Unfortunately, it doesn't fix many other cases.
For example, transport Sigma needs to be disabled. That is the goal. The transport doesn't depend on any other flight group to arrive, so there are no dependecies to anyone else. However, the only ion bearing ships are Y-W Blue that arrive only after all of T/A Alpha have been destroyed.
Even when we can trace a dependecy between Y-W Blue and T/A Alpha, we cannot trace any between Y-W Blue and
Transport Sigma.
Unless we start tracing dependencies between the goal of being disabled and the fact of carrying ion weapons. But then that could trace dependencies with all rebel Y-Wings in the mission (and B-Wings, and rebel Transports), even those that have other objectives and goals and are totally unrelated!

We could still end in a situation that after some T/A Alpha escapes, and so, Y-W Blue will never come, and so Epsilon won't be disabled, the mission will not detect this as a fail, because there could be other ion carrying ships around, that won't actually attempt to disable the transport, but they might, perhaps? So we are again at square one.

You could say, "Discard all other ion carrying ships that don't have Epsilon as primary or secondary target and 'disable' as orders".
Yes, perhaps. But the logic is getting more and more complex, and takes months to implement and debug. :D

I just wonder if all this is worth the effort, or most of the time the developers made sure that all critical craft were marked as mission goals.

I like you idea of the game warning or rejecting a mission when it detects a goal requirement cycle. I wouldn't enable that for all situations. Sometimes you are building a mission, and you do it in several stages, where you check how ships behave and most of the time don't have the whole goal list ready, or even designed.
So it would be disabled for testing. But if you want to "publish" your mission, you need to have a valid, complete-able goal list.


PS:
Just thinking on another case that isn't trivial to detect and actually happens on the test mission in XWVM.
In the mission, the goals are:
- The special ship in SHU group Epsilon must be boarded.
- SHU Hasti needs to complete its mission.

SHU Hasti comes when you first identify any ship in SHU group Epsilon. Then it starts boarding the first shuttle belonging to Epsilon group that you disable.
What if you disable any of the non-special ships in group Epsilon?
Hasti boards that ship and hypers out completing its mission.
However the mission is not completed because the special ship in Epsilon hasn't being boarded.
But the mission isn't failed either. It's just in "walking dead" state.
How you detect that "The special ship in Epsilon" cannot be boarded anymore?
As you can see, it becomes trickier and trickier.

The parts are breaking off now? Really nice

What do you think about the models from this artist, i.e. stormtrooper transport https://www.artstation.com/artwork/aa2JJ.

Maybe you can get in touch to get some collaboration going?

Those models look gorgeous. I don't think I have seen a better DX-9 transport anywhere else. But Factalsponge's models are all awesome. My favorite is his Assault Gunboat.

However, those models aren't proper for realtime 3D engines (videogames). The amount of detail is just too much to handle. These are more for renders, where each frame can take up to several minutes to fully render.
You can use them for the CGI for a movie (where the complexity of a model is irrelevant, as you have all time in the world to produce the rendered sequence), but not for a videogame (where model complexity is critical, since you need to render all ships in a frame, 60 frames per second, and the more complex a model is, the longer it takes to draw).

I guess we could ask him for permission to use his models (or his renders) as references for creating our own low poly versions of them. What in his models is geometry detailing, in ours should be just textures and bump mapping.

It's a tricky issue, to be sure.

I don't think it is feasible to account for all potential failure scenarios, but I think it might be possible to catch some of the more annoying ones.

From what I've observed, most of the issues that cause missions to become uncompletable fall into these categories:
- A critical ship is not spawned because the arrival condition is not met
- A critical ship is not disabled because there are no craft capable / allowed to disable it (based on allocated flight orders).

As previously discussed, the first category is quite difficult to fully account for without extensive / recursive graphing, and even then may not be perfect. What might be an option is to keep track of when a FG will definitely not spawn because the condition can never be met (e.g. FG spawns on a time delay from a frigate that has been destroyed).

The second category should be possible to do, if maintaining a flag for all ships on the map (and those still in the spawn queue/set) at any one time indicating if it is capable of using ions (something like CAPABILITY_DISABLE containing True/False ?) and an array of allowed targets, based on primary and secondary allocated orders.

If a ship needs to be disabled (and the player is not in an ion-capable craft), the engine could check every x ticks against ion capable craft and their allowable list of targets, to see whether the critical craft are contained. It would also be necessary to check if friendly ion craft are still capable (as far as we can tell) of spawning as part of this check. If the check fails, perhaps a warning icon could be displayed in the corner of the targetting computer (or somewhere in the cockpit) to indicate the mission may not be completable?

Attempting to express this in pseduocode:
if(!(ionCraftArray.getAllowedTargets($critical_craft) || spawnQueue.containsFriendlyIonCraft() || playerIsIonCapable() ) ){
display_mission_uncompletable_warning();
}

--
Also, that latest screenshot looks great - the shuttle blowing apart is really cool, the mission goal screen is handy and the throttle indicator has a nice effect.

We will monitor the situation with the goal checking. If it proves to be annoying (meaning that many times the player is finding himself in an unwinnable mission that isn't reporting Mission Failed) then we can put more effort on making the goal checking error proof.

In the end, I think it will be basically how you describe it, Scotsdezmond. Some hardpoint and primery objective checking code can determine if there is a chance that a ship will be disabled or boarded.

In the meanwhile, I had some few minutes to spend on the game, so I attempted to implement a first try of that idea about the 3D planet backdrops with a dedicated unmoving camera that matches the rotation of the player's camera.
This are the results.

That planet has two moons (one is eclipsed by the planet). Actually, they just are a 1 meter diameter sphere for the planet, with a 1.1 diameter semitransparent sphere for the clouds, and the moons are two 0.1 meters diameter spheres.

Of course, someone with an artistical talent could do better work than me on the planet materials and all of that. But I think it doesn't look bad for a first try.
What do you think?

I like the look of the planet / moon - having true 3D celestial objects seems to make the experience more immersive, in my opinion, and a separate cloud layer does make it look more dynamic!

I did notice that the object on the right seemed slightly distorted - appearing more like an oval than a sphere - but I suspect this might just be the FOV being used?

Yes. I might need to play with the "planetary camera" settings. The planets are spheres, but I guess, the closer they are to the edges of the field of view, the less circular they look.
I added a really slow rotation to the clouds layer and to the moons, so during the course of a mission you can see some moonset and moonrise. All these settings could be also randomized and seeded by a hash of the mission name or something.

I think I will next work on letting the user remap their input method, and make the frigate properly shoot and move. Also, replace the frigate's XWAU model with something else. Once this is done, we would be ready for a first dev-test release that you all could download and play.

Remapping joystick buttons make sense, but I would keep the default X-Wing series keyboard mappings, since the commands are already ingrained in our brain. I would say this is not of high priority.