[chief1983]

Final here. Go there.


We managed to take care of quite a few significant issues in RC1, so we're now ready to present the community with 3.7.0 RC2!  This is based on revision 9691.
Previous 3.7.0 RC1 Release Thread

Important!!
As always, you need OpenAL installed.  Linux and OS X come with it but Windows users will need to get Creative's OpenAL installer.

Important!!
Also, since the internal code linking for TrackIR was revised, an external DLL is now required for FSO to use TrackIR functions.
The following DLL is simply unpacked in to you main FreeSpace2 root dir.
TrackIR is only supported on Windows.
TrackIR SCP DLL (Mirror) (Mirror) (Mirror)

Launchers, if you don't have one already:
All platforms:  wxLauncher (ongoing project for a unified launcher)
Windows:  Launcher 5.5g (Mirror) (Mirror) (Mirror) Not compatible with Windows 8, use wxLauncher above
OS X:  Soulstorm's OS X Launcher 3.0
Linux:  YAL or by hand or whatever you can figure out.

Known issues:

• There may still be trouble converting retail pilots.  You might experience crashes.  Post logs.
• See the list of Fix for next release bugs - mark a bug as an elevated priority (high, urgent, immediate) to get it included in that filter.
• Here is the filter for Target 3.7.0 bugs.

WINDOWS Builds
Compiled on MSVC 2008 SP1

If you don't know which one to get, get the third one (no SSE).  If you don't know what SSE means, read this: http://en.wikipedia.org/wiki/Streaming_SIMD_Extensions
You can use freely available tools like CPU-Z to check which SSE capabilities your CPU has.

fs2_open_3_7_0_RC2.zip (Mirror) (Mirror)
This one is based on the SSE2 Optimizations from the MSVC Compiler.
MD5: 1fad2714d9044c55369d9111f40ba396

fs2_open_3_7_0_RC2_SSE.zip (Mirror) (Mirror)
This one is based on the SSE Optimizations from the MSVC Compiler.
MD5: 6dedf720f4100941a05094fed2305962

fs2_open_3_7_0_RC2_NO-SSE.zip (Mirror) (Mirror)
MD5: 89f33e5e6f763d3d674881318d3beb55

What are those SSE and SSE2 builds I keep seeing everywhere?
Your answer is in this topic.


OS X Builds
Compiled on Xcode 3.2.6

FS2_Open-3.7.0_RC2.dmg (Mirror) (Mirror)
MD5: 3a8e201c2b6ecdf408f553ea30e4faf9


LINUX Builds
Compiled on Ubuntu 12.04 LTS 32bit, GCC 4.6.3

fs2_open_3.7.0_RC2.tar.bz2 (Mirror) (Mirror)
MD5: ae8392f99ea488e582bd8e2775071c65


FREEBSD 64-bit Builds (experimental, limited support)
Compiled on GhostBSD LXDE 3.0 64bit, GCC 4.2.1

Starting with 3.7.0 RC2, and all revisions after r9691, all FreeBSD release and nightlies will be 64-bit.

fs2_open_3.7.0_RC2.tar.bz2 (Mirror) (Mirror)
MD5: 2e6c0e2d1e555d5b4bbfd5cca6a3376a

Source Code Export
fs2_open_3_7_0_RC2_src.tgz (Mirror) (Mirror)
MD5: 5593656f36ba0244b20af6dcfabf9bbf


Changelog since 3.6.18 (the entire thing fits in a forum post!  Wow!):

Code: [Select]

------------------------------------------------------------------------
r9640 | Goober5000 | 2013-04-20 19:12:41 -0500 (Sat, 20 Apr 2013) | 1 line

Yarn's patch to make version checking work correctly
------------------------------------------------------------------------
r9641 | Goober5000 | 2013-04-22 00:50:02 -0500 (Mon, 22 Apr 2013) | 1 line

the fix for Mantis #2845 in isolation
------------------------------------------------------------------------
r9642 | Goober5000 | 2013-04-22 01:30:48 -0500 (Mon, 22 Apr 2013) | 1 line

fix the is-in-box sexp
------------------------------------------------------------------------
r9643 | Goober5000 | 2013-04-22 02:33:12 -0500 (Mon, 22 Apr 2013) | 4 lines

