Per uploaded file frustration.diff (3.0 KiB)

Zarel commented

Zarel likes this very much.

But UINT8_MAX is a bit high for frustration. I'm thinking more like 32?

Per uploaded file frustration2.diff (3.0 KiB)

Per changed status from new to closed

Per set resolution to fixed

Per commented

(In [8765]) Add a new droid variable frustration that is set each time it gets stuck. For a time after,
the droid will fire on any destructible features nearby if there is nothing else to fire at.
This might clear the way in some cases. This closes #1165

bugreports@... commented

I've got input that may be related to this, but don't know what's the correct place to post it:

1. I often get droids trapped between buildings or buildings and terrain. For example, building 4 turrets in a 2x2 matrix can leave a droid trapped in the middle, or building a couple turrets that are parallel with the hills can leave a droid trapped between the hills and turrets.

I've noticed that there is some code which, when they're stuck for a while, makes them kind of "slide" between the structures and manage to free themselves. This happens after some variable amount of time, but in the large majority of cases, that time is way too long. If it is a tunable parameter, it'd be useful to shorten it to something like 50% or 60% the current time.

2. I've noticed that in Svn-HEAD, something is changed in the way how units start movement when they receive an order to move somewhere. They always seem to start by going forward and left, and then actually decide where they want/need to go. This behavior is most noticeable with trucks, and they often make unusually large left turns when they start movement, even if they really need to go in a completely other direction, or are already aligned at the right path.
   (As said, it happens with all units, but most noticeable with trucks. I.e, you can order trucks
   to go somewhere-- when they take on the correct path and start moving in a line to final destination, click the same location again. They are already aligned on it and should just
   continue moving straight forward, but instead, they go into the whole left-turn thing...)

This was not happening in 2.2.2. I think the change is for the worse, because they waste time, are not as flexible as they were before, and they often get stuck when multiple units are ordered to move and need to maneuver in limited space...

Per commented

(In [8766]) 2.3: Add a new droid variable frustration that is set each time it gets stuck. For a time after,
the droid will fire on any destructible features nearby if there is nothing else to fire at.
This might clear the way in some cases. This closes #1165

Per commented

We are aware that droids getting stuck is still a problem, and getting worse since some time in the past, but not sure why. There are other open bug reports on that, so if you have more information on it, please add it there. See #1076 and #305