View Issue Details
| ID | Project | Category | Date Submitted | Last Update | |
|---|---|---|---|---|---|
| 0001288 | AI War 1 / Classic | Bug - Other | Nov 12, 2010 6:57 am | Nov 15, 2010 2:46 pm | |
| Reporter | mr_lolz | Assigned To | Chris_McElligottPark | ||
| Status | resolved | Resolution | fixed | ||
| Product Version | 4.030 | ||||
| Fixed in Version | 4.034 | ||||
| Summary | 0001288: Artillery Gaurdian firing with instant reloadtime | ||||
| Description | A bug is frequently occouring in my games where an artillery gaurdian will cease to have a reload time and will instead fire a constant non-stop volley of missles for insane damage. there are also normally functioning artillery gaurdians in my games, so it seems that somthing causes individual gaurdians to go fire frenzy, and it isnt unique to one game as I have seen it occour in several seperate games, both on my and AI planets. I have not noticed this bug affecting any other units. | ||||
| Tags | No tags attached. | ||||
| Internal Weight | |||||
|
|
Ouch, that would be most disturbing. To clarify, do you have any saves where this can be reproduced at-will? No worries if not, but it will make much easier if so. My guess is that it's related to the overkill-refunding mechanism I added months ago that speeds up (but doesn't zero out) the reload of a ship whose shot had to be removed because its target was already dead midflight. As a mechanic it makes no realism sense but it really helps avoid the need for razor-sharp avoidance of overkill and underkill in the code :) |
|
|
I bet it's partly the overkill shot regeneration and the new "machine gun burst" code. I've seen flak guardians also fire out a near endless stream of shots. |
|
|
Yea, but the machine-gun-burst stuff doesn't actually alter the number of shots or anything like that, though perhaps it's causing the overkill-refund code to trigger more often in cases that used to be rare. |
|
|
Well, even if a single shot of a burst doesn't fully recharge the timer (and only does 1/20th of a recharge on a burst of 20, like I would EXPECT), it could still cause guardians with high damage and shot counts to be "missing" enough shots that it accumulates into a steady stream of firing. For instance, the artillery guardian fires 20 shots at 20 targets, reloads, and fires again at the same 20 targets before the initial shots reach their destination. Lets say that it gets to do this 5 times (so there are 6 shots floating for each of 20 targets) due to the hugely excessive range the guardian has. When the first volley reaches their targets the guardian fires again, only now there are some additional units in range, so the volley targets them. 20 * 6 shots die from their target having been killed and grant the guardian an amount of reload. Lets assume that this is more than enough to fill a full recharge cycle. So the guardian fires again, immediately, after those 20 shots get fired (in fact, it queues an additional 20 behind the 20 already delayed). More targets are in range than 20 now, so these new shots are at those and not overkilled targets. But lets say that there are 60 units in range. We already know that the guardian can fire 6 times before any shots reach their destination, which leaves each target with two shots inbound. One to kill, one fired as overkill. As soon as the first volley reaches its target, 20 shots cause a reload boost. The second volley reaches, causing another 20 reload boost. Lets say that both combined are enough for a full reload. Additionally in that time there was enough time for a full reload anyway so the guardian gets to add another 60 shots into the air in the time it took for 40 shots to reach their targets. Enough shots in queue could lead up to a point at which the amount of time it takes to empty the queue, the queue has again increased by a non-zero number of shots. Therefore, enough units flowing into range and enough units being targeted for overkill would cause this kind of behavior, even if the partial reload mechanic for multi-shot bursts was working as intended (it gets worse when you have two guardians too, as each one can also be adding overkill shots to targets the other is killing). (I'm someone who can see how two rules can interact and create chaos from order. I enjoy creating Mandelbugs and Bohrbugs in my spare time.) |
|
|
I just realized what this is: it's for multi-shot ships, as soon as any shot misses their timer gets reset. This is making multi-shot ships vastly overpowered right now, for example with this. I'll have to make it so that it's percentage based or something along those lines. |
|
|
That's what I'd figured it was, but I could see it being the result of "operating normally" in a specific situation. But yes. Percentage based is what it should be. |
|
|
Chris, yea, I knew what it was. But with reload based on whole seconds, the appropriate response for a lot of these is just to remove the overkill refund altogether. Of course, that will make it possible to achieve disproportionate tactical advantage by sending a couple fighters through a wormhole to "drain" all the nearby mlrs turrets, etc. Either that or make the reload time FInt-based, or have a secondary variable for tracking the "partial-second refund total thus far", which seems a waste of the memory footprint. I could be missing something, though. |
|
|
Could you alter your int variable of seconds to instead track an int of milliseconds? Essentially you'd be adding a *1000 to one place and a /1000 to another. |
|
|
Right, but *1000 is cpu-expensive, and /1000 moreso. |
|
|
If we went partial-tracking we'd probably just use our FInt class that we use instead of float (since floating point math is not deterministic), which is achieved via >> 12 and << 12 operations. |
|
|
How many multi-shot units actually reload so slowly that it could be exploited? |
|
|
Fair'nuff. @KDR: Riot control starships, leech starships, most guardians, fortresses.... |
|
|
Yea, one side getting "first strike" because of sending a couple leading fighters through first is a bigger deal than it seems, particularly because the AI does this to you basically every wave, and it's problematic because the human can avoid the problem by keeping their local turret grid on low-power until the actual wave comes through and then turning it on. We really don't want to encourage that kind of micro. |
|
|
We can't easily track milliseconds, anyway, because the game has to be synchronous and there is a variant number of milliseconds (or seconds, for that matter) per game turns. By making it per-game-second, we're able to maintain sync through various performance scales while also keeping performance low. It's super complicated, I don't really have time or inclination to get into the whole thing now, but in essence we used to do it with a "number of turns" calculation, and now we do it by game-second for a lot of very good reasons. |
|
|
Thanks! * Multi-shot ships no longer are able to get any "freebie" shots if their target dies while their shots are incoming against it. This nerfs the mutli-shot ships to a minor degree, but more significantly it is a CPU-cheap way of solving a huge bug that was recently leading to multi-shot ships sometimes getting loads and loads of freebie shots that they weren't supposed to -- leading to things like the "rapid fire artillery guardian," for instance. |
|
|
Farewell, alpha-strike capability of mlrs turret clusters :) But that's preferable to the bugs we're fixing with this. |
|
|
Indeed. We could go with something more complex, and in the future we might do so, but for now I went with the most efficient thing I could think of in terms of time and CPU. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| Nov 12, 2010 6:57 am | mr_lolz | New Issue | |
| Nov 12, 2010 8:43 am | keith.lamothe | Note Added: 0003268 | |
| Nov 12, 2010 3:43 pm | Draco18s | Note Added: 0003302 | |
| Nov 12, 2010 3:45 pm | keith.lamothe | Note Added: 0003303 | |
| Nov 12, 2010 6:15 pm | Draco18s | Note Added: 0003310 | |
| Nov 15, 2010 9:17 am | Chris_McElligottPark | Note Added: 0003528 | |
| Nov 15, 2010 9:17 am | Chris_McElligottPark | Assigned To | => Chris_McElligottPark |
| Nov 15, 2010 9:17 am | Chris_McElligottPark | Status | new => confirmed |
| Nov 15, 2010 10:13 am | Draco18s | Note Added: 0003545 | |
| Nov 15, 2010 10:28 am | keith.lamothe | Note Added: 0003549 | |
| Nov 15, 2010 10:50 am | Draco18s | Note Added: 0003551 | |
| Nov 15, 2010 11:02 am | keith.lamothe | Note Added: 0003553 | |
| Nov 15, 2010 11:03 am | keith.lamothe | Note Added: 0003554 | |
| Nov 15, 2010 11:11 am | KDR_11k | Note Added: 0003556 | |
| Nov 15, 2010 11:13 am | Draco18s | Note Added: 0003557 | |
| Nov 15, 2010 11:14 am | Draco18s | Note Edited: 0003557 | |
| Nov 15, 2010 11:31 am | keith.lamothe | Note Added: 0003562 | |
| Nov 15, 2010 12:26 pm | Chris_McElligottPark | Note Added: 0003574 | |
| Nov 15, 2010 2:40 pm | Chris_McElligottPark | Note Added: 0003615 | |
| Nov 15, 2010 2:40 pm | Chris_McElligottPark | Status | confirmed => resolved |
| Nov 15, 2010 2:40 pm | Chris_McElligottPark | Fixed in Version | => 4.034 |
| Nov 15, 2010 2:40 pm | Chris_McElligottPark | Resolution | open => fixed |
| Nov 15, 2010 2:42 pm | keith.lamothe | Note Added: 0003616 | |
| Nov 15, 2010 2:46 pm | Chris_McElligottPark | Note Added: 0003619 |
