Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.
Sign upMassive slowdown with explosives. #24748
Comments
This comment has been minimized.
This comment has been minimized.
|
Reproduction case here https://cdn.discordapp.com/attachments/365907426270117888/476630276483710976/Midville.7z |
This comment has been minimized.
This comment has been minimized.
|
Possible connection to #24683? Landmines also have a shrapnel value, and at least in my experience have sometimes exhibited the slowdown issue. Their base Explosive Damage and falloff coefficient are far too low to explain the reality bubble-wide damage to vehicles, and the explosion code seems straightforward enough that there shouldn't be any weirdness there. That said, the I've also observed the damage happen without the slowdown. Either way, Shrapnel seems to be somehow involved. |
This comment has been minimized.
This comment has been minimized.
|
Its caused by the same set of changes, but this issue is a performance bug and that issue is a balance bug. |
kevingranade commentedAug 9, 2018
Game version:
As of commit 6953a4a
Introduced by #24171
Operating system:
Observed on all OSs (Several windows versions, several Linux distributions)
Tiles or curses:
Both
Mods active:
Many combinations.
Expected behavior
Sub-second latency when an explosive goes off.
Actual behavior
Many-second (observed at over a minute) latency while processing an explosive.
Steps to reproduce the behavior
Reproduces very intermittently, always triggered by an explosive with a fragmentation component, but not all fragmentation explosions trigger the bug.
Probably a better chance of triggering the issue by setting off explosives near many obstacles, such as trees or buildings. Possibly involves monsters in the area of effect.
Further investigation has found that the proximate cause of the lag is excessive FoV calculation work triggered by game::shrapnel() in cast_zlight_segment(). This function should only visit most tiles once in order to calculate LoS between the origin and the visited square, but something is causing the algorithm to visit some tiles upwards of 1,000 times.
My best guess is that cast_zlight() has a bug causing it to improperly partition the beams it is casting, resulting in a massive amount of overlap between beams and really excessive work.
As a quick fix, the game::shrapnel() function could be refactored to call castLight() (the legacy 2D shadowcasting implementation) instead.