Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Test Builds => Topic started by: taylor on May 26, 2005, 04:44:27 am
-
First new build from me for a while but there will hopefully be a few good things in here. All of this is in CVS so all future builds should have these changes as well. The main things that have changed or been fixed (since Phreak's build):
- Timer changes to fix broken loading bar on some systems that would have one spot lit and then jump to the end. This change could affect various parts of the game so if anything is either really slow or really fast please report it. This could fix several speed issues too that seemed to affect only certain systems so if any old bugs are fixed by this please report it.
- Various memory related fixes that mainly helps developers but should prevent some crashes as well.
- Don't try to page out ship textures when that ship explodes. Just like Phreak's build and is reported to fix the EFF explosion stuttering.
- Various pilot file related fixes to prevent data loss due to mod use. Now it won't let you in the barracks or the techroom if your current campaign is missing. Also in the barracks it won't let you access a pilot who is using a campaign that's currently missing.
- Some ANI related fixes to help guard against crashing when the ANI is corrupted. If the ANI is corrupted it will stop playing at the first sign of a problem so if something appears to cut off early that would likely be the reason.
- Make sure that lasers aren't rendered with fog in nebula missions.
- A fix to not have rendering errors when a laser is animated but it's glow is not.
- Various sound related crash fixes.
Included in this build are two versions of the release/debug files with the different audio APIs, DirectSound and OpenAL. The DirectSound filenames are my typical: fs2_open_T-<date>.exe for release builds and fs2_open_T-<date>-dbg.exe for debug builds. The OpenAL builds have "OAL" between the "_T" and the date. The plan is to eventually dump DirectSound and go just with OpenAL on all platforms but it needs a lot of testing first. If you have sound problems or sound related crashes then please specify which build you are using when you report it.
*UPDATED*
- fixed a bmpman error that would cause anis to not get unloaded properly. This turned into something like a memory leak as you played from mission to mission.
- several OpenAL fixes, possible crashes are fixed too but not tested to that fact.
- prevented display of missile indicators, and offscreen target brackets with disable-hud-except-messages
- fix issue where a mission with no briefing text/stages might show the text from a previous mission.
- docking abort on warp out crash fixed by Goober
- fix anis in briefing screens that didn't show in previous build
- experimental change to OpenGL where it should reduce redundant image processing when non-DDS textures are already power-of-2, saves some memory too.
- some attempts to address the various errors reported by redmenace. Not all fixed but will hopefully give better debug info now so the real problems can be found.
And now for the build: http://icculus.org/~taylor/fso/testing/20050530-win32.rar
-
Direct Sound is working fine for me, when playing with OpenAL I can hear strange (scratching) sounds that let me think my sound card can't handle it... (Different Problem than reported in the Testers Forum).
And I get many crashes and errors with some campaigns and missions that worked fine with some older builds.
While loading a mission it stopped and nothing else happened.
-
I am getting a crash in the campaign mission SM2-04.fs2. fs2_open crashes right after the Uhera explodes. Attached in the relevant data.
-
Im still getting crashes with this build when loading missions from the techroom, a la my other post..
Using the debug mode nothing shows up when it crashes, though apparantly im missing some files (dev only?) such as
Warning: Couldn't open texture 'cyan_glow_small'
referenced by model 'fighter01.pof'
File:U:\src\cvs\fs2_open.testing\code\Model\ModelRead.cpp
Line: 2227
Call stack:
------------------------------------------------------------------
model_load() techroom_select_new_entry() techroom_change_tab() techroom_init() game_enter_state() gameseq_set_state() game_process_event() gameseq_process_events() WinMainSub() WinMain() WinMainCRTStartup() kernel32.dll 7c816d4f()
------------------------------------------------------------------
and other "glows" along with .tbl files, and..
For "fighter01.pof" I couldn't find Fighter01-01a.ani but I did find Fighter01-01a.dds.
tga: Couldn't open 'red_glow_small.tga'
couldn't find particle pcx for Shivan Heavy Laser (and others)
afaik I got all the required files, have i missed something or does none of this matter? right now im assuming its dev only (the U drive reference, and some other references in the debug)
As for the crashing when loading problem, you mentioned that was only on phreaks build so i guessed this might fix it- is anyone else having the problem? (Try loading "As Lightning Falls" and "Exodus" from the techroom)
-
1. Movies are only playing their audio in the game while the loading screen is finished but not disapearing. In other words no video.
2. In mystery of the trinity, while using Open GL, if you target the trinity you get a crash.
3. Can't use debug with open GL when you get error messages and select no. You get a black screen.
4. Nebulea Missions are incredibly slow.
5. Crashes and error messages, see attachment
-
6. Error Message, while looking at the Orion in the mission "Lion At The Door"
-
Well in TBP 3.2, the standard build won't play the oggs as usual, while the OAL build does as WMC's May 2nd build did, and CTDs as soon as you try to get beyond the pilot select screen. The only difference is that WMC's build is that with his, after the CTD, the ambient rumble would continue after the program shut down and persist until you reboot... this doesn't occur with Taylor's OAL build. It seems that OAL is both a problem and a solution for TBP 3.2. I have no idea how we're gonna solve this one.
-
Originally posted by redmenace
I am getting a crash in the campaign mission SM2-04.fs2. fs2_open crashes right after the Uhera explodes. Attached in the relevant data.
There is a Mantis bug on this one. I have yet to have it happen to me so it's a little difficult to back through and find the problem. Seems to happen only with that one ship though, only in that one mission, and it's not a model issue.
1. Movies are only playing their audio in the game while the loading screen is finished but not disapearing. In other words no video.
Is this OGL or D3D? I only tested movies on startup (intro) and in the techroom. Do movies work properly there for you?
3. Can't use debug with open GL when you get error messages and select no. You get a black screen.
Is that during the loading screen? If so then just wait on it. It is loading and should go back to a normal screen when it hits the briefing. If that's not the case, and it's happening in a mission too without ever giving you a screen back then let me know. I'm assuming that you are running fullscreen?
4. Nebulea Missions are incredibly slow.
In both OGL and D3D? I only really noticed a big speed drop in D3D. I'm trying to locate that problem now but if it does happen in OGL then that would make it easier for me to find.
6. Error Message, while looking at the Orion in the mission "Lion At The Door"
Is that with the new HTL model or the original? If the new one does the old one still give this error?
I'm going through your other messages and logs now and have a few things to fix. I'll update this weekend.
@Trivial Psychic: I'll go through the DirectSound code again just in case I'm missing something. Do you have any more info in the pilot select CTD? Is it happening with only one pilot or all of them? New ones too? Does it seem data related (ie. does the current TBP release or standard FS2 data crash)? If you can send me the errorlog.txt file then I'll try and track that down and get it fixed. Also try with -nomusic and see if it still happens if so then try -nosound. I've had a couple of issues with corrupting audio streams in the OAL build so it could just be that. If -nomusic fixes it then get me the mainhall music and I'll work out a fix.
-
Originally posted by taylor
@Trivial Psychic: I'll go through the DirectSound code again just in case I'm missing something. Do you have any more info in the pilot select CTD? Is it happening with only one pilot or all of them? New ones too? Does it seem data related (ie. does the current TBP release or standard FS2 data crash)? If you can send me the errorlog.txt file then I'll try and track that down and get it fixed. Also try with -nomusic and see if it still happens if so then try -nosound. I've had a couple of issues with corrupting audio streams in the OAL build so it could just be that. If -nomusic fixes it then get me the mainhall music and I'll work out a fix.
Well, I gave it a try with -nosound and it made it past the pilot select screen, so whatever it is, it has to do with how music oggs interact with the OpenAL implimentation for other sounds. I've included the errorlog (http://www3.sympatico.ca/daniel.topps/errorlog.txt). Just be aware, that I rename all builds that I install to my own proprietary system. It is fs2_open_XXXXX_2005-XX-XX_r.exe. the main XXXXX stream is where the creator's name or short for it will be displayed. Any special build notes (such as OAL) will be separated by a "_" before the "r".
Since you asked for the mainhall music, HERE (http://www3.sympatico.ca/daniel.topps/b5_season5.ogg) it is.
-
Both Directsound and OpenAL seems to work fine for me. Nebula missions also work without considerable slowdown.
Herc however had little problem, those two purple lights just outside the cockpit were actually seen while on first person mode inside the cockpit. Kinda hard to explain, could somebody just testride the herc in firstperson and see if there's anything...strange going on. Or then the incident above is not a bug but a new feature, or something. Check back later...
-
Originally posted by taylor
There is a Mantis bug on this one. I have yet to have it happen to me so it's a little difficult to back through and find the problem. Seems to happen only with that one ship though, only in that one mission, and it's not a model issue.
Yes, basically. I also noticed a texture flickering issue as well.
Is this OGL or D3D? I only tested movies on startup (intro) and in the techroom. Do movies work properly there for you?
I believe it is both in open GL and D3D. Unless I post otherwise, assume that the intro and the techroom movies work fine.
Is that during the loading screen? If so then just wait on it. It is loading and should go back to a normal screen when it hits the briefing. If that's not the case, and it's happening in a mission too without ever giving you a screen back then let me know. I'm assuming that you are running fullscreen?
I will take a look into that. Assume that is goes back unless I post otherwise.
In both OGL and D3D? I only really noticed a big speed drop in D3D. I'm trying to locate that problem now but if it does happen in OGL then that would make it easier for me to find.
D3D. And the more violent the nebulea the slower it is. IE more lightning. On recently destroyed ships debris the electrical lightning seems to slow down the game as well.
Is that with the new HTL model or the original? If the new one does the old one still give this error?
I will take a look into that. Assume that is the HTL model that is the cause.
I'm going through your other messages and logs now and have a few things to fix. I'll update this weekend.
In regaurds to number 2, I will check the problem with targeting the Trinity.
-
In number 3 it is not going back. In window mode it does continue to load. I will double check. But I did notice that it does take a longer than normal to load.
In bug 2 I have the fs.log and errorlog attached to this post.
In bug 6, there is a wing departing the hanger. This, as it turns out, is not caused by the HTL model. It is strictly related to fs2_open IMO. I tried with out the VPs being used.
-
I got 2 additional crashes during one during Slaying the Ravana regaurding vec3d like the one Lion at the door.
Second was during Into the Maelstrom and concerned a failed assertion. Unfortunatly I did not get a copy of the fs.log before I started up fs2_open.
-
During Fient! Perry! Reposte! I got 1 crash with no error message and one nonfatal error message.
-
That vecmat thing is a pain. It only seems to happen for me in HTL mode so perhaps we can just do without the warning there unless there is actually something to be fixed. Bobboau would know better than me about that though. It's not a big deal on Linux since the warning won't interrupt your game. On Windows is a bigger deal since you actually have to deal with it right then. Enough bug reports have been filed where the non-fatal vecmat warning is the reported crash that I think it's time for fixing or deleting.
The "Fient! Perry! Reposte!" crash is a model_get() problem where it seems to be NULL but there isn't a NULL check there. The real problem of course is that shouldn't ever happen. I'll have to try and recreate that because it's going to need some backtracking to find out why it happened. I'll go ahead and add the extra NULL check but it won't really help the problem. Does it occur in a reproducable way or just sometimes (or one time)?
-
I will play the mission a few times, but it appears to be fairly random.
-
Ok, the stutter bug is fixed, but the OpenAL version won't let me start TBP for some reason.
Well, I'll report more later.
-
I had a crash during "A Game of Tag."
I was warping out and then Wokka...
-
Originally posted by DaBrain
the OpenAL version won't let me start TBP for some reason.
The current release or the beta? I haven't had any problems with the current release but please send an errorlog.txt or something so I can figure out what's wrong. That one errorlog that Trivial Psychic posted gave me a clue that has been fixed but I don't know why it would have gotten to that point in the first place. I'm making a couple of OpenAL changes now so perhaps that will fix it.
Originally posted by redmenace
I had a crash during "A Game of Tag."
A docking bug. Adding a NULL check should prevent the Assert(), or an outright crash that would occur in release builds. Was any ship currently docked or had you called for a support ship at the time you jumped out?
A new build will go up today with as many of these fixes as I've been able to handle.
-
Originally posted by taylor
A docking bug. Adding a NULL check should prevent the Assert(), or an outright crash that would occur in release builds. Was any ship currently docked or had you called for a support ship at the time you jumped out?
:sigh: This is probably my department, but the reason there's an Assert and not a NULL check is because this should never ever ever happen. Therefore I echo taylor's request for information. :)
-
Actually that is exactly what happened. I had called in support and it was coming very close to me before I jumped out. Like 2 seconds away maybe.
-
Hmm... I think I know what the problem is then.
Would you mind running a bunch of tests for me? :) If you would, try jumping out at various points before the support ship gets to you (say, three... when it arrives, just before it docks (which you already did), and in the middle). See which ones crash and which don't.
-
I will create a custom mission then and do that later after I come back from the hardware store ;7
-
It's the same basic problem as the jump-in dock crash from a couple of months ago. I did test that a little and the support ship did have to get rather close for it to mess up. At that point the ai goal would be reset since the ship was effectively gone. There is no check in the docking code to handle aborts from that as far I know.
So basically it can and does happen, there is simply no check to guard against it. At least that's what it looks like to me after going over the code. Same thing that happened last time where the docking request would come in just as the ship was warping in but the ai goal was -1 until after the full warp-in sequence had completed. I am pretty hesitant to put a NULL check in this one though since that's obviously not the best fix but would certainly get the job done. I'll just leave this one to you then Goober.
-
Ok, I was able to recreate the one crash but found no others such as while on approach and while rearming(while rearming I found that it would just abort rearming and abort the warp out sequence.). If one wishes to recreate it, i would suggest that you go in loops with the support ship very near and while doing so warp out when it is very near.
-
Originally posted by taylor
It's the same basic problem as the jump-in dock crash from a couple of months ago. I did test that a little and the support ship did have to get rather close for it to mess up. At that point the ai goal would be reset since the ship was effectively gone. There is no check in the docking code to handle aborts from that as far I know.
So basically it can and does happen, there is simply no check to guard against it. At least that's what it looks like to me after going over the code. Same thing that happened last time where the docking request would come in just as the ship was warping in but the ai goal was -1 until after the full warp-in sequence had completed. I am pretty hesitant to put a NULL check in this one though since that's obviously not the best fix but would certainly get the job done. I'll just leave this one to you then Goober.
Is this (http://fs2source.warpcore.org/cgi-bin/cvsweb/cvsweb.cgi/fs2_open/code/ship/Attic/aicode.cpp.diff?r1=text&tr1=2.94&r2=text&tr2=2.95) the old crash bug you're referring to? Because I don't think these are the same things.
I think this might be a bug in the goal system... the "rearm" goal is removed but the support ship is still in the "dock" mode. Redmenace, can you replicate this bug in any other build?
-
Originally posted by taylor
The current release or the beta? I haven't had any problems with the current release but please send an errorlog.txt or something so I can figure out what's wrong. That one errorlog that Trivial Psychic posted gave me a clue that has been fixed but I don't know why it would have gotten to that point in the first place. I'm making a couple of OpenAL changes now so perhaps that will fix it.
Beta, or even worse. I've messed a lot around with it.
I'm right now downloading the newest staff beta. I'll see how it works.
Edit: It works now. ;)
Looks like I screwed up too much before.
But sometimes the sound, when my is hit, is too loud.
Other than that it worked fine. Maybe it's the Beta pack. I didn't check it's sounds.
-
Originally posted by Goober5000
the old crash bug you're referring to? Because I don't think these are the same things.
Yeah that's the bug to which I was referring. It's a different instance of the same problem. The problem code isn't taking into account that the goal system either isn't set or got reset while still trying to execute. The goal system isn't setup for a ship that is just warping in. When the warp in proceedure is done then it's setup but with that other bug it would try and process the ship before that point. That bug was because it would keep looping through until it got into the dock mode, the fix was to avoid that case until the goal system had been readied.
This new problem is the same thing, when the warp out proceedure gets to a certain point the goal gets reset but it will still try and process the docking mode. The extra NULL check in this case would prevent it from contiuning to dock at this point but the better fix would be, as you mention, to make sure that docking is aborted when the rearm goal is removed.
The old way took all of this into account I believe. I don't know if it was intentionally handled but it did work.
-
mmph... the trouble is, I don't think there *was* an old way. I didn't change much of the goal code, so I don't think this would have been changed all that much. :doubt:
-
Originally posted by Goober5000
mmph... the trouble is, I don't think there *was* an old way. I didn't change much of the goal code, so I don't think this would have been changed all that much. :doubt:
You know the code better so I'm reaching a little in my description and that may be a bit confusing. I'm interpreting the code based on the observed behavior and the previous bug fix rather than a real understanding of your changes.
The main thing I notice that's different, and what we both notice as wrong, is that a rearm abort doesn't signal undock. Looking in the icculus.org code (since it's untouched here) I see that you split ai_cleanup_dock_mode() into a rearm version as well as a dock version. Missing from the rearm part is this block of code:
if ( aip->ai_flags & AIF_DOCKED ) {
ai_info *other_aip;
Assert( aip->dock_objnum != -1 );
// if docked, and the dock_objnum is not undocking, force them to near last stage
other_aip = &Ai_info[Ships[Objects[aip->dock_objnum].instance].ai_index];
if ( (other_aip->mode == AIM_DOCK) && (other_aip->submode < AIS_UNDOCK_3) )
other_aip->submode = AIS_UNDOCK_3;
ai_do_objects_undocked_stuff( objp, &Objects[aip->dock_objnum] );
}
I don't know the current equivalent of AIF_DOCKED but the submode is getting reset here so that could be the difference. I haven't really looked at your other changes though so this check may be redundant or just wrong with the new code. I would guess that something similar is needed though.
-
Oho, very interesting. That's exactly what it is; I didn't think of that when I split the two functions. That'll get committed right away. Thanks. :)
-
i havent been able to make a new build work with nukemod sence wc's fs2_open_C03122005_o.exe build. i think it has something to do with the most recent changes made to the ships table parsing code. its not seeing the $ai class: entry for some reason. its also not reading the flags.
-
I have done some extra testing of the Mission The King's gambit. I got two seperate crashes.
This is the first.
-
This is the second.
-
Originally posted by redmenace
3. Can't use debug with open GL when you get error messages and select no. You get a black screen.
Not really a fix but you should be able to ALT-TAB back to the desktop and then ALT-TAB back to the game. It may take a couple of seconds but should become active again. If that doesn't work let me know. I'm looking for a code fix but this isn't very high on the priority list right now.
-
Originally posted by redmenace
This is the second.
This is the same as this bug (http://mgo.maxgaming.net/mantis/bug_view_page.php?bug_id=0000389). Could you add your information?
-
Originally posted by Goober5000
This is the same as this bug (http://mgo.maxgaming.net/mantis/bug_view_page.php?bug_id=0000389). Could you add your information?
Done.
-
I got a crash loading "Speaking in Tongues" from the techroom. I was using '-allslev' I had just played a few missions in a row including one repeatedly using Quickstart after dying. Attached is the relevant information.
-
Originally posted by redmenace
I got a crash loading "Speaking in Tongues" from the techroom. I was using '-allslev' I had just played a few missions in a row including one repeatedly using Quickstart after dying. Attached is the relevant information.
At least parts of this should be fixed in the 0530 update build. Give that one a try, assuming that you want to play through that many missions again, and see if you get the same results.
-
may 30 build? where?
-
Originally posted by redmenace
may 30 build? where?
I updated the first post. Since it was mainly bug fixes for this build I didn't bother putting it in a new topic.
-
Originally posted by taylor
- Timer changes to fix broken loading bar on some systems that would have one spot lit and then jump to the end. This change could affect various parts of the game so if anything is either really slow or really fast please report it. This could fix several speed issues too that seemed to affect only certain systems so if any old bugs are fixed by this please report it.
My system was one of those which had the problem wherein the briefings did not scroll forward as they are supposed to (Win 2000 SP4). Instead I had to go to the briefing end and hit the back button repeatedly to read each step of the briefing. The timer fix seems also to have fixed this issue for me. I only played a couple missions without incident, but fixing this issue is huge to me. Great work! :yes:
-
I had a crash involving the hud in The Sicilian Defense. Unfortunatly no fs.log and no errorlog and I can't reproduce.
-
This occured right after load.
-
i found my problem, vwep support is busted. it seems the $Show Weapon Models: (yes,yes) flag is causing the problems. i thought bob commited this. either it was disabled without me knowing or it was broke by somone.
-
I tried Endgame Again and got an crash.
-
I got a crash involving the HUD again. This time I have the fs.log but for some reason errorlog isn't being written.
-
I think I fixed the hud_color_index thingamajig.
The change is in CVS (I took out a 0.5, though I could also have added 0.5 to the check.)
Basically in the next CVS build, check and see that the shield graph is displaying at the same intensity as it was, and doesn't crash.
-
I will keep that in mind tomorrow when I run my gambit of tests.
-
Ahm... it looks like custom loading screens are still broken.
-
ok, I just finished Bearbating. However I noticed a problem. Trebuches are inflicting 0 damage on the Sathanas Forward Flak Cannons. In retail you use them to knock or help knock them out.
Then in High Noon I noticed that the Colossus was firing at space and continueing to fire but intersecting and showing off impact explosions of the beam long after the Colossus had broken up in an massive explosion.
I also noticed that the breifing for this mission labeled the wing I was flying in as Alpha 4 instead of Alpha.
Attached is a log file for both missions.
-
The forward flak guns are hard to take out though... the model geometry means that you don't get a direct hit unless you shoot from above them or from the side. Doing it from the front rarely works. Try shooting them from different angles and see what happens.
-
Alright, but I will take a look at retail as well just to be sure.
-
That's what I've experienced in retail. I haven't played through the main FS2 campaign in SCP recently.
-
I got another crash concerning the BMPMAN. fs.log posted and error message. I am also noticed the Lighting effects on the players hud and the targeting and radar are not taking place.
-
Here is an image concerning the briefing error.
-
Originally posted by redmenace
I got another crash concerning the BMPMAN. fs.log posted and error message. I am also noticed the Lighting effects on the players hud and the targeting and radar are not taking place.
Can you create an empty file named debug_filter.cfg in the data directory and try to get this again? The lack of bmpman debug info makes it difficult to figure out what's going on here. Also I notice that most the these bmpman errors seem to be mostly D3D related. Does it happen as much in OGL? When I was debugging the new code I only did it in OGL so I'm thinking that I might need to update the D3D stuff to properly handle the use of bm_release().
-
well i am sure I will come across it eventually again. So I will just keep an eye out for it. I will create that said empty file. As soon as I can play the rest of the original campaign. I will start over in Open GL to fix to not only test the BMPMAN problem but hunt any others out there strictly related to Open GL.
Also I forgot to mention previously. Movies are now occasionally not playing after the loading screen. This might actually be related to the debug builds themselves.
Also I noticed, specifically with the vec3d errors that the music in game stops responding and I get taken to the error. This is in Direct Sound. I have not tested it in. Open AL.
-
Originally posted by redmenace
Also I forgot to mention previously. Movies are now occasionally not playing after the loading screen. This might actually be related to the debug builds themselves.
I have noticed this as well for some time now, in debug as well as in release builds. Sometimes, movies start, but the screen does not get cleared and only the movie audio plays. There have been some attempts to fix this, but it still happens every now and then. However, it appears to me that movies work ok if running the game in a window. Of course, given the intermittent occurence of this issue, it might be that it just might have not happened while I was testing in window mode.
A good test - redmenace, you may want to try this - would be to go to the Cutscenes in Techroom and start selecting from the list of available ones. Play a few seconds of the movie, then stop the movie, select another one, play a few seconds, stop, etc. I have found out that by doing this, I get the problem to occur after a few attempts.
-
I got a loading crash in "Into the Lion's Den."
-
I got another loading crash in Exodus.
-
I got a crash during Dunkerque while attacking nehema bombers.
-
I got another crash during "Dunkerque."
Involved "Assert: aigp != NULL"
-
I have a crash in "Their Finest Hour"
the fs.log is also saying that I do not have a debug_filter.cfg, but as asked I have put an empty file in c:\games\freespace2\data and c:\games\freespace2\SCP\data.
-
Originally posted by redmenace
Involved "Assert: aigp != NULL"
Fixed last night. Same bug as your previous support ship docking problem. The code that was supposed to fix it never got executed but now that's fixed.
the fs.log is also saying that I do not have a debug_filter.cfg, but as asked I have put an empty file in c:\games\freespace2\data and c:\games\freespace2\SCP\data.
[/B]
If you created the file with notepad then make sure it doesn't have an extra .txt extension on it which notepad always tacks on. If it gets listed as a text file in Explorer then that's what happened but you wouldn't see the .txt if you have hide extenstions turned on.
-
Here is the file I created.
-
I hope the rest of the information is helping.
-
Bah, stupid Windows version. It goes in ${HOME}/.fs2_open/data under Linux and OSX but the Windows version just has it in the same directory as the binary. Just move it and it should work fine.
The bug reports are deffinitely a help, though I am starting to wonder if you're just padding your post count. ;)
The first Dunkerque crash where you are attacking the bombers looks to be hitting one of the first bugs you posted about, the model_get() crash. I added the extra NULL check there which is what it hit. That helps figure out where it's coming from but I still can't say that I know exactly why it happened. It looks to just be a problem with WMC's updated jumpnode code as it doesn't appear to handle model_load() errors very well but the rest of the code should have picked up the slack, at least in a debug build. I'll add an extra debug printout at the problem area and see if that can't help figure out what's going on. I'll try and reproduce as well but haven't been able to so far.
-
Originally posted by taylor
Bah, stupid Windows version. It goes in ${HOME}/.fs2_open/data under Linux and OSX but the Windows version just has it in the same directory as the binary. Just move it and it should work fine.
:lol: alrighty then
Originally posted by taylor
The bug reports are deffinitely a help, though I am starting to wonder if you're just padding your post count. ;)
:lol: Well if I am padding my post count, it is better than spamming in hidden and abandoned forums. :D And more constructive I might add. Honestly though, as I said in the internal, I am testing all of the retail missions. So I figure this is the best way to communicate severe and bothersome crashes in order to have them fixed for the next release
Originally posted by taylor
The first Dunkerque crash where you are attacking the bombers looks to be hitting one of the first bugs you posted about, the model_get() crash. I added the extra NULL check there which is what it hit. That helps figure out where it's coming from but I still can't say that I know exactly why it happened. It looks to just be a problem with WMC's updated jumpnode code as it doesn't appear to handle model_load() errors very well but the rest of the code should have picked up the slack, at least in a debug build. I'll add an extra debug printout at the problem area and see if that can't help figure out what's going on. I'll try and reproduce as well but haven't been able to so far.
Good to hear. Hopefully the more thorough debug spew will help get all these fixored.
Also here is some more debug spew from the bogus hitpos error.
http://dynamic.gamespy.com/~freespace/forums/attachment.php?s=&postid=680554
Can you also post an updated build tonight?
-
Originally posted by redmenace
:lol: Well if I am padding my post count, it is better than spamming in hidden and abandoned forums. :D And more constructive I might add. Honestly though, as I said in the internal, I am testing all of the retail missions. So I figure this is the best way to communicate severe and bothersome crashes in order to have them fixed for the next release
I know I certainly don't mind it. They are good bug reports which makes it easier to find out what's going on. I never mind that. :)
Can you also post an updated build tonight?
I'll try. I'm working on a audio releated problem now and am testing a pilot file corruption fix. If I don't feel good enough about a public build tonight then I'll just PM you a link and let you know what to stay away from. Everything looks good so far though.
-
Thats good. As soon as I get done with the BMPMAN error and get you a decent debug spew, I will start working on Open GL so we start making progress towards our next release.
-
I went over the jumpnode code; it's pretty simple and doesn't look like there should be any problem with it unless the model fails to load. I made a small change that should help speed things along and keep it from checking a nonexistent model when looking for which jumpnode something is in.
-
In "Apocalypse" I got a BMPMAN related error. I am not sure if it is the one you are looking.
-
Originally posted by taylor to redmenace
If I don't feel good enough about a public build tonight then I'll just PM you a link and let you know what to stay away from.
;7