I tried your fix, but to no avail. I also tried increasing soundmegs to 512 megs, but that didn't work either. I also had problems with the x64 version of the version of ioquake3 that can be downloaded straight off of the website, as in it didn't boot up at all, leaving me with no error message to work with.

Is that the version from ioquake3.org/get-it/test-builds/ ? You might try running it with a clean baseq3 (i.e. only pak0-pak8).

It could also be useful if you send a logfile from the startup (with any ioquake3 version that exhibits the problem). Start the game, run "/condump temp.txt" in the console, and post the temp.txt file. It would likely be saved under %appdata%\Quake3\baseq3.

Ok. Once I get home, I will give you the log.

I get this problem with your version. I tried running with a clean Quake 3, with no .pk3 files other than pak0-pak8, and when I add 15 bots in UIE, I still hear popping when gunshot sounds or footstep sounds are occurring. I should've states this in the main post, but it pops randomly. When sounds are made, sometimes it pops, and sometimes it doesn't, but most of the time, it doesn't. I also tried without any mods period, no UIE, no maps, no models. I still hear popping with multiple bots. This is all ox the x64 version. As previously stated, this error is missing on the x86 version.

Can you reproduce the problem using the official ioquake3 x64 test build from the link above, as well as my version?

I sent you the text.txt file through Gmail. Yes, I was able to recreate the problem with the test build on github, so this is definitely not a problem with your version, and rather maybe with something that is specific to the x64 version. Would you happen to know what that is?

It does seem to be something relatively specific to your system at this point, perhaps a directshow configuration or filter problem, since that's probably what ioquake3 is using for sound output. Directshow is prone to problems that affect 32-bit and 64-bit applications separately. You might consider just sticking with the 32-bit versions of ioquake3, since there isn't really much difference as long as at least one of the versions works.

Edited 25 seconds after the original posting.

Sad to see this problem solving come to an abrupt ending. I will stick with the x86 version. Thanks for the help!

I've just noticed a weird problem. When I go into skirmish and load a map, the game will instead load some other random map different from what I chose. I don't know what could've caused this, because this came out of nowhere. All that I could think of that might of caused it was me installing defrag into my Quake 3 folder, but I don't know if this caused it. I don't get this problem when I load the map from console.

Edited 12.44 hours after the original posting.

UI Enhanced has a lot of complicated stuff in the skirmish menu, and I'm not really sure how it all works myself. I think you should be able to delete the file %appdata%\Quake3\uie\uieSkirmish.dat to reset the map list and other settings, which might help the problem.

Your fix worked like a charm. I no longer have that problem. Because this was fixed, I went to get some more Quake 3 maps (1600 more, infact) and the game is slow. Specifically, the menus and UI were slow, the actual game ran fine. It's still usable, it's just annoying to wait 2 minutes to load the game up, choose a map, and start playing. Would you happen to know of things that I can do to speed this up a bit?

At a guess, that uieSkirmish.dat file you delete was a cache file containing metadata. The next time you start the game without any changes, should be a lot quicker. Well, that is how I would have done things :]

I think UI Enhanced is just inefficient at dealing with large numbers of maps. Having to parse a large number of arena files is inherently slow to some degree, but UI Enhanced has code that unnecessarily repeats the process over and over again, among other inefficiencies. It doesn't seem to be designed with large numbers of maps in mind.

You might want to consider alternative map loading schemes, such as viewing the map list in one game window and typing the map names into the console in another.

@Tig My filesystem engine does something exactly like that using a file called fscache.dat. Unfortunately I think the problem in this case isn't the engine, it's just that the UI Enhanced menus weren't made to handle thousands of maps.

I've noticed that when I am in the actual maplist, it isn't slow. Its just the skirmish menu that is slow. I also tried taking the game off of my SSD and putting it on my 7200rpm hard drive (exponentially slower) and the game slowed down a ton. So its not a cap in file access speed by the game, as putting it on a faster drive sped it up. Specifically, the game only really lags when I hover my cursor over the map name in the skirmish menu, when I click on the map to enter the maplist, and when I load the map. Those are the only places where it lags.

Edited 21.47 minutes after the original posting.

Here's one more thing you could try, but I don't know if it will work at all. Copy this file into the UI Enhanced (uie) directory:

stvef.org/files/uix86.dll

When you run the game, run the following command in the console before loading the UI Enhanced mod:

/set vm_ui 0

This definitely sped the skirmish menu up by at least 3x. The only problems I can notice is that loading into the menu from a map is slow, and I don't know if this is only true for your version or your fixes, but in some maps, player models and gun models are too dark. Their textures aren't black, as shooting will brighten up the gun and nearby models, showing their actual colors. I tried switching renderers and graphics options, but to no avail.

I'm glad the dll helped. That's probably all I can do optimization-wise at the moment.

The models are too dark relative to what? Could it be caused by the mod paks you placed in basemod earlier? You might try removing them temporarily.

The models are too dark compared to the regular ioquake3 available for download on the ioquake3 website. Removing the basemod files didn't work either.

Hmm, if you can give me the name of a specific map and model that exhibits the problem I'll see if I can reproduce it.