code cleanup related to Mantis #2845...
straighten out and standardize the differences between the various OPF_SHIP_WING_* argument types
make sure all ships using an OPF_SHIP_WING_* type actually specify and handle the type they need to (removing the ones that don't make sense, e.g. you can't set the orientation of a waypoint)
enforce type safety by clarifying the distinction between "any ship on a team" and "every ship on a team", and splitting the OSWPT_TYPE_TEAM type to accommodate this (which maintains compatibility with the original OPF_SHIP_WING_TEAM type)
------------------------------------------------------------------------
r9644 | Echelon9 | 2013-04-22 07:09:29 -0500 (Mon, 22 Apr 2013) | 1 line

Fix Mantis 2824: AddressSanitizer: global-buffer-overflow in obj_snd_delete_all()
------------------------------------------------------------------------
r9645 | Echelon9 | 2013-04-22 07:12:50 -0500 (Mon, 22 Apr 2013) | 1 line

Fix Mantis 2834: AddressSanitizer: global-buffer-overflow in get_max_ammo_count_for_bank()
------------------------------------------------------------------------
r9646 | Echelon9 | 2013-04-22 07:16:23 -0500 (Mon, 22 Apr 2013) | 1 line

Fix for Mantis 2821: AddressSanitizer: global-buffer-overflow in ship_get_secondary_weapon_range()
------------------------------------------------------------------------
r9647 | Echelon9 | 2013-04-26 04:40:07 -0500 (Fri, 26 Apr 2013) | 1 line

Let form follow substance; when using indentation around if() ensure the approach is clear
------------------------------------------------------------------------
r9648 | Echelon9 | 2013-04-26 06:39:05 -0500 (Fri, 26 Apr 2013) | 1 line

Fix Mantis 2853: AddressSanitizer: heap-buffer-overflow in change_ship_type()
------------------------------------------------------------------------
r9649 | Echelon9 | 2013-04-26 08:04:11 -0500 (Fri, 26 Apr 2013) | 1 line

Fix Mantis 2854: AddressSanitizer: global-buffer-overflow in do_subobj_hit_stuff()
------------------------------------------------------------------------
r9650 | FUBAR-BDHR | 2013-04-27 02:35:26 -0500 (Sat, 27 Apr 2013) | 1 line

From Yarn fix for Mantis 2849 +Flags: does not select main halls
------------------------------------------------------------------------
r9651 | The_E | 2013-04-27 08:06:01 -0500 (Sat, 27 Apr 2013) | 2 lines

Fix my fix from revision 9305: Properly check for null pointer dereference
------------------------------------------------------------------------
r9652 | niffiwan | 2013-04-28 00:42:47 -0500 (Sun, 28 Apr 2013) | 1 line

log the correct CSG version
------------------------------------------------------------------------
r9653 | Echelon9 | 2013-04-28 07:33:19 -0500 (Sun, 28 Apr 2013) | 1 line

Fix Mantis 2850: AddressSanitizer: global-buffer-overflow in emp_randomize_chars()
------------------------------------------------------------------------
r9654 | Echelon9 | 2013-04-28 08:50:03 -0500 (Sun, 28 Apr 2013) | 1 line

Fix for loading of AVIs in BP. As discussed with The_E on IRC, this bug may have had a range of unintended consequences, although not clear why it hasn't been picked up already.
------------------------------------------------------------------------
r9655 | Echelon9 | 2013-04-28 08:51:41 -0500 (Sun, 28 Apr 2013) | 1 line

Extra logging functionality for BMPMAN. This helped localise the fix in r9654.
------------------------------------------------------------------------
r9656 | Zacam | 2013-04-28 18:16:50 -0500 (Sun, 28 Apr 2013) | 1 line

Fix for Mantis 2841: From CommanderDJ, Allows FRED to select/set Main Hall by string input, not just integers.
------------------------------------------------------------------------
r9657 | niffiwan | 2013-04-29 04:01:24 -0500 (Mon, 29 Apr 2013) | 3 lines

