Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Test Builds => Topic started by: taylor on June 22, 2005, 01:50:17 pm
-
I spent about 27 hours Sunday/Monday just working on bug fixes for this thing so if you have problems, please keep them to yourselves. :p :D
- fix custom loading screens
- fix wrong/random text with ship message brackets
- various random crash bugs fixed
- fix a few multi related crashes
- make networking compatible with pre-March builds (breaks all other builds since March but should work with 3.6.5 again)
- fix player ship targetting an invisible object when hit with emp (WMCoolmon)
- simulated speech disabled when you use -nosound
These two need some testing:
- make sure that player can't target invisible ships when tartget-target's-target is pressed or when targetting subsystem in view (not in CVS until it's poven to not have side-effects)
- small changes to particle code to help speed rendering a little and address several potential crashes. It will also now properly allow for not using any particle anis which previously could have caused numerous issues including large memory usage and massive slowdowns. (this is in CVS but not verified to fix reported issues)
Also be sure to give networking a try again. Most of the crash bugs should be addressed but if it's filed in Mantis and still open please verify that it's fixed or not. EDIT: The multi subsystem damage bug has now been fixed.
Da Build: http://icculus.org/~taylor/fso/testing/20050622-win32.rar
** No OpenAL builds this time so the download is smaller **
One other little, tiny thing just for OGL users: compression! Not really exciting but it's about ready for public use and I don't want to release another test build just for it. This change will not be in 3.6.7 so if you don't want to test it that's fine.
It's like -pcx2dds (which never worked for OGL) but taken to a higher level. Like -pcx2dds it will compress textures into DDS format when they are uploaded to the video card however the new feature will replace the original uncompressed data in bmpman with the new, compressed, data. So it's with OGL only and with power-of-2 textures only but it will compress PCX, TGA, JPG and ANI frames using DXT5 or DXT1 as the case requires. ANI frames currently use DXT1 but will likely use DXT5 for quality in the final version of the code. It's estimated to knock 40-50% (on average of various missions) off of the memory needed to run the game.
The new cmdline option for this feature is -img2dds so if you feel like giving it a try let me know how well it works. I'm interested in any slowdowns during game play, improperly rendered graphics, any change in mission load times, and general resposiveness in game. The final version of the code will work for D3D too but since I only use OGL I just coded it for now.
-
Good news Taylor :)
Since our Bug was good reproducable I just played again, shoot at a capship and everything seems to be fine now, my FPS stays constantly on 120, no more dropdowns. I just played a few seconds, but it works pretty smooth.
You are the man, thanks buddy :yes: :)
-
Good to hear. If further testing shows that it's still a problem let me know.
-
Originally posted by taylor
I spent about 27 hours Sunday/Monday just working on bug fixes for this thing
:eek2:
Egads man. Go get some sleep, you deserve it. :):yes:
-
Nebuleas fixed?
-
Originally posted by redmenace
Nebuleas fixed?
Still not sure what the problem is. I'm giving priority to the multi damage bug right now and the nebula bug is the only other major thing on my list (now that the particle bug is fixed). I did make various changes which might help in an indirect way but I haven't actually tested that yet.
EDIT: Well, multi subsys damage bug is now squashed. And I'm sure to everyone's delight, it was entirely my fault. :D Now off to your neb slowdown bug...
-
Looking good, slowdown while firing on capships is minimal to nonexistent. For some strance reason my fps never goes beyond 60.
In overall, this build of miracle runs very smoothly. I'll try netplay later on...
Once again Taylor, Job suberbly done !
-
I think I wanted to test the one sooner build. It didn't happen. :)
But let me see if my 'crash when cruisers present' still persists with this build.
-
Originally posted by starfox
For some strance reason my fps never goes beyond 60.
This usually happens when you are running in OGL mode with a screen resolution that doesn't match your desktop. Windows will default to a 60hz refresh rate and if you don't disable v-sync in your drivers then you'll max out at around 60 FPS. You can either make the global change in you driver settings or change your desktop resolution to what you run the game in, change the refresh rate to a higher setting, then change your resolution back to normal. Next time you run the game it should get everything right. If that is the problem anyway.
Originally posted by TopAce
I think I wanted to test the one sooner build. It didn't happen.
But let me see if my 'crash when cruisers present' still persists with this build.
Gotta say "Huh?" on this one. Too much going on for me to remember what this was about. Is this an IBX thing? If so just be sure the delete the IBX files in question and let them regenerate. It should have correct data then and not cause any rendering issues or crashes. From the MediaVPs, these files are known to generate wrong data 100% of the time so delete them before running this build if you had problems before: cruiser01.ibx, cruiser01x.ibx, fighter2t-03.ibx, miner2v-01.ibx.
-
No, the problem is with my hard drive, I think. Since I reinstalled the whole machine(windows, everything), half of the games crash for me randomly, Jedi Academy crashes randomly, Knight of the old Republic crashes five or ten minutes into the game and FS crashes, too.
I don't think it is a problem with the SCP, although I have not tried retail FreeSpace.
-
Gonna check this build tonight :)
-
vwep kinda works now, it still crashes when i try to use the hellbat, but other ships with vwep seem to work.
-
Error! Current GL Version of 1.1 is less than the required version of 1.2...
Please don't say we need Cats newer than 5.4, cos Omega hasn't updated his set yet.
-
Originally posted by SuperCoolAl
Error! Current GL Version of 1.1 is less than the required version of 1.2...
Uhh, that's pretty wrong. Version 1.1 is what Microsoft ships as the software GL version. I don't think a driver upgrade is in order but you might want to reinstall the version that you already have. Something looks to be wrong with the install if it's only finding the software GL version.
-
:wtf: all cats have been higher than 1.2
-
I'm just gonna use older builds until Omega's next set come out, which can't be long now.
-
Originally posted by SuperCoolAl
I'm just gonna use older builds until Omega's next set come out, which can't be long now.
It should still fail the version check regardless of what build you are using. Older builds only checked the minor version but 1 is still less than 2 so it shouldn't work. I'd be interested to know what builds work for you in OGL mode if this one doesn't.
-
every other build i try works
-
My 20050613 build worked?
-
no just tested it, but 0606 works
-
There hasn't been any changes to the version detection code since then. The init code has changed a little though so I guess it's failing to init with hardware and using software as a fallback. The change to the init code was supposed to help get rid of the green backgrounds with popups and what not. I think you suffered from that problem.
I'll PM you a link to a build without the init changes and we'll see if that's the problem. Just be sure to test the green screen problem too while you're at it. I hate ATI. The new code works perfectly with NVIDIA.
-
Crashes in multiplayer mode, almost every time, as soon as it receives a server list. :(
No error, just straight CTD. I'll do a debug build later, and see what it says.
-
Originally posted by Raa
Crashes in multiplayer mode, almost every time, as soon as it receives a server list. :(
Crap. This is probably my fault. I'd be interested in what a debug build says but I'll try it out tonight as well and see what I find.
-
Running this and the build immediately preceding this one, ATI Cat Omega 5.4 in OGL under WinXP w/SP2, running TBP. On the green background problem, I can't even make it that far. On previous builds, any attempt to enter any "room" from the mainhall, results in the game minimizing itself. If I'm in the techroom, it also happens when I click on a capital ship (the model, not the entry on the side). With these new builds, 1, they don't show the spash screen, 2, when restoring from the previously-mentioned minimizing, the screen is all jumbled. I tried to take a screenshot, but it just took it of my desktop background rather than the game. It was as if someone had chopped the screen laterally and then separated each by a same-side slice of static, offset each screen slice somewhat to the left, then had them jumping back and forth between screen and static. Each attempt to alt-tab and restore only makes the image worse. Because things are so jumbled, its impossible to tell where the cursor is. Once, I openned the game, then selected "exit", which minimized the game. When I maximized it back, the jumbled thing was still there, but I could see greenage in the background, leading back to the original green background thing.
Sorry Taylor.
-
I tried flying multi with this build and everything worked great - except that the 6-7% subsys bug was still there. :(
The weird thing is that I flew with Raa and MatthewPapa, who used this build too, and neither of them had that problem at first. But then when we changed wingman positions it came back...
Take 1:
Alpha 1: MP
Alpha 2: G5K (subsys bug)
Alpha 3: AI
Beta 1: Raa
Beta 2: AI
Beta 3: AI
Take 2:
Alpha 1: Raa
Alpha 2: MP (subsys bug)
Alpha 3: G5K (subsys bug)
Beta 1: AI
Beta 2: AI
Beta 3: AI
Take 3:
We used the 20050103 build and nobody got the subsys bug. ;)
-
Yeah the subsystem fix isn't in this particular build since I didn't find it until later. The bug is just plain stupid. I fixed some type/size issues (for multi-platform compatibility), one of which was here, and though the proper values were computed they weren't actually assigned. It was using other data which tended to stay the same which is why it wouldn't ever repair either, it kept getting reset to this other data value. It would/should also only affect the client side though so whoever is acting as server shouldn't have a problem and I don't think AI should either.
I'm preparing an updated build now with what will hopefully be fixes for Trivial Psychic and SuperCoolAl. Plus a couple extra sanity checks for the server list to hopefully prevent the crashing that Raa had. And the subsystem fix of course.
Look for that to be available in a couple of hours (needs a little more testing on my side).
EDIT: Ok, try this: http://icculus.org/~taylor/fso/willrobinson/20050624-win32.rar and let me know if anything is better or worse.
-
I can't run the app. I've tried removing the mediavps and stuff but got errors. I'm not sure if I require the devIL's dlls again or not.
BTW, what are the map files for?
Here's what's in the error log:
fs2_open_T-20050624 caused Unknown exception type in module ntdll.dll at 001b:7c94eb28.
Exception handler called in Freespace 2 Main Thread.
Error occurred at 6/25/2005 21:32:22.
C:\Games\FS2Open365\fs2_open_T-20050624.exe, run by Dario.
1 processor(s), type 586.
1024 MBytes physical memory.
Registers:
EAX=0012e05c CS=001b EIP=7c94eb28 EFLGS=00000246
EBX=0012ff24 SS=0023 ESP=0012e000 EBP=0012e388
ECX=0012e0b4 DS=0023 ESI=0012e00c FS=003b
EDX=0000007b ES=0023 EDI=00000001 GS=0000
Bytes at CS:EIP:
e9 ca 8f fe ff 48 48 74 2e 83 a5 e4 fc ff ff 00
-
Error: Current GL Version of 1.1 is less than the required version of 1.2
Switch video modes or update your drivers.
File:D:\src\fs2_open.testing\code\graphics\gropengl.cpp
Line: 3928
[This filename points to the location of a file on the computer that built this executable]
Call stack:
------------------------------------------------------------------
------------------------------------------------------------------
E:\Inferno\fs2_open_T-20050622.exe -spec -glow -jpgtga -nomotiondebris -pcx2dds -snd_preload -env -ambient_factor 75
It works in D3D. All previous builds worked fine for me...
Edit: haven't tried the latest build two posts up. Will give it a go now :)
-
Originally posted by taylor
Yeah the subsystem fix isn't in this particular build since I didn't find it until later. The bug is just plain stupid. I fixed some type/size issues (for multi-platform compatibility), one of which was here, and though the proper values were computed they weren't actually assigned. It was using other data which tended to stay the same which is why it wouldn't ever repair either, it kept getting reset to this other data value. It would/should also only affect the client side though so whoever is acting as server shouldn't have a problem and I don't think AI should either.
I'm preparing an updated build now with what will hopefully be fixes for Trivial Psychic and SuperCoolAl. Plus a couple extra sanity checks for the server list to hopefully prevent the crashing that Raa had. And the subsystem fix of course.
Look for that to be available in a couple of hours (needs a little more testing on my side).
EDIT: Ok, try this: http://icculus.org/~taylor/fso/willrobinson/20050624-win32.rar and let me know if anything is better or worse.
Ok, I tried running the build. It doesnt give me an error upon laucnh, and I can get to the pilot loading screen fine. However, it CTDs immediately thereafter, without any error message.
-
I got a CTD while using pofspew to regenerate a new set of IBX files.
Assert: be->handle == handle
File: c:\src\fs2_open.testing\code\bmpman\bmpman.cpp
Line: 2445
[This filename points to the location of a file on the computer that built this executable]
Call stack:
------------------------------------------------------------------
model_page_out_textures() model_unload() model_free_all() doexit() exit() Warning() model_load_texture() read_model_file() model_load() game_spew_pof_info() WinMainSub() WinMain() WinMainCRTStartup() kernel32.dll 7c816d4f()
------------------------------------------------------------------
Assert: f < MAX_MEM_POINTERS
File: c:\src\fs2_open.testing\code\globalincs\windebug.cpp
Line: 1497
[This filename points to the location of a file on the computer that built this executable]
Call stack:
------------------------------------------------------------------
_vm_free() close_help() doexit() exit() WinAssert() bm_release() model_page_out_textures() model_unload() model_free_all() doexit() exit() Warning() model_load_texture() read_model_file() model_load()------------------------------------------------------------------
The graphics option was set to Open GL.
-
@Singh: Was that with the release or the debug build? No errorlog.txt was produced?
@High Max: That is a content problem and not something that we can, or will, fix. Assuming that you are using Chapter 4 I gave it a try just to see.
Main errors:
- There are secondary weapons in the primary weapons section of weapons.tbl
- Too many AI classes unless you are using an Inferno build (max is 10, has 11)
- Ships require primary weapons, 7 of which are missing from weapons.tbl
I gave up looking after that. You'll have to report these problems to the mod author to get them sorted out. You might want to suggest that it get tested with a debug build in order to better find these errors as even retail would have had major issues with these problems.
@redmenace: What build did you run with? The log that you sent wasn't formatted properly for a current build in OGL mode. The output format changed in the 20050613 build to be more readable so it's pretty easy to see that it's not recent. Hmm, in fact it's not a log from a pofspew run either since it's got a full mission load in it. I guess you attached the wrong file?
Sorry about the MEM_POINTERS thing. After you had problems with it before I bumped the limit and then just disabled it all together. I guess it helps Bobboau to have it there but since what it finds is pretty much the same thing as the Linux build would have it's easier and more efficient for me to just run Valgrind and get much more detailed information than to have Bobboau's memleak checker in there.
-
Actually it is your 6/24 build. And it is a POF spew. I deleted all of the ibx and created new ones, then recieved a crash after an error message concerning vecmth3d or something like that.
-
Actually concentrate on the other bugs for the time being. I cannot seem to reproduce this error. I will have to play a series of missions to see if we are having the same issues with the BMPMAN again. Also, has WMC fixed the camera problem yet in the final mission from retail?
-
Originally posted by redmenace
Actually it is your 6/24 build. And it is a POF spew. I deleted all of the ibx and created new ones, then recieved a crash prior to another one concerning vecmth3d or something like that.
Hehehe, you're right. I had another one of your files named fs.zip so firefox named the new one fs-1.zip and I didn't think to check before looking just at the old fs.zip. :)
I can't recreate this one either after trying various different things. I you get it again let me know. If by the camera problem you mean the fact that it skips the supernova then no it's not fixed. If WMC doesn't fix it then I'll add it to my list to fix this week.
-
Probably a screwy if statement situation in the render_frame_setup function.
My "plans" for tomorrow are trying to get my computer working from a SATA drive (Hmm, for some reason I'm getting a sense of deja vu while typing this post). That probably means repeated attempts to install an OS for awhile, once I decide whether I want to go the masochistic path and switch to Linux, cave and buy XP, or try and hack in SATA drivers on my Win2k install disk. ;)
Oh, and buy/fix the SATA cable.
In other words, be my guest. :)
-
It appears that the bug, where your laser bolts turn into white/red squares when facing the sun, is still there.
I think there were some threads about it somewhere, but I'm suprised its still there, thought it was squashed some time ago.
If this has already been reported, then my apologies
-
Originally posted by starfox
It appears that the bug, where your laser bolts turn into white/red squares when facing the sun, is still there.
I think there were some threads about it somewhere, but I'm suprised its still there, thought it was squashed some time ago.
If this has already been reported, then my apologies
Yep, was about to post this (was playing not on debug unfortunately) but you beat me to it.
It also happens not only from laser bolts but sometimes from subspace jumps or ship explosions (usually corrects itself in 2 seconds but in that time a huge white box kills immersion)
-
vwep wont seem to work on ships without a secondary bank for some reason. it got a direct ctd without an error message im most cases and an ocasional message like i reported before it got fixed. i managed to work around this. i simply gave the helbat the ability to carry a high yeld remote detonated mine. its fun to place those in front of an enemy fighter bay :D in this case the bug contributed to my mod :D
-
Alright, I finally got a chance to work with your 6-24 build but I am seeing missing poly on Babylon 5. Everything else looks good. The GOD Sat is fixed though.
-
Originally posted by redmenace
Alright, I finally got a chance to work with your 6-24 build but I am seeing missing poly on Babylon 5. Everything else looks good. The GOD Sat is fixed though.
And this with a new B5 IBX right? I'll have to grab the model and take a look but it may be a day or two from now before I get the chance. If you notice any others let me know.
-
I believe so.
-
I have tested several missions one after another. I have noticed a few things
Occasionally Laser with get blocky in a Nebulea while using DX. I also noticed the I get a crackling sound with lots of action IE AAA, Beams firing etc. The Music also stops working if I get thrown to the desktop because of an error. I have also noticed some some music problems in briefing as well. Could be related to ingame music as well. I will have to try a Regular build and see if it is just debug builds alone.
-
I've noticed the crackling sound myself in a few recent builds. Like redmenace said, it usually happens when many sound effects are playing at the same time, and it goes away during periods of relative quiet. If no one's reported it in Mantis yet, I'll do it later.
-
I get CTD when engaging subspace drive sometimes (it happens either just as it's about to enter 3rd person view, or just as the ship is about to enter the portal)
It's random though, but enough to merit mentioning. I haven't got it to replicate while running the debug version spew though :P. Kind of funny for me to be annoyed that I can't get the game to glitch.
-
Originally posted by LOA--Paul
I get CTD when engaging subspace drive sometimes (it happens either just as it's about to enter 3rd person view, or just as the ship is about to enter the portal)
Do you have an errorlog.txt file for this?
-
Newer build: http://icculus.org/~taylor/fso/willrobinson/20050702-win32.rar
There are a couple of minor bug fixes and speed ups in here but this build is mostly for testing non-standard resolution fixes. I expect it to be pretty close to perfect now but it needs to be tested that non-standard resolutions work as expected and the standard resolutions didn't get broken in the process.
-
When jumping out, before you've reached third person, if a ship in your escort list takes damage your warpout is aborted.
edit: I haven't tried the new build you just posted, just saw it, so maybe you fixed it, but if not-- yeah. :P
-
Just has a thought, when it crashes on warp out had you called for a support ship to rearm you? If so then it's a known problem.
Not sure about the aborted warpout thing. That's a new one on me and I'll try and look into it tomorrow if I have the time. If you get any more details on that let me know. I assume that it can happen in any mission right (provided there is a ship on the escort list that's taking damage)?
-
Originally posted by taylor
Just has a thought, when it crashes on warp out had you called for a support ship to rearm you? If so then it's a known problem.
Not sure about the aborted warpout thing. That's a new one on me and I'll try and look into it tomorrow if I have the time. If you get any more details on that let me know. I assume that it can happen in any mission right (provided there is a ship on the escort list that's taking damage)?
Yes but the situation is rare (warpout during escort ship being hit)
It usually happens to me if I'm warping out and a debris hits one or something. It kept happening on the third mission (chase bosch, destroy freighters and two cruisers with help of psamtik)
and my warpout kept being aborted. I realized whenever the Psamtik's name would blink in my escort list, I'd get aborted.
edit: Also kudos on getting that scrambled avi thing fixed! I'm the one who posted the mantis report about the CTD. I finally got to finish the missions after it using this build without having to move the vp file out of the FS2 directory.
-
Originally posted by taylor
Not sure about the aborted warpout thing. That's a new one on me and I'll try and look into it tomorrow if I have the time. If you get any more details on that let me know. I assume that it can happen in any mission right (provided there is a ship on the escort list that's taking damage)?
i think i ran into this while playing the main campaign. i couldnt jump out for some reason, i noticed it took too long to slow down to jump speed and i think the game got tired of waiting, so i reduced throttle and tried again. and it worked.
-
Taylor, I'm still getting the weirdness I described under OGL with my ATI card on your 07-02 build. In fact, the last build that didn't have the OGL weirdness I described was your 06-02 build. It still had the greenage when bringing up an option box, but no weirdness.
9600XT-128MB
Cat Omega 5.4 or 5.6
WinXP
Also, I've been noticing some odd CTDs, completely random. This is under D3D BTW, and after flying 6 missions or so, I got dumped just as I was warping out. I've noticed it before over the past month or so, but its been so random that I haven't reported it. I extracted the map file so I'll see if it gives any better feedback on the errorlog other than:
FS2_OPEN_TAYLOR_2005-07-02 caused an Access Violation in module FS2_OPEN_TAYLOR_2005-07-02.EXE at 0197:004c656b.
Lotsa help right? :doubt:
Later!
-
Okay, I played enough with this build to have an opinion on it. Unfortunately, my comp has been weird for some time, so I don't know if some crashes were the fault of the build or my HD.
The build appears to be a little bit more stable than the others, you fixed the task switching crash in a half. I am only sayng in a half, because it still crashes if Windows automatically puts the programme on the desktop because of a pop-up ad or windows alert. I think you should fix this by 3.6.7.
I would also request the use of a default :v: texture if the texture what a model uses is a JPG, TGA or 32-bit PCX when -jpgtga and the -32bit flags are off. Currently, there is only an invisible texture, which would not hurt by itself, but the shots go through it and it makes let's say, the Hi-poly Herc I indestructible with lasers.
-
Originally posted by Trivial Psychic
Also, I've been noticing some odd CTDs, completely random. This is under D3D BTW, and after flying 6 missions or so, I got dumped just as I was warping out. I've noticed it before over the past month or so, but its been so random that I haven't reported it. I extracted the map file so I'll see if it gives any better feedback on the errorlog other than:
This is the docking bug that's up to Goober to fix since he didn't like my attempt. I left my fix in most of my builds until the last couple in an attempt to provide a little extra motivation.
Originally posted by TopAce
The build appears to be a little bit more stable than the others, you fixed the task switching crash in a half. I am only sayng in a half, because it still crashes if Windows automatically puts the programme on the desktop because of a pop-up ad or windows alert. I think you should fix this by 3.6.7.
This is with OGL, D3D or both (can't remember if you said or not)? I haven't had it happen in OGL at least but I don't test D3D that much unless I make a change that could affect it.
I would also request the use of a default texture if the texture what a model uses is a JPG, TGA or 32-bit PCX when -jpgtga and the -32bit flags are off. Currently, there is only an invisible texture, which would not hurt by itself, but the shots go through it and it makes let's say, the Hi-poly Herc I indestructible with lasers.
It will already fall back to the standard PCX if not using -jpgtga but that's only if the model still uses the same texture filenames. The new Herc I uses different texture names so it's really the model that needs to be modified rather than it being a code issue. Either that or PCX versions of the textures need to be included along with the TGA versions.
-
I use D3D.
-
Originally posted by taylor
This is the docking bug that's up to Goober to fix since he didn't like my attempt. I left my fix in most of my builds until the last couple in an attempt to provide a little extra motivation.
Yeah, yeah. :)
-
Originally posted by Goober5000
Yeah, yeah. :)
Couldn't resist it. :D
-
In regaurds to the before mentioned bugs, I will post them in mantis including the Babylon 5 model problem.
-
I've just tried 20050702. As far as I could test, looks good. Doesn't take all of my RAM.
CMDLINE: C:\Games\FS2Open365\fs2_open_T-20050702.exe -spec -glow -pcx32 -jpgtga -cell -dnoshowvid -env -fps -stats
A few things to point out, though:
1) Have the maps for the vasudan freighters' (http://webs.sinectis.com.ar/dsusman/fs2-scp-gameplay/screen0012.jpg) been changed?
2) When the warp tunnel opens, shows boxes circling, then the standard warp effect and then the new "closing" tunnel effect (which looks cool. Makes me believe I'm flying in Star Trek Universe :))
3) What happened with the in-game music? Briefing and debreifing musics are there, though. Main Screen too.
4) Where is mantis? :(
-
Originally posted by mrduckman
3) What happened with the in-game music? Briefing and debreifing musics are there, though. Main Screen too.
Main screen turn on!?!?!?
Sorry, couldn't resist. :p
#1: You're probably using mv_cell, only use it when you want cell-shaded ships and have the option enabled in the launcher.
#2: Yeah, that's Bobb's effect, I think he is/was doing some stuff with the warp effect. Probably shouldn't be in CVS without a command line option though.
#3: Don't tell me OGG support is broken again. :wtf: Try removing mv_music and see if it still happens.
#4: Move zig (http://lore.maxgaming.net/~scp/mantis/login_page.php)
-
Originally posted by mrduckman
I've just tried 20050702. As far as I could test, looks good. Doesn't take all of my RAM.
CMDLINE: C:\Games\FS2Open365\fs2_open_T-20050702.exe -spec -glow -pcx32 -jpgtga -cell -dnoshowvid -env -fps -stats
A few things to point out, though:
1) Have the maps for the vasudan freighters' (http://webs.sinectis.com.ar/dsusman/fs2-scp-gameplay/screen0012.jpg) been changed?
Answer: remove -cell from your command lines.
2) When the warp tunnel opens, shows boxes circling, then the standard warp effect and then the new "closing" tunnel effect (which looks cool. Makes me believe I'm flying in Star Trek Universe :))
That's a known bug. It occurs mainly with warp effects, but also sometimes with explosions.
3) What happened with the in-game music? Briefing and debreifing musics are there, though. Main Screen too.
Sounds like you might have a miss-match of ogg and wav. Either you've got the table for the oggs but no files, or the reverse.
4) Where is mantis? :(
http://www.hard-light.net/forums/index.php/topic,33327.0.html
Hope this helps.
-
Originally posted by mrduckman
3) What happened with the in-game music? Briefing and debreifing musics are there, though. Main Screen too.
This problem popped up recently, and someone (I think karajorma) figured it out. Something to do with the VP or cfile system.
-
Originally posted by WMCoolmon
#3: Don't tell me OGG support is broken again. :wtf: Try removing mv_music and see if it still happens.
Odd. Wasn't using it.
-
Originally posted by Trivial Psychic
Sounds like you might have a miss-match of ogg and wav. Either you've got the table for the oggs but no files, or the reverse.
Hmm. No. no vp, no files in the dirs. Thanks for the help :)
-
That's where the philosophy of trial and error comes into play...especially when making a game that wasn't really designed for this in the first place.
-
Originally posted by High Max
Why is it that newer builds seem to create more bugs? They are supposed to be better and fix old bugs, not create new ones:sigh:
I don't think that bug is anything new. I remember reports of it last year. The problem is that it doesn't happen for most people and I don't think any of the main developers have had it happen which makes it harder to track down and fix.
-
I'm getting white cubes instead of enemy ships for a split second as they finish warping in with the latest build. (July 2nd) Not sure if this happens consistently, or if -only- enemy ships are effected. Haven't checked the debug build, but to be honest I'm not sure how to use that effectively.
switches: -spec -glow -pcx32 -jpgtga -d3dmipmap -cell -rlm -ship_choice_3d -smart_shields -snd_preload
and it also happens if I enable the -3dwarp and -tbpwarpeffects switches.
Running on a P4 2.8 Ghz processer without HT, with a GeForce4 Ti 4600 and mobo by ASUS. Game is set to 1024x768x32 in D3D mode.
I don't think this bug is new as I remember reading about graphics bugs like this, but it's late and I can't be buggered to read back right now ^_^;
Hope this helps! (and was a good bug report, it's my first one o-o; )
Edit: li'l addition, don't think anyone's read this post yet but...
Edit2: gah, forgot to mention I'm playing the Freespace Port and I noticed it on those Vasudan fighters you fight in the beginning. If you think it'll make a difference, I'll retest in the normal campaign.
-
If I set -fov to a low value, say 0.2, the all the targeting stuff (the brackets, missile lock etc) are too near to the center. If a ship is in the center of the screen, everything is fine, but if it is near the edge of the screen, the gauges are in the wrong position.
If I set -fov to 0.8, the gauges are still correct if a ship is in the center. However, if the ship is near the edge of the screen, the gauges are too far towards the edges of the screen.
So it seems there is a "magical" value where everything is fine...
The 3D radar still has the old background... It's easy to fix by putting an empty 2D_radar.ani (IIRC) into data/huds, but it would be nice to get rid of it automatically.
When using the -start_mission option, the name of the mission cannot contain a dash. For example when trying to start sm3-08.fs2, I get the error "Could not find sm3.fs2". Perhaps you should be using GNU geopts :)
Command line options:
-spec -glow -pcx32 -jpgtga -d3dmipmap -nomotiondebris -2d_poof -pcx2dds -dualscanlines -ship_choice_3d -targetinfo -3dwarp -tbpwarpeffects -ballistic_gauge -snd_preload -fps
I am using D3D, Geforce4 Ti4200 64MB. Media vps 3.6.6 except adveffects.
-
Those values are far from optimal. The best settings for FOV are somewhere between 0.35 and 0.5.
WMC did put up a guide to selecting the correct FOV somewhere.
-
Originally posted by karajorma
Those values are far from optimal. The best settings for FOV are somewhere between 0.35 and 0.5.
WMC did put up a guide to selecting the correct FOV somewhere.
I know the values are far from optimal. For me, best would be 0.37. However, this does not change the fact that the position of the gauges is wrong.
I think the targeting stuff should be displayed correctly for every fov, no?
-
There is no 'should' or 'should be' in the SCP.
-
In theory they should work for every FOV but since the game is pretty much unplayable with 0.2 or 0.8 it's not really that big a problem.
-
Originally posted by TopAce
There is no 'should' or 'should be' in the SCP.
:nod:
Is. Or is not. There is no 'should'.
-
^ Exactly what I was thinking about. After posting it, I started to hope you don't turn that post against me.
*sigh of relief*
-
Originally posted by karajorma
In theory they should work for every FOV but since the game is pretty much unplayable with 0.2 or 0.8 it's not really that big a problem.
I have looked again. It is also noticable with 0.35 and 0.5. It seems correct at 0.65.
However, I realised this also happens in the 3.6.5 build, so here is not the correct thread and I'll file a bug report on mantis. I'll post the details (measured deviations at 1024x768 and 1280x1024 etc.) there.
I just wanted to add I like this new build. It corrected an annoying bug for me. And the 1280 resolution works much better than in 3.6.5 (although not perfect). Great work all you coders/designers etc. are doing!
Now I just have to buy more memory for lightspeeds high res planets and nebulas...
-
taylor, I know what you said in the internal, but I thought you might want to take a look at these two bugs
-
Here is the second.
-
Originally posted by pflumm
If I set -fov to a low value, say 0.2, the all the targeting stuff (the brackets, missile lock etc) are too near to the center. If a ship is in the center of the screen, everything is fine, but if it is near the edge of the screen, the gauges are in the wrong position.
I think that's the same reason that glowpoints and the stars are distorted.
It's really obvious with glowpoints: If they're in the center of the screen, everything is fine. But the farther away from the center they get, the more they are distorted (in the direction away from the center)
Maybe the -fov setting only gets applied to 3d objects and background nebulas, but not HUD indicators, glowpoints and generated stars ?
-
It's probably an issue in g3_project_vertex and/or g3_rotate_vertex, possibly a hardcoded FOV value or an assumption on one somewhere.
-
@redmenace:
Both of those errorlogs seem to be some registry problem. Either creating or reading an entry.
The MAX_MEM_POINTERS thing is something that I have disabled in some builds and just increased slightly in others. You probably want to bring this to Bobboau's attention and see what he wants to do about it. I don't like that code at all so given free reign I'd just remove it. The bmpman error is related to this so fixing this should fix that bmpman error too.
Not sure about the beam problem. I'll look into it when I get the chance. If it keeps happening then bug Goober about it so that it can get fixed faster.
-
The open gl crash is registry related?
Assert: be->mem_taken > 0
File: u:\src\cvs\fs2_open.testing\code\bmpman\bmpman.cpp
Line: 2105
Call stack:
------------------------------------------------------------------
gr_opengl_bm_lock() bm_lock() bm_page_in_stop() level_page_in() freespace_mission_load_stuff() game_start_mission() game_enter_state() gameseq_set_state() game_process_event() gameseq_process_events() WinMainSub() WinMain() WinMainCRTStartup() kernel32.dll 7c816d4f()
------------------------------------------------------------------
Assert: be->type != BM_TYPE_NONE
File: u:\src\cvs\fs2_open.testing\code\bmpman\bmpman.cpp
Line: 2248
Call stack:
------------------------------------------------------------------
opengl_create_texture() gr_opengl_tcache_set_internal() gr_opengl_tcache_set() gr_tcache_set() gr_opengl_tmapper_internal() gr_opengl_tmapper() g3_draw_poly_constant_sw() g3_draw_2d_poly_bitmap() gr_bitmap() gr_opengl_flip() gr_opengl_cleanup() gr_close() doexit() exit() WinAssert()------------------------------------------------------------------
-
Originally posted by redmenace
The open gl crash is registry related?
No, I think that one is related to the MAX_MEM_POINTERS thing. That keeps track of allocated memory, as a leak detector, but appears to cause several strange errors when it runs out of slots used to keep track of used memory. That code would only catch some of the possible leaks anyway which I why I prefer to just use Valgrind under Linux for leak detection. It's considerably more advanced and at least 98% of the possible memory leaks would happen in both Windows and Linux. The MAX_MEM_POINTERS thing would catch none of the bad memory leaks that I've seen in the code so far and only a few of the minor ones (with total leaks less than 1Meg).
The bmpman error is basically where a DDS image didn't load properly. I assume this is a side affect of the MAX_MEM_POINTERS thing, though it may not be. Another possibility is that it's just an image or loader problem but in that case it would happen every time (which it might, you didn't say). The code used the load DDS images is the same for D3D and OGL so it's not really OGL specific and should have happened for D3D too under the same circumstances.