[logomancer]

So, I've been trying to compile the patched code you all say to use on Linux, and I'm running into some issues. The trivial ones first:

• People looking to patch the code should make sure you're using patch with the --binary option, otherwise it'll barf on the .vcproj files (probably because they're using Windows newlines).
• There appears to be C++11 code in the patch, which means g++ won't compile it without using the -std=c++11 or -std=gnu++11 compiler directives. This can be done by setting the CXXFLAGS environment variable while configuring makefiles.

...But even if you do both of these things, the code doesn't compile, throwing this error:

Code: [Select]

globalincs/fsmemory.cpp: In function ‘void* operator new(size_t)’:
globalincs/fsmemory.cpp:6:56: error: declaration of ‘void* operator new(size_t) throw (std::bad_alloc)’ has a different exception specifier
In file included from ./globalincs/pstypes.h:688:0,
                 from globalincs/fsmemory.cpp:2:
./globalincs/fsmemory.h:8:15: error: from previous declaration ‘void* operator new(std::size_t)’
globalincs/fsmemory.cpp:22:59: error: declaration of ‘void* operator new [](size_t) throw (std::bad_alloc)’ has a different exception specifier
In file included from ./globalincs/pstypes.h:688:0,
                 from globalincs/fsmemory.cpp:2:
./globalincs/fsmemory.h:12:15: error: from previous declaration ‘void* operator new [](std::size_t)’

I'm using Arch Linux with kernel version 3.6.10-1, gcc version 4.7.2, glib version 2.17. My hardware is a Phenom II 955 with 16 GB RAM. If you need any further details, just ask.

[pecenipicek]

People looking to patch the code should make sure you're using patch with the --binary option, otherwise it'll barf on the .vcproj files (probably because they're using Windows newlines).

Utterly irrelevant on Linux, because, well, you arent going to be running those files there anyhow...

There appears to be C++11 code in the patch, which means g++ won't compile it without using the -std=c++11 or -std=gnu++11 compiler directives. This can be done by setting the CXXFLAGS environment variable while configuring makefiles.

Have you set it for the CFLAGS variable as well? if you have differing CFLAGS & CXXFLAGS you better explain yourself.

Also, the command you are using to compile would be nice to have. (the whole ./configure and other stuff) Also, post the WHOLE compilation log.

[logomancer]

Utterly irrelevant on Linux, because, well, you arent going to be running those files there anyhow...

True enough. I did it so future patches wouldn't complain and give up prematurely.

Have you set it for the CFLAGS variable as well? if you have differing CFLAGS & CXXFLAGS you better explain yourself.

Turns out I didn't. It being a switch for the C++ compiler, I figured I could get by without it there. Plus, the error's in a C++ source file anyway. Nevertheless, I added it, and there was no change.

Also, the command you are using to compile would be nice to have. (the whole ./configure and other stuff) Also, post the WHOLE compilation log.

Fair enough, here's what I did.

I started by checking out rev 9470 of the antipodes build:

Code: [Select]

svn co svn://svn.icculus.org/fs2open/branches/antipodes/ -r 9470
Then I copied the patch from the download to the antipodes directory, changed to the antipodes directory and applied it :

Code: [Select]

patch -p0 --binary < BP.patch
Since there was no configure command, I ran autogen.sh in the directory, and then reconfigured it to add in the C++11 switch:

Code: [Select]

CFLAGS="-std=c++11" CXXFLAGS="-std=c++11" ./configure
And then I ran make, with no options. And this is what comes out.

Hope this helps.

[pecenipicek]

i have no idea then, as everything seems to be in order. time to wait for a coder i guess


for the record, i know it compiled fine for TAP builds which use the BP patches, but that was on gcc-4.5.4 and i'm not sure if there are differences between that patch and the patch distributed for this.
i'm not willing to test with 4.7 on gentoo yet, but i'll give it a try later with the gcc-4.6.3 once i get the AoA files down.

[Mars]

Aesaar - I forgot to mention, the Belles a beaut. I  love the way you managed the frontal curve and rear blockiness.

[[Wolf]Maverick]

Are the old pilots files of AoA and WiH lost? Do we have to replay WiH act1 and 2? I also noticed that my Hud is now completly green, is it possible to restore the original FS2 Hud Colour Settings?
Thanks

[General Battuta]

Are the old pilots files of AoA and WiH lost? Do we have to replay WiH act1 and 2? I also noticed that my Hud is now completly green, is it possible to restore the original FS2 Hud Colour Settings?
Thanks

These builds use the new pilot code, so while your old pilot files are still available if you use an old build, you'll have to start fresh. But Act 3 (when released) will be its own campaign file, and you can jump right in there.

HUD color should be configurable somewhere in the options menus.

[Luis Dias]

So I gather that you are skipping War in Heaven 2 to go directly to 3.

Either that or you have successfully confused me with all the crazy numbering.

[Ravenholme]

So I gather that you are skipping War in Heaven 2 to go directly to 3.

Either that or you have successfully confused me with all the crazy numbering.

I'm wondering if it's meant to be Blue Planet 3 - War in Heaven Act 2

[FreeSpaceFreak]

So I gather that you are skipping War in Heaven 2 to go directly to 3.

Either that or you have successfully confused me with all the crazy numbering.

The first release of WiH contained two acts. I can't remember the titles, but they're on the loading screens. The second release, which will (presumably) be known as WiH2, will contain the third act of the story.

(At least, that's how I understood the announcement.)

[Dragon]

Yes, WiH2 is really WiH Act 3.

[redsniper]

So I gather that you are skipping War in Heaven 2 to go directly to 3.

Either that or you have successfully confused me with all the crazy numbering.

Please read the thread! In the very first post it says that they're releasing Act 3 of WiH, not BP3. WiH is and always has been BP2. We're still on BP2.

[Nyctaeus]

Act I: Chrysalis
Act II: Apotheosis
Act III: Tenebra

First release of WiH contains Act I and Act II. Second release will contain Act III... Moment. WiH will be a trilogy, or you're making also Act IV?

[The E]

There are 2 more acts to follow, and we're working on them at the moment. We just thought that releasing the stuff we have finished and polished enough would be a nice thing to do.

[General Battuta]

Our plan was to release Blue Planet like this:

Blue Planet 1 (released)

Blue Planet 2 R1 (acts 1 + 2) (released)
Blue Planet 2 R2 (acts 3, 4, 5)

Blue Planet 3

Unfortunately our progress on BP2 R2 has been slower than we'd like. We think it's really important to keep momentum going in terms of releases, so we're releasing Blue Planet 2 Act 3. Blue Planet 2 Acts 4 and 5 are still WIP. Then there's BP3.

I know, it's confusing and it sucks we don't have more to ship. But we thought people would rather have a modest amount to play now than a huge amount to play who-knows-when.

When BP2 is done it'll look like this:

Act I: Chrysalis
Act II: Apotheosis
Act III: Tenebra
Act IV: War in Heaven
Act V: Revenant

[General Battuta]

There's also a lot of big story content in this release, and the forum discussion has been so excellent we thought people deserved more to work with.

[Luis Dias]

There's also a lot of big story content in this release, and the forum discussion has been so excellent we thought people deserved more to work with.

 

[Crybertrance]

So, I finally decided to re-play AoA with the update, but Im getting these 3 errors:

Code: [Select]

A mainhall with the name 'BP1-Start' already exists. All mainhalls must have unique names.
ntdll.dll! ZwWaitForSingleObject + 21 bytes
kernel32.dll! WaitForSingleObjectEx + 67 bytes
kernel32.dll! WaitForSingleObject + 18 bytes
fs2_open_3_6_17_SSE2_BP.exe! <no symbol>
fs2_open_3_6_17_SSE2_BP.exe! <no symbol>
fs2_open_3_6_17_SSE2_BP.exe! <no symbol>
<no module>! <no symbol>


Code: [Select]

A mainhall with the name 'BP1-Middle' already exists. All mainhalls must have unique names.
ntdll.dll! ZwWaitForSingleObject + 21 bytes
kernel32.dll! WaitForSingleObjectEx + 67 bytes
kernel32.dll! WaitForSingleObject + 18 bytes
fs2_open_3_6_17_SSE2_BP.exe! <no symbol>
fs2_open_3_6_17_SSE2_BP.exe! <no symbol>
fs2_open_3_6_17_SSE2_BP.exe! <no symbol>


Code: [Select]

A mainhall with the name 'BP1-End' already exists. All mainhalls must have unique names.
ntdll.dll! ZwWaitForSingleObject + 21 bytes
kernel32.dll! WaitForSingleObjectEx + 67 bytes
kernel32.dll! WaitForSingleObject + 18 bytes
fs2_open_3_6_17_SSE2_BP.exe! <no symbol>
fs2_open_3_6_17_SSE2_BP.exe! <no symbol>
fs2_open_3_6_17_SSE2_BP.exe! <no symbol>

I get this error whenever I return to the mainhall (on startup, I get no errors at all).

Debug log : http://pastebin.com/Xs4a5zDr

[The E]

Code: [Select]

-reparse_mainhall
This flag. Why do you have it on?

[Echelon9]

Something is wrong with the 7z package.
Have downloaded the non-executable archive (for Linux/MacOS) from FSMods, and getting the files and folder structure but all zero kb files.

Fixed by upgrading to a newer 7zip Mac decompresser, Keka