Warzone2100 / old-trac-import

Archived Import of (old) Warzone 2100 Trac
0 stars 0 forks source link

Implement AI droid frustration #1165

Closed wzdev-ci closed 14 years ago

wzdev-ci commented 14 years ago

keyword_movement_ai resolution_fixed type_patch (an actual patch, not a request for one) | by Per


When AI droids get stuck, the presence of map features could be a contributing factor. This patch adds a new droid variable called 'frustration' that is set each time it gets stuck, and decremented each frame thereafter. When frustrated, the droid will fire on any destructible features nearby if there is nothing else to fire at. This might clear the way. Other ways to act out frustration may be added at a later time ;-)


Issue migrated from trac:1165 at 2022-04-15 20:11:30 -0700

wzdev-ci commented 14 years ago

Per uploaded file frustration.diff (3.0 KiB)

wzdev-ci commented 14 years ago

Zarel commented


Zarel likes this very much.

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

wzdev-ci commented 14 years ago

Per uploaded file frustration2.diff (3.0 KiB)

wzdev-ci commented 14 years ago

Per changed status from new to closed

wzdev-ci commented 14 years ago

Per set resolution to fixed

wzdev-ci commented 14 years ago

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

wzdev-ci commented 14 years ago

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...

wzdev-ci commented 14 years ago

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

wzdev-ci commented 14 years ago

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