You have to use these mp3s due to the file names:

http://www.quake-1.com/files/modfiles/travail_soundtrack_mp3_easy.zip

They go in id1\music or travail\music folder. 

I have already renamed the mp3's myself beforehand. I also have the original Quake soundtrack in id1\music, also named track##.mp3. 

If it says ...

"track name is 03"
"playing track03.mp3"

Then check the volume control in Windows.

If it is just saying ...

"track name is 03"
and doesn't say "playing track03.mp3"

Then you don't have track03.mp3

If you aren't using -nocdaudio and aren't getting either of the above messages, something else is wrong. 

It says:

Track name is 03
playing track03.mp3

It's not my sound being disabled from within Windows, either, I can listen to anything else just fine. 

Have you tried renaming any old map and replacing one? 

After testing several maps from several gamedirs, I can safely say it's not a mapside problem ;) 

If it says playing, you can rule out everything the user is doing as a problem. It isn't the map or anything else.

It's either the engine, DirectX drivers or possibly Windows settings somehow.

In the future, I'll get broader testing of the change to get wider feedback. This modification hasn't had broad testing at this point. 

These are some features I think any Quake engine should have these days:

1. connect blah:port working well (this is the game that introduced online multiplayer after all)

2. NAT fix

3. Ping in scoreboard (it's just useful)

4. Support for fake CD tracks from ogg or mp3 files

The reason for having the basic multiplayer functions is that some people test their multiplayer-capable mods in Fitzquake because they're doing singleplayer maps as well.

The reason for the ogg/mp3 support (ogg is fine) is that finding and swapping and maintaining and storing CDs is a nightmare, especially since Quake CDs are getting older and rarer, and the Steam version doesn't come with the CD. 

My stupid test suggestion was made stupider. I meant to say 'mp3' not 'map'. 

An SP engine feature request / question.

Could we have global sounds play genuinely globally, and not only when in the player's LOS? 

Yeah, that should go into QSB 1.0.

Sorry for thread hijacking :-P 

Unlike other ports, Fitzquake freezes for a couple of seconds when using the edicts command in conjunction with -condebug. 

 

That actually sounds normal enough. The edicts command spews a *lot* of text to the console, all of which is written to the HD using unbuffered IO when -condebug is enabled. I'd be surprised if an engine does anything other than freeze for a short while, in fact. 

the solution is to buffer that stuff, but the negative of buffering is if you crash before you flush the buffer, you end up not logging whatever was buffered.

I guess it depends on what the primary use case of -condebug is. If it's diagnosing a crash, vs. just a convenient reference for later use. 

Well, it works flawlessly in GLquake and Ezquake for example. Winquake freezes, too.
The delay varies depending on the OS. On XP, it takes roughly 40 seconds for E1M1, on Win7 almost 100 seconds (and I even had to close it from the task manager afterwards). GL seems to handle the buffering differently then? 

ah, good to know. I can look at how they do it, maybe i did break something. 

> Well, it works flawlessly in GLquake and Ezquake for example. Winquake freezes, too.

That's odd because it's the same code in WinQuake as in GLQuake... 

On my linux C2D box, there's a noticeable delay, but nothing really. Day of the lords with 144/166 kills takes less than 2 secs with -condebug. Whatever it is, i think it's in quore-0.3.0 too, which uses some fitzquake code. 

1s here (athlon 2 x2 240). Exe: 16:04:11 Jul 5 2008 on Lunix. 

The original glquake generally would redraw the screen once for every line of text printed to console. For large dumps (like the edicts command) this took a long time, so I changed it to write everything first, then update the screen once at the end.

This is faster overall, but results in a small period of no screen redraws. Since in my testing it only takes a fraction of a second, I never saw this as being a problem. I suppose that with -condebug, it takes longer and this hang is noticable. However, the alternative is that printing 500 lines takes 500 render frames, i.e. like 5+ seconds.

I still haven't tested this so it may be there is some other dumb bug causing the lag. But that's my current theory. 

i guess there's some coding reason why you couldn't just make it print 100 characters at a time instead of all or nothing? 

probably the whole system needs to be re-thought. Quake has some weird linkage between console updates and screen renders which doesn't make a lot of sense; I think the original motivation was when you are disconnected there is no map rendering to trigger a screen redraw, so the console printing needs to do it.

Really we should just redraw the console at a fixed rate when disconnected, and then printing doesn't have to be linked to drawing. 

I'm just curious as to the reasons why someone would want -condebug on all of the time. I suspect that it's not intended for this kind of general use (the presence of "debug" in the name kind of gives that away...) so it shouldn't really be considered performance-critical.

Seems to me that people might be using it to keep a log of events in a multiplayer game rather than it's intended purpose (checking console messages immediately prior to a crash - see the Quake readme) so maybe switching it to buffered I/O as a default is the way to go.

I'd suggest adding a "condebug" cvar, so it can be toggled if it causes trouble. Value 1 uses buffered I/O, value 2 uses unbuffered I/O. Also use unbuffered I/O if developer is 1. You can keep -condebug on the command-line, check it at startup and set the appropriate cvar value if you wanted as well. 

...that the edicts command is a pathological worst-use-case as well. Expecting performance from it might be a little bit unreasonable.

And also that it's actually quite important for the intended use of condebug that it be unbuffered and write each line individually, otherwise you might not get the console message indicating what caused the crash.