Tarvis: Here's some other controls-related improvements that would make joystick users very happy:
{...}
-View position axes. Will be handy for things like TrackIR and possibly Oculus Rift. Even though it'll look janky it should also support the directional 2D cockpit views too, because it still has the ultimate function of looking to the left when you physically look left. Later 3D cockpits would allow for fine angular control instead of locking to 45 degree directions
I don't know if you mean that Oculus and TrackIR should support the 2D cockpit view.
I don't see how that would work without inducing headache or claustrophobia. I think Oculus adn TrackIR will need to wait to 3D cockpits for usability reasons. Anyway, we are talking way in the future here now. :)
Tarvis: As for mechanics, one thing in particular stands out to me: The Targeting Computer view mode. Frankly it seems useless to me, since it is no more accurate than the F and R radar views! I think ways to make it useful would make the "dot" correspond to where to aim to hit the target, and not the target's position, and second to make it more "zoomed in" for finer aiming. This would be a bit of a crutch though, so I understand not doing this since it would change gameplay balance.
And lastly...S-Foils. Did they have any functional purpose besides the novelty? I wonder if a speed boost when S-Foils are closed like Rogue Squadrion would be nice. Again this is one of those things that would change gameplay, though.
Do you have any nostalgia feeling for the XW targeting computer? Because even when I agree on the premise that we should stay true to the original game, I personally think that XW's targeting computer is absolutely useless, and the devs found out a better use for it in TIE Fighter, and their hands didn't shake a little when they retrofitted TIE's targeting computer to the rebel craft in XvT and XWA.
In my prototype I already experimentally added the aim hint thing, though. I mean, when you have a TIE Figher selected and in front of you, you get to see a little indicator telling you where to shoot at, accounting for your weapon speed and your target's current vector. It simple as hell to get that done with easy vector math, so I did it just to feel the gameplay with it.
It makes dogfighting much easier for newbies, and allow veterans to easily snipe TIEs from far away. So I think if we choose to keep it, it should be an optional setting, or some easy mode that grants a lower score in the mission.
I also added a target relative direction hint. It's an arrow that appears when your target isn't in front of you, and it points to the direction you need to turn to to face it. This one is maybe redundant with the F and R sensor spheres, but it helps a lot during close dogfights.
Tarvis: Pilot restoration: Even the DOS CD version of X-Wing added this, so it's a must. Automatically doing it and going back to the briefing TIE-Fighter style would be a help, though, instead of having to hit "Modify Pilot" and go back through the concourse.
There is a big difference between what XWCD does and what TIE does. In XWCD you can revive the pilot, but it wipes out all your scores and demotes you to Officer. In TIE, if you die or are captured, the game rolls you back to the point just before you started the mission instead. So you don't get to keep any score or kills you did during the mission you went down, but neither you lose your previous score, rank and kill count.
It is funny that the XW developers put so much effort on making deaths or captures so punishing, to the point of the flight sim itself accesses your pilot file and kills it in the precise moment that your ship explodes (instead of waiting to the debriefing room, for example). So you couldnt kill the game in order to save your pilot.
I would go for just accomplishing what TIE fighter went after, only without the complex Backup/Restore mess they organized. Your pilot will never be killed or captured "permanently". You will just have to repeat the mission and you will not get to keep the score and kills you got during failed attempts. Maybe, I will reuse the Int16 value that currently stores the pilot status (alive, captured, killed) to record a counter of "deaths" or "captures".
If someone wants to keep the classic behavior (I don't know why. Maybe they like to challenge themseves to see how high rank can they achieve before dying) I could always add a little button to the register screen to reset the pilot death count in exchange of resetting also the rank and the score and kills. But I don't see many people using this.
Altureus: Yes, I would totally love to see an improved version of this game done. If you are looking for voice over artists for characters myself and a couple other guys are pretty good with that kind of stuff.
I think you should form a team and get this done, there are plenty of Star Wars fans and X-Wing fans that would love to see this done as well.
Also, it wouldn't bet too hard to find people who have specific accents or talents with specific characters.
Hi, thanks for the enthusiasm!
But before involving a lot of people to put their talents on something that big, we should have some solid game going on and working first. Otherwise there is a huge risk of breaking expectations and getting into problems.
Tarvis: Anyway, I figured out how the loops are stored in the MIDI files, and how the beginning song gaps are skipped. It is indeed a MIDI SysEx command in this format. It is a Jump command, telling the player to jump to a given position in the song. So, every MIDI has a Jump command in the beginning to tell it to skip the silence block, and at the end, a command to tell it to loop back to a certain point. (For reference: every MIDI in iMUSE is 480 ticks per beat)
What to say!? You are doing a lot of impressive reverse engineering there! I feel truly humbled.
But the more you discover about the midi iMuse, the more I feel like it's too complicated to get a midi synth running without getting ourselves into something much more complex that we should, at this stage, at least.
We need to note down all your discoveries because we definitely will come back to this when we are confortable and willing to implement a real musical synthetizer like ScummVM does (don't they use fluidsynth also?).
I experimented yesterday with the digital audio output in the project. Audio is represented by N channels of float values between -1 and 1. Before being sent to the audio hardware, this data can be processed easily by accessing the array of floats and doing whatever we feel with it. If we keep somewhere some metadata about the loops and tails, the program could just use that information to know what to send to the audio output. I don't think there is any need to separate the different parts in different files, as long as we keep the metadata at hand.
For example, if the concourse music is not yet ready for the concourse to change screen, we can register so in the metadata file, somehow.
Then the audio system could lift a flag like "Wait before moving on" that the main game would await to go away before moving on to the next screen or whatever.
The same could be done with the flight sim midis, unless all of them have the same durations, for skipping the silence or recognizing when the tail starts and it is okay to start merging the next queued chunk.