That's an interesting point - I am curious myself, as this project has inspired me to begin putting together a full-size campaign with the hope that one day in the future, it might be playable in XWVM, and wondered how the cutscenes would work.

I made one observation related to docking and capturing while creating a mission in X-Ed, which was not really a surprise to me but was an interesting confirmation of behaviour. (Note: I was playtesting in the original 1993 DOS Floppy version - without B-Wing installed)

In the test mission, I created a FG of 6 containers (Chi) which are to be captured - 5 have normal cargo, 1 has special cargo. I have a trigger for a FG of shuttles (Blue) intended to do the capturing (Board to Take order in X-ED) and are set to spawn when the containers are ID'd. My original intention was that the player would need to ID all 6 containers, then a shuttle would spawn and do the capture of the containers (in a round-robin fashion).

After trying the mission, I found my assumptions were a bit faulty:
- Using the "spawn after CON Chi is identified" trigger actually only waits for one (any one) of the containers to be ID'd - not the whole group - in this context, the one with special cargo is irrelevant, since the trigger works with any of the 6 containers.
- Using a single shuttle to do the capture meant that only one container was boarded before it decided to fly home.
- The shuttle would board its equivalent container FG number - i.e. Blue 1 boards Chi 1. I confirmed this when modifying the mission design to spawn 6 shuttles in the FG instead, one for each container. In this situation, Blue 1 boards Chi 1, Blue 2 boards Chi 2, and so on.
- I also observed some clipping on the part of the AI when the shuttles returned to the hanger of the mothership (a Nebulon B) - shuttles 2 and 3 overlapped by about a third of their mass on final approach to the hangar.

These observations are very useful for me. Thanks!

So identifying one container triggers the arrival of the shuttle, that then proceeds to board the container of the same number as the shuttle's. I wonder what is done, then, to make a shuttle board the special craft in a group of ships. Like in the Historical Y-Wing Mission 6. I need to document all of this.
Perhaps the shuttle boards the first ship in the target group that is awaiting boarding. In the case of other moving ships, it would be the one awaiting boarding due to a Rendezvous order, or disabled with ions. In the case of containers, the first one in the group because awaiting boarding is everything that containers do?
No idea. This needs to be experimented. :/

I have also noticed that sometimes the original engine disables collisions for certain ships. Entering or leaving hangar is one of those situations, when ships can totally clip other ships in their group or other groups without consequences.
I have also noticed that sometimes ships can shoot thru other ships, particularly TIEs. But not always. I have implemented it in XWVM by allowing ships of same IFF to shoot thru each other when both are attacking the same target (the player is never selectable for this "cheat").
Otherwise entire flights of TIEs destroy themselves when focusing fire on a rebel ship.

I have also seen ships clipping other ships without colliding when they are disabling their targets. I cannot remember the mission, but it was about a flight of Y-Wings disabling some shuttles. The Y-wings would totally fly thru the shuttles after every pass while trying to disable them.

I've put together a folder on Google Docs which anyone can view and edit, containing some test missions and a document where the observations can be noted (not intended to replace the existing XWVM document, but rather to collect specific observations, potentially across different versions of the game) - I would encourage anyone to add to this if they feel like it. I'll try and add some more as time allows.

Note: These are open to the public via the links, so please exercise due caution. I may restrict access to specific contributors in the future if needed.

Testing folder - https://drive.google.com/folderview?id=0B2cwqp-lDTwjdm1WRlBTRmxjQ3M&usp=sharing
Testing and observations doc - https://docs.google.com/document/d/1sfULqgaFrF2EqWwF8qOlqE77w1OuZdKjyP80CJ0jTa0/edit?usp=sharing

Great initiative!

Thanks - I added 2 new variants of the test mission, which use transports instead of containers. The short version of the results is that, well, there didn't seem to be a change in behaviour at all.

One thing I did observe was by accident - after inspecting some of the transports, I accidentally destroyed one by colliding with it (their shields were already down as I specified this in the mission config) - in this case Chi 4. The equivalent capturing shuttle, Blue 4, then reported as "Looking for craft to board" while the other shuttles went about their mission as usual. When all other shuttles had finished docking (they do this all simultaneously, which is interesting), it woke up, boarded Chi 1 and went home. Of course, Chi 1 was already empty at this time, and Blue 4 was still empty after docking, so it technically didn't "do" anything, but it was enough for it to complete its mission and caused the mission to still pass successfully.

So a ship with the orders to board, first tries to board the ship on the target flight group matching its wingman number.
If it doesn't exist, then it waits until the leader is free to be boarded and boards it.
So I guess a mission like that, to make sense, would require 100% of Chi group to be boarded, AND or INSTEAD OF 100% of Blue group to complete mission.

