[SirKnightly]

Sorry for the delay on this one, had a lot of issues crop up between hosting and personal things.  Getting RC2 out now at least, hopefully nightlies will be sorted out in the near future.  scp.fsmods.net appears to be gone for good unfortunately.

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. Alternatively, if Creative's OpenAL doesn't work with your hardware, you can use OpenAL Soft.

Hidden Text: TrackIR Users • Show

Important!!
An external DLL is required for FSO to use TrackIR functions.  The following DLL is simply unpacked in to your main FreeSpace2 root dir.
TrackIR is only supported on Windows.
TrackIR SCP DLL (Mirror) (Mirror)

Launchers, if you don't have one already:
All platforms:  wxLauncher (ongoing project for a unified launcher)

Hidden Text: Alternative Launchers • Show

Windows:  Launcher 5.5g (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:

• Github issues and pending pull requests
• Open non-feature issues in Mantis: 121
• 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.4 bugs.

Windows
Compiled on Windows 7 SP1 64-bit, MSVC Community 2015 Update 2

fs2_open_3.7.4_RC2.7z (Mirror) (MD5)
This one is based on the SSE2 Optimizations from the MSVC Compiler.

Hidden Text: Alternative builds • Show

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.4_RC2_AVX.7z (Mirror) (MD5)
This one is based on the AVX Optimizations from the MSVC Compiler (fastest build if your CPU supports AVX instructions).

fs2_open_3.7.4_RC2_SSE.7z (Mirror) (MD5)
This one is based on the SSE Optimizations from the MSVC Compiler.

fs2_open_3.7.4_RC2_NO-SSE.7z (Mirror) (MD5)

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

OS X Universal (32/64-bit Intel)
Compiled on OS X 10.11.4, Xcode 7.3 (Apple LLVM version cross-reference)

fs2_open_3.7.4_RC2.dmg (Mirror) (MD5)

Hidden Text: Other Platforms, Source Code • Show

Ubuntu Linux 32-bit
Compiled on Ubuntu 14.04.4 LTS 32-bit, GCC 4.8.4
The Ubuntu builds are built and provided as a reference, and also because Ubuntu is a very common Desktop Linux distribution.  We usually recommend Linux users compile their own builds, but if you happen to be running 32-bit Ubuntu, or 64-bit Ubuntu with 32-bit libraries installed, these may work fine for you.  There have been reports of package managers maintaining FSO packages in various Linux distributions, if you plan to package an FSO release for a distribution please let use know and we will include a reference to it in our release posts.

fs2_open_3.7.4_RC2.tar.bz2 (Mirror) (MD5)


FreeBSD 64-bit (experimental, limited support)
Compiled on PCBSD 10.2 64-bit, clang 3.4.1
As FreeBSD is still a small player in the desktop space, but PC-BSD is becoming a much more user-friendly platform, we were able to get it reliably working with our build system.  The limited user base for these builds will likely keep them in the experimental realm, so if you do have any issues or successes with them, please report your experiences here.

fs2_open_3.7.4_RC2.tar.bz2 (Mirror) (MD5)

Source Code Export (MD5)
fs2_open_3_7_4_RC2_src.tgz (Mirror)

[CT27]

I apologize if this may be a simple question but I haven't downloaded RCs in a while (I usually just do nightlys or official releases):

Does this cover bugfixes made as of April 7?  Any nightly before that I ran into problems with with a couple campaigns.

[chief1983]

Appears some of the builds never made it to the mirrors either, I will have to look into getting that fixed soon.  I don't know why they haven't been seeded from the primary to the mirrors yet.

[chief1983]

But to answer your question, there should be quite a few bug fixes in here.  Anything above the March 7 RC1 commit on the 3.7.4 commits page.

[AdmiralRalwood]

Does this cover bugfixes made as of April 7?

chief1983 already linked you to the list of commits in the 3.7.4 branch, but in general here's the goal with release branches: bugfixes (especially for crashing bugs) get backported; new features do not. Anything in between is going to be considered on an individual basis, but generally leaning towards "don't backport"; the idea is to keep the branch as stable as possible.

If a release candidate crashes for you, let us know immediately: we want the final 3.7.4 release to be the only executable most people need to use until 3.8 is ready.

[CT27]

I'm trying to learn all this terminology, what do you mean by 'backporting'?

[AdmiralRalwood]

I'm trying to learn all this terminology, what do you mean by 'backporting'?

The main branch is the master branch; it's what nightly builds get built off of. 3.7.4 has its own branch; since they're separate branches, commits to master don't affect the 3.7.4 branch in any way. So if a bugfix gets merged, it needs to be separately ported "backwards" to the 3.7.4 branch (current master/nightly builds are 3.7.5).

See also: https://en.wikipedia.org/wiki/Backporting

[ssmit132]

A question - if I find (what I think is) a bug, do I still open an issue on Mantis, or should I do it on GitHub instead? Because I've encountered another issue in my messages.tbl escapades.

EDIT: The issue was because of a table error, so I guess I don't need to open an issue for that. It would still be nice to know which place is prefered for bug reports, however.

[AdmiralRalwood]

We're leaning towards GitHub Issues right now. If you're unsure if something is a bug or an asset issue (like a malformed table), you can always hop on IRC and ask.

[Lykurgos88]

I have now encountered multiple times a game crashing bug with RC2, that I have not yet found any logical explanation. The error is as follows:

Code: [Select]

ERROR: 00005.fs2(line 57):
Error: A file name was expected but no name was supplied!

File: parselo.cpp
Line: 331
Int3(): From c:\code\fs2_open_3_7_4_rc2\code\globalincs\windebug.cpp at line 1260

The thing is, I recently played a whole campaign with RC2 and had no problems, but in other campaigns there is now this same crash in multiple missions.

I have no idea what is going on.

[m!m]

That error means that the mission file is invalid. What campaign is that mission part of?
The code that checks for that error has been added recently but the error has probably always existed.

[The E]

Yeah, the best way to troubleshoot this is to open this 00005.fs2 file in a text editor and see what line 57 actually says.

[Lykurgos88]

There is clearly something else going on than the mission file being corrupt.

There are now multiple missions in campaigns like Ryleh and Dimensional eclipse that work with 3.7.2 but not in 3.7.4 RC2 because of this same error.

If you don't want to download any mods, I happened to found a vanilla singleplayer mission that crashes with this same bug. This time the error line is 56.

Download the attached mission file and put it in data\missions to see it for yourself. The file should be fine, because it works in 3.7.2, so problem should be in 3.7.4 RC2.

[attachment DELETED!! by Strong Bad]

[chief1983]

And, as they tried to explain, line 56 of that file is:

Code: [Select]

$Ani Filename:

I'm not saying it's acceptable that so many essentially working missions are now unplayable, if that's actually the case now, but no one said they are corrupt.  Merely that we added a check for another possible problem with some mission files, namely, the missing filename value.  The code is doing its job in this case, but I'll leave it open for discussion on if there are any changes needed in terms of how this error is being handled currently.

[Lykurgos88]

Well yeah, maybe the check should be produce a log warning and not crash the entire game 

[AdmiralRalwood]

The behavior in question was introduced in this commit (PR here, merged by yours truly), but I'll copy the description here for the sake of convenience:

Add validation when parsing a file spec

This issue was spotted by Taranis who encountered an assertion caused by
an empty file name. This check will make sure that every string parsed
as a file name will at least contain one character.

Bad data (i.e. data provided by a modder/FREDer that doesn't actually make sense for the engine to attempt to do anything with) should never trigger an assertion; that's why the error message was introduced. In this particular case, however, the relevant code already tests for an empty filename string and handles it accordingly, so the error is just breaking working missions (which we try not to do if we can avoid it). It might, in this case, have been better to fix the specific kind of empty file name problem Taranis found rather than generating an error every time a filename is expected but not provided; unfortunately, there's no mention of what the assertion was in the commit or PR description.

[Lykurgos88]

@AdmiralRalwood
Thanks for the clear-up!

There are actually a couple of other (somewhat longstanding) bugs that I'm trying to reproduce with RC2, but one of them is actually presented in a mission that is now blocked because of this "filename" check. So is there a possibility for a RC3 before final release?

The bug is related to in-game event where player is using joystick and is suddenly denied of any input --> ship starts turning around slowly instead of staying still like it was supposed to in older FSO builds. I will try to get a more specific description and examples when I get a chance. (note that the joystick is perfectly calibrated in this case and doesn't make any twitch movements on its own)

Another potential bug that comes to my mind is how the optional framebuffer shockwaves react with FS1 explosions. Unlike with FS2 explosions which seem to work nicely, the FS1 era shockwave explosions can cause microlag and nasty looking square shaped distortions. Even the background nebulas can get 2 second long color changes, which never happens with FS2 shockwaves.

I will try to remember all the other oddities as well that I have encountered and post them here in the following days. 

[niffiwan]

It might, in this case, have been better to fix the specific kind of empty file name problem Taranis found rather than generating an error every time a filename is expected but not provided; unfortunately, there's no mention of what the assertion was in the commit or PR description.

From the name of m!m's branch, I'm going to guess it was a missing fictionviewer file, and there's only two assertions in code/missionui/fictionviewer.cpp? OFC it'd be great if Taranis or m!m could comment (I had a look through Taranis's posts and he must have raised the issue on IRC).

[m!m]

I think most of the conversation happened in IRC. The assertions in fictionviewer.cpp don't look familiar but the actual assertion may have happened outside of the fiction viewer code. I think the assertion happened somewhere in cfile where the filename was checked for the first time. I'm fine with changing the code so an empty string is a valid filename but if FRED writes missions with invalid filenames that also needs to be fixed.

[AdmiralRalwood]

I think most of the conversation happened in IRC. The assertions in fictionviewer.cpp don't look familiar but the actual assertion may have happened outside of the fiction viewer code. I think the assertion happened somewhere in cfile where the filename was checked for the first time. I'm fine with changing the code so an empty string is a valid filename but if FRED writes missions with invalid filenames that also needs to be fixed.

Well, that's the odd thing; as far as I can tell, FRED has always defaulted ani_filename to "<default>", so it would seem that... a nonzero number of FREDers are manually erasing that for whatever reason. Unless all of these missions happen to be contained within the two campaigns Lykurgos88 mentioned (in which case it might be less effort to just fix those missions and call it a day), it would seem we need to continue to support those missions that are otherwise perfectly fine.