be the last one to join a game and you'll be at the end of the line for all radius checks.
when you do a 'findradius' check, it incrementally loops through all game entities. well as it's looping, I store information in the radius checking entity as a weight if it's a possible target. If an ent is closer or moving faster towards it, it's id is stored and used. each player has allot of stored things already in their backpack of information; their speed, where they are, where they were, where they may be next, and a bazillion other wf things (stock q3 is a wallet, wf is a filing cabinet. THATS gonna be a tough cleanup, whew).
if the entity already has a candidate for full-time thinking, it just watches that one target until it's not thinking fulltime; then loops through all of the ents again in a findradius looking for potential targets and just picks the best one out of the bunch.
What I do is after the check to being friendly or foe, just like any other findradius check, I just use where they are going and see if they are going towards the thinking entity and their speed with a vector distance check. It is some vector math and a few square roots for creating a weight system, but nothing complex.
when a possible target is in range, the actual number of the target is stored in the ent as well as a numbered weight in the ent for the next frame check. I'm using a starting range that is roughly 2x the size of the original ent's findradius range so there is a buffer. If any target is within the range (1000 units or so for the sentry, for example) the ent is hyperthinking as it always was.
So in effect, you place a sentry on any platform in the enemy base in zero it's always going to be hyperthinking.
One of the biggest issues that always pissed me off was that the whole findradius check was flawed for picking out enemies. You could have a turret in midfield and it would ALWAYS fire at one target until it fails the checks. That means one person could hog up the whole shebang for all ai ents by dancing around. The sentry is different as once it finds an enemy it always remembers that enemy till it's dead or out of view or frozen.
as far as laggy players, i'm up on the predictive paths like you would see for item pickup (BG_EvaluateTrajectory) and using those for all enemies within a maximum radius. since it's already doing a check on all entities, just figure out if its coming or going and how fast it's going using the stored prediction anyway; if it's coming towards it then start thinking faster. There is a buffer zone put in which allows for error on the server as well. I limited the client's fps to go no lower then the server's fps; if it is then its so predictive it doesn't matter.
teleport destinations, if they are near, are considered possible enemies (if their targeting ent's team doesn't match the ent's team) and even given a fake velocity; what velocity the player would get when coming out of one. It was easy to fix all of dman's maps, at spawn I just checked the links for teleporters, linked it if it was a destination; if it wasn't then it's freed and a destination is spawned and linked.
it also consolodates allot of code and eliminates redundant checks.
If it is flawed, its easy to revert back during testing, maybe to be revisited if it is flawed and fixed. a server-side variable decides what function to use
