qc
Hardware & Tech
.qc (dot qc) - the group for quake c coders of all denominations. If you make quake one mods and write code in quake c, join our group! I'll try to answer any quake c questions - please post your inquiry in the forums...
Quake c - gone bad #F - a day at the races
Post a comment
Description
Plus - cool shadows! Heh heh.
I also think this would be a cool effect in game. If it could be duplicated without bringing the server to its knees.
(Yes - I had sound turned off on purpose...)
This isnt the fun sort of race - no one is taking any bets. Unless it is when the server may crash.
What is happening here?
A race condition exists in frikbot spawn code. I discovered it with Archon and thought it was something I might have introduced when I added in pk*bots.
However, it seems frikbot can do this all by himself. As frikbots die and respawn, somehow a group gets stuck at one (more, or even all!) spawn points in a constant spawnfrag cascade. This doesnt happen with humans - after the first couple spawnfrags, you tend to hesitate to make sure the spot is clear.
In theory, as long as the number of spawn points is greater than the number of players, this should not happen.
In Archon I added some delay code if respawns were happening to quickly. I'll have to port that code over to this instance of frikbot. Unfortunately this does affect the frikbot contained in v1.06 RECODED, so that will need an update as well.
The thing I find really interesting in this instance is the server was running for days in a stress test of v106 recoded. The bots had hit the 29K score range. (Yes, thats 29000+.) And they had not got into the race condition. Unless it can cure itself. I plan on watching this run for a bit and see if that happens.
But, if it didnt happen until I poked my head in, I wonder if its possible to aggravate the race condition by killing the right sequence of bots?