[Oxyd] [0.17.56] Biter groups get stuck on cliffs and go idle

[Muppet9010]

This save is from a biter battles (Mewmew) tonight. If you look north there are many groups of biters that were sent by the scenario at the north's silo, but got "stuck". The biters were formed in to an attack group at near their spawners and then given an attack move command at the silo I believe.
Oddly south side doesn't seem to have suffered the same issue, despite the map being mirrored. However, biter group forming and attacking isn't uniformly ordered. So maybe a lot of biter groups tried to form at once to start this issue.

Load the save, join a team via the GUI and then you can /editor.

biter battle oddness.zip

(23.32 MiB) Downloaded 95 times

[thymey]

Here is a VOD of the issue - Threat Level just steadily rises as biters get stuck https://www.twitch.tv/videos/451865757?t=02h44m40s

[Oxyd]

There are about 900 pathfinding requests currently going on in that save. I can see one attack group with 700 members, most of which are still trying to reach the group, making up a large portion of the pathfinding requests.

In other words, this is ridiculous. You need to contact the scenario author and ask them to readjust their expectations on what a reasonable number of pathing biters is at any given time.

Not a bug.

[Gerkiz]

There are about 900 pathfinding requests currently going on in that save. I can see one attack group with 700 members, most of which are still trying to reach the group, making up a large portion of the pathfinding requests.

In other words, this is ridiculous. You need to contact the scenario author and ask them to readjust their expectations on what a reasonable number of pathing biters is at any given time.

Not a bug.

Hi Oxyd,
How is this not a bug? There isn't anything written in the API that would suggest that there is a limit on how many members a group can have.
What we also tend to see is that the members in groups that are aligned (in formation) are completely frozen. I would rather see that the group that is formed (exempting those that haven't reached the group) to go to their destination. Is this something that is doable?

Thanks.

[Oxyd]

There are about 900 pathfinding requests currently going on in that save. I can see one attack group with 700 members, most of which are still trying to reach the group, making up a large portion of the pathfinding requests.

In other words, this is ridiculous. You need to contact the scenario author and ask them to readjust their expectations on what a reasonable number of pathing biters is at any given time.

Not a bug.

Hi Oxyd,
How is this not a bug? There isn't anything written in the API that would suggest that there is a limit on how many members a group can have.
What we also tend to see is that the members in groups that are aligned (in formation) are completely frozen. I would rather see that the group that is formed (exempting those that haven't reached the group) to go to their destination. Is this something that is doable?

Thanks.

There isn't a limit, but the more pathfinding units you have at any given time, the longer it will take for them to get a path. The biters you are seeing aren't frozen, they are waiting for a path. If you wait long enough, they'll get moving. The groups themselves are also waiting for a path – and they, too, will get moving once they receive a path.

[BlueTemplar]

I was wondering, Ashes of the Singularity seems(?) to have managed to parallelize its AI (including pathfinding??) :
A long rambling series on Ashes of the Singularity
(Scroll down to "Something new" - that "META unit" sounds a lot like Biter groups though?)
Why threading matters for Ashes of the Singularity
What is the state of pathfinding parallelization for Factorio?

[Oxyd]

I was wondering, Ashes of the Singularity seems(?) to have managed to parallelize its AI (including pathfinding??) :
A long rambling series on Ashes of the Singularity
(Scroll down to "Something new" - that "META unit" sounds a lot like Biter groups though?)
Why threading matters for Ashes of the Singularity
What is the state of pathfinding parallelization for Factorio?

That META unit thing does sound roughly like our unit groups. Although they seem to be more concerned with how commanding units works for the player and not requiring them to give an order to each individual unit.

Parallelising anything gamestate-related in Factorio is difficult because of our multiplayer design which requires the game to be deterministic.

[BlueTemplar]

But surely this is the case for the gameplay portion of all(?) RTS games? (Considering how they all(?) seem to be plagued by desync issues from time to time...)

[Oxyd]

But surely this is the case for the gameplay portion of all(?) RTS games? (Considering how they all(?) seem to be plagued by desync issues from time to time...)

So how do they solve it?

[BlueTemplar]

I guess that they... don't ?
Well, StarCraft 2 for instance has a very specific way in how it clumps groups of units together when moving (but that's probably still single-threaded) (I wonder if this is what Rampant uses?),
while there are hints that AotS might have done something about the parallelization... but I don't have much more information than what I already gave here, sorry...

[Oxyd]

I guess that they... don't ?

And neither do we.

while there are hints that AotS might have done something about the parallelization... but I don't have much more information than what I already gave here, sorry...

Yeah, that blog post you linked doesn't go into much detail at all.

[jackazzm]

But have you seen They are billion? imagine BILLIONS of biters

[Oxyd]

But have you seen They are billion? imagine BILLIONS of biters

They Are Billions doesn't have multiplayer. And it doesn't have to simulate an entire factory in addition to simulating units.

So yes, imagine billions of biters – but also imagine no belts, no inserters, no assemblers, no trains, no bots, and no multiplayer.

[Muppet9010]

this bug does see to have gone a bit off track. It was meant to highlight how the biters are prone to getting stuck on cliffs and likely other indestructible path blocking elements. And then they seemed to just give up after a while.
If this is "accepted/expected" behaviour from the current mechanics then so be it. Seems an odd place for people to be suggesting possible alternative mechanics.

[BlueTemplar]

Well, if this limitation is in place, it's because of CPU cost issues, isn't it ?

----

Hmm, here's a post where Brad Wardell goes into slightly more details about it :
https://steamcommunity.com/app/228880/d ... 5899353802

And Steam is getting worse, I can't neither post, not even edit my old post because that requires Steam ownership of the game !
Anyway, here's the link to the archived post on the old Steam forums that I linked to in my subsequent post, about how threads are used in SupCom1, that is dead now :
https://web.archive.org/web/20170524181 ... stcount=10

Or this retrospective:
https://www.ign.com/articles/2016/04/06 ... ration-rts
Yeah, information about pathfinding is still scarce in these, and I still don't understand why Brad is insisting that SupCom1 is a single-threaded game ??

[BlueTemplar]

Huh, and Stardock released a new game, seemingly based on AotS tech :

(click for video)

Though, yeah, there's probably a good reason why the player doesn't seem to be allowed to place a building in the enemy path...