BUGFIX (minor): The body queue size is too small for more than 8 bots.

[ghost]

Player animations are often change to a random frame number after death because there is no free body queue spot. Additionally corpses sometimes will start to rotate, this happens also due to the too small body queue size. This is a long standing vQ3 bug. I highly recommend to increase the body queue size to 128 or even more (although 128 seems enough to get rid of this issue assuming 64 clients/bots is the maximum of connected clients). The fix for this bug is simple, just increase BODY_QUEUE_SIZE in g_local.h from 8 to 128. In case you never experienced this issue, here is the test scenario:

1. devmap q3tourney3 in FFA mode (the issue is not map dependant, but on q3tourney3 you see nearly all corpses at once).
2. add 64 bots and let them fight, spectate the corpses. From time to time (when there is no free body queue slot, corpses starts to rotate or they change to a random frame number).

zturtleman used my fix here as well: https://github.com/zturtleman/mint-arena/commit/3faafa1769dfe45700bb2403785dab5150ec7ce4#diff-8f5ec7e7dd41d8912016c09df1d25db2 though he just increased the body queue size to 64 (I don't remember why he only uses 64, maybe we thought it will count to maximum clients or so, but this is NOT the case). Unfortunately my old google code project (ioid3) he is referring to is gone.

[ec-]

1) mod/engine can't handle big number of connected clients because it simply crashes on a massive configstring updates so in real you should use less than 32 clients, anything greater is not recommended 2) every corpse uses one map entitiy - which becames very deficite resource (we have < 1023 in total) on a map with many clients, i.e. if you reserve too much entities for corpses - you may lose in-game events, projectiles, etc. It is possible to increase corpses count to some reasonable value like 16 but greater values is just a waste of resources

[ghost]

Damned, where are you know all this from? You are genius! Thanks for pointing this out! Okay, so do you know any other way to fix this bug without wasting ressources? Something like decouple corpses from client to not affect the body queue (models)? I tried a lot of unlink the corpse (entity) but this doesn't help. You said:

mod/engine can't handle big number of connected clients because it simply crashes on a massive configstring updates so in real you should use less than 32 clients, anything greater is not recommended <

That's funny, your project is the only one I know that handles 64 bots without crashing! That is why I like your project so much! Even Spearmint and Ioquake3 will crash after a while (e.g.: after a map change). This is the reason why the issue of rotating corpses and bad corpse animations is so visible in Q3e + baseq3a! Other projects can't even handle 64 bots! So you think Q3e + baseq3a is also unstable with more than 32 clients?

[ec-]

Possible fix - do not use dedicated body queue and allocate entities dynamically depending from current usage (like it works now for projectiles, events)

I fixed 64-client usage but as I said - it is very close to crash because command buffer on engine side is limited to 64 commands so even if you're printing only single "XXX entered the game" for each client - there will be no space for configstring update messages or "\map_restart" for example. It can be mitigated by collecting all possible print commands into single one but not worth an effort as for me

[ghost]

Sorry to ask you again but what do you mean by 'allocate entities dynamically ... like it works now for projectiles, events' I didn't know that projectiles, events are dynamically allocated now, when was that added? I mean which commit? Sorry for all my questions, I'm not used to your projects until now! After a while I will not ask such amateur questions, I promise! I will look for a better fix for this issue.

[ensiform]

Slightly unrelated but it is possible to free up some entity space by making irrelevant server entities not take up space in the entity list at all. Things that don't need to be sent to clients typically can be skipped. There are other mods for idtech games that have done this in the past.

[ec-]

By dynamically I mean common entity pool, not fixed 8-item array

It is possible to remove some items like server-side triggers, locations (already done) but this list is not long

[ghost]

@ec Ah, thanks man, I thought with 'now' you meant something like 'the new method'. @ensiform Can you please give more information of which mods for idtech games that have done this in the past, which mods do you mean?

To both of you, I know this is not a forum, so is there any place where we can deal with coding stuff (Q3e and ETe)? Maybe Discord?

[ensiform]

@KuehnhammerTobias you could check Jedi Knight Galaxies mod on GitHub. I believe that has the most extensive work on that front.