View Issue Details
| ID | Project | Category | Date Submitted | Last Update | |
|---|---|---|---|---|---|
| 0001533 | AI War 1 / Classic | Bug - Other | Nov 22, 2010 8:55 am | Jan 7, 2011 4:48 pm | |
| Reporter | Toll | Assigned To | keith.lamothe | ||
| Severity | minor | ||||
| Status | resolved | Resolution | fixed | ||
| Product Version | 4.038 | ||||
| Summary | 0001533: AI targetting seems to be wonky | ||||
| Description | I just built a nest of snipers on a planet under AI control. The AI never sent ships to target the snipers at all, but let them all just sit there and get shot at. This seems a bit silly to me (and is likely related to 0001158). | ||||
| Tags | No tags attached. | ||||
| Internal Weight | |||||
| related to | 0001158 | resolved | Chris_McElligottPark | Make spec. forces ships act more as if on FRD. |
|
|
I'll be curious if you still see this in 4.043... |
|
|
I'll make sure to double-check it when the patch is released. Got a rough ETA? |
|
|
Within the next hour or so, I'm just finishing up some last things. Thanks! |
|
|
I don't have enough Spec. forces running through a nearby planet, so I can't test with those, but when I ran a couple of spire ships onto a planet to free all those ships and then retreated with the spire ships, the newly-freed ships still didn't target my science lab. Ditto on my sniper nest. |
|
|
Hmm, that part is interesting indeed. |
|
|
Uploading a save, in case you can get something fun out of that one. My sniper nest is on Piasi and the science lab is on Geoku. |
|
|
|
|
|
Keith, there's only so much time for something like this, and I suspect it might already be fixed with so many of the recent changes, but can you look at this? If something gets shot by a sniper, it should alert it and everything else at its guard post just like any other time ships are shot, right? |
|
|
Thanks for the save :) Chris, here's what I saw: 1) On the AI planet with the human mkIII science lab, the AI ships would spawn correctly (in a roughly AI-eye/deepstrike-response way) and be free, and would get an attack order to kill the science lab, but would within a few seconds change to having a wormhole order to go to the adjacent human planet (human homeworld, actually), and due to the firepower rules would stack up on the wormhole on the AI's side and just wait. 2) On the AI planet with the human sniper-turret nest that was _just_ inside buildable range, I put the sniper-turrets in low power to actually let some AI reinforcements live long enough to observe. The AI reinforcements spawned and went into low-power like normal, so I brought a few sniper-turrets out of low power and shot one of the command station's guard ships. They all popped out of low-power and made towards the sniper-turret nest but shortly thereafter redirected to the wormhole leading to the adjacent human world (same one, actually), and just sat there waiting. What do you want changed? |
|
|
If you're asking me, it sounds prudent if the ships actually kill all enemies on their planet before trying to go to another planet to wreak havoc. Especially if they're just going to sit on the wormhole and wait... |
|
|
I was asking Chris, but yes, I agree with what you said from a tactical perspective. Implementation-wise it's more complex. |
|
|
There's also tactical issues like "we don't stand a chance against that attack fleet, let's go try to hurt the humans before we die" which they basically do if you roll in with a spire capital fleet or similar. |
|
|
That's a toughie, yeah. I think the problem there is that the AI is basically ignoring player ships on that planet if they are below a certain threshold -- which, in larger combat situations, is by design. The AI ignores the stragglers so that it can more effectively crush the human opposition elsewhere. Otherwise you wind up being able to lead the AI on a merry chase while the player is able to bolster defenses. The two cases that I think need to be accounted for are when the player has fixed-position ships on an AI planet, or when there are saboteur-type units of any kind there (which right now is always immobile, anyway). I just put in a quick change to AITactics.cs that might fix that -- can you check? If not, that will need some more hunting, but my change should help on this, anyway -- most likely the AI was deciding that the human presence was too insignificant to consider as even being present, previously. |
|
|
Sure, will take a look in a moment, thanks :) In the science-lab case it was definitely a very minor presence. In the sniper-nest case it was a pretty sizeable turret ball, like 400 total I think. |
|
|
Hmmm... I may have fixed the first case (at best) but not affected the second, then. For the second one... I'm not sure what's going on there. It might be an edge case that is not specifically fixable, if the turrets are that powerful and the AI is rightly deciding to flee, but then runs into another planet on the other side that is even more powerful, it winds up just waiting, etc. One fix to that would be that... well, hold on, I've got something to try. |
|
|
I should add that in playing other games I've seen "if there's a ton of enemy firepower on my planet, don't wait at the wormhole because of lots of enemy firepower on the other side" logic working just fine. In this case it may be that the turret-ball firepower pales in comparison to the fortresses and spire stuff on the other side, so that's not kicking in. Honestly, when the AI just has a handful of ships on the planet with the turret ball and there's a massive human presence on the neighboring human planet, there's nothing the AI can really do with those ships. If anything, the tactically wise thing to do is just retreat those ships somewhere else, but I'm not sure how much we want to get into that. |
|
|
I've got an awesome thing I'm working on at the moment: getting rid of WaitPoint. Instead, just having the IsWaitingAtAttackMovePoint. Then that should override their actually going through the wormhole, while they will be working in FRD mode in the meantime, returning to the AttackMovePoint whenever not doing something more important. The best of all possible solutions for the moment, I think! |
|
|
Also, for clarity, AttackMovePoint will become FocalPoint. Since it's now used for Attack-Move, FRD, and now Waiting, too. |
|
|
Ok, just retested with your recent changes, and 1) On the science-lab-III planet the AI ships (both the newly spawned ones and the ones already hanging out by the wormhole) dutifully dogpiled it to death. 2) On the turret-ball planet nothing seemed to be happening, since there weren't any AI ships left. Then a _massive_ blob of AI raptors decloaked right by them and did their level best to take out those turrets. They failed miserably, but it looked cool :) I'd say that we're done with this one. |
|
|
Awesome :) Wish I could've seen the raptor-blob... |
|
|
Yeah -- awesome stuff! Though, I'm actually making a few more changes that are not checked in yet, and that's solving this even better. I've tested too, with the same results you're getting. :) |
|
|
Well, when 4.063 is out you can, using the save you attached to this report :) |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| Nov 22, 2010 8:55 am | Toll | New Issue | |
| Nov 22, 2010 8:55 am | Toll | Relationship added | related to 0001158 |
| Dec 2, 2010 9:24 pm | Chris_McElligottPark | Note Added: 0004957 | |
| Dec 2, 2010 9:24 pm | Chris_McElligottPark | Assigned To | => Chris_McElligottPark |
| Dec 2, 2010 9:24 pm | Chris_McElligottPark | Status | new => feedback |
| Dec 2, 2010 9:26 pm | Toll | Note Added: 0004958 | |
| Dec 2, 2010 9:26 pm | Toll | Status | feedback => assigned |
| Dec 2, 2010 9:31 pm | Chris_McElligottPark | Note Added: 0004961 | |
| Dec 2, 2010 10:44 pm | Toll | Note Added: 0004989 | |
| Dec 2, 2010 10:46 pm | Chris_McElligottPark | Note Added: 0004991 | |
| Dec 2, 2010 10:48 pm | Toll | Note Added: 0004993 | |
| Dec 2, 2010 10:49 pm | Toll | File Added: Targetting bug.sav | |
| Jan 6, 2011 5:29 pm | Chris_McElligottPark | Note Added: 0007611 | |
| Jan 6, 2011 5:29 pm | Chris_McElligottPark | Assigned To | Chris_McElligottPark => keith.lamothe |
| Jan 6, 2011 5:29 pm | Chris_McElligottPark | Status | assigned => acknowledged |
| Jan 7, 2011 3:03 pm | keith.lamothe | Note Added: 0007740 | |
| Jan 7, 2011 3:06 pm | Toll | Note Added: 0007741 | |
| Jan 7, 2011 3:09 pm | keith.lamothe | Note Added: 0007742 | |
| Jan 7, 2011 3:11 pm | keith.lamothe | Note Added: 0007744 | |
| Jan 7, 2011 3:23 pm | Chris_McElligottPark | Note Added: 0007746 | |
| Jan 7, 2011 3:28 pm | keith.lamothe | Note Added: 0007747 | |
| Jan 7, 2011 3:37 pm | Chris_McElligottPark | Note Added: 0007748 | |
| Jan 7, 2011 3:43 pm | keith.lamothe | Note Added: 0007751 | |
| Jan 7, 2011 3:57 pm | Chris_McElligottPark | Note Added: 0007752 | |
| Jan 7, 2011 4:03 pm | Chris_McElligottPark | Note Added: 0007753 | |
| Jan 7, 2011 4:44 pm | keith.lamothe | Note Added: 0007761 | |
| Jan 7, 2011 4:44 pm | keith.lamothe | Status | acknowledged => resolved |
| Jan 7, 2011 4:44 pm | keith.lamothe | Resolution | open => fixed |
| Jan 7, 2011 4:47 pm | Toll | Note Added: 0007763 | |
| Jan 7, 2011 4:48 pm | Chris_McElligottPark | Note Added: 0007764 | |
| Jan 7, 2011 4:48 pm | keith.lamothe | Note Added: 0007765 |
