Enemy not attacking?
Re: Enemy not attacking?
Frikbot's code looks like it hacks the world entity through startframe to be the bot. I thought you would need to store oself, then use a default entity as the bot, then switch back again when done, but somehow it gets away with not doin any of that. It sure looks like all the bots would be thinking at the same time in that case. There must be othyer code I didnt study yet that pumps them into the player slots, so their nextthink is that of an actual client. It dont sound like there would be a way in that case to stagger the Frikbots, unless self.nextthink is still somehow valid?
Re: Enemy not attacking?
assignments to world.* will trigger an error.
startframe is called noticably more often than 10 times a second. it can still stagger thinks, though doing so may result in jerky bots so I suspect it updates runs every bot every frame... hey, at least that there's only 16 bots in regular quake.
the frikbot code that 'allocates' player slots is quite nasty and trivial to crash in quakeworld. using dp_qc_botclient or whatever it is is generally a good idea if only because it means you can clean up most of that code, greatly reducing it. Using extensions also means you can just use the engine's player physics instead of having to provide your own (buggy, because its not identical) code.
startframe is called noticably more often than 10 times a second. it can still stagger thinks, though doing so may result in jerky bots so I suspect it updates runs every bot every frame... hey, at least that there's only 16 bots in regular quake.
the frikbot code that 'allocates' player slots is quite nasty and trivial to crash in quakeworld. using dp_qc_botclient or whatever it is is generally a good idea if only because it means you can clean up most of that code, greatly reducing it. Using extensions also means you can just use the engine's player physics instead of having to provide your own (buggy, because its not identical) code.