[Parias]

Hah. You know what? I might have to take back my earlier sentiments - maybe there is something specific to the launcher app or FSO causing this.

Don't burn me at the stake yet - I'm only changing my stance because I actually have something vaguely resembling tangible proof. Up until this point I've always had some kind of disc in my system's drives, but today ended up removing all that media. When I launched the game via launcher.exe, Windows suddenly (before the launcher even fully loaded) threw a generic "There is no disk in the drive. Please insert a disk into drive G:" (one of my DVD drives) with "fs2_open_3_6_12_RC4r_INF_SSE2.ex - No Disk" in the title bar. I repro'd the issue with Process Monitor running, looked for all instances of G:\, and found this:



Interesting, no? In a way this might also explain why another person was reporting the error didn't happen if they did their own build from source - seems like this might be a legacy of the configured dev environment from whoever built this particular exe, though I'm hardly a Visual Studio expert.

The error of course is otherwise utterly benign and I can skip it and launch the game with no impact - I expect putting a disc back in my drive will of course make it go away again too (the "not found" failure will occur gracefully rather than making Windows freak out about non-existent media). Just wanted to throw my two cents in here anyways that the problem might have something to do with the way the latest builds were put together after all, since now there's actually something in the way of tangible evidence to present to this end.

[Tomo]

That makes sense - I also have a drive G with removable media (Compact Flash card reader)

Also explains why it's not seen by very many people, because you'll only see it if a *removable* Drive G exists - otherwise, Windows comes back with PATH NOT FOUND instead.
- Will try remapping that drive letter tonight to see what difference it makes.

This does prove that there's something screwy in the PDB stuff.

Anyway:
The dialog pops up when you start the Launcher because the first thing the Launcher does is to run FS2-Open to get the supported and recommended command line (and other) options. It also does that whenever you select a new FS2-Open executable.

[The E]

Well, according to this: http://msdn.microsoft.com/en-us/library/yd4f8bd1(v=VS.71).aspx that's just what it is designed to do, and there's nothing we can really do about it (except maybe ask chief to move the drive location to somewhere seldom used, like V: or W:). Short version: PDB debugging embeds the absolute path to the pdb in question in the exe (and no, there is no way to adjust that behaviour), and the search path for the pdbs calls that location first, then the current exe path.

[Fury]

Since pdb's are unnecessary with R-builds as far as I know, perhaps chief should remove R-build pdb's from his script. That alone would eliminate the problem for most people for most of the time. Even if the problem still occurs with D-builds, it's a minor annoyance. Even so, pdb-extensions for D-builds could be renamed until you need them.

Removing R-build pdb's would also cut 7z-archive size from 14.0 MB to 11.5 MB if he would use LZMA Ultra compression. He doesn't use Ultra though so archives are larger. Still, roughly 20% size reduction in archive sizes by just removing R-build pdb's is useful. Combine that with highest compression level and chief can shrink nightlies down to 11.5 MB. I hope that'd be enough to get him into including SSE2 debug builds in SSE2 archives, because downloading both SSE and SSE2 nightlies for the debugs is a mild annoyance.

[The E]

Since pdb's are unnecessary with R-builds as far as I know, perhaps chief should remove R-build pdb's from his script. That alone would eliminate the problem for most people for most of the time. Even if the problem still occurs with D-builds, it's a minor annoyance. Even so, pdb-extensions for D-builds could be renamed until you need them.

Nope, it wouldn't. The problem isn't the presence of pdbs, it's the way how pdbs are used by Windows. Whether or not you have pdbs is completely irrelevant; the simple fact that these builds were made using pdb debugging information is enough to trigger this.

Removing R-build pdb's would also cut 7z-archive size from 14.0 MB to 11.5 MB if he would use LZMA Ultra compression. He doesn't use Ultra though so archives are larger. Still, roughly 20% size reduction in archive sizes by just removing R-build pdb's is useful. Combine that with highest compression level and chief can shrink nightlies down to 11.5 MB. I hope that'd be enough to get him into including SSE2 debug builds in SSE2 archives, because downloading both SSE and SSE2 nightlies for the debugs is a mild annoyance.

True, but beside the point.

[Fury]

The problem isn't the presence of pdbs, it's the way how pdbs are used by Windows. Whether or not you have pdbs is completely irrelevant; the simple fact that these builds were made using pdb debugging information is enough to trigger this.

Do R-builds need to be made using pdb debugging information in the first place? It's just doesn't seem useful.

[The E]

I guess not. Looking at the project configuration, it seems that the release exes are built with the Linker /DEBUG switch on, which seems unnecessary.

[Zacam]

Probably because the Preprocessor Definitions was supposed to house a PDB_DEBUGGING option and they are not.

I'm fine with removing the linker setting so long as it is tested. And it's probably high time that the project settings get re-evaluated anyway.