Fix mantis 2753: save csg just before mission starts
read loadout indexes into int instead of uint & ensure -1 is not used as array index
initialise Player_loadout struct during FSO start
------------------------------------------------------------------------
r9658 | niffiwan | 2013-04-29 07:15:07 -0500 (Mon, 29 Apr 2013) | 1 line

Remove a duplicate line in r9657 - thanks to Echelon9 for noticing this
------------------------------------------------------------------------
r9659 | Echelon9 | 2013-04-29 07:55:53 -0500 (Mon, 29 Apr 2013) | 1 line

Fix for Mantis 2833: AddressSanitizer: heap-buffer-overflow in get_char_width()
------------------------------------------------------------------------
r9660 | The_E | 2013-04-29 14:54:58 -0500 (Mon, 29 Apr 2013) | 1 line

Fix for Mantis 2857: We need to tell generic_anim_load what to load, really. Otherwise this whole exercise is kinda pointless :P
------------------------------------------------------------------------
r9661 | m_m | 2013-04-30 03:02:33 -0500 (Tue, 30 Apr 2013) | 1 line

Fix for Mantis 2846: Problems with mission loop animations
------------------------------------------------------------------------
r9662 | niffiwan | 2013-04-30 03:25:43 -0500 (Tue, 30 Apr 2013) | 2 lines

Fix for mantis 2802: when restoring last missions loadout, ignore weapons on absent ships
Also clear ship weapons & weapon-counts when clearing loadout slots
------------------------------------------------------------------------
r9663 | niffiwan | 2013-04-30 03:28:17 -0500 (Tue, 30 Apr 2013) | 2 lines

Revert "Fix for mantis 2802: when restoring last missions loadout, ignore weapons on absent ships"
Wrong patch you git!
------------------------------------------------------------------------
r9664 | niffiwan | 2013-04-30 03:35:16 -0500 (Tue, 30 Apr 2013) | 1 line

Fix for mantis 2855: fix off-by-one, add negative index check, empty invalid slots & enable mprintfs
------------------------------------------------------------------------
r9665 | The_E | 2013-04-30 11:16:40 -0500 (Tue, 30 Apr 2013) | 2 lines

From Plombo: Make the FXAA shaders conform to the (absolutely braindead, I might add) GLSL specs.
Also makes Mesa happy.
------------------------------------------------------------------------
r9666 | Zacam | 2013-04-30 18:16:33 -0500 (Tue, 30 Apr 2013) | 3 lines

Doxygen and clean-up start for making the controls more robust.
Doxygen additions: z64555
Tab/Whitespace cleanup: My fault.
------------------------------------------------------------------------
r9667 | Zacam | 2013-05-01 02:41:43 -0500 (Wed, 01 May 2013) | 1 line

From z64555; a better version of r9666's Doxygen comments.
------------------------------------------------------------------------
r9668 | niffiwan | 2013-05-01 05:00:44 -0500 (Wed, 01 May 2013) | 2 lines

Fix for mantis 2802: when restoring last missions loadout, ignore weapons on absent ships
Also clear ship weapons & weapon-counts when clearing loadout slots
------------------------------------------------------------------------
r9669 | Zacam | 2013-05-04 00:46:47 -0500 (Sat, 04 May 2013) | 1 line

Fix for Mantis 2829: If it doesn't like trying to @param a double stuffed func, then don't. We have the @params defined in the original draw_func_ptr anyway.
------------------------------------------------------------------------
r9670 | Zacam | 2013-05-04 00:59:26 -0500 (Sat, 04 May 2013) | 2 lines

Fix for Mantis 0002860: Tostring function for enumerations returns invalid for highest enumeration index
From: Admiral MS
------------------------------------------------------------------------
r9671 | Echelon9 | 2013-05-04 02:19:32 -0500 (Sat, 04 May 2013) | 1 line

Fix Mantis 2819: AddressSanitizer: stack-buffer-overflow in l_File_read_f()
------------------------------------------------------------------------
r9672 | Echelon9 | 2013-05-04 19:17:10 -0500 (Sat, 04 May 2013) | 1 line

