[chief1983]

Final here. Go there.


After a brief interlude, we have a 3.6.16 RC1 build, and Mantis' open issue list has been cut by almost 2/3s!  This is based on revision 9482.  Build filenames for Windows in that revision differ from what is below, that is committed to a revision after this and RC2 or final will have matching Windows output filenames between SVN and the released files.
Previous 3.6.14 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)
OS X:  Soulstorm's OS X Launcher 3.0
Linux:  YAL or by hand or whatever you can figure out.

Known issues:

• The now-standard Inferno builds have trouble converting retail pilots.  You might experience crashes.  Post logs.
• The Windows RC1 builds didn't have the speech and voice recognition options enabled, this will be fixed in the next 3.6.16 release.
• There are some standalone crashes currently being investigated.
• 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.6.16 bugs.

WINDOWS Builds
Compiled on MSVC 2008

Inferno Builds
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_6_16_RC1.zip (Mirror) (Mirror)
This one is based on the SSE2 Optimizations from the MSVC Compiler.
MD5: 70b3e4d0360b9880bce3946958e2511a

fs2_open_3_6_16_RC1_SSE.zip (Mirror) (Mirror)
This one is based on the SSE Optimizations from the MSVC Compiler.
MD5: 005d61c0528a784b7c0384a0041c0c16

fs2_open_3_6_16_RC1_NO-SSE.zip (Mirror) (Mirror)
MD5: 44afcb935fc4a23b6cdaafa276bd9d20

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

Inferno Build
FS2_Open-3.6.16_RC1.dmg (Mirror) (Mirror)
MD5: 4c1023063ce67d7eeb15e07474e557fe


LINUX Builds
Compiled on Ubuntu 12.04 LTS 32bit

Inferno Build
fs2_open_3.6.16_RC1.tar.bz2 (Mirror) (Mirror)
MD5: 4d512b754ef8039ee1358431b1617743


FREEBSD Builds (experimental, limited support)
Compiled on GhostBSD LXDE 3.0 RC2 32bit

Inferno Build
fs2_open_3.6.16_RC1.tar.bz2 (Mirror) (Mirror)
MD5: cea9d7ad6e86d212edc3921f3d8f24bf

Source Code Export
fs2_open_3_6_16_RC1_src.tgz (Mirror) (Mirror)
MD5: 1683c7cbc0425bff938a632ec1995e09


Changelog since 3.6.14:
( Additionally, see here: 3.6.13 Changelog (since 3.6.12) )
Trunk SVN Log, 3.6.16 is completely in sync with trunk aside from commits to modify build filenames and versioning.


EDIT: Fixed the "Target 3.6.16" link  // G5K

[headdie]

Awesome New Years present guys

[Echelon9]

...
OS X Builds
Compiled on Xcode 3.2.6

Inferno Build
FS2_Open-3.6.14.dmg (Mirror) (Mirror)
MD5: 4c1023063ce67d7eeb15e07474e557fe
...

I've updated the Mac Xcode 4 project files to reflect the 3.6.16 RC phase.

Currently it looks like this thread has the older 3.6.14 based Mac builds only.

[chief1983]

We weren't committing any of these version number changes to trunk, only the 3.6.16 branch.  And I'm not sure what you mean, the builds in this thread should all have been from the 3.6.16 branch, and you can see where the Xcode and Xcode 4 projects had their versions bumped at here.

[jg18]

chief, I think he means two things:

(1) The posted Mac builds are 3.6.14, not 3.6.16 RC1.

(2) The builds are still listed as "Inferno Build", but I thought we did away with that name, since the Inferno build is now the default build.

Also, just wondering, will there be Xcode 4 builds for whichever OS X versions it supports (10.7+? 10.6+?) and Xcode 3 builds for previous OS X versions?

[chief1983]

Ah.  Ok, I did doublecheck and yeah, didn't think after editing the post in Notepad and then making it, that I could have missed updating the links but I did.  Gotta make a better release post template method I guess.  The OS X links now link to the right builds.  The Inferno designation is still there because they are still Inferno builds, with the Inferno flag enabled.  Antipodes is where more of the move away from Inferno separation has been done, but even that is just flipping the switch to be the other way around.  The switch for Inferno or not Inferno is essentially still there everywhere in the codebase.

Why do we need Xcode 4 builds?  To my knowledge, the Xcode 3 builds should still run on all the platforms we can support.  I currently run the Xcode 3 builds on 10.7.  I don't know how well they run on 10.8 yet.

[jg18]

As for Inferno, well I thought that since they're now the default, listing them as Inferno builds could cause confusion, given that Inferno isn't in the executable name anymore.

