Check m_hFiredByPlayer when tracking portal rules #320
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The
SpeedrunTimer::TickRulesfunction seemingly attempts to track only those portals shot by players, as evidenced by the queries for a player handle, followed by queries for the weapon handle. However, this is not an exhaustive check, and can lead to false positives in some cases.For example, if the player has a single-portal device, a secondary linked portal opened via map logic will still count as being owned by the player's portal gun. This is likely because the portal gun is still linked to that orange portal, despite not being able to create it. This becomes an issue in cases where SAR's demo data is used to count portal placements in custom maps.
To fix this, I've added a check for the
m_hFiredByPlayerhandle of the portal, which seems to only be valid when the portal has actually been fired by a player wielding a portal gun. I've tested this and confirmed that it works as intended on a workshop map that would typically be susceptible to the false positive edge case mentioned earlier.