More notifyWhenAttacked-control

Kasami

I'm a fan of the email-notification system, and use it both to send replaylinks to myself for debugging and reviews, and status reports I can read on the go.

Normally this is working fine, but when a lot of going on, especially when under attack, the spam of ramparts, walls and civilian creeps under attack is overflowing my mail box.

I therefore use notifyWhenAttacked to toggle notifications off for creeps I know can and will be under enemy fire, that I do not want notifications for.

Since this costs 0.2 cpu for each time, I try to be very restrictive, and do it at tick 1499/599 for creeps/claimers. However, with structures, ramparts in particular, it's much more tricky, since I don't track when they are done and adjust notifyWhenAttacked then.

The second problem is that I have no way of reading out the current value of notifyWhenAttacked, so if I want to do it periodically I have to set notifyWhenAttacked(false) on all structures I'm not interested in having notifications about. That adds a significant CPU-cost, that should be unnecessary.

I have some thoughts on possible solutions for this, ordered by my preference:

Add a new notificationStatus property to creeps and structures, allowing me to check the current status
Make me able to set the default of notifyWhenAttacked to false instead of true
Add some kind of set-all notifyWhenAttacked-function that can be applied to structuretypes and creeps
Make new settings on the Notification-panel for grouping attacked-notifications the same way we can group error-notifications

Keep up the good work! We ️ IVM! Looking forward to that the future might hold!

Thanks, Kasami

Shibdib

Toggling this costs cpu? Well that's good to know as I do it for every creep..

Simple solution would be to remove the CPU cost from this or make it toggleable for creeps as a spawn option, and structures when the construction site is created

Hiryus

@kasami said in More notifyWhenAttacked-control:

Add a new notificationStatus property to creeps and structures, allowing me to check the current status

I'm used to set memory for this:

Creep.prototype.disableNotifs = function () {
    if (this.memory.notifs === false) return OK;
    const result = this.notifyWhenAttacked(false);
    if (result === OK) this.memory.notifs = false;
    return result;
};

However, I'm 100% for a global or spawn toggle.

MrFaul

A callback for notifications would be super awesome...
So you can easily manipulate the message before it is sent.

Knightshade

This is a good idea. Constantly getting pinged due to minor engagements is extremely annoying, but disabling notifications entirely is a suboptimal solution. Looping through literally everything and disabling notifyWhenAttacked is extremely wasteful, and doesn't really scale well.

I've looked into trying to have a system to catch newly build structures and creeps to override the notification system there specifically, but the overhead required for tracking would render moot any savings gained by not just periodically looping through everything. (And of course, looping through everything every tick is not really an option, so there will be a gap where the notifications aren't updated).

So such a change would be extremely welcome.

SystemParadox

According to the source, notifyWhenAttacked only creates an intent if the value is changed, so you won't be charged 0.2 CPU every time.

I profiled this and calling notifyWhenAttacked(false) for every creep cost me less than 0.1 total CPU each tick (I have about 65 creeps). It would still probably be more efficient (and more useful) if we could check the current value ourselves, but at least we don't get hit with the 0.2 CPU charge every time.

artch

Now room events log exists and serves the same purpose with connection to Game.notify, and we're actually considering removing notifyWhenAttacked at all as an unneccessary complication.

SystemParadox

I'm totally in favour of that. I think the event log should be an essential part of the game.

However, I get the impression that many players are avoiding using it due to the extra CPU cost - myself included. Is there something that can be done about this? When you read the documentation the first impression is that it might be quite expensive. I've now profiled it and under peaceful conditions it's about 0.09 per tick to deserialise the event log for 10 rooms, without doing any processing on it. I'm not sure what might happen if you've got a lot of remote rooms or if there's a battle going on.

It feels a little unfair. Why isn't this already deserialised like the other game objects?

It's also all-or-nothing. If you disable the built-in notification system you have to process the entire log for all events for every room on every tick no matter what. And that's every room with visibility, not just every owned room or even every room with a creep in it. There's no way to filter it by event type or target before deserialising it. If I have visibility to a battle between other players, I'm going to have to deal with all those events too.

artch

@systemparadox I don't think that in this particular case of receiving notifications you have to parse it every tick. You'd want to be notified only about some major attacks, not about single-tick events. You can parse the log only once per 10 or 50 ticks, and it will be enough to track important events such as a siege that was started against your room, since dismantlers will be attacking your walls for hundreds of consequent ticks.

SystemParadox

That's a good point!