Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Test Builds => Topic started by: Goober5000 on April 25, 2005, 07:26:57 pm
-
http://fs2source.warpcore.org/exes/latest/20050425-Goober5000.rar
Latest CVS. The sexp bump should actually be in this one.
Added to the website.//redmenace
-
*Dls in the vein hope that it'll be both stable, and somehow fix the shinemap issue :p*
-
Have given it a try, but the release build refuses to load any missions. Crashes with memory access violation error. Have saved error log file, once without compatibility, once with win98 compatibility. If needed it can be MantisfiedSame thing. Debug build gave one error when I let my ship get destroyed:
Warning: Null vec3d in vec3d normalize.
Trace out of vecmat.cpp and find offending code.
File:C:\Languages\Visual Studio Projects\Visual C++\fs2_open\code\Math\VecMat.cpp
Line: 771
Call stack:
------------------------------------------------------------------
vm_vec_normalize() g3_draw_rotated_bitmap_3d() g3_draw_rotated_bitmap() fireball_render() obj_render() obj_render_all() game_render_frame() game_frame() game_do_frame() game_do_state() gameseq_process_events() WinMainSub() WinMain() WinMainCRTStartup() kernel32.dll 7c816d4f()
------------------------------------------------------------------
Other than that, the debug build ran good, but with with about a 35% reduction in frame rate over the 20040414 release build.
I have this same issue with the 20040423 build. Will not load missions. Gets to loading screen and crashes. Doesn't seem to matter what features are enabled, same results every time.
This seems to be a problem for just these builds. Tech room models have glows and shine maps working, and looks great. Just can't play the game.
System:
WinXP Sp2
[email protected] HT
MSI 5950 Ultra, 256mb
1 gb dual ch DDR
Using 1024x768 resolution.
-
i think i found the access violation error. i'll write a report in mantis once i get home in a few hours.
We also have the window centered on the desktop if you're using the "-window" command line. additionally, cutscenes should play in windows now. any problems related to that should be submitted here:
http://mgo.maxgaming.net/mantis/bug_view_advanced_page.php?bug_id=0000361
-
Can you make the window centering optional? I prefer it in the corner to be honest. It allows me to watch the debug window/IM client at the same time. :)
-
Actually I think we should keep it centered. You can always drag it to the corner.
-
Here's a fun feature I added - try putting "$AliveSnd" on a subsystem and/or "$DeadSnd" if it's going to get destroyed.
Note that this uses the new sound parsing stuff, so you can use the sound filename instead of the sounds.tbl index...although the sound still needs to be in sounds.tbl.
-
Originally posted by Goober5000
Actually I think we should keep it centered. You can always drag it to the corner.
Ditto. I have the taskbar on top, and it's a PITA to have to go through the steps to move it every time.
-
As long as it's dragable that's okay :)
-
Running FRED_d produces following error message (for all weapons)
Warning: $LaunchSnd: sound index out of range on 'Mass Driver'. Must be between 0 and 0. Forcing to -1 (Nonexistant sound).
File:C:\Languages\Visual Studio Projects\Visual C++\fs2_open\code\Gamesnd\GameSnd.cpp
Line: 287
Call stack:
------------------------------------------------------------------
fred2_open_d.exe 005608fa()
fred2_open_d.exe 0056290b()
fred2_open_d.exe 00563313()
fred2_open_d.exe 0044f213()
fred2_open_d.exe 00447711()
fred2_open_d.exe 00903702()
fred2_open_d.exe 00903064()
fred2_open_d.exe 00900c09()
fred2_open_d.exe 009010a5()
USER32.dll 77d43a68()
USER32.dll 77d4a8f9()
USER32.dll 77d4450d()
USER32.dll 77d4887f()
ntdll.dll 77fb4da6()
USER32.dll 77d48ab5()
------------------------------------------------------------------
Older builds work fine. Same applies to the game exe. Instant CTD on mission loading (no error messages). Older builds work fine as well.
-
I've been using latest-CVS debug builds and had no troubles...
-
TBP won't run a single mission with this build. I crashed in the loading screen at ~25%. Always.
-
Originally posted by DaBrain
TBP won't run a single mission with this build. I crashed in the loading screen at ~25%. Always.
yes, my reports is based on WCSaga dataset. Although a debug build will load a mission. It crashes after ~30 seconds. Again, no error messages.
-
Originally posted by DaBrain
TBP won't run a single mission with this build. I crashed in the loading screen at ~25%. Always.
Seems to be a similar problem for Inferno, SCP edition.
-
It does the same for me using the stock 3.6.6 media vps.
-
I have to second what Tolwyn and the others just said. Though I can load small test-missions (a few ships only, nearly no scripts), but all bigger mission crash upon loading.
This following stands on the end of most debug-logs, maybe you guys reduced some limits again for multi or just in accident ? I hope this here helps :
(http://www.starman.ag5.de/pics/error.jpg)
-
Test results:
Installation type: Vanilla FS, no FSport, no mod, no options enabled:
14th build: can load and play missions, but crashes occacionally, oddly did not produce error log or message.
23rd build: can enter tech room, but when loading a mission crashes almost immediately - memory access violation error.
25th build: exactly same results as 23rd build above.
Top bit of the error log, just before the stack dump:
fs2_open_r_20050425 caused an Access Violation in module fs2_open_r_20050425.exe at 001b:00647300.
Exception handler called in Freespace 2 Main Thread.
Error occurred at 4/28/2005 16:47:32.
C:\Games\FreeSpace2\fs2_open_r_20050425.exe, run by Malcolm.
2 processor(s), type 586.
1024 MBytes physical memory.
Read from location 00000009 caused an access violation.
Registers:
EAX=02d957ff CS=001b EIP=00647300 EFLGS=00010286
EBX=01860df4 SS=0023 ESP=0012f884 EBP=0012f890
ECX=00000000 DS=0023 ESI=00000009 FS=003b
EDX=01860df4 ES=0023 EDI=01860df4 GS=0000
Bytes at CS:EIP:
8a 06 46 8a 27 47 38 c4 74 f2 2c 41 3c 1a 1a c9
I can run debug builds, but not the release builds. I have no problem doing further testing if someone will point out to me what exactly to look for that would be the most helpful. I haven't had any problems with Fred2 though, but again, that is with no mods enabled.
-
Fred2_open_d gives an error message on the $LaunchSnd and $ImpactSnd for every single weapon in the table. It demands that all weapon sounds fall in the range between 0 to 0 (which obviously fits none of them), and then informs me that it is forcing them all to -1.
I was trying to use this fred2_open_d to debug my tables, because something is causing a CTD on the first bar of the mission loading screen in fs2_open_r, which fs2_open_d seemed to associate with a misnamed subsystem (a CTD seems like an extreme response to something so minor, btw), but after about a hundred iterations of the sound error, I gave up trying.
-
Both Goob's 04-23 and 04-25 "r" builds CTD during mission load. Debug versions of these builds will run, but the over-pick nature of debug builds these days makes them inefficient to use. WMC's 04-23 build works fine in that respect. He's got a newer build out too, but he just hasn't announced it. I haven't tested that build fior stability.
-
Whatever is wrong with the Herc (that gets picked out EVERY TIME it shows up in a mission :doubt:) really should get fixed. I think it's that it has 5 LODs + debris, where the game expects only 4.
-
What needs to be done about the herc is make FSO accept more LODs.
-
TP: Careful with that build. I made some changes to the medals code, so if you're using it I'd suggest you back up your pilot/campaign save files. Before I got it fully tuned, I accidentally wiped out my main FS2 campaign progress + score + medals. I uploaded it for the testers, as if it turned out to work fine I was going to post it here.
-
Warning accepted. I'll stick with your 04/23 build for now then. Too bad about Goob's CTD.
-
Originally posted by StratComm
Whatever is wrong with the Herc (that gets picked out EVERY TIME it shows up in a mission :doubt:) really should get fixed. I think it's that it has 5 LODs + debris, where the game expects only 4.
actually thats a table problem. the old herc is ok, but if you're using bob's herc which has 5 LODs, then there are 5 LODs but only 4 defined in the tables.
-
I guess FSO does support more than 4 LODS. On a whim, I added another distance entry for the Herc and FRED debug stopped complaining about it.
-
BR's STL crashes at 2 'blocks' of loading, every time. Works fine with older builds.
-
Here comes the old mantra of FS2 SCP testing:
What's your configuration (CPU, G-card, RAM, S-card, OS, joystick ect.)?
What flags did you use?
What mod did you use (anything beside main FS2 counst as a mod)?
What vp files were loaded?
Where were the files?
Did you use the mod function of the launcher?
What mission did you load?
What's inside the errorlog?
If it wasn't a CTD (Cut to Desktop) what errormessage did you recieve?
-
Also,
What did a debug build say?
I'm not singling you out, lots of people don't use or don't mention debug builds. A computer can go through over 10,000 lines of code in a second; narrowing down which line is causing the problem is made a lot easier if there's a debug build error that can be followed up on.
What we need in the launcher is a bug-reporting tab that has fields/says all this. :)
-
*grin*
Y'know, when I posted that, my admin soul thought 'This is so useless. Noone can do anything with this: it's almost spam'. But everyone else was doing it! :)
Rerunning the 0425 debug build, it complains about not having Lightspeeds nebulas (which I was sure I had, but I guess normal builds don't complain about it) and it worked fine.
-
It's actually quite interesting that you can even see the second loading block. For most everyone it jumps from the first to the last instantly.
-
Really? For me, it usually takes quite some time to progress through all of them, with some pauses in between. Granted, my machine's not the fastest around, but it's not a fossil, either.
-
On my crappest machine (2100xp,256Mb,5500) it can take almost a minute to go through the loading, with most of it being the first few bits. I thought that was normal for low spec machines?
-
Originally posted by WMCoolmon
Also,
What did a debug build say?
I'm not singling you out, lots of people don't use or don't mention debug builds. A computer can go through over 10,000 lines of code in a second; narrowing down which line is causing the problem is made a lot easier if there's a debug build error that can be followed up on.
What we need in the launcher is a bug-reporting tab that has fields/says all this. :)
I'm surprised this bug hasn't recieved more attention. Basically, under release builds, FSO will crash during the 1st 2 loading bars. On the other hand, if one uses the debug build and attempts it, it will work properly (assuming the user has no outstanding table errors). There is no error message related to the crash under the release builds. This occurs both under Goober's 23rd and 25th builds.
-
Originally posted by Trivial Psychic
I'm surprised this bug hasn't recieved more attention. Basically, under release builds, FSO will crash during the 1st 2 loading bars. On the other hand, if one uses the debug build and attempts it, it will work properly (assuming the user has no outstanding table errors). There is no error message related to the crash under the release builds. This occurs both under Goober's 23rd and 25th builds.
I'm getting that one too. Happened on Snyc and some MG missions I tried testing it on.
-
try WMC's newest builds. I think i fixed something that probably caused it.