[Goober5000]

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.

[mrduckman]

Originally posted by WMCoolmon

#3: Don't tell me OGG support is broken again. Try removing mv_music and see if it still happens.

Odd. Wasn't using it.

[mrduckman]

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

[Descenter]

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.

[taylor]

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.

[Ver Greeneyes]

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.

[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.

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.

[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.

[pflumm]

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?

[TopAce]

There is no 'should' or 'should be' in the SCP.

[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.

[WMCoolmon]

Originally posted by TopAce
There is no 'should' or 'should be' in the SCP.

Is. Or is not. There is no 'should'.

[TopAce]

^ Exactly what I was thinking about. After posting it, I started to hope you don't turn that post against me.

*sigh of relief*

[pflumm]

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...

[redmenace]

taylor, I know what you said in the internal, but I thought you might want to take a look at these two bugs

[redmenace]

Here is the second.

[Col. Fishguts]

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 ?

[WMCoolmon]

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.

[taylor]

@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.

[redmenace]

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()------------------------------------------------------------------