As for Xcode 4, I didn't know if there were performance enhancements/optimizations or the like that made it preferable to Xcode 3 for the OS X versions that it supports (I've never used 4). If there aren't, then never mind.

[chief1983]

There may be.  But I wasn't going to change projects after .14's long RC phase started, and I wasn't going to change them between .14 and .16 and increase the room for error.  When we merge antipodes into trunk I will probably move to MSVC2010 for Windows, and think about switching to Xcode 4 for release builds for OS X.  However, the Xcode 4 in the App Store is currently only shipping with Lion and up SDKs.  I don't know if the Lion SDK can even target Snow Leopard, but there's no reason I think we shouldn't still be able to support Leopard even at least, other than Apple keeps wanting to stop supporting the older platforms immediately upon a new OS release.  I might be able to copy over the older SDK from Xcode 3 or an older Xcode 4 and make it work with the latest Xcode, but I won't be doing that for 3.6.16.  Just sticking with what works.

[Trivial Psychic]

I don't wish to be picky, but don't release candidates usually have Sim-Speak enabled?

[chief1983]

It's always something...I'll get that fixed for whatever the next release is.

[Rodo]

Ok, so I'm having a STRANGE problem:

I'm fredding some random mission right, changing this and that and then I go to some fighter and change the type of ship to a different fighter, say... from Uly to Herc II.
Save and run the mission from the techroom, when I get inside my ship is STILL a Uly and I'm like...WTF?

So, does the game save a chache of missions or something like that? cause this is driving me crazy
Note that I suspect this affects more than just ship types, I can see other changes I've made haven't been applied.

I can provide a test mission, but somehow I think it will not matter, because of the high probability of this being a cache problem of some kind.

EDIT: it's easy to test, just make a new mission, place two fighters and form alpha wing with those, then save and play.
Close FS2 and return to FRED, change your fighter to something else and save, now test again. That should do it.

[FUBAR-BDHR]

It's supposed to save your selected ship type for that mission.  As long as the old ship type is still a valid loadout ship you get it as the default.  There was a bug where this was not working properly all the time that was fixed. 

[chief1983]

So I know this coincided with a big BP release, but I'm interested in hearing any testing results from this build, good or bad.  So if you've already downloaded it and played around with this release a bit, please let us know how it went for you.

[mjn.mixael]

Ok, so I'm having a STRANGE problem:

I'm fredding some random mission right, changing this and that and then I go to some fighter and change the type of ship to a different fighter, say... from Uly to Herc II.
Save and run the mission from the techroom, when I get inside my ship is STILL a Uly and I'm like...WTF?

So, does the game save a chache of missions or something like that? cause this is driving me crazy
Note that I suspect this affects more than just ship types, I can see other changes I've made haven't been applied.

I can provide a test mission, but somehow I think it will not matter, because of the high probability of this being a cache problem of some kind.

EDIT: it's easy to test, just make a new mission, place two fighters and form alpha wing with those, then save and play.
Close FS2 and return to FRED, change your fighter to something else and save, now test again. That should do it.

This is not an issue. FUBAR already explained that his is a result of intended behavior. FSO is pre-loading your last loadout for the mission, regardless of what the new default loadouts are. It's supposed to do this. As proof, do this variation of your test...

just make a new mission, place two fighters (ShipX) and form alpha wing with those, then save and load the mission in FSO. Change your ship from the default (ShipX) to any ship (ShipY). Any ship will do. Play the mission. Close FS2 and return to FRED, change your fighter to something else (Not ShipX or ShipY) and save, now test again. That should do it. FSO will pre-load ShipY because that's the last loadout you used for the mission.

Again, this is intended behavior.

If you need the default loadout, use the 'Reset' button for the ships and weapon loadout screens.

[Rodo]

oh I think I'm getting what you're going to now, so it's loading the previous ship because FS2 thinks I selected that one the last time I played the mission? Fair enough then, no issue there.

[mjn.mixael]

Been working with RC1 since it was posted. Seems pretty solid. Nothing major to report.

[HAZARDLEADER]

Works pretty good for me. The only thing that I have to do is "Disable GLSL support" or the ships will appear with clear black textures. (Screen shot attached)  It probably has something to do with my 7 year old video card.  Other than that, my computer runs this build without a problem.



[attachment deleted by a basterd]

[Rodo]

Question:
Is it normal for the ship-invisible sexp to turn off the auto-targeting mode for the player?

test mission attached.

[attachment deleted by a basterd]

[Goober5000]

Yes, both targeting and auto-targeting are explicitly deactivated if the ship is targeted.

Code: [Select]

if (!visible && Player_ai->target_objnum == Ships[shipnum].objnum) {
hud_cease_targeting();
}

[chief1983]

Thanks for the reports guys.