Awesome! Good luck!

Yes, that would be nice.
But at this point, that is eyecandy. If I find a way to do that that takes me 1 hour to do, sure I could add it at this point. If it is gonna take me more than that, I would leave it for one of the polishing passes later on.

Edit:
I have searched for something fast to get it done, and I have found this, paid for, asset: https://youtu.be/OmOsyQFgI8s
Do you think it would work? It somehow reminds me to the scene when Luke is shot down on his snowspeeder during the Battle of Hoth. Or when R2D2 is disabled by the Jawas in Episode IV.

I like that Unity lightning demo, looks very nice.

The original source of the 'disabled ships' effect is probably from this scene in The Empire Strikes Back: https://www.youtube.com/watch?v=5BkOVSFb2Zw (at 2:43).

The effect is more... limited in that scene than in XWA.
In the movies, ionized ships seem to spark with the ion energy for a few seconds, then stay basically dead, maybe because their electric systems are fried or something after a EMP blast.
In XWA, though, it is more like a running effect while they are disabled. Like if they were constantly being struck by lightning bolts.

It certainly add something over how it is in X-Wing, TIE Fighter and XvT. But I wonder whether they overdid it a little bit.

Adywan added some rather subtile lightning to the disabled Star Destroyer in "ESB: Revisited". I think that looks nice as well.
https://youtu.be/MnhyN6Jf1Fg?t=2m49s

Did you notice the shield hits in my game Az? I paid for an fx asset thing already...nothing says I didn't buy it for this :)

Progress update:
- AI manages their power settings. When a shielded ship is under 75% shields, it will set shield recharge to "increased". When under 50%, it sets it to "full". In any other case, it sets it to "Balanced".
These figures are chosen by intuition. It's clear that shielded ships in X-Wing recover shields by incrasing their shield power setting. You can tell that they move more slowly and the "Shd Dn" status moves back to "Ok", especially Shuttles.
However, I cannot tell which particular thresholds they use, or if whether is related to AI rank or not. In my current build, all AI ranks do this.

- Ships come out of and leave into hyperspace. The hypering in and out "sublight jump" feels a little bit faster and shorter than in the original X-Wing. But it also looks closer to how it is in the movies and series, so I am inclined to leave it like it is until you people can see it and give your opinion on it.

- Boarding, docking, capturing, cargo taking, cargo delivery, cargo exchanging, and destruction of the boarded craft are implemented. Shuttle Hasti finally comes to board Epsilon 3 and take Ackbar home!

- Escorting ships leave when their orders are completed or cannot be completed. Y-Wings Blue no longer stay to help when Hasti has left or been destroyed.

- General improvements to formations. When the formation leader is destroyed or disabled, another ship in the flight group is elected formation leader and the rest form around it as pivot.



Bonus Track:
On Mice and Models

Apart from that, I have been researching how to dynamically import ship models into the game, both for modding purposes and for having a systematic way to create the models we are shipping XWVM with.
- OPT importing would be great as a backup alternative to have. It would not only allow the game to use the X-Wing 98 edition models, but also some others like from original XWAU models downloaded from their site. However, building an OPT importer would be a project on itself. Since we have not shortage of quality models made by our community, I am giving this a low priority.

So I will focus on importing the realistic models made by MajorParts and other potential contributors, as well as the retro style models made by FekLeyrTarg.
The Unity engine is great at importing models, but only at development time.
That means, that while I am developing the engine, I can easily import virtually any model (it supports tons of different formats). So it is really easy to decide a set of models to have, and have them from the get go.

However, this all changes at runtime. There isn't a trivial way in Unity to import a model when the game is compiled and installed on the user's computer.
That would be the scenario for "modding", where the game is already built, but it needs to allow the user to alter its contents without rebuilding it.
So a solution needs to be developed to allow the user to "mod in" new models. That is, to import models at runtime, as opposed to during development.

Then again, by thinking further, if a solution is going to be developed for this scenario, shouldn't we just factor out unnecessary redundancy from the code by making _all_ models being imported like this, instead of having two different ways (at build time, and at run-time)?
We could treat the base set of models, our models, the "default mod" that is enabled when the game is fresh installed.
Or actually treat the "Realistic models" and the "Retro models" as two mods that come packed with the game, and you choose one of them, whichever you prefer, when you start the game.

For that scenario, I have found two solutions that seem to be used in many Unity-based games (in particular, it is very clear in a successful virtual tabletop game in Steam called Tabletop Simulator).
- OBJ models, with textures and metafile, zipped. Let's call them OBZ for short.
- AssetBundles.

I will explain each:

OBZ
You can make a 3D model in any 3D modelling tool, like Blender, 3D Studio, Maya, etc. Then they save the model in their own format or they export to a choice of kind-of-standard formats like Collada, FBX, or OBJ.
In this case, we would choose the OBJ format. That would export the model geometry in a OBJ file, plus all the used textures in independent image files.
Then we would have the metafile, that is a text file describing how the textures are applied to the geometry (materials), plus all information related to spaceship itself in X-wing (where are the cannons, the cockpit, what part of the geometry are the wings or the fuselage, where are the hitboxes, the different LODs, etc).

This file could be created by hand, or assisted by some tool or Unity editor.

AssetBundles
AssetBundles are the Unity propietary way to pack assets together and load them at runtime.
For our purposes, the model artist would need to import their model into a Unity editor window, configure all materials in there, generate the metainformation about the starship, and then export the whole ship as an AssetBundle. Then the AssetBundle is loaded at runtime by the game and everything works fine.


