Flying through transparent lava hurts too much by 6x-9x factor
#11
Aha, that's the one: commit "Made scrape_player_on_wall() based on a timer. [...]" introduced the bug. In a build of the commit before that one, "Propagate Hack_DblClick_MenuMode", the damage of lavafalls is correct and independent of the frame rate (as far as I can tell). Thanks for the suggestion.
Reply
#12
That commit can be reverted cleanly in tip, at the price of reintroducing whatever problem(s) zico was trying to fix. I have not checked whether the problem can be fixed without a revert.
Reply
#13
Fix excessive lavafall damage should resolve this. This only applied to lavafalls, not lava walls. Although the bug increased damage taken from each contact with the lava fall, I did not find the increase to be substantial enough to be noticeable when flying through at speed. Hovering in the lavafall produced notably higher damage. As a workaround, affected users should avoid loitering in a lavafall, and should instead fly through at speed. (This is probably good advice anyway...)

Quoting from the commit:

Like many things in the main game loop, lavafall handling was historically done on a per-frame basis, then its effects were scaled to FrameTime to normalize the results. Ignoring rounding errors, this produced roughly equivalent damage for high framerate users (who experienced many but small damage hits) and low framerate users (who experienced few but large damage hits). However, the randomized movement was not scaled to FrameTime, which caused differing results for high framerate users versus low framerate users. Commit b36c6f20c705 tried to fix this by forcing scrape_player_on_wall to run at a capped maximum effective frame rate, then scaling the damage in check_volatile_wall accordingly, so that high framerate users would experience fewer damage hits, but the ones they received were larger, thus maintaining approximately the same damage as before.

Prior to b36c6f20c705, damage was always scaled to FrameTime. In b36c6f20c705 and later, damage scaled to max(FrameTime, DESIGNATED_GAME_FRAMETIME), causing users with a high frame rate (and thus low FrameTime) to take more damage on each pass. This damage increase was balanced by an added hack in scrape_player_on_wall to limit the frequency of the scrape so that high framerate users would skip some scrapes, giving them a virtual frame rate appropriate to DESIGNATED_GAME_FRAMETIME. However, the damage is only balanced if the new governor is used consistently. It is not used consistently, so it caused a regression for passable lava surfaces. Scraping on a solid lava surface goes through scrape_player_on_wall and respects the governor. Touching a passable lava surface (only available in Descent 2) bypasses scrape_player_on_wall and jumps directly to check_volatile_wall, thereby bypassing the governor. This allows high framerate users touching a passable lava surface to take many hits (as they always did), but not receive the full benefit of downward scaling the damage (as they once did) due to the new max() expression. Thus, they are damaged frequently, but still take damage consistent with being damaged infrequently.
Reply
#14
Confirmed, lavafalls now inflict damage at the correct rate at 200 FPS and at 30 FPS. Thanks!
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)