View Issue Details
| ID | Project | Category | Date Submitted | Last Update | |
|---|---|---|---|---|---|
| 0001910 | AI War 1 / Classic | GUI | Dec 8, 2010 2:32 am | Jan 10, 2011 3:46 pm | |
| Reporter | Suzera | Assigned To | keith.lamothe | ||
| Status | resolved | Resolution | fixed | ||
| Product Version | 4.040 | ||||
| Summary | 0001910: Sometimes guardposts and their attached ships and guardians are not autotargeted at times | ||||
| Description | They'll sit there not firing. This is actually something that seems to have started back in .043 and I keep forgetting to bring it up. There doesn't seem to really be a rhyme or reason to it either. Any theory I've had about it so far just keeps getting shot full of holes when it fails to predict. So far I have theorized these: 1) Any guard posts and shis attached stop getting autotargeted when they release. This was quickly disproven. 2) Long range non-guardians will fire while the rest of the post stays offline, and this breaks things. This one stands up a little better. It still isn't quite right because it doesn't happen every time there is a long range non-guardian in the group. There was a third theory I had, but I can't remember it right now. This comes up fairly often in the video I recorded tonight, but I forgot to mark down any time markers on this one instance that was really really obvious where my ships were standing next to a post for a couple minutes while I left them alone not firing on the post. I need to go to sleep at the moment though. | ||||
| Tags | No tags attached. | ||||
| Internal Weight | |||||
|
|
er a while back chris implemented something silly - ships will not try to anger a guard post that is not angered. I havent seen too much issue with it in my games (and I havent seen yours), however id assume if the guard post is seeded with suitably low-range ships they wouldnt auto-agress.. Solutions would be to manually shoot them or anger them somehow. Bomber starships are fairly good at this with their high hp and good armor |
|
|
THAT was the change I was looking for. Yeah. That one. The ships avoid firing at posts. It's really annoying when the ships will jump out for a bit, freeze, but stay on and shooting but not get autotargeted. About every 15th post will bug out to not let any remaining guard post or attached ships be fired upon in my games. After manually targeting any attached ship or post that is bugged like that in the system they usually go back to being shot automatically though. |
|
|
The not-autotargeting-unangered-guard-post thing isn't really the root cause here, that just makes the root cause more obvious. Basically AI ships guarding a guard post stay in "low power" mode until something wakes them up. This saves a fair bit of cpu processing (particularly when you have scouts parked on the planet so the AI ships aren't constantly all checking to see whether they can eat the scout yet), but it seems to be an unending source of bugs. Perhaps one of you might be able to spot the problem. Here's the logic that decides, per cycle, per ship, whether it should be in low-power mode or not: if ( obj.Player.Type == PlayerType.AI && obj.ActionStatus == ActionStatus.Normal ) { if ( obj.GuardingObject != null && obj.CoordinatingShip == null && obj.UnitData.ShipType != ShipType.ShipModule ) { if ( obj.GuardingObject.Health <= 0 || obj.GuardingObject.ToBeRemoved || obj.GuardingObject.CurrentPlanet != obj.CurrentPlanet ) { obj.SetGuardingObject( null, true ); obj.IsBuyQueueEnabled = true; } else { if ( obj.ProtectingForceField != null && obj.ProtectingForceField.LastAngeredGameSecond >= cutoffGameSecond ) { obj.SetGuardingObject( null, true ); obj.IsBuyQueueEnabled = true; } else if ( obj.UnitData.AIIsActiveGuard ) { if ( obj.GuardingObject.LastAngeredGameSecond >= cutoffGameSecond || obj.LastAngeredGameSecond >= cutoffGameSecond ) { obj.SetGuardingObject( null, true ); } obj.IsBuyQueueEnabled = true; } else if ( obj.Player != null && obj.Player.AIDifficulty >= 7 && obj.CurrentRollup != null && obj.CurrentRollup.AIEnemyHumanFirepower > 0 && obj.CurrentRollup.AIEnemyHumanFirepower > obj.CurrentRollup.AIAlliedFirepower2X ) { obj.SetGuardingObject( null, true ); obj.IsBuyQueueEnabled = true; } else { if ( obj.GuardingObject.LastAngeredGameSecond >= cutoffGameSecond || obj.LastAngeredGameSecond >= cutoffGameSecond ) { obj.SetGuardingObject( null, true ); obj.IsBuyQueueEnabled = true; } else if ( obj.GuardingObject.LastAlertedGameSecond >= cutoffGameSecond || obj.GuardingObject.ObjectToKill != null || obj.ObjectToKill != null ) { obj.IsBuyQueueEnabled = true; } else { obj.IsBuyQueueEnabled = false; } } } } else { obj.IsBuyQueueEnabled = true; } if ( !obj.IsBuyQueueEnabled && obj.ObjectToKill != null ) obj.IsBuyQueueEnabled = true; } |
|
|
Hmm, it seems to be playing fast and loose with the concept of spacing, that's going to be a bit hard to read. Edit: ok, that should be better, just had to replace spaces with tabs, etc. |
|
|
The case below and the last innermost case are the only ones where the unit can become "buyqueueenabled" in the inner nested case set, but not lose it's guard post. I assume the last inside case before setting "buyqueueenabled" to false really only applies when the post is dead, but that might be something to check on. The ships go active, fight for a bit, but then aren't targetable when they attempt to return to their guard post. They stutter their movement heavily on the way back as well (they move in very very small bursts about every second/a few tics). It may be going active, getting buy enabled through this statement, then getting buy disabled before losing its post association and that breaks things. It could be only when they aren't angered long enough to trigger post abandonment. else if ( obj.UnitData.AIIsActiveGuard ) { if ( obj.GuardingObject.LastAngeredGameSecond >= cutoffGameSecond || obj.LastAngeredGameSecond >= cutoffGameSecond ) { obj.SetGuardingObject( null, true ); } obj.IsBuyQueueEnabled = true; } The very last if looks like it might do something funny too since that looks like it could enable buyqueue but still have a post association. if ( !obj.IsBuyQueueEnabled && obj.ObjectToKill != null ) obj.IsBuyQueueEnabled = true; I'm making guesses at AIIsGuardActive mostly, but I think I understand what the rest should be as far as this code goes. |
|
|
AIIsActiveGuard is for stuff like snipers, since they're always "relevant" to the battle regardless of position and are. You can ignore that branch for stuff like the triangle ships. SetGuardingObject(null, true); just means "free this ship", so it permanently becomes threat and can never be put back in low-power mode (because of the check for obj.GuardingObject == null). "obj.GuardingObject.LastAlertedGameSecond >= cutoffGameSecond" means "has the guard post shot at something lately" "obj.GuardingObject.LastAngeredGameSecond >= cutoffGameSecond" means "has something hit the guard post lately" The "Alerted" case is not supposed to free the ship, just bring it out of low power so it can do something. The "Angered" case is supposed to free all guards permanently (they won't return to the guard post, at least not to guard it). Oh, for reference, cutoffGameSecond == GameSecond - 30. Anyway, I've got an idea for making this a bit less fiddly, we'll see how it goes. |
|
|
It happens more with long range ships like snipers and bombards. That looks like a likely culprit. Maybe being buy queue enabled with an inactive guard post as owner breaks a function somewhere else. I'm not sure what GameSecond is supposed to be either. :) I assume it's a second on the clock though. |
|
|
Snipers should be basically totally unaffected by this except to be freed if the guard post is attacked. So IsBuyQueueEnabled is always true for them (and always has been for all other ships before this performance-improvement was added). Guard posts are never put in low power since "obj.GuardingObject == null" is always true for them. |
|
|
Sorry to be lazy, but I'm testing/working-on some other stuff right now, can someone point me at one of the saves of these problems that I'm sure is laying around somewhere around here? :) |
|
|
There is one thing I notice that ISN'T in there (I think) that activates all the ships remaining on the plant. If you approach the command center with a large fleet but do not cross the 2x strength of planet barrier, the ships will sometimes all activate, but don't get freed. They (mostly) go back to their posts if you leave. I can look at it in more detail later tonight if it's not fixed by whatever you're about to do. It could also be related to that if that isn't in there. I don't usually pay attention to where the CC is half the time and just pretend it's another post until everything starts attacking. |
|
|
I'll pause and save a bugout when I get one tonight. I'll check to make sure it persists after load too. |
|
|
Yea, that code is elsewhere and just frees everything, causing it to stop entering the branch we're talking about at all. |
|
|
They aren't getting freed (not increasing threat meter, or at least not ALL going into it) properly then sometimes if I am remembering right. It might also be, if they are getting freed, that they are thinking they'll attack planets and are getting stuck because the planet is too strong. I do tend to have 20-30 turrets on border planets. |
|
|
Suzera -- that's by design, and you're correct that it's elsewhere. The ships stay as guards, but their guard ranges are relaxed, when the command station is threatened. |
|
|
Ok. I know what I am looking for tonight if it happens again then. :) |
|
|
Cool -- thanks! |
|
|
|
|
|
Uploaded save. Still not sure why exactly this is happening if it is none of the above theories. Planet is TTT. It is on the rightmost side, to the right of my cluster. |
|
|
Is this any better in 4.050+? |
|
|
I'm having this problem on 4.051. It seems only to happen with the guardians themselves. I've seen it with MRLS guardians several times and once with a laser guardian. If I directly click them they target just fine. |
|
|
I can confirm that I am seeing weirdness with guardian autotargeting. Several times my fleet has been getting shot at by a guardian that they don't return fire at (even with nothing else in their range) unless I manually order them to. It seems to be based on the type of guardian; some get autotargeted and some don't. Zombie Guardians are a particular frustration, as they seem to be in the "never attacked unless manually targeted" camp. |
|
|
Does the not-autofiring-at-zombie-guardian thing reproduce when you save and then reload? Can you attach such a save? |
|
|
Nvm, found it doing the not-autofiring-at-guardian in my own testing, and it is reproducing when I reload the save. |
|
|
I've seen it happen with non-guardians, at least in the past, but guardians and starships do seem to be the most affected. The posts too become activated and then won't be auto-fired upon yet still fire at you. |
|
|
I am fairly sure this has been fixed. Yes? |
|
|
I'm not aware of a fix being done for it, though we did discuss one possible way of fixing it in email. |
|
|
Ok, it's always hard to remember. We'll have to look at this again when we get a chance in the coming week, then, if no-one else confirms it's fixed first. |
|
|
Should be taken care of for 4.065. It will still be possible for AI ships to "snipe" without retaliation if they have an effective range over 11,000, but within that they should actually be "angered" rather than just "alerted" when attacking you so they'll be autotargeted. Outside that range your ships won't auto-shoot unless the AI ship has been angered because otherwise your siege starships and snipers and whatnot would wind up aggroing large chunks of AI stuff you may not want aggro'd. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| Dec 8, 2010 2:32 am | Suzera | New Issue | |
| Dec 8, 2010 2:53 am | Lancefighter | Note Added: 0005588 | |
| Dec 8, 2010 3:22 am | Suzera | Note Added: 0005590 | |
| Dec 8, 2010 10:28 am | keith.lamothe | Note Added: 0005608 | |
| Dec 8, 2010 10:28 am | keith.lamothe | Assigned To | => keith.lamothe |
| Dec 8, 2010 10:28 am | keith.lamothe | Status | new => feedback |
| Dec 8, 2010 10:29 am | keith.lamothe | Note Added: 0005609 | |
| Dec 8, 2010 10:33 am | keith.lamothe | Note Edited: 0005608 | |
| Dec 8, 2010 10:34 am | keith.lamothe | Note Edited: 0005609 | |
| Dec 8, 2010 1:40 pm | Suzera | Note Added: 0005643 | |
| Dec 8, 2010 1:40 pm | Suzera | Status | feedback => assigned |
| Dec 8, 2010 1:41 pm | Suzera | Note Edited: 0005643 | |
| Dec 8, 2010 1:44 pm | Suzera | Note Edited: 0005643 | |
| Dec 8, 2010 1:45 pm | Suzera | Note Edited: 0005643 | |
| Dec 8, 2010 1:46 pm | Suzera | Note Edited: 0005643 | |
| Dec 8, 2010 1:47 pm | Suzera | Note Edited: 0005643 | |
| Dec 8, 2010 1:51 pm | keith.lamothe | Note Added: 0005644 | |
| Dec 8, 2010 1:51 pm | Suzera | Note Edited: 0005643 | |
| Dec 8, 2010 1:53 pm | Suzera | Note Added: 0005645 | |
| Dec 8, 2010 1:54 pm | Suzera | Note Edited: 0005645 | |
| Dec 8, 2010 1:55 pm | Suzera | Note Edited: 0005645 | |
| Dec 8, 2010 1:57 pm | keith.lamothe | Note Added: 0005646 | |
| Dec 8, 2010 2:02 pm | keith.lamothe | Note Added: 0005649 | |
| Dec 8, 2010 2:05 pm | Suzera | Note Added: 0005650 | |
| Dec 8, 2010 2:06 pm | Suzera | Note Edited: 0005650 | |
| Dec 8, 2010 2:07 pm | Suzera | Note Added: 0005651 | |
| Dec 8, 2010 2:07 pm | keith.lamothe | Note Added: 0005652 | |
| Dec 8, 2010 3:06 pm | Suzera | Note Added: 0005658 | |
| Dec 8, 2010 3:07 pm | Suzera | Note Edited: 0005658 | |
| Dec 8, 2010 3:21 pm | Chris_McElligottPark | Note Added: 0005663 | |
| Dec 8, 2010 3:26 pm | Suzera | Note Added: 0005664 | |
| Dec 8, 2010 3:28 pm | Chris_McElligottPark | Note Added: 0005665 | |
| Dec 8, 2010 10:51 pm | Suzera | File Added: Not autotargeting.sav | |
| Dec 8, 2010 10:52 pm | Suzera | Note Added: 0005745 | |
| Dec 8, 2010 10:52 pm | Suzera | Note Edited: 0005745 | |
| Dec 8, 2010 10:53 pm | Suzera | Note Edited: 0005745 | |
| Dec 8, 2010 10:54 pm | Suzera | Note Edited: 0005745 | |
| Dec 15, 2010 4:44 pm | keith.lamothe | Note Added: 0006229 | |
| Dec 15, 2010 4:44 pm | keith.lamothe | Status | assigned => feedback |
| Dec 18, 2010 12:03 pm | arthurp | Note Added: 0006400 | |
| Dec 18, 2010 1:15 pm | MaxAstro | Note Added: 0006403 | |
| Dec 18, 2010 1:20 pm | keith.lamothe | Note Added: 0006404 | |
| Dec 18, 2010 4:47 pm | keith.lamothe | Note Added: 0006410 | |
| Dec 18, 2010 9:21 pm | Suzera | Note Added: 0006418 | |
| Dec 18, 2010 9:21 pm | Suzera | Status | feedback => assigned |
| Jan 7, 2011 11:42 pm | Chris_McElligottPark | Note Added: 0007895 | |
| Jan 7, 2011 11:42 pm | Chris_McElligottPark | Status | assigned => feedback |
| Jan 7, 2011 11:44 pm | keith.lamothe | Note Added: 0007897 | |
| Jan 7, 2011 11:46 pm | Chris_McElligottPark | Note Added: 0007900 | |
| Jan 10, 2011 3:46 pm | keith.lamothe | Note Added: 0008149 | |
| Jan 10, 2011 3:46 pm | keith.lamothe | Status | feedback => resolved |
| Jan 10, 2011 3:46 pm | keith.lamothe | Resolution | open => fixed |
| Apr 14, 2014 9:28 am | Chris_McElligottPark | Category | Bug - UI => GUI |