Pros and Cons:
OBZs would involve more development time: Code for reading OBJs is available, but then it becomes almost mandatory to develop a little editor to glue the geometry, the textures, materials, and ship information, all together in the metafile. Otherwise an artist could get crazy if they wanted to fix all that information by hand.
In the positive side, this would make it totally independent from Unity, and somehow, I feel that importing from a OPT file shouldn't be much different so, somehow, the effort could be leveraged in the future.

AssetBundles are simple to make. Just import the model, make some pretty materials for it, assign shaders or whatever. And decorate the meshes with ship information. Then export. Done.
The cons are that the artist needs to have the Unity editor installed in their computer to make the AssetBundle. Also, this ties us totally to Unity.

Exciting progress! Looking forward to playing around with this.

On a purely selfish note, I'll vote for OBZ, simply because I happen to have a repository of incredible ships for Fate of the Galaxy that I've already converted to obj for our website's ship database. So I could create a pack using those ships to play with - of course I couldn't distribute it to anyone (with the possible exception of other members of the FotG team).

Wow! That sound like excellent progress!

Good ideas with the two options. I would wager that OBZs would help the game have a wider appeal since it would be easier for anyone to add in their own models. That's just my two cents though. Good luck on whatever option you decide on!

I think, with a proper editor, going down the OBZ route sounds more flexible.
IIRC, Freespace 2 does something similar.

I think it's the most "future proof" solution. Everyone can make OBJ models, since it's basically an industry standard and almost every modelling tool can export to that. Also, it is simple enough to be imported by the game.
It has some problems, though:

- Material information is lost. When importing the models, you will need to create new materials for the ship. This is kind of expected. You can tweak many sliders and play with the shaders in Unity materials, so of course it wasn't going to match how materials work in modelling tools. UV mapping and texture files will still be there, but I guess the importer will need to allow you to choose textures for the albedo, bump mapping, etc, and play with some sliders and parameters to leave it at your taste. Then these settings would be stored in the metafile.

- Mesh hierarchy is lost. This is also annoying. When importing the model, you will need to group the different meshes to form up ship parts (a wing, the cockpit, the engines, the cannons). Then establish the hierarchy again: the cannon belongs to the wing, the wing belongs to the fuselage, the fuselage belongs to the ship.
This is necessary mainly for when ships explode, and the different parts break of. Also, if we had a targeting computer that let us select individual ship components, like in TIE Fighter, this would be needed.
We can circumvent this limitation by establishing the hierarchy in the mesh names. So the cannon mesh could be called "Wing.Cannon" instead of just "Cannon", so that the importer knows that the Cannon should be a child of the Wing in the hierarchy tree.
All this info would also be saved in the metadata file.

Sorry for the spam.

Last evening, following some playtesting by MajorParts, I spent my time trying to solve a problem regarding how the AI is supposed to change their mind on the fly to better follow their priorities.
The scenario was this:
In the test mission, there are several group is TIE Fighters that fight the rebel ships. One particular group, TIE Fighter group Delta, has as priority the rebel shuttle Hasti. If Hasti is destroyed, the mission is failed.

Well, it can perfectly happen that T/F Delta come to the mission before Hasti does. In that case, they target one of the Y-Wings and dogfight it to death.
It may then happen that Hasti arrives, rescues Ackbar and escapes into hyperspace before the T/F Delta is able to finish off their targeted Y-Wing, so the mission becomes much easier since there is no threat to the rebel shuttle.

Obviously, the solution to this is that T/F Delta must be on the look of the arrival of their primary objective. So now, during a dogfight, and about every 5 seconds, every ship will spend some milliseconds reconsidering if there is a better target for them to attack.

It was a quick solution to the problem, but now I wonder if that would be the most appropiate, or there could be a better one. You can now notice how the ships pause for a fraction of a second, during dogfights, selecting a better target. They seem to be cleverer now, but I somehow feel that this isn't how ships behave in the original game.

What are your impressions on this? Have you been dogfighting an enemy that all of sudden ignores you and goes against another objective?

That is definitely a nice behavior to have in the AI, at least even for the 'brutal' mode if it doesn't fit into the old style of gamelay.

Okay. I am going to ask for some help here with a riddle, because definitely several heads think better than one or two. :)
Also, some of you have some expertise with editing missions for the original X-Wing.

The riddle is this:

XWVM reads the mission files from the original X-Wing mission file folder. The mission files have a binary format that is not self descriptive, but it mostly figured out after so many years.
However, there is a field I don't totally understand it's encoding to read.
That field is the Arrival Delay field for every flight group. When the Arrival Condition of a flight group is met, then there can be an period of time that the flight group needs to wait for before actually arriving to the sector. This amount of time is specified in this Arrival Delay field.

The field in the mission file is encoded with one number. By using some editors, I have compared the number encoded with the amount of time it represents. Here are several examples:

Encoded -> Time in game
1 -> 1m
2 -> 2m
26 -> 36 s
44 -> 2m 24s
47 -> 2m 42s

So, from those samples, can anyone find out a general way to turn the encoded value into an amount of minutes and seconds?
I have some hypothesis, but it doesn't work with the first two samples:
Seconds = Units of the encoded value, times 6.
Minutes = Tens of the encoded value, minus 2.

This works for 26, 44 and 47. But not for 1 and 2. For these two, it seems like
time in minutes = encoded value.

Some notes:
Editors (both XED and XWMB) don't let you enter an amount of seconds that isn't a multiple of 6. You seem to be able to enter any amount of minutes. And actually, you are even allowed to enter minutes and seconds in a way that they overlap. For example, editors let you enter something like 2m 120s, that seem to translate into the encoded value 60 (that matches my hypothesis).

Any brilliant mind sees a pattern here that corrects my hypothesis to cover also the 1 and 2 values?