View Issue Details
| ID | Project | Category | Date Submitted | Last Update | |
|---|---|---|---|---|---|
| 0021903 | AI War 2 | Bug - Gameplay | Oct 24, 2019 11:58 am | Sep 22, 2020 5:19 pm | |
| Reporter | OzoneGrif | Assigned To | keith.lamothe | ||
| Severity | minor | ||||
| Status | resolved | Resolution | fixed | ||
| Product Version | 1.001 Official Game Launch! | ||||
| Summary | 0021903: Melee ships (ie. Gangsaw) won't ram naturally into enemy ships unless in pursuit mode | ||||
| Description | This is an issue with the melee ships, if you don't set them in pursuit mode, they will remain mostly passive during the battles. The only way to use them correctly is to put all the melee ships in one dedicated fleet, then set it to pursuit mode. They should go for the kill naturally, as soon as the enemy gets "close enough". The issue here is to define what "close enough" means. Some melee ships are meant to be quickly destroyed and rebuilt (ie. the missiles), these almost always benefit from attacking the whole planet (infinite range). Others would require a shorter range. | ||||
| Tags | No tags attached. | ||||
| related to | 0023219 | resolved | keith.lamothe | Melee ships on attack-move mode don't behave differently than when moving/attacking without any modes |
|
|
Maybe in target list planning, ships with a melee targeting modifier automatically check a specific distance? That would make the distance hard coded for every melee ship, but it's very easy to implement. |
|
|
Classic gave melee ships like Cutlasses a "Target Seek Range". Seems to be similar to your idea. |
|
|
Got a save game that easily reproduces the problem? |
|
|
save game, melee ships are not attacking for fleet 1, yet they are very close to the guard post and its ships |
|
|
Badger, your new "attack mode" sounds particularly applicable for melee units -- looking forward to testing this |
|
|
For 2.117: * Melee units in attack-move mode will now go after units within a limited range (equivalent to a weapon with range=Normal1), so you have a middle-ground between "only attack your direct target or things actually touching you" and "pursue anything on the planet". This doesn't solve the problem for melee units not in any particular mode; I also implemented a "always put player melee units in attack-move mode unless in pursuit or hold-fire" rule but wound up backing that out as it seemed to conflict with things like normal move orders (the gangsaws would refuse to comply, and instead kept eating whatever they had caught, etc). So I'm sure we're not done here, but I'd like feedback on what the next steps should be after you have a chance to see the seek-range in action. |
|
|
Went ahead with a further refinement, after all: * Also, even when not in attack-move mode, player melee units without orders (and not in hold-fire mode) now automatically move to attack nearby targets. If all such targets die or move away, the melee unit goes back to where it was. I was skeptical, thinking it would lead to annoying edge cases where it seemed to resist player commands, etc, but it actually works really smoothly in my testing. I'm confident it will break horribly once released into the wild ;) |
|
|
How does this feel in 2.117? |
|
|
I reopen the issue after testing: it's not working as described. Issue 0000001: Meele Ships return to original position - Create a new game with the Consumer Fleet - Wait for the fleet to construct a few ships - Press [1] to select the fleet and its ships - Click anywhere in the map == The fleet and ships moves to the point clicked, then all the melee ships return to the original spot You can also try with just one ship, it will have the same issue.x This issue disappears after using [Attack Mode], but I have the feeling that's because it breaks the system. If you destroy one ship to rebuild it, the new ship will have the issue again. Issue 0000002: Meele ships are not attacking unless in [Attack Mode] - You said they should attack and return to their position when not in attack mode, they don't attack at all, and won't return to their original position. When in [Attack Mode] everything works fine and feels right. |
|
|
Please open a new issue, rather than reopening this one. When there are multiple problems that are tracked by the same bug report it's much harder to work |
|
|
Sorry, I didn't see the followup messages here; I thought clicking 'monitor' would tell me about them. I've changed my settings to hopefully fix that. For 2.509: * Fixed some issues with the new-ish melee unit behavior of flying out to attack nearby enemies when otherwise idle: ** Fixed a bug where a melee unit would go back to its prior location after a direct order from the player (like a normal move order). ** Fixed a bug where a melee unit's memory of where to go back to after no targets were in range would persist across wormhole jumps (causing it to try to go to that location on the new planet, which doesn't make sense). ** Fixed a bug where melee units wouldn't use their implicit attack-move behavior if their internal behavior flag had been changed away from default and then back. So new melee units would use the behavior, but ones that had been around for a while often would not. I can't get them to significantly misbehave anymore. I'm confident someone else can succeed where I failed ;) |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| Oct 24, 2019 11:58 am | OzoneGrif | New Issue | |
| Oct 24, 2019 11:58 am | OzoneGrif | Description Updated | |
| Oct 24, 2019 12:31 pm | wm46 | Note Added: 0053924 | |
| Oct 24, 2019 1:04 pm | RocketAssistedPuffin | Note Added: 0053926 | |
| Oct 25, 2019 12:56 am | BadgerBadger | Note Added: 0053941 | |
| Oct 25, 2019 12:06 pm | OzoneGrif | File Added: meleebug.zip | |
| Oct 25, 2019 12:06 pm | OzoneGrif | Note Added: 0053960 | |
| Oct 25, 2019 1:30 pm | ZeusAlmighty | Note Added: 0053965 | |
| May 27, 2020 7:31 am | Ubifan | Relationship added | related to 0023219 |
| Aug 10, 2020 11:44 am | keith.lamothe | Note Added: 0058027 | |
| Aug 10, 2020 11:45 am | keith.lamothe | Note Edited: 0058027 | |
| Aug 11, 2020 9:41 am | keith.lamothe | Note Added: 0058040 | |
| Aug 11, 2020 9:42 am | keith.lamothe | Assigned To | => keith.lamothe |
| Aug 11, 2020 9:42 am | keith.lamothe | Status | new => resolved |
| Aug 11, 2020 9:42 am | keith.lamothe | Resolution | open => fixed |
| Aug 13, 2020 9:14 am | keith.lamothe | Note Added: 0058062 | |
| Aug 30, 2020 3:04 am | OzoneGrif | Status | resolved => feedback |
| Aug 30, 2020 3:04 am | OzoneGrif | Resolution | fixed => reopened |
| Aug 30, 2020 3:04 am | OzoneGrif | Note Added: 0058285 | |
| Aug 30, 2020 12:29 pm | BadgerBadger | Note Added: 0058290 | |
| Aug 30, 2020 12:29 pm | BadgerBadger | Status | feedback => resolved |
| Aug 30, 2020 12:29 pm | BadgerBadger | Resolution | reopened => fixed |
| Aug 30, 2020 12:29 pm | BadgerBadger | Note Edited: 0058290 | |
| Sep 22, 2020 5:19 pm | keith.lamothe | Note Added: 0058623 |