Fix Mantis 2862: Crash exiting game from command briefing on newly created pilot, caused by double free in cutscenes.cpp
------------------------------------------------------------------------
r9673 | Echelon9 | 2013-05-04 19:25:49 -0500 (Sat, 04 May 2013) | 1 line

Fix Mantis 2859: Game crashes if mod is changed with the same pilot in use. From niffiwan.
------------------------------------------------------------------------
r9675 | Goober5000 | 2013-05-07 20:43:47 -0500 (Tue, 07 May 2013) | 1 line

fix for Mantis #2856 - combine all the has-[un]docked[-delay] sexp functions and make adjustments for the order of ship checks
------------------------------------------------------------------------
r9677 | Echelon9 | 2013-05-10 09:46:32 -0500 (Fri, 10 May 2013) | 1 line

Fix Mantis 2837: AddressSanitizer: heap-buffer-overflow in sexp_get_damage_caused()
------------------------------------------------------------------------
r9678 | niffiwan | 2013-05-21 04:27:24 -0500 (Tue, 21 May 2013) | 1 line

Fix for mantis 2801 from Mr_Maniac: increase buffer size to correctly handle localisation strings > 1024 chars
------------------------------------------------------------------------
r9679 | niffiwan | 2013-05-22 05:27:12 -0500 (Wed, 22 May 2013) | 1 line

Fix for mantis 2868: clear all mission completed flags when changing campaigns
------------------------------------------------------------------------
r9680 | Backslash | 2013-05-25 16:16:44 -0500 (Sat, 25 May 2013) | 1 line

Small fix to selection set / multitarget / hotkey wing behavior. If a set is not active and something is targeted that is in a set, pressing THAT set's key will not change targets, but just activate the set.
------------------------------------------------------------------------
r9681 | niffiwan | 2013-05-29 05:26:16 -0500 (Wed, 29 May 2013) | 1 line

Fix for mantis 2864: correctly init message_extra struct
------------------------------------------------------------------------
r9682 | niffiwan | 2013-05-30 04:32:35 -0500 (Thu, 30 May 2013) | 1 line

Fix for mantis 2879: clear/reset *everything* in Campaign struct
------------------------------------------------------------------------
r9683 | karajorma | 2013-05-31 04:09:37 -0500 (Fri, 31 May 2013) | 1 line

Fix for Mantis 1863 (Ships with an arrival cue of true and a delay do not arrive on the standalone). Might possibly fix Mantis 1815 too.
------------------------------------------------------------------------
r9684 | karajorma | 2013-05-31 04:14:09 -0500 (Fri, 31 May 2013) | 1 line

Assign the debris signature correctly.
------------------------------------------------------------------------
r9685 | karajorma | 2013-05-31 04:17:17 -0500 (Fri, 31 May 2013) | 1 line

Better error reporting for this issue (in order to help track down a Diaspora bug).
------------------------------------------------------------------------
r9686 | karajorma | 2013-05-31 04:18:14 -0500 (Fri, 31 May 2013) | 1 line

We only need to see this error once in FS2. Ensure that this instance only appears in FRED.
------------------------------------------------------------------------
r9687 | The_E | 2013-05-31 17:33:05 -0500 (Fri, 31 May 2013) | 1 line

From Axem: Patch for Mantis 2870 (hook variable for On Death: scripting hook is not always set correctly)
------------------------------------------------------------------------
r9688 | niffiwan | 2013-05-31 18:38:11 -0500 (Fri, 31 May 2013) | 1 line

Fix for mantis 2880: handle -1 red alert departed ship indexes
------------------------------------------------------------------------
r9689 | niffiwan | 2013-05-31 18:39:09 -0500 (Fri, 31 May 2013) | 1 line

Fix for mantis 1326: add & handle "not present" state for red alert ships
------------------------------------------------------------------------


[headdie]

awesome work guys, fyi posted on Facebook group and reddit

[ktistai228]

Nice. Your work is really awesome dudes!

[Yarn]

I've been wondering: What happens if you try to run an SSE(2) build on a system that does not support SSE(2)?

[chief1983]

Crashes.

[Yarn]

Crashes.