I definitely need to implement some kind of queuing system for boarding ships. I think there are several examples of missions where a particular ship is boarded in order by many other ships, that patiently wait their turn.

Thanks for these observations!

Our shuttle so far with 2 99% complete TIEs....

That's a fantastic level of detail, looks great!

The work you folks are doing looks fantastic; I've actually been watching the project for quite a while! That said, I probably won't play much. I like FS2, and I like X-Wing, but I just don't see them mixing well. For me, part of the X-Wing experience is having a cockpit for every ship, which I haven't seen any FS2 mod pull off. Regardless, congrats on your work! It looks great so far!

I'd really appreciate it!

Amazing, Major. :)

(Diaspora, a Battlestar Galactica game based on Freespace 2, did a fine job on the cockpits)

Very good point, and I'd probably think the same if I hadn't played it myself and know just how much fun it is. We've sped things up way faster than vanilla FS2 and it genuinely feels like I'm in the middle of a movie battle more than anything else I've played. It's a blast, and I can't wait until we're able to release something for you guys to try for yourselves. That's a good point. Cockpits are something that we do really want, but it takes talented artists that we just don't have. If anyone here knows someone who can create great movie-quality looking cockpits, we definitely have the position open.

We've tried to import the cockpits from the First Strike mod (we've had some friendly cooperation between us) and sadly the just don't work with our HUD setup. We really need to be able to create them from scratch with working panels replacing our HUD so everything's visible. That said, having the cockpits made an enormous impact visually in regards to overall immersion. If we still haven't been able to get anyone to make proper models for us perhaps we'll find a way to release a separate cockpit pack using those placeholder models for those who want to play around with them. No promises, but it's an idea.

One of the primary reasons cockpits are so important is that VR is essentially unplayable without them. FSO doesn't quite have proper Rift support yet but there's a few developers working on it off and on, and as more and more people pick up headsets you can guarantee there will continue to be more interest in it.

Regarding cockpits (in XWVM), how exactly would we go along deciding on their layouts? Maybe it would be good to decide on a cockpit camera FOV, so that the layouts can be created with that in mind (so all the elements are visible all the time).

Also what criteria does a 3D model have to fulfil to have certain parts work as screens and UI elements? Would you need the screen surfaces as separate objects?

I would like to have more time to answer this forum, but I am in the middle of a long vacation and I have access to a laptop for few minutes now and then.

I have no experience with VR. But I was thinking on developing the game in a way that the user could tweak the eye camera height, distance to the dashboard and FOV so that they would feel personally comfortable. A bit like what you do when you sit first on a car you have never driven before, and you move the seat and the mirrors around before starting it.
Again, I don't know if that is the standard procedure with VR games or that would be considered too advanced and, instead, we need to make a set of settings the user chooses one from.

The 3D model of the dashboard and rest of the interior of the cockpit has no technical requirements other than these:
- It needs to resemble the original 2D cockpits.
- The instruments need to have a big enough flat surface to place the interactive instruments on.

The instruments are basically like flat decals that are stuck on top of the dashboard geometry. They are standard, so different ships with different geometry will use the same instruments.
They can be rotated in any axis, scaled, moved, or even stretched if needed.
Also, if the geometry is divided in several submeshes, you can child instruments to a particular mesh, and when the mesh animates (it rotates, for example), the instrument will inherit the transformation.

The most direct application of this that I can think of would be the radar scopes. If you look at the Y-Wing cockpit in my demo video, you can see the blue circle on the rhomboid metal structure. The blue circle is the instrument that is rendered at real time. This is a child of the rhomboid thing that is part of the geometry of the cockpit. My idea was that with a slider (or automatically), the player could angle these scopes so that they directly face his eyes, just like you would do with the rearview mirrors in your car.

The monitor (targeting computer and message logs) have an arbitrary shape, but have a totally flat face for getting the instrument decal showing.
Basically, all other instruments are the same.

Just to throw this out there: there is also the possibility of different aspect ratios being used, which could influence FOV and instrument placement.

These days, a 16:9 ratio is of course most likely, but I would imagine some players would want to play in 4:3, 16:10, 21:9 (those new LG ultrawide monitors seem to be a popular choice) and 5:4 (if they're still rocking a 1280x1024 screen).

In each case a different FOV would probably be appropriate - I was reminded of this when watching Markiplier's No Man's Sky playthrough and found the low FOV to be a bit distracting (and this was, at least at the time, hardcoded into the PS4 version of the game). Low FOV is common for consoles, where the player is sitting 6+ feet away from the screen, but not so ideal with a desktop monitor.

Thanks, that's all I needed to know. I have no idea if I have time to work on these, but I thought I'd ask, just in case ;)