unthrottle eventAttacked()

[NoQ]

eventAttacked() is throttled, so do not worry too much about it being called too many times.

I just ran a few tests with eventAttacked not being unthrottled on the code side:

Code: Select all

--- a/src/cluster.cpp
+++ b/src/cluster.cpp
@@ -556,11 +556,11 @@ void clustObjectSeen(BASE_OBJECT *psObj, BASE_OBJECT *psViewer)
 // tell the cluster system that an object has been attacked
 void clustObjectAttacked(BASE_OBJECT *psObj)
 {
+       triggerEventAttacked(psObj, g_pProjLastAttacker);
        if ((aClusterAttacked[psObj->cluster] + ATTACK_CB_PAUSE) < gameTime)
        {
                psScrCBTarget = psObj;
                eventFireCallbackTrigger((TRIGGER_TYPE)CALL_ATTACKED);
-               triggerEventAttacked(psObj, g_pProjLastAttacker);
 
                switch (psObj->type)
                {


I believe it allows to significantly improve the AI's combat micromanagement, while not really having too much performance decrease (in my case this event is relatively lightweight). I can easily throttle it the way i want on the script side if i find it necessary.

Alternatively, i could use a new event that is called, for example, eventAttackedUnthrottled(victim, attacker), so that not break existing scripts (if any).

[aubergine]

I think having the extra event would be the best approach - if a script is running slowly, the developer can compare performance between the two events to quickly assess the performance impact of using the unthrottled event.

As we've seen from NullBot, performance issues tend to arise elsewhere, often in unexpected places (like searching for oil).

[Per]

Ok, unthrottled in master. Be careful though, or you'll create stuttering when people start thermite bombing!

I hope to soon look into spreading events over multiple frames, if they start to queue up.

[NoQ]

Oops, now someone needs to fix the attack warning sound (:
P.S. I already like the way it goes (:

[Per]

Oops, now someone needs to fix the attack warning sound (:

Fixed. Can now be adjusted through rules.js

[NoQ]

Hmm, now that i think of it ... how about we still have some throttling on the code side, but of a different sort.
For instance, don't call the event too often for any particular victim object, while still calling it often if multiple objects were just attacked.

We can rely on psVictim->timeLastHit property in eventAttacked to handle that.
But this property is set to current game time before calling eventAttacked.
So we need to call eventAttacked before setting this variable.

Probably something like that:

[aubergine]

So then you'd have effectively a clusterAttackedThrottled() and a objectAttackedThrottled()?

[NoQ]

What the hell did i post as a patch? >_<
Fixed the message above.
Still interested in some feedback.

[Per]

Looks good. Will commit (a slightly modified version).

[NoQ]

Yay (:

[NoQ]

Oops i think we're having a typo in triggerEventAttacked:

Code: Select all

-   if (gameTime - psVictim->timeLastHit < ATTACK_THROTTLE)
+   if (gameTime - lastHit < ATTACK_THROTTLE)

(because of that, eventAttacked isn't called at all right now in master)

[Per]

Oops i think we're having a typo in triggerEventAttacked:

Code: Select all

-   if (gameTime - psVictim->timeLastHit < ATTACK_THROTTLE)
+   if (gameTime - lastHit < ATTACK_THROTTLE)

(because of that, eventAttacked isn't called at all right now in master)

My bad. Fixed.

[NoQ]

Emm sry ... i still don't see that typo fixed yet after a git pull, and a relevant commit isn't present in the timeline.

[Per]

Emm sry ... i still don't see that typo fixed yet after a git pull, and a relevant commit isn't present in the timeline.

I forgot to push it