I figured that, but I'm wondering how it crashes. Does it display a message like "Your CPU does not support SSE2," or does it crash some other way (e.g., the standard Windows "This program has stopped working" or whatever)? If the latter is true, then does it crash immediately? (I'd try it myself if I could, but I don't have a non-SSE2 machine. That's why I'm asking.)

[Talon 1024]

I got this bug after completing Universal Truth (last mission of BP:AoA):

Code: [Select]

Red Alert: asked to delete ship (Alpha 4) with invalid ship state (0)
<no module>! KiFastSystemCallRet
<no module>! WaitForSingleObject + 18 bytes
<no module>! SCP_DumpStack + 354 bytes
<no module>! Error + 229 bytes
<no module>! red_alert_delete_ship + 155 bytes
<no module>! red_alert_bash_wingman_status + 806 bytes
<no module>! game_post_level_init + 172 bytes
<no module>! game_start_mission + 373 bytes
<no module>! game_enter_state + 550 bytes
<no module>! gameseq_set_state + 310 bytes
<no module>! game_process_event + 242 bytes
<no module>! gameseq_process_events + 152 bytes
<no module>! game_main + 782 bytes
<no module>! WinMain + 330 bytes
<no module>! __tmainCRTStartup + 358 bytes
<no module>! WinMainCRTStartup + 15 bytes
<no module>! RegisterWaitForInputIdle + 73 bytesI was playing using the FSO 3.7.0 RC2 build, I had the BP: WiH mod activated, and I was playing the BP: AoA campaign.

[attachment deleted by ninja]

[Yarn]

I got this bug after completing Universal Truth (last mission of BP:AoA):

(error)

I was playing using the FSO 3.7.0 RC2 build, I had the BP: WiH mod activated, and I was playing the BP: AoA campaign.

First of all, you need to move your FreeSpace 2 installation out of Program Files and to a shorter path, such as C:\Games\FreeSpace2.

Code: [Select]

  -mod blueplanet2,blueplanet,mediavps_3612,NewHTLShips,zoom
Try removing NewHTLShips and zoom from your mod list, whatever those are.

Code: [Select]

Found root pack 'C:\Program Files\Games\GOG.com\Freespace2\mediavps_3612\MV_Advanced.vp' with a checksum of 0x4b8b0f5a
Found root pack 'C:\Program Files\Games\GOG.com\Freespace2\mediavps_3612\MV_AnimGlows.vp' with a checksum of 0x6a554026
Found root pack 'C:\Program Files\Games\GOG.com\Freespace2\mediavps_3612\MV_Assets.vp' with a checksum of 0x529cc70f
Found root pack 'C:\Program Files\Games\GOG.com\Freespace2\mediavps_3612\MV_CB_ANI_1.vp' with a checksum of 0x6b831455
Found root pack 'C:\Program Files\Games\GOG.com\Freespace2\mediavps_3612\MV_CB_ANI_2.vp' with a checksum of 0xb58a1f46
Found root pack 'C:\Program Files\Games\GOG.com\Freespace2\mediavps_3612\MV_Effects.vp' with a checksum of 0xb9a9a485
Found root pack 'C:\Program Files\Games\GOG.com\Freespace2\mediavps_3612\MV_Music.vp' with a checksum of 0xb3e21469
Found root pack 'C:\Program Files\Games\GOG.com\Freespace2\mediavps_3612\MV_Root.vp' with a checksum of 0x6ffd5c78
You did not install the MediaVP update files. Get them here. (You need the three labeled "update.")

Code: [Select]

Found root pack 'C:\Program Files\Games\GOG.com\Freespace2\fiction_viewer.vp' with a checksum of 0x3b5771b2
Found root pack 'C:\Program Files\Games\GOG.com\Freespace2\komet_fs2.vp' with a checksum of 0x5d3b2de5
Whatever these files are, they do not belong in the root FS2 folder. Move or delete them.

Code: [Select]

Found root pack 'C:\Program Files\Games\GOG.com\Freespace2\tangoA_fs2.vp' with a checksum of 0x2e10c984
Found root pack 'C:\Program Files\Games\GOG.com\Freespace2\tangoB_fs2.vp' with a checksum of 0x0a5f4659
Delete these.

