Factorio Forums

There is an alert sound if the aliens have attacked and destroyed a building. However, sometimes the alert sounds many seconds after my turrets have already killed off the aliens. This makes me wonder whether there are still live aliens missed by my turrets.

So I suggest that an alarm is not sounded when
* An alert has already been sounded in for a destroyed object within that general area within the last minute.
* There are no more aliens within a radius around the alert.

How do you define "THE" in this case?

I thought about it a while and this definition is really not so easy, and especially not, if you want a method, which doesn't need much CPU.

ssilk wrote:How do you define "THE" in this case?.

The is a "definite article", used, especially before a noun, with a specifying or particularizing effect, as opposed to the indefinite or generalizing force of the indefinite article a or an.

I think you missed a word, if I did not miss something then your post is therefore nonsense.

The alert sound plays a second time if:

-more than 1 building had been destroyed
-the alert for the first kill timed out, making alert #2 the first one, which hasn't timed out yet

It usually doesn't play a third time because by the time #2 times out, all other alerts from the same attack timed out as well.

I think the system could be improved a bit to not sound twice when, say, two adjacent wall were killed in an attack that was stopped immediately after, but they need to keep sounding more than once if aliens keep raiding your base.

But currently, the second alarm seems to play many seconds after the last building destroyed, which is extremely confusing. If it only played in the moment a building was destroyed, then there would be no problem.

thuejk wrote:I think you missed a word, if I did not miss something then your post is therefore nonsense.

I'm sorry, this was just stupid. In Germany such a formulation it's an easy to point to a part of text. But I think this time it was too obscure. (But on the other hand Xeona understood, what I meant... no, it was just a stupid asked question.... )

To your question. I meant of course the "the's" in your two points:

* An alert has already been sounded in for a destroyed object within that general area within the last minute.
* There are no more aliens within a radius around the alert.

My question was how do you define that, what I marked italic. And with definition is of course meant "what is the rule (the algorithm) to detect this?"

E.g. how do you know, what objects are destroyed within the last minute within an area? Of course: You need to set some kind of mark in the tile on the ground. And before you call an alarm you need to check the whole ground for this kind of information. Up to 60 times per second.

And to be honest: I don't know the reason for the current behavior (or have forgotten them). But I remember about problems with the CPU-usage of this detection.

ssilk wrote: E.g. how do you know, what objects are destroyed within the last minute within an area?

From a programming perspective, this is absolutely trivial. Keep a global linear linked list of the previous alerts. Every time you want to trigger a new alert, you run through that list first. You then prune any old alerts older than the timeout, and look for alerts withing the timeout within a certain radius. This is not a hard problem.

This list will practically never be longer than 10 items long, so absolutely trivial from a space and performance perspective. And only have to be checked once per alert.

Of course: You need to set some kind of mark in the tile on the ground. And before you call an alarm you need to check the whole ground for this kind of information. Up to 60 times per second.

No, that is absolutely not how you would do it. And absolutely not "of course".

That's what I wanted to know. and the "of course"-part was thought as example of what I mean. And if you watch about my mistakes.

This is about how a second alarm echo occurs 5-10 seconds after the first alert even if the wave is already dead, right?

An Alert happens for some reason even though no biters were there to do damage.

Ranakastrasz wrote:This is about how a second alarm echo occurs 5-10 seconds after the first alert even if the wave is already dead, right?

An Alert happens for some reason even though no biters were there to do damage.

Yes, that alarm that always makes you think there is a new attack!

If you know how to reproduce the delayed alarm make a bug report. I had that bug too, saw a bug report about this, but i couldn't reproduce it later.

Xelephant wrote:If you know how to reproduce the delayed alarm make a bug report. I had that bug too, saw a bug report about this, but i couldn't reproduce it later.

There was a bug report already. It had been moved to "not a bug" by Rseding91, with no mention of it being a problem of reproduction. Which I think is stupid, but it is their game. Hence I posted this here in suggestions.

It's not a bug, that much is clear.

Whether or not that behaviour makes sense, is another question, and whether or not it should be changed is up to discussion, thus is should be held in suggestions.
However, instead of closing it with a lifeless 'Not a bug.', Rseding91 could have suggested to take this to the suggestions board. Anyway, we're here now, and I'm also in favour of improving alert behaviour.

Xelephant wrote:If you know how to reproduce the delayed alarm make a bug report. I had that bug too, saw a bug report about this, but i couldn't reproduce it later.

Reproduction is easy. Build a wall. Make biters attack it, and destroy two pieces, then kill them. The game will sound the second alarm when the first one expires, even though the biters are long since dead.

What should happen instead is that the duration of the first alarm is refreshed when the second one activates (but doesn't sound immediately), and is maybe sounded again immediately when the first destruction happened, and at least x seconds passed.


So let's sum up current behaviour:
-Biters destroys object
-Game sounds an alarm, object is added to casualties list
-Biter destroys second object
-Object is added to casualties list
-Biter is killed
-Casualty #1 times out, is removed from list
-Game sounds alarm for Casualty #2
-Casualty #2 times out, and is also removed from the list
Usually, #2 times out briefly after #1, often before you even have a chance the check what caused the alarm, making it appear like a blind alarm

What we want to happen:
-Biters destroys object
-Game sounds an alarm, object is added to casualties list
-Biter destroys second object
-Object is added to casualties list
-Second alarm is sounded, if the first alarm was longer than 5 seconds ago
-Biter is killed
-Casualty #1 times out, is removed from list
-Game sounds alarm for Casualty #2
-Casualty #2 times out, and is also removed from the list

Of course this should be expendable for any number of objects.
I do not believe alarms should be separeted by attack regions, there is simply no need. Alarms contain to location information, you have to separately gather it from the map. I would also in that context suggest to increase the timeout for attack alarms on the map, so you don't have to drop everything and react immediately to catch that information. Or, optionally, make it possible to view recent (last x minutes) alarms.

Xeanoa wrote:It's not a bug, that much is clear.

How is that clear? It is obviously something that nobody would ever design to work that way if they sat down and thought about it. That IS a bug.

thuejk wrote:

Xeanoa wrote:It's not a bug, that much is clear.

How is that clear? It is obviously something that nobody would ever design to work that way if they sat down and thought about it. That IS a bug.

Unless the devs say they designed it to work differently than it does, it doesn't fit the definition of a bug. It's just counter-intuitive design.

A software bug is an error, flaw, failure or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways.

I think the developers have just not understood the problem.

Simple change: Do not play the warning sound if the UI alert will time out before the sound finishes playing.

Edit: Nevermind. It's probably something different that people are experiencing and reporting.

Arguably it is a bug, if you click the alert you will see it gnawing on your wall.

...

I'll show myself out.

Deadly-Bagel wrote:Arguably it is a bug, if you click the alert you will see it gnawing on your wall.

...

I'll show myself out.

Have you ever taken a closer look? They're shrimp, not bugs!

See attached save. Due to the minimum time between audio alarms, the second turret death causes alerts to last just long enough to cause a "delayed" alarm sound. Definitely not a bug as Rseding said, but my vote would be for the alarm sound to be skipped if the visible alert will fade within around 240 ticks.

Audible alarms are good, but more harmful than helpful when delayed this long.