Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Nightly Builds => Topic started by: SirKnightly on December 04, 2009, 11:53:16 pm
-
Here is the nightly for Windows on 04 Dec 2009 - Revision 5698
Group: SSE2
fso-WIN-SSE2-20091204_r5698.7z (http://swc.fs2downloads.com/builds/WIN/fso-WIN-SSE2-20091204_r5698.7z)
MD5Sum (http://swc.fs2downloads.com/builds/WIN/fso-WIN-SSE2-20091204_r5698.md5)
Group: Standard
fso-WIN-Standard-20091204_r5698.7z (http://swc.fs2downloads.com/builds/WIN/fso-WIN-Standard-20091204_r5698.7z)
MD5Sum (http://swc.fs2downloads.com/builds/WIN/fso-WIN-Standard-20091204_r5698.md5)
Group: Inferno
fso-WIN-Inferno-20091204_r5698.7z (http://swc.fs2downloads.com/builds/WIN/fso-WIN-Inferno-20091204_r5698.7z)
MD5Sum (http://swc.fs2downloads.com/builds/WIN/fso-WIN-Inferno-20091204_r5698.md5)
Group: Inferno_SSE
fso-WIN-Inferno_SSE-20091204_r5698.7z (http://swc.fs2downloads.com/builds/WIN/fso-WIN-Inferno_SSE-20091204_r5698.7z)
MD5Sum (http://swc.fs2downloads.com/builds/WIN/fso-WIN-Inferno_SSE-20091204_r5698.md5)
Group: Inferno_SSE2
fso-WIN-Inferno_SSE2-20091204_r5698.7z (http://swc.fs2downloads.com/builds/WIN/fso-WIN-Inferno_SSE2-20091204_r5698.7z)
MD5Sum (http://swc.fs2downloads.com/builds/WIN/fso-WIN-Inferno_SSE2-20091204_r5698.md5)
Group: SSE
fso-WIN-SSE-20091204_r5698.7z (http://swc.fs2downloads.com/builds/WIN/fso-WIN-SSE-20091204_r5698.7z)
MD5Sum (http://swc.fs2downloads.com/builds/WIN/fso-WIN-SSE-20091204_r5698.md5)
------------------------------------------------------------------------
r5693 | portej05 | 2009-12-02 11:16:33 -0600 (Wed, 02 Dec 2009) | 1 line
Changed paths:
M /trunk/fs2_open/code/fred2/fred.cpp
M /trunk/fs2_open/code/freespace2/freespace.cpp
M /trunk/fs2_open/code/globalincs/mspdb_callstack.cpp
M /trunk/fs2_open/code/globalincs/mspdb_callstack.h
M /trunk/fs2_open/code/globalincs/windebug.cpp
Commit to update PDB_DEBUGGING in preparation for new allocator system
------------------------------------------------------------------------
r5694 | portej05 | 2009-12-03 01:01:48 -0600 (Thu, 03 Dec 2009) | 1 line
Changed paths:
M /trunk/fs2_open/code/freespace2/freespace.cpp
M /trunk/fs2_open/code/osapi/osapi.cpp
Running as standalone no longer disables windows key (Mantis #2047)
------------------------------------------------------------------------
r5695 | portej05 | 2009-12-03 04:23:59 -0600 (Thu, 03 Dec 2009) | 1 line
Changed paths:
M /trunk/fs2_open/code/globalincs/mspdb_callstack.cpp
Fix "SymRefreshModuleList" symbol not found error on platforms without dbghelp.dll v6.5+ (we really should distribute that monster)
------------------------------------------------------------------------
r5696 | Goober5000 | 2009-12-04 00:19:02 -0600 (Fri, 04 Dec 2009) | 1 line
Changed paths:
M /trunk/fs2_open/code/freespace2/freespace.cpp
fix for Mantis #2044
------------------------------------------------------------------------
r5697 | portej05 | 2009-12-04 00:58:22 -0600 (Fri, 04 Dec 2009) | 1 line
Changed paths:
M /trunk/fs2_open/code/globalincs/mspdb_callstack.cpp
MSPDB fix for VC6 users.
------------------------------------------------------------------------
r5698 | portej05 | 2009-12-04 18:50:09 -0600 (Fri, 04 Dec 2009) | 1 line
Changed paths:
M /trunk/fs2_open/code/freespace2/freespace.cpp
Turns out enableWindowsKey/disableWindowsKey isn't defined for all platforms
------------------------------------------------------------------------
-
Something in this build causes the launcher to crash. When I try to select any of the revision 5698 builds the launcher freezes. I checked the standard, the SSE2, the SSE2 inferno and one of the debug builds. It does the same thing with the Babylon Project launcher.
-
Works fine here.
-
Starting with this build I have not been able to get any of the new nightly builds to work (5700 0r 5706). The launcher freezes if I try to select any of the new builds and fred 2 wll not work with any of the new builds. I tried renaming the exe files to drop the date and rev number. and replacing the old file with the new, both named fs2_open_3_6_11r_sse2 so I didn't have to select the new exe file. When I went to open the launcher I got a message saying there was no disk in drive D. Maybe this is a unique problem to windows 7 but I haven't had any problems with Rev. 5692 and previous.
-
Win7 x64 and the builds are still working fine.
-
I am also getting this error.
It occurs right at the beginning of the executable, whether run by the launcher to get the available flags, or normally to run the game.
No FS2Open log is created.
- Reported in http://www.hard-light.net/forums/index.php?topic=66996.msg1325174#msg1325174
This bug appears in this SirKnightly and is still seen in 5716.
-
I think there may be a bug in the launcher, but we've not been able to find anything definitive in the past few days.
Could you check the command line in cmdline_fso.cfg and paste it here?
-
Check this thread: http://www.hard-light.net/forums/index.php?topic=66996.0
It's not an FSO issue, but a Windows one.
-
Clearing the recent documents history has no effect whatsoever.
Note that this is *not*a launcher crash - it is an unexpected error message from FS2Open Inferno SSE that does not exist in 5692.
It doesn't appear to be related to the launcher at all, as it also occurs when the FS2 Open executable is run directly.
I have tried this with my normal cmdline_fso.cfg, no cmdline_fso.cfg, a blank one and with the following:
-mod fsport-mediavps,fsport,mediavps
All these situations have identical error messages.
- My CPU is an Athlon XP 3000+, and I don't think that supports SSE2.
-
And I am telling you, if the error message you get is "Windows - No Disk"
"Exception processing message c0000013 Parameters 75b6bf7c 4 75b6bf7c 75b6bf7c", then it is a Windows issue, not an FSO one. Note the results of this Google search: http://www.google.de/search?hl=en&q=%22Exception+processing+message+c0000013+Parameters+75b6bf7c+4+75b6bf7c+75b6bf7c%22&btnG=Search&aq=f&oq=
-
That doesn't answer the question, The E.
It *does not occur* in 5692.
It *occurs every time* in 5698.
All support and system files are unchanged. The Launcher is not used.
It does not matter if I run one first and then the other, it does not matter if I've just rebooted or not.
Therefore, there is a change between 5692 and 5698 that is causing the error.
It may well be an error from one of the Windows APIs called by FS2 Open, but it is definitely and without doubt caused by a change between 5692 and 5698, and it is therefore *under our control*
I'm going through builds to find the change that caused it.
-
That may well be, but until someone else reports this, I am going to continue to assume that the issue is something on your end. Nothing personal, just tech support.
-
Tomo: Try redownloading the executable - could be a corrupted image.
-
I've been unable to build a version that runs at all in VC 2008 Express - the compiled app always gives the following error:
"SymRefreshModuleList" could not be located in dbghelp.dll
What am I missing?
-
What about redownloaded nightly builds? You might also need to update your checkout of the code.
-
Tomo: That symbol is no longer used in Trunk (or antipodes).
Please make sure you have updated your repository.
-
Thanks - I'm doing a full clearout of my SVN folders now to be certain.
I have bounced up and down versions several times and done a Tortoise SVN client update so I can well believe it's got confused.
When was dbghelp added and removed - basically, when I sync to builds between 5692 and 5698 will it turn up again?
As to redownloading - I've now had a chance to try that from the above 5698 links.
The No Disk error still occurs in a freshly downloaded copy of INF SSE and INF.
- Incidentally, this system has a floppy disk drive and several card readers that turn up as drives even when empty.
A couple of the Google hits imply these may be related.
-
It *does not occur* in 5692.
It *occurs every time* in 5698.
Therefore, there is a change between 5692 and 5698 that is causing the error.
It may well be an error from one of the Windows APIs called by FS2 Open, but it is definitely and without doubt caused by a change between 5692 and 5698, and it is therefore *under our control*
I'm going through builds to find the change that caused it.
I hope you find the answer because I can't get any of the revisions since 5692 to work right. I'm running Windows 7 and have been since it was released. I didn't have this problem until revision 5698.
-
Same symptoms? Similar error message? Anything that would give us a clue as to what is going on?
-
Yes, see my previous posts. The difference is that I typically use the launcher and don't start directly from the exe file.
-
Again, all I can say is that everything I have found so far on the internets leads me to believe it is a Windows issue, not a FSO one.
http://social.technet.microsoft.com/Forums/en-US/itprovistahardware/thread/696fae8f-462f-4e08-8315-1dadc38f02f9
http://www.consumingexperience.com/2007/11/windows-no-disk-exception-processing.html
Now, judging by the commits in that time, that is between 5692 and 5698, none of them springs immediately to mind as being the culprit for this.
-
I guess I'll re-download Rev. 5692 and go back to using it until I figure out my "Windows" problem.
-
dbghelp has been linked in for a long time - as long as PDB_DEBUGGING has been there.
5693 required a more recent version of dbghelp.dll, however that change was fixed in 5695.
5698 is now almost 30 revisions out of date. Is there a reason why you need such an old build?
-
It *does not occur* in 5692.
It *occurs every time* in 5698.
dbghelp has been linked in for a long time - as long as PDB_DEBUGGING has been there.
5693 required a more recent version of dbghelp.dll, however that change was fixed in 5695.
5698 is now almost 30 revisions out of date. Is there a reason why you need such an old build?
To locate the cause of the problem - basic fault finding, yes?
It is still in 5733 and 5716.
On my PC the error does not appear to be fatal - but presumably on others it may be.
-
I have a hunch on this, I think the other instance of HRESULT_FROM_WIN32 needs to be removed as was done for one of them in 5695. I think portej missed one with that fix. Even if it's not causing a problem here, if one was removed I can only assume the other needs to be removed too.