[niffiwan]

  Could you please also post your pilot files?  I may have derped in the code somewhere.

(and why on earth is the red alert code getting bent out of shape there, I didn't think UT Mk I was a red alert mission )

[technopredator]

I figured that, but I'm wondering how it crashes. Does it display a message like "Your CPU does not support SSE2," or does it crash some other way (e.g., the standard Windows "This program has stopped working" or whatever)? If the latter is true, then does it crash immediately? (I'd try it myself if I could, but I don't have a non-SSE2 machine. That's why I'm asking.)

It depends on the OS, since it's going to handle the exception generated by the CPU. On Windows it'd be the same as when a .exe/.dll is corrupted or has been undeleted and has some trash in it; to know exactly you should Google info about CPU & OS hardware exception handling.

And THANKS a lot, keep them coming      

[Talon 1024]

  Could you please also post your pilot files?  I may have derped in the code somewhere.

(and why on earth is the red alert code getting bent out of shape there, I didn't think UT Mk I was a red alert mission )

Call Stack:

Code: [Select]

Red Alert: asked to delete ship (Alpha 4) with invalid ship state (0)
<no module>! KiFastSystemCallRet
<no module>! WaitForSingleObject + 18 bytes
<no module>! SCP_DumpStack + 354 bytes
<no module>! Error + 229 bytes
<no module>! red_alert_delete_ship + 155 bytes
<no module>! red_alert_bash_wingman_status + 806 bytes
<no module>! game_post_level_init + 172 bytes
<no module>! game_start_mission + 373 bytes
<no module>! game_enter_state + 550 bytes
<no module>! gameseq_set_state + 310 bytes
<no module>! game_process_event + 242 bytes
<no module>! gameseq_process_events + 152 bytes
<no module>! game_main + 782 bytes
<no module>! WinMain + 330 bytes
<no module>! __tmainCRTStartup + 358 bytes
<no module>! WinMainCRTStartup + 15 bytes
<no module>! RegisterWaitForInputIdle + 73 bytes
Sorry I didn't post my pilot files back then, but I had stupidly deleted my pilot files for the BP:AoA campaign.

[attachment deleted by ninja]

[Talon 1024]

I just got the same error message after playing the FS1 mission "Tenderizer" on FSPort, except it was Alpha 3 instead of Alpha 4. Alpha 3 died before the mission ended, so I think that may be part of what's causing the problem.

[Macfie]

I'm getting the same message anytime one of my wingmen dies on a red alert mission.  The mission  can then be played and the missing wingman is recreated.  If I replay the mission and all my wingmen survive I don't get the message.  This has happened on several different campaigns.  I am using the current nightly, but it happened on Release 3.7.0 RC2 first. 

[niffiwan]

I think I must have introduced this bug from this tickets patch.

Could you please use the test campaign/missions from this mantis ticket & let me know if you can reproduce the bug?  I thought I'd tested the suspect patch fairly extensively with this test case.\


edit: hmmm... did this error occur when your wingmen were flying Ulysses class fighters?  (or for fsport, whatever is the 1st defined ship in the mod?  i.e. ship index 0?)
edit2: actually, after a bit more reading, I don't think the ship class is relevant.  Maybe more relevant is, how did the bugged wingmen die / exit the mission?
edit3: reproduced with Tenderizer... for some reason none of my destroyed wingmen were written to the pilot file... 
edit4: oh for crying out loud, why do none of your wingmen have the "red-alert-carry" flag in that mission    (guess that explains the bug, I didn't handle a red-alert use case that I didn't know about)

[niffiwan]

I've created a patch and attached it to the mantis ticket.  Could you please give it a test?  Or if it makes it easier, I can push the patch into trunk and you can grab the next nightly, just let me know.

[Talon 1024]

Here are some Windows builds made with niffiwan's patch (mantis2904-svn.patch) for the sake of convenience:

http://www.ciinet.org/kevin/fs2_open_3_7_0_RC3_SSE2.exe
http://www.ciinet.org/kevin/fs2_open_3_7_0_RC3_SSE2-DEBUG.exe

And a few issues to note:
- I'm unable to switch campaigns if the current campaign that the pilot is using is unavailable "pilot save file for the campaign is invalid".
- If I've previously run into an error where it says "Red Alert: asked to delete ship (blah) with invalid ship state" and I try to load the next mission, I don't encounter that error anymore, but my weapons loadout gets reset to the default loadout (or at least what I assume is the default loadout for the mission) after the next mission is loaded. I don't know if that problem occurs if I do a normal playthrough anymore, as I haven't had the chance to test that yet.
E: I don't encounter the red alert error anymore, but my weapons loadout gets reset to the default loadout (or at least what I assume is the default loadout for the mission) after the next mission is loaded.

[Trivial Psychic]

I was encountering this bug in my work with Inferno, and I finally got myself around to testing this with FSO.  I feel that its important enough to squish before 3.7.0 goes official.

http://scp.indiegames.us/mantis/view.php?id=2905

I tested this with the latest trunk build, 3.7.0 RC2 and the above-posted RC3.  They all display the same issue.

[niffiwan]

Here are some Windows builds made with niffiwan's patch (mantis2904-svn.patch) for the sake of convenience:

http://www.ciinet.org/kevin/fs2_open_3_7_0_RC3_SSE2.exe
http://www.ciinet.org/kevin/fs2_open_3_7_0_RC3_SSE2-DEBUG.exe

And a few issues to note:
- I'm unable to switch campaigns if the current campaign that the pilot is using is unavailable "pilot save file for the campaign is invalid".
- If I've previously run into an error where it says "Red Alert: asked to delete ship (blah) with invalid ship state" and I try to load the next mission, I don't encounter that error anymore, but my weapons loadout gets reset to the default loadout (or at least what I assume is the default loadout for the mission) after the next mission is loaded. I don't know if that problem occurs if I do a normal playthrough anymore, as I haven't had the chance to test that yet.
E: I don't encounter the red alert error anymore, but my weapons loadout gets reset to the default loadout (or at least what I assume is the default loadout for the mission) after the next mission is loaded.

Thanks for testing. It seems that "pilot save file for the campaign is invalid" error is not related to the red alert issue, could you please create a new mantis for it?  Could you also include steps on how you produced this error?

I'll also have to investigate the reset to default loadout issue, I thought I'd tested this previously    I assume by next mission you mean in "Shell Game" (which follows Tenderizer) your craft is reset to a Herc with 2x Avenger primary banks?  And the Herc's default secondaries?

[Talon 1024]

Well, when I started playing "Universal Truth" in BP1, I chose Balor and Maxim for primaries, and Harpoons and Trebuchets for secondaries. When the game red-alerted to "Journey's End", I only had Balors, Subachs, and one bank of Harpoons.

I haven't tested with "Tenderizer"/"Shell Game" yet, but after looking at Journey's End and Universal Truth in FRED, I'm now guessing that the loadout bug is caused by the Team Loadout in "Journey's End", as the Team Loadout in that mission does not have Maxims or Trebuchets.

Edit: OK, I tested with "Tenderizer" and "Shell Game", and my weapons loadout was fine after I completed tenderizer.

[niffiwan]

Well, when I started playing "Universal Truth" in BP1, I chose Balor and Maxim for primaries, and Harpoons and Trebuchets for secondaries. When the game red-alerted to "Journey's End", I only had Balors, Subachs, and one bank of Harpoons.

I haven't tested with "Tenderizer"/"Shell Game" yet, but after looking at Journey's End and Universal Truth in FRED, I'm now guessing that the loadout bug is caused by the Team Loadout in "Journey's End", as the Team Loadout in that mission does not have Maxims or Trebuchets.

Edit: OK, I tested with "Tenderizer" and "Shell Game", and my weapons loadout was fine after I completed tenderizer.

Yep, I've confirmed that the Universal Truth/Journey's End loadout issue is due to the weapon pool values in Journey's End, missing Maxim/Trebuchets.  Add them to bp-22.fs2 and the loadout is as expected.  Except that I've found another bug where you get odd behaviour when one of your missile banks was empty.  The empty bank either gets refilled (if the weapon is in the weapon pool) or removed entirely (if not)   New mantis time, but target it for 3.7.2 I think, not 3.7.0