View Issue Details

IDProjectCategoryLast Update
0001772AI War 1 / ClassicBug - OtherDec 22, 2010 7:17 pm
ReporterDraco18s Assigned ToChris_McElligottPark  
Status resolvedResolutionfixed 
Product Version4.044 
Fixed in Version4.054 
Summary0001772: Multi-Stacked FFs: When one dies, everything is left unprotected for a moment
DescriptionScreenshot series to follow, will post in order.
TagsNo tags attached.
Internal Weight

Activities

Draco18s

Dec 4, 2010 12:02 am

developer  

Draco18s

Dec 4, 2010 12:02 am

developer  

Draco18s

Dec 4, 2010 12:03 am

developer  

Draco18s

Dec 4, 2010 12:03 am

developer  

Draco18s

Dec 4, 2010 12:05 am

developer   ~0005124

Last edited: Dec 4, 2010 12:05 am

In order:
1) Things unprotected, no remains.
2) 2 Remains (tractor and grav turret), things protected.
3) 2 FFs died, things unprotected
4) 3 remains (3 tractors--grav turret rebuilt), things protected.

keith.lamothe

Dec 4, 2010 11:24 am

administrator   ~0005197

How long of a moment are we talking? The game only processes so many TryProtections calls per second to avoid major cpu death on planets with tons of ff's. There's a punch-through so that command stations _always_ get to retry if they just lost their ff protection (and even then shots landing in the same frame as the ff dying can get through, it's just rare).

Chris_McElligottPark

Dec 4, 2010 11:29 am

administrator   ~0005200

Actually, having ANY ship that just lost it's FF protection retry probably wouldn't be a bad idea. That would drain fairly little CPU power in most cases, as it's not common to have a ton of ships all losing FF protection at once. I suppose the two exceptions would be: if the ship doesn't have supply, or the player is human and is in a brownout at the time. Or if the ship has been paralyzed (EMPed). Those could get expensive.

Draco18s

Dec 4, 2010 11:33 am

developer   ~0005203

Last edited: Dec 4, 2010 11:35 am

A couple seconds, actually. It was long enough that it wasn't difficult to screenshot.
Notably we were on Time -2, but that helped alleviate the lag of 3000 Neinzul ships warping in (allow more time for processing -> consistent slowdown). But I still think it was for a full second of game-time, as the Neinzul ships were able to take down a shield from full radius to dead as it would never receive protection from the other FFs, despite being smaller, and then everything else was still unprotected long enough to get shot to rubble.

About every 3 waves we'd have to rebuild the FF stack (about 15 to 20 Mk1s and 5 Mk2s).

As for the every-ship-retry, you could add them to a stack and only process so many per game tick, so that if a ton DO lose protection (say lost supply or a brownout) you'd spread the processing out, and in most cases there wouldn't be a new FF anyway, so it wouldn't matter if they had to wait.

keith.lamothe

Dec 4, 2010 11:58 am

administrator   ~0005211

Chris, if you want to have that special flag default to true, that would probably be sufficient to try what you're suggesting. I make no warranty on what happens to cpus ;)

Chris_McElligottPark

Dec 22, 2010 7:04 pm

administrator   ~0006767

Ok:

* A change has been put in place to make ships immediately re-check for new forcefield protection as soon as they lose protection from a prior force field. This was previously the case for command stations only. This will have some performance impact, but will greatly help correctness in the case of multi-stacked force fields. And in most cases, the performance impact will hopefully be negligble, but we look forward to your feedback on that.

Draco18s

Dec 22, 2010 7:17 pm

developer   ~0006772

Sweet.

Issue History

Date Modified Username Field Change
Dec 4, 2010 12:02 am Draco18s New Issue
Dec 4, 2010 12:02 am Draco18s File Added: Screenshot_2010_12_04_00_00_32.png
Dec 4, 2010 12:02 am Draco18s File Added: Screenshot_2010_12_04_00_01_08.png
Dec 4, 2010 12:03 am Draco18s File Added: Screenshot_2010_12_04_00_01_14.png
Dec 4, 2010 12:03 am Draco18s File Added: Screenshot_2010_12_04_00_01_33.png
Dec 4, 2010 12:05 am Draco18s Note Added: 0005124
Dec 4, 2010 12:05 am Draco18s Note Edited: 0005124
Dec 4, 2010 11:24 am keith.lamothe Note Added: 0005197
Dec 4, 2010 11:24 am keith.lamothe Assigned To => keith.lamothe
Dec 4, 2010 11:24 am keith.lamothe Status new => feedback
Dec 4, 2010 11:29 am Chris_McElligottPark Note Added: 0005200
Dec 4, 2010 11:33 am Draco18s Note Added: 0005203
Dec 4, 2010 11:33 am Draco18s Status feedback => assigned
Dec 4, 2010 11:35 am Draco18s Note Edited: 0005203
Dec 4, 2010 11:58 am keith.lamothe Note Added: 0005211
Dec 22, 2010 7:04 pm Chris_McElligottPark Note Added: 0006767
Dec 22, 2010 7:04 pm Chris_McElligottPark Status assigned => resolved
Dec 22, 2010 7:04 pm Chris_McElligottPark Fixed in Version => 4.054
Dec 22, 2010 7:04 pm Chris_McElligottPark Resolution open => fixed
Dec 22, 2010 7:04 pm Chris_McElligottPark Assigned To keith.lamothe => Chris_McElligottPark
Dec 22, 2010 7:17 pm Draco18s Note Added: 0006772