View Issue Details
| ID | Project | Category | Date Submitted | Last Update | |
|---|---|---|---|---|---|
| 0010001 | AI War 1 / Classic | Bug - Gameplay | Dec 10, 2012 7:33 pm | Dec 11, 2012 4:19 pm | |
| Reporter | lordrahl | Assigned To | keith.lamothe | ||
| Status | considering | Resolution | open | ||
| Product Version | 6.009 | ||||
| Summary | 0010001: Not all ships from waves/exogalactic strikeforces/CPA's attack and they end up pooling on one planet | ||||
| Description | The description and screenshots are in this thread: http://steamcommunity.com/app/40400/discussions/0/846939071269986619/ I have attached one of the save files in which this behavior occurs. | ||||
| Tags | No tags attached. | ||||
| Internal Weight | |||||
|
|
|
|
|
I posted this in the steam thread you linked but including this here too: Thanks for posting the save :) Looking at it, the behavior appears to be working as designed: the threatfleet isn't camping your wormholes, it's hanging back a few hops like it's supposed to, looking for an opening to attack you. There are only 2 planets of yours it can hit, and both have absolutely absurd defensive power. Therefore it concludes that attacking would not be prudent ;) In other words: you're chokepointing it, and it's responding by (in a more mobile sense) chokepointing you. If you bring a fleet out that it thinks it can take, it will go after that fleet. If you uncover either chokepoint enough for it to think it can win, it will go after that planet. If you're curious about the logic, you can turn on Advanced Logging (advanced tab of settings window) and check the LogicLog_AIMechanic_ThreatFleet.txt file in AIW's RuntimeData directory. Here's an entry from when I ran your save: 12/11/2012 10:43:39 AM (6.009) ----------------------------------- Doing Threat Fleet Logic regular check; Game Time: 12:51:45 Fleet power check: totalExistingThreatFleetFirepowerNotOnTarget:0 totalExistingThreatFleetFirepowerOnTarget:18401722 humanFirepowerMustBeThisHighToCountAsBlockingPlanet:1840172 humanFirepowerMustBeThisLowToBeAttackable:9200861 lowestSpeedAnywhere:36 typeCausingLowestSpeedAnywhere:DreadnoughtII lowestSpeedOffTarget:0 typeCausingLowestSpeedOffTarget:None Rejecting low-firepower-without-human-command-station planet Leatoothqa, math breakdown: planet.HumanMilitaryFirepowerSim:15 humanFirepowerMustBeThisHighToCountAsBlockingPlanet:1840172 Rejecting excessive human-firepower planet Lenowdu, math breakdown: planet.HumanMilitaryFirepowerSim:65563132 humanFirepowerMustBeThisHighToCountAsBlockingPlanet:1840172 ( ( planet.AttackingShipsFirepowerSim + planet.ThreatShipsFirepowerSim ) / 2 ):0 humanFirepowerMustBeThisLowToBeAttackable:9200861 Rejecting excessive human-firepower planet Neilikci, math breakdown: planet.HumanMilitaryFirepowerSim:48382826 humanFirepowerMustBeThisHighToCountAsBlockingPlanet:1840172 ( ( planet.AttackingShipsFirepowerSim + planet.ThreatShipsFirepowerSim ) / 2 ):0 humanFirepowerMustBeThisLowToBeAttackable:9200861 No accessible eligible targets, so rallying in AI space on planet Maskillau Just to see what would happen, I altered my dev copy to make it always willing to attack the lesser of your two chokepoints; shortly after loading it generated this entry: 12/11/2012 10:49:54 AM (6.009) ----------------------------------- Doing Threat Fleet Logic regular check; Game Time: 12:49:39 Fleet power check: totalExistingThreatFleetFirepowerNotOnTarget:205521 totalExistingThreatFleetFirepowerOnTarget:18196201 humanFirepowerMustBeThisHighToCountAsBlockingPlanet:1840172 humanFirepowerMustBeThisLowToBeAttackable:55563132 lowestSpeedAnywhere:36 typeCausingLowestSpeedAnywhere:DreadnoughtII lowestSpeedOffTarget:42 typeCausingLowestSpeedOffTarget:AICarrierIII Rejecting low-firepower-without-human-command-station planet Leatoothqa, math breakdown: planet.HumanMilitaryFirepowerSim:15 humanFirepowerMustBeThisHighToCountAsBlockingPlanet:1840172 Rejecting excessive human-firepower planet Lenowdu, math breakdown: planet.HumanMilitaryFirepowerSim:58619132 humanFirepowerMustBeThisHighToCountAsBlockingPlanet:1840172 ( ( planet.AttackingShipsFirepowerSim + planet.ThreatShipsFirepowerSim ) / 2 ):0 humanFirepowerMustBeThisLowToBeAttackable:55563132 Accepting significant-but-not-excessive human-firepower planet Neilikci, math breakdown: planet.HumanMilitaryFirepowerSim:48382826 humanFirepowerMustBeThisHighToCountAsBlockingPlanet:1840172 ( ( planet.AttackingShipsFirepowerSim + planet.ThreatShipsFirepowerSim ) / 2 ):0 humanFirepowerMustBeThisLowToBeAttackable:55563132 Selecting random accessible target Neilikci And proceeded to path around the outer ring, so it could come in on your northern chokepoint. They waited until the bulk were at the wormhole and then went through. The main battle lasted about 5 minutes of game-time (considerably longer in real-time on my low/medium-end laptop) and your defenses got the threatfleet down to about 10k before they were broken in that system. I didn't do anything to control or optimize your defenses; I think the fight could have been won if your mobile assets from the other chokepoint were brought in. Then I ran the test again with the auto-target-carriers setting on, but no other control by me. This time the battle lasted about 2.5 minutes of game time and took the threatfleet down to about 4.5k ships and no carriers, but 2k of it was mkV guardians from the carrier-early-pop combination, and was probably more dangerous than the alternative. Controlling the fight and selectively killing carriers to cut down on their firepower contribution would have been a good thing, as well as focusing the lightning guardians, etc. Overall, I think it was a winnable fight for the humans if they tried, and thus the threatfleet logic was correct in not committing to that attack. That said, it was a lot closer than the numbers reflected so I'll probably put in a change for the next beta release to have it count carriers (which includes their contents) more heavily to reflect how dangerous they are, and thus be more likely to attack once it's built up a lot of carriers like that :) Anyway, for your situation in this game I would recommend baiting the threatfleet to attack one of your chokepoints by pulling your mobile forces out (your stationary chokepoint may have enough non-mobile stuff to make it not work for this), and when they come in to attack bring your mobile forces back in (via some way that lets you engage from a distance) to nail them. They'll probably retreat before you can defeat them in detail but it'll take a chunk out of them. More generally: if you play 8 Homeworld (or whatever it was) on the Fallen Spire campaign you can expect these kinds of numbers even on ultra-low, unless you're careful to nip threatfleet buildup before it gets to this level. If you don't want 20k threatfleet, pick fewer homeworlds or don't chokepoint so heavily on your very border. For instance, you could capture and moderately defend the approaches to your main defenses, and the threatfleet would happily go back and forth with you over those worlds. Goodness, that was a lot of beams... ;) |
|
|
So, currently, the AI was not fully considering what is inside carriers? That would actually explain quite a bit. Such as cases where the AI clearly could take on something, but runs away. Because it is only considering the "loose" ships and the carriers themselves, and ignoring the stuff in the carriers, so it thinks it has less than it really does. EDIT: It still doesn't explain why sometimes a "held-up" fleet would refuse to attack even though they had enough, but then all of a sudden be willing to upon a save-load cycle. |
|
|
"So, currently, the AI was not fully considering what is inside carriers?" No, it counts them just as if they were outside. I said I would probably change it to count that more heavily. |
|
|
Ah, because you have to first strip the carrier, and then you get the ships. Also, the fact that carriers have immunities that the inside ships probably don't have (tractor beam, FF for movement, etc), and the implications for popping them early mean that loaded carriers tend to be more dangerous than just the "sum of their parts". That seems to make sense. Still not sure why the AI seems to "run" or "hesitate" too early though. If I can get saves with either of these behaviors, I'll upload them on a new ticket, and probably make a post in the originating forum thread as well. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| Dec 10, 2012 7:33 pm | lordrahl | New Issue | |
| Dec 10, 2012 7:33 pm | lordrahl | File Added: Circles 1.sav | |
| Dec 11, 2012 12:18 pm | keith.lamothe | Note Added: 0029110 | |
| Dec 11, 2012 12:18 pm | keith.lamothe | Assigned To | => keith.lamothe |
| Dec 11, 2012 12:18 pm | keith.lamothe | Status | new => considering |
| Dec 11, 2012 12:23 pm | TechSY730 | Note Added: 0029111 | |
| Dec 11, 2012 12:24 pm | TechSY730 | Note Edited: 0029111 | |
| Dec 11, 2012 3:16 pm | keith.lamothe | Note Added: 0029112 | |
| Dec 11, 2012 4:19 pm | TechSY730 | Note Added: 0029113 |
