Is there a simple utility to convert wav files to avoid the "sound is not looped" or "is a stereo sample"? 

I�d like to know this too. I�ve experimented with basic old windows sound recorder, which generally works.

I don�t know much (next to nothing) about sound editing but if you go into properties and the option that�s probably called "convert now" (I�m using spanish XP and don�t know the translations that well) you can change the Kilohertz to something that quake recognises - but like I say there seem to be some sounds that it will never recognise, and when it tries to use them quake crashes or doesn�t play em - just the standard dud sound message.

I can�t remember exactly what I was converting em to, maybe 16bit stereo? (which was wierd cos it was a higher quality than the recording had been before).

Does anyone know the specific system used? 

See part 4 of the link below... It sounds the sound is 8-bit stereo... Maybe there exist audio tools that can convert sound to 8-bit .wav file

http://www.gamers.org/dEngine/quake/spec/quake-spec22.html

I hope it helped.. 

Maybe one of these audio softwares could help...

http://www.e-soft.co.uk/

Enjoy ! 

This one also works...

http://koyotstar.free.fr/indexEn.html 

 

suggestions and links, I'll check them out. Ugh, big downloads ... ;) 

on my way out so can�t check yet, but; windows sound recorder everyone has already - why I asked for the specific sound bit / type that quake requires, cos there�s more options for conversion in there that I haven�t used yet.

anyhoo, probly I�ll check those programs also. 

11khz, 16bit mono, but you can also use 8bit.

and soundrecorder more than suffices for doing conversions.

however, if you're converting down from 44khz or 22khz, it might not always sound good with soundrecorded, and a better sound software might be needed to play around with the sound to make it better in 11khz. 

That's more like it, thanks! 

i got the alloc_hunc error again.
Thought it had something to do with too much textures in the wad file, but i forgot.
So I lowered the texture rate, but still got the same error.

Forgot the map ,and later played it with ordinairy quake batch -winmem 32 as proof and it played fine.

1616 polyhedrons 279 entities. 

I have an serious problem with "packet overflow" warnings. I have run fullvis on my map and unfortunatelly there are some places where I get this warnings on higher skills. I have some questions:
1. Is this warning computer speed dependant?
2. Is it possible that it appears only in gl engine? (it appears in fitzquake but not in software joequake).
3. Since I can't reduce the visibillity in this part of the level I have to reduce the number of entities. What are the best things to remove? (torches, flames, monsters, anything else). I guess removing the GL would be most effective, but I won't do this :)
4. There is an big amount of lights (torches and flames) in that open area, can their sound cause problems with packet overflow? Is there a possibility to remove the sound from a light_flame?

