View Issue Details
| ID | Project | Category | Date Submitted | Last Update | |
|---|---|---|---|---|---|
| 0002511 | AI War 1 / Classic | Bug - Other | Jan 17, 2011 2:41 pm | Jan 18, 2011 1:47 am | |
| Reporter | Varone | Assigned To | Chris_McElligottPark | ||
| Status | resolved | Resolution | fixed | ||
| Product Version | 4.069 | ||||
| Fixed in Version | 4.070 | ||||
| Summary | 0002511: Spawned wave doesn't move | ||||
| Description | A wave of neinzul ships spawned at a planet and the threat went to around 2000. However they don't move and obviously die in the end. Something isn't doing what it should be! Uploaded the save game for you to check. | ||||
| Tags | No tags attached. | ||||
| Internal Weight | |||||
| related to | 0002491 | resolved | Chris_McElligottPark | Special Forces ships not patrolling (and spontainous freeing of ships on load) |
|
|
|
|
|
Looking. Money's on a ff being involved :) |
|
|
Hmm, something is wrong with that save. None of the waves are moving, i played a bit longer and and the exo galaxy wave never moved and the second youngling wave never moved. Continuing with that save i've got 3000 threat and counting. |
|
|
Yea, something is pretty seriously wrong, that carrier and those younglings really should be moving, they're not under an ff or anything. I'm drilling into the AI logic, currently, having established that it wasn't sending any commands to that carrier. |
|
|
Are they waiting on a focal point? |
|
|
I found the issue that was stopping them, and emailed you (Chris) separately about it since it's pretty technical AI stuff. |
|
|
Ok -- thanks. But I don't see any emails. |
|
|
Fair enough, gmail's making fun of me then ;) Here's what I wrote: " I've been investigating this one and found something strange in that it seems that surely this would have been noticed earlier. Anyway, here goes: In the save attached to this report, there's a carrier with a bunch of youngling ships on one of the southern planets around one of the warp gates. They're entirely freed, etc, and show as frd. But they don't move at all. The only human presence is 3 scouts... Oh! I think I understand now. You know the change to make the AI more aware of cloaked ships? I think they're noticing the scouts. Anyway, I did a lot of debug.log stuff to confirm that the AI was not actually sending any commands for that carrier, and then drilled into WaitingTactics and then ShipCombatTactics on the AI thread to figure out what was going on. Turns out that in ShipCombatTactics it's always taking the branch marked with the comment "//if enemies have ships here", and that branch has no provision for sending the ships to any other planet, just gives attack orders against the human units it thinks are there. So it just sits there. I scrapped the 3 scouts and within seconds the nearby human planet was swarmed by the younglings. Anyway, I'll see if I can get it to ignore the scouts, but wanted to run this by you as it seems like a pretty big thing. " It's one of those tricky ones in general, actually; say the human has 100 raptors hiding out: if a wave is spawned on that planet (due to not having a neighboring warp gate and going to ??? instead) should it just hang around indefinitely because of the cloaked human ships? If not, then doesn't that bring it back to the complained-about situation where the AI would just ignore the major threat and go off to humanland? |
|
|
Okay -- awesome sleuthing. I can fix that in a matter of moments, actually. I got this one from here, now that you did the hard part. ;) |
|
|
Yea, I was able to get it "working" by adding if ( enemy.CloakingLevel == CloakingLevel.Full ) continue; towards the top of the loop just after "#region hasEnemies Calculation". But I don't know if that continues to meet all your goals for that branch. |
|
|
No, that just un-does a very important change from a prior version, actually. ;) |
|
|
Because the change broke free ship behavior ;) |
|
|
True enough. That just needs to be changed to skip the scout and scout starship ship types, at any rate. And Spirecraft Scout, come to that. With that change in place of what you put there, that should actually finish it, if you want to do it. |
|
|
Here is the thing. A "smart" player would neither wait indefinitely nor go ahead, as both behaviors are highly ab-usable if blindly followed. Rather, they would try to get some sort of decloaker in and try to find the hidden ships, then use their available military ships (including waiting ones) to kill them once revealed, then possibly move to the next planet. Of course, the AI currently takes no active effort to decloak, so this is not an option without adding a huge block of logic that I'm sure you don't want to debug before a major release. Maybe only send some military ships through? I don't know. Tricky situation to deal with there. EDIT: I do agree that simply ignoring non-military cloaked ships is safe enough though. |
|
|
Yes, that's what I started with (will need to add the IsScoutForListings attribute to spirecraft scouts, I think), but then it occurred to me that a single cloaked human raptor on the planet would cause the same problem of the completely idle wave (a wave of self-decaying younglings, no less). |
|
|
Not that tricky. The AI doesn't give a flip about scouts. And we're not adding vast tracts of new AI logic for cloaked ships this close before 5.0. If there are cloaked dangerous ships, the AI is well advised to wait a bit. |
|
|
For the younglings, those ought to be looking for a regenerator based on main thread logic, right? |
|
|
YES! AI younglings so far have almost completely ignored regenerators. I'm surprised no one brought this up earlier. |
|
|
They specifically have code that is suppsoed to make them find regenerators, already. Must not be working. |
|
|
It is for humans, and it does preempt the previous human order when it triggers. It doesn't seem that the AI is willing to let their younglings go, or they give them another order before their younglings can reach a regenerator. |
|
|
Oh, do you think this, "scouts choke moving between planets" bug of the AI is what is causing the special forces hiccup in 0002491? |
|
|
The self-attrition thing is a side issue, the main one concerned about is being able to totally paralyze AI threat by hiding a single cloaked raptor on every planet :) Not that that's a trivial endeavor, but it's doable. |
|
|
And the connection with the special forces bug did occur to me, but I don't see how it could be related to the worst of it. There were no scouts on Murdoch. |
|
|
Well, the self-attrition one can be left alone, I think. We need to redo this logic in general, though, I think, to handle the raptor case you brought up. I'll think about it and see what I can put in. |
|
|
Only the special forces stacking up on POI, not the freed guards being mysteriously going on the attack only a load. Those are two separate issues. EDIT: Any further conversion about the other bug I will respond to in that bug, if guess. |
|
|
Oh, right, I think you're dead-on that the POI SF-paralysis could be caused by this exact scout thing. |
|
|
Regarding the resistance fighters, just as a side note, I made the following changes in general so far: * A bug in prior versions was preventing the devourer golem from ever entering human planets. Whoops! That's now fixed, so better watch out. * Previously, zombie ships and all the other minor faction ships would really wander far and wide, much moreso than they should have. Fixed so that they'll now wander only to adjacent planets near to the planet they are currently on each time they decide to go a-wandering. |
|
|
All set! * Made some various internal improvements to how the AI decides to stay at a planet to defend itself against enemy threats (most notably cloaked enemy threats, but in general). The specific rules are difficult to really explain as it's all internal math, but in general the result should be for it to more properly weight threats and react more like what a human would do. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| Jan 17, 2011 2:41 pm | Varone | New Issue | |
| Jan 17, 2011 2:41 pm | Varone | File Added: this1.sav | |
| Jan 17, 2011 2:43 pm | keith.lamothe | Note Added: 0008911 | |
| Jan 17, 2011 2:43 pm | keith.lamothe | Assigned To | => keith.lamothe |
| Jan 17, 2011 2:43 pm | keith.lamothe | Status | new => acknowledged |
| Jan 17, 2011 3:14 pm | Varone | Note Added: 0008914 | |
| Jan 17, 2011 3:19 pm | keith.lamothe | Note Added: 0008915 | |
| Jan 17, 2011 3:45 pm | Chris_McElligottPark | Note Added: 0008918 | |
| Jan 17, 2011 3:58 pm | keith.lamothe | Note Added: 0008922 | |
| Jan 17, 2011 4:04 pm | Chris_McElligottPark | Note Added: 0008927 | |
| Jan 17, 2011 4:08 pm | keith.lamothe | Note Added: 0008928 | |
| Jan 17, 2011 4:12 pm | Chris_McElligottPark | Note Added: 0008930 | |
| Jan 17, 2011 4:18 pm | keith.lamothe | Note Added: 0008932 | |
| Jan 17, 2011 4:31 pm | Chris_McElligottPark | Note Added: 0008942 | |
| Jan 17, 2011 4:33 pm | keith.lamothe | Note Added: 0008944 | |
| Jan 17, 2011 4:34 pm | Chris_McElligottPark | Note Added: 0008946 | |
| Jan 17, 2011 4:35 pm | TechSY730 | Note Added: 0008947 | |
| Jan 17, 2011 4:36 pm | TechSY730 | Note Edited: 0008947 | |
| Jan 17, 2011 4:36 pm | keith.lamothe | Note Added: 0008948 | |
| Jan 17, 2011 4:37 pm | Chris_McElligottPark | Note Added: 0008949 | |
| Jan 17, 2011 4:37 pm | TechSY730 | Note Edited: 0008947 | |
| Jan 17, 2011 4:38 pm | Chris_McElligottPark | Note Added: 0008950 | |
| Jan 17, 2011 4:39 pm | TechSY730 | Note Added: 0008951 | |
| Jan 17, 2011 4:40 pm | Chris_McElligottPark | Note Added: 0008952 | |
| Jan 17, 2011 4:42 pm | TechSY730 | Note Added: 0008954 | |
| Jan 17, 2011 4:44 pm | TechSY730 | Note Added: 0008955 | |
| Jan 17, 2011 4:45 pm | keith.lamothe | Note Added: 0008956 | |
| Jan 17, 2011 4:46 pm | keith.lamothe | Note Added: 0008958 | |
| Jan 17, 2011 4:48 pm | Chris_McElligottPark | Note Added: 0008959 | |
| Jan 17, 2011 4:49 pm | TechSY730 | Note Added: 0008960 | |
| Jan 17, 2011 4:49 pm | TechSY730 | Note Edited: 0008960 | |
| Jan 17, 2011 4:50 pm | keith.lamothe | Note Added: 0008961 | |
| Jan 17, 2011 4:52 pm | TechSY730 | Relationship added | related to 0002491 |
| Jan 17, 2011 11:11 pm | Chris_McElligottPark | Note Added: 0009021 | |
| Jan 18, 2011 1:47 am | Chris_McElligottPark | Note Added: 0009034 | |
| Jan 18, 2011 1:47 am | Chris_McElligottPark | Status | acknowledged => resolved |
| Jan 18, 2011 1:47 am | Chris_McElligottPark | Fixed in Version | => 4.070 |
| Jan 18, 2011 1:47 am | Chris_McElligottPark | Resolution | open => fixed |
| Jan 18, 2011 1:47 am | Chris_McElligottPark | Assigned To | keith.lamothe => Chris_McElligottPark |
