View Issue Details

IDProjectCategoryLast Update
0001533AI War 1 / ClassicBug - OtherJan 7, 2011 4:48 pm
ReporterToll Assigned Tokeith.lamothe  
Status resolvedResolutionfixed 
Product Version4.038 
Summary0001533: AI targetting seems to be wonky
DescriptionI 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).
TagsNo tags attached.
Internal Weight

Relationships

related to 0001158 resolvedChris_McElligottPark Make spec. forces ships act more as if on FRD. 

Activities

Chris_McElligottPark

Dec 2, 2010 9:24 pm

administrator   ~0004957

I'll be curious if you still see this in 4.043...

Toll

Dec 2, 2010 9:26 pm

reporter   ~0004958

I'll make sure to double-check it when the patch is released. Got a rough ETA?

Chris_McElligottPark

Dec 2, 2010 9:31 pm

administrator   ~0004961

Within the next hour or so, I'm just finishing up some last things. Thanks!

Toll

Dec 2, 2010 10:44 pm

reporter   ~0004989

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.

Chris_McElligottPark

Dec 2, 2010 10:46 pm

administrator   ~0004991

Hmm, that part is interesting indeed.

Toll

Dec 2, 2010 10:48 pm

reporter   ~0004993

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.

Toll

Dec 2, 2010 10:49 pm

reporter  

Targetting bug.sav (364,429 bytes)

Chris_McElligottPark

Jan 6, 2011 5:29 pm

administrator   ~0007611

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?

keith.lamothe

Jan 7, 2011 3:03 pm

administrator   ~0007740

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?

Toll

Jan 7, 2011 3:06 pm

reporter   ~0007741

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

keith.lamothe

Jan 7, 2011 3:09 pm

administrator   ~0007742

I was asking Chris, but yes, I agree with what you said from a tactical perspective.

Implementation-wise it's more complex.

keith.lamothe

Jan 7, 2011 3:11 pm

administrator   ~0007744

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.

Chris_McElligottPark

Jan 7, 2011 3:23 pm

administrator   ~0007746

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.

keith.lamothe

Jan 7, 2011 3:28 pm

administrator   ~0007747

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.

Chris_McElligottPark

Jan 7, 2011 3:37 pm

administrator   ~0007748

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.

keith.lamothe

Jan 7, 2011 3:43 pm

administrator   ~0007751

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.

Chris_McElligottPark

Jan 7, 2011 3:57 pm

administrator   ~0007752

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!

Chris_McElligottPark

Jan 7, 2011 4:03 pm

administrator   ~0007753

Also, for clarity, AttackMovePoint will become FocalPoint. Since it's now used for Attack-Move, FRD, and now Waiting, too.

keith.lamothe

Jan 7, 2011 4:44 pm

administrator   ~0007761

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.

Toll

Jan 7, 2011 4:47 pm

reporter   ~0007763

Awesome :) Wish I could've seen the raptor-blob...

Chris_McElligottPark

Jan 7, 2011 4:48 pm

administrator   ~0007764

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

keith.lamothe

Jan 7, 2011 4:48 pm

administrator   ~0007765

Well, when 4.063 is out you can, using the save you attached to this report :)

Issue History

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