I would test it all out by myself, but full vis takes too much time (25h) on my old comp. :(


I was using aguirRe's winquake during development, but it doesn't give any errors about packet overflow (even if it would I would ignore this since the level wasn't fully vised). I think now that it is better to always test the map with standard engines and use the enhanced versions only in case of crashes or problem hunting. 

1. It's not generally computer speed dependant, but I guess some variations could occur.

2. No, it's only engine protocol packet size dependant, std size is 8000 bytes. Fitz and Joe should have the same problems as both use the std size AFAIK. I don't know why you're seeing a difference.

3. Usually the problem is too many [active] entities in view. If you can't reduce visibility, you'll have to reduce entities. I don't know if there's a difference in various entities as such, but some entities spawn other entities (edicts, e.g. HK missiles), which makes removing them more effective.

4. I don't know if torches add up to the packet limit as they're static entities.

In any case, you can modify the entity section and just do qbsp -onlyents without redoing vis each time you test.

Btw, are you using std progs or a custom one? Using a custom progs could be the cause of packet overflow (e.g. ejecting many shell cases). OTOH, using a custom progs can also help you to reduce edicts by removing corpses, delaying spawns etc.

Let me know if you need help investigating this issue. 

At the moment I don't have the time to check out your suggestions. But thanks a lot.
Some additional info:
I don't use any special progs.dat. In software joequake there is no overflow, in joequake-gl the problem starts to appear and in fitzquake the problems are getting bigger.
If I kill all the monsters with genocide (it is an impulse command) then there is no packet overflow in any place. There are many gibs in this map because GL is the main weapon. Maybe using a progs.dat with corpse removal would solve the problem, but I don't like this idea. Is packet overflow in two places in a level a realy bad thing?
I remember that I was getting some warnings when compiling with -onlyents after some entities were removed/added, but I will check it out. 

IMHO, having "massive" packet overflow warnings in some places in a map dicrease its quality. AguirRe helped me for CDA: there was a lot of packet overflow warnings at the very first release, and using a spawn64-like progs.dat helped to limit the number of entities the engine have to manage, and then help to avoid packet overflow... Believe me, it works fine, and furthermore you could add more monsters in the map... ;) 

you could of course have each monster in the concerning area fire trigger_relays that in turn killtarget the monsters. this way, at least their heads would be removed which might possibly reduce the packet overview a little (however, it would also remove their corpses if they are not gibbed, which probably looks weird. maybe delay values could help).
dunno if this would make much sense, just an idea... 

I remember asking a question about the Quake1 CD music and whether I could rip it off the CD and play it from my hard drive.

Because I used Fitzquake it seemed not to able to be done.

So anyway, there I am thinking more about this when I look at the Quake CD and cannot see any music files. Can anyone tell me how to extract the music files? 

I just recalled that JoeQ has a custom filter mechanism; via cvars you can filter out gibs or corpses. I'd assume that if this was enabled, you might get less packet overflows in JoeQ.

Hmm, if I recall correctly, the filter was on the client side and packet overflows occur on the server side ... then maybe it doesn't make a difference after all in this case. 

any cd-ripping program will do, like eac (exactaudiocopy) for example. 

how do I trick the normal AI into believing that (eg.) a grate in the floor can be walked over by a monster? Can I do it when the grate is a func_wall? I tried a clip brush . . . 

If packet overflows are only occuring when you start gibbing things, there are a few easy changes you can make to the progs that will reduce the problem. One is just to reduce the lifetime of the gibs, probably look in ThrowGib to do that. You could also alter the monsters to spawn fewer gibs when they die, or set a higher threshold for gibbing so fewer of them do so. The latter solution is more work though, as you have to alter such settings on a per monster basis.

A more sofisticated method would be to have a cap on the number of gibs there can be in the level, say 20, and remove the oldest one each time a new gib needed to be spawned. This would also be a much more substantial coding effort.

ijed: You can try filling the gaps with "skip" brushes, search through this thread on google or something for some details on how to use them/where to get the skippy program from. The problem with this method is it makes the floor truely solid, so you can't fire through it/drop grenades down the gap. If the grate is quite fine, and you don't need anyone to fire through, you should be alright. But if that's gonna cause problems with the combat, then you may be stuck, I don't know of a real fix for that one. 

...I had a similar problem recently. I eventually populated that area with flying and jumping enemy (scrag and fiend) and that got around the problem to a degree. I contemplated a matrix of monster_jumps but because of the architecture it all looked too meh! If the path to travel is simple enough (single grate and only two directions to travel) the monster_jump might work without looking naff.

On another note, I was pleasantly surprised the other day to find that Death Knights and Knights can cross the continuous moving platforms in DM2 with relative ease. (The moving plats just around the corner from the lava trap room) How can they do this but baulk at some grates that the player has no trouble traversing?

Yes aguirRe I'll send you the .map if you want :) 

Last night I was doing some work on my D3 map and the computer froze up during a compile.

I waited a while in case it unfroze but that didn't happen so I had to hit the reset button.

The .map file was subsequently screwed, however I wasn't too worried as I simply went into the maps directory and pulled out the last .bak file.

It won't load. :(

Gives me this error when I try to load it into the editor:

"ERROR: file C:\Program Files\Doom 3\base\maps\abd3sp1\008_3_bak.map, line 45492: couldn't read expected floating point number"

At this point I start shivering uncontrollably. Due to foolishness on my part I have about two weeks worth of mapping unsaved since the last backup.

Basically, all I am asking is that if I get a text editor that shows you the line numbers, should I be able to simply delete the problamatic lines to get the map to load so I can salvage bits of it? 

After some digging around I found that a chunk of the .bak file is missing as well, a fair bit of geometry information and all the entity listings. Luckily, when I copied and pasted out a few random chunks of the geometry text into a new file I was able to rescue much of what I thought I had lost.

I will have to reinsert all the models and lighting for the newer areas, however that isn't much compared to having to rebuild it all. :) 

Thanks. Got them.