I am in the menu adding bots using the "Add Bot" Section. This happens with UI Enhanced running, and it happened to about 75% of the bots that I tried to add. I will test to see if this occurs without UI Enhanced running.

So it appears that the bots that didn't work in UI Enhanced don't even show up in the list of bots in vanilla Quake 3. I will check in the baseq3 folder to see if there are any problems with missing .pk3 files or problems with .pk3 files having the wrong name.

I'm guessing that this is a limit with the number of bots available to use in Quake III Arena. Do you happen to know of any way to increase that limit?

I tried adding the bot through the main menu, and not when I was already in the map. I got the error message "Client (Slot #) is not connected" I tried adding the bot manually through the console, and I got the same "Bot not defined" error message.

I've also noticed that the xcsv hi-res texture pack that ioquake3 recommends to use doesn't appear to work, and the High Quality Quake mod doesn't appear to work either.

I believe the bot problem may be caused by an overly small directory list buffer in g_bot.c->G_loadBots. This limit isn't normally updated as part of UI Enhanced because it is part of the game vm rather than UI. I made an updated mod pak to increase that limit; try adding it to the UI enhanced directory: stvef.org/files/ui...maplimitup2.pk3

My filesystem project doesn't allow regular paks in baseq3 to override the main game paks. Instead you have to create a directory called 'basemod' alongside baseq3 and place the mod paks there. This helps prevent random paks from causing unwanted changes or problems. Try creating the basemod folder and move the mod paks into it and see if that fixes the problem.

Ok, I will try these fixes and report back!

I just tried your 2 fixes that you provided, and both of them worked. As always, I will post any problems that I encounter here. Thanks for the workarounds!

I don't know if this is only true for your version, but when I run the x64 version, the sound keeps popping whenever I add a lot of bots. I don't get this problem on the x86 version. Even when I am in an empty room with no bots, whenever I walk and create footstep sounds, the volume pops. Do you know why this is?

Edited 44.58 minutes after the original posting.

I couldn't immediately reproduce the problem on my system. It could be related to the old SDL dll that comes with normal ioquake3 builds. I prepared a test build using the current SDL version, available here:

stvef.org/files/io...wfs_sdltest.zip

Just unzip this file into the quake 3 directory and overwrite existing files, including SDL264.dll. Note that this dll doesn't currently work with other ioquake3 builds, so you might want to back up the old version.

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.