CheckClient
Moderator: InsideQC Admins
6 posts
• Page 1 of 1
CheckClient
I hate this function because it makes monsters see only player clients and not other monsters
Is there a replacement that lets it see both? Because I want a monster to hate another monster by getting into its view rather than provoked by friendly fire from monster.
Is there a replacement that lets it see both? Because I want a monster to hate another monster by getting into its view rather than provoked by friendly fire from monster.
- leileilol
- Posts: 2783
- Joined: Fri Oct 15, 2004 3:23 am
If you give a special string (such as .targettype) to all valid "squishy" entities that monsters should be considering for possible aggression, then you could simply use the find command.
However, find would have every monster looking at every monster in the map. To take some of the burden off the QC, you could instead use findradius. This would trim all entities that are outside of the monster's "wake up and kill" range (I think this is RANGE_FAR in QC but not sure) in the engine with much less work on the QC end. Findradius also ignores entities that are nonsolid I think, so really it's ammo, buttons, monsters, players, triggers, things like those that you'd be sorting through.
Another advantage is if a monster checks another monster and says "oh, that guy's my ally and I don't want to attack him", it can then check "hmm... is he mad at something I can see? Or if I can see him, is he mad at something he can still see? Well then I'm mad at it too" and accomplish multiple tasks with the same loop.
Even if there's a lot of entities in a small area, if the monsters are each only scanning every 0.1 or even 0.5 seconds (using some .float timer to space out the scans), then it shouldn't be bad at all.
I hope that helps!
However, find would have every monster looking at every monster in the map. To take some of the burden off the QC, you could instead use findradius. This would trim all entities that are outside of the monster's "wake up and kill" range (I think this is RANGE_FAR in QC but not sure) in the engine with much less work on the QC end. Findradius also ignores entities that are nonsolid I think, so really it's ammo, buttons, monsters, players, triggers, things like those that you'd be sorting through.
Another advantage is if a monster checks another monster and says "oh, that guy's my ally and I don't want to attack him", it can then check "hmm... is he mad at something I can see? Or if I can see him, is he mad at something he can still see? Well then I'm mad at it too" and accomplish multiple tasks with the same loop.
Even if there's a lot of entities in a small area, if the monsters are each only scanning every 0.1 or even 0.5 seconds (using some .float timer to space out the scans), then it shouldn't be bad at all.
I hope that helps!
When my computer inevitably explodes and kills me, my cat inherits everything I own. He may be the only one capable of continuing my work.
- Wazat
- Posts: 771
- Joined: Fri Oct 15, 2004 9:50 pm
- Location: Middle 'o the desert, USA
the problem is the function returns one player per frame.
make it return one player or monster per frame and you end up with really slow reacting monsters (average map of 60? thats 6 seconds to see a nearby monster).
So any 'replacement' would have to be noticably different in design.
'Findradius also ignores entities that are nonsolid I think'
DP finds them.
Findradius is a suitable replacement, so long as its slightly staggered between monsters. While 6 seconds is too slow, 0.5 is imho fine for non-player entities, though you'd want to spot players a little faster really.
if (e.flags & (FL_MONSTER | FL_CLIENT))
that would do nicely.
make it return one player or monster per frame and you end up with really slow reacting monsters (average map of 60? thats 6 seconds to see a nearby monster).
So any 'replacement' would have to be noticably different in design.
'Findradius also ignores entities that are nonsolid I think'
DP finds them.
Findradius is a suitable replacement, so long as its slightly staggered between monsters. While 6 seconds is too slow, 0.5 is imho fine for non-player entities, though you'd want to spot players a little faster really.
if (e.flags & (FL_MONSTER | FL_CLIENT))
that would do nicely.
- Spike
- Posts: 2892
- Joined: Fri Nov 05, 2004 3:12 am
- Location: UK
Spike wrote:Findradius is a suitable replacement, so long as its slightly staggered between monsters. While 6 seconds is too slow, 0.5 is imho fine for non-player entities, though you'd want to spot players a little faster really.
That's pretty much what I've always done for bots, RTS units etc.
I normally have them do a findradius at random times between 0.1 and 1 seconds each, to nicely stagger them out and have a slight variance in reaction times.
Apathy Now!
-

MauveBib - Posts: 634
- Joined: Thu Nov 04, 2004 1:22 am
6 posts
• Page 1 of 1
Who is online
Users browsing this forum: No registered users and 1 guest