soldiers getting stuck

Bug #1395238 reported by king of nowhere on 2014-11-22
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Won't Fix

Bug Description

Playing on trident of fire, a map with narrow chokepoints were soldier can only fight one at a time, it happened that during a big battle the soldiers just stopped fighting and stood there. and, on a similar issue, that they stood there waiting for attackers even when there were no more of them.
First save, ccc, has the two sides stuck. notice how the blue and red soldiers are there and ready to fight, but they are just standing still.
ccc3 has the red soldiers standing there for no apparent reason.

Related branches

king of nowhere (lainluigi86) wrote :
king of nowhere (lainluigi86) wrote :

by the way, ignore all the messages of empty mines; i intentionally made mines in wrong places as a self challenge. that's not another bug.

king of nowhere (lainluigi86) wrote :

I found the reason of the block, and posted it in the forum a while ago. Sorry for not reposting it here too.
"After more games, I found out the reason of the bug: there is the point of the map where only one soldier at a time can pass. I attack an enemy on the other side of it. my soldiers reach the building, win the fight and set it to fire (too close to other buildings to conquer). I also send other soldiers to attack other buildings. Now, if the timing is wrong, the soldiers going back from the first attack and the ones going forward from the second attack will meet in the middle and no one can pass. enemy soldiers will rise to meet the attackers (second wave), but they cannot reach them because there is the first wave still in the way. they only increase the mess. this can only be solved by dismantling/destroying the source or the target of the attack. It's not a bug, it's a weakness of the game engine."

Nasenbaer (nasenbaer) wrote :

I guess the best would be to introduce some kind of traffic rule - leaving soldiers before returning soldiers or the like - meaning, if a returning soldier blocks the way of a leaving soldier, he unblocks the way

Changed in widelands:
status: New → Confirmed
importance: Undecided → High
milestone: none → build19-rc1
Janosch Peters (janosch-peters) wrote :

While working on a bugfix for Bug #1522290, I figured out a solution for this issue. It is, however, not really elegant: I changed attack_update so that attacking soldiers require an unblocked path to their target. If they cannot find one they return home.

This is only meant as a first suggestion. A better solution woulf be something like Nasenbaer suggested: The attacking soldiers should "step aside" to make space for returning soldiers.

I attached a patch which works for me. It prevents soldiers from getting stuck and solves the performance issue #1522290.

king of nowhere (lainluigi86) wrote :

it won't solve all issues. it is still possible that both players attack each others, at times different enough that their respective soldiers won't fight at the narrow point, and then soldiers of opposite sides coming back - either because wounded, or after burning down the enemy building - would find themselves stuck at the narrow point. In that case, all soldiers involved would be only trying to come back home.
But yes, that would be an extremely unlikely scenario. I doubt it's ever going to happen, both sides attacking each other at very accurate timing, so the proposed fix should work. If nothing else, it would prevent the most common scenario, that caused by a single player attacking

GunChleoc (gunchleoc) wrote :

How about making the soldiers move in a random direction when they get stuck, rather than return home?

Janosch Peters (janosch-peters) wrote :

My first solution is rubbish. Please ignore the patch. If I start an attack with +10 soldiers, only half of them make it to the enemy lines. The others return to their building before they even started an attack.

I am currently trying to implement GunChleocs idea of random movements to break up the deadlock.

king of nowhere (lainluigi86) wrote :

it is not necessarily rubbish. it would probably work with a timer telling the soldier to go back after a couple minutes it is stuck, not immediately. this would give all the soldiers the time to go through the bottleck in case of a large attack.

I made another attempt to fix this bug. The solution is not elegant, but very simple: When soldiers figure out that they are stuck, they just walk to their destination ignoring blocked nodes. I made this change in behaviour only to soldiers returning home, because for attacking soldiers its not easy to tell if they are stuck or just waiting very long to get to an enemy because there might be a lot of fighting going on before them.

It is a pragmatic solution for a bug which will for most players never occur. Only a few LoC are changed and the solution will always work.

A solution using a random walk would be preferable because the game logic isnt spoiled (soldiers walking through other soldiers). The drawback, however, would be that a random solution might not always work. It is not straightforward to implement and the code changes would certainly be bigger. I tried this approach but had diffculties with performance.

TiborB (tiborb95) wrote :

I have not looked at the code, but can you be more specific about "When soldiers figure out that they are stuck"?

GunChleoc (gunchleoc) wrote :

There is a pre-existing signal == "blocked" variable that he used.

I won't be able to look at this in detail without my development machine, so I can only really contribute to this in about a month or so. Having soldiers that walk home walk through other soldiers as a last resort is OK though - we could also have them try X random steps first, but that would also mean more code that can go wrong.

If soldiers cannot walk onto a node on their path because it is blocked by another soldier, the "blocked" signal is emitted. On the next call to attack_update the pathfinding is triggered and the soldier tries to walk along a new path. If the soliders is blocked on the new path as well, it either means he just had bad luck or the soldier is stuck.

In my patch I consider a soldier as stuck if the soldier is blocked X+1 times in a row. Where X is currently set to 10.

Do you guys agree that this patch is ready to be merged? If so I would start a merge request.

GunChleoc (gunchleoc) wrote :

I haven't had time to look at the code in detail yet (currently travelling), but your concept is good. Please create a branc with merge request :)

Changed in widelands:
assignee: nobody → Janosch Peters (janosch-peters)
SirVer (sirver) wrote :

Fixed in r7687.

Changed in widelands:
status: Confirmed → Fix Committed
GunChleoc (gunchleoc) on 2016-10-25
Changed in widelands:
status: Fix Committed → Fix Released
GunChleoc (gunchleoc) wrote :

Fixed in build19-rc1.

kaputtnik (franku) wrote :

Looks like this has regressed:

Changed in widelands:
status: Fix Released → Confirmed
Leighton Man (leightonman) wrote :

Savegame attached

GunChleoc (gunchleoc) on 2017-11-03
Changed in widelands:
milestone: build19-rc1 → build20-rc1
GunChleoc (gunchleoc) wrote :

The previous fix will print "soldier is stuck," and then force a move. When I tested this, the keyword didn't come up in the output. So, we're not getting to that code point right now.

Leighton Man (leightonman) wrote :

Here's another saved game where soldiers are stuck. In this one soldiers can be seen walking "through" others so that fix seems to work. Eventually, after a few minutes I get a console message "TrainingSite::drop_stalled_soldiers: Kicking somebody out."
"Forcing flag at (6, 17)"
And, a few seconds later, the situation is resolved.
Hope this helps

GunChleoc (gunchleoc) wrote :

Thanks! This confirms my analysis that the first fix is working and that we need a second fix.

Changed in widelands:
assignee: Janosch Peters (janosch-peters) → nobody
GunChleoc (gunchleoc) on 2018-04-19
tags: added: military
Changed in widelands:
milestone: build20-rc1 → build21-rc1
GunChleoc (gunchleoc) wrote :
Changed in widelands:
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.