-
Notifications
You must be signed in to change notification settings - Fork 2.7k
[TF2] Fix #618 causing money to be aggressively collected in the playable area #1307
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
Co-authored-by: John Kvalevog <jkvalevog@protonmail.com>
Vector vecMins, vecMaxs; | ||
pRespawnRoom->GetCollideable()->WorldSpaceSurroundingBounds( &vecMins, &vecMaxs ); | ||
if ( IsPointInBox( GetCollideable()->GetCollisionOrigin(), vecMins, vecMaxs ) ) | ||
if ( !pRespawnRoom->m_bDisabled && pRespawnRoom->PointIsWithin( GetAbsOrigin() ) ) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the respawn room gets disabled before the money comes to rest, will this result in the money not autocollecting? Some maps may disable certain respawn rooms for robots mid-game but may not make those areas walkable for players.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That would indeed happen, but I'm operating on the assumption that there's not really much reason to disable spawnroom entities in MvM except for making an area walkable and using RecomputeBlockers
, given that robots won't attempt to hotswap their loadouts and their actual spawnpoints will continue to function as the mission maker directs independent of the spawnroom's status. Though of course if there's any maps this change would break, it would be worth reviewing this part again.
Vector vecMins, vecMaxs; | ||
pRespawnRoom->GetCollideable()->WorldSpaceSurroundingBounds( &vecMins, &vecMaxs ); | ||
if ( IsPointInBox( GetCollideable()->GetCollisionOrigin(), vecMins, vecMaxs ) ) | ||
if ( !pRespawnRoom->m_bDisabled && pRespawnRoom->PointIsWithin( GetAbsOrigin() ) ) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if ( !pRespawnRoom->m_bDisabled && pRespawnRoom->PointIsWithin( GetAbsOrigin() ) ) | |
if ( !pRespawnRoom->m_bDisabled && ( pRespawnRoom->PointIsWithin( GetAbsOrigin() ) || pRespawnRoom->IsTouching( this ) ) |
Correct me if I'm wrong but couldn't we also double check to see if the cash entity is touching the trigger using IsTouching?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IsTouching()
would require the spawnroom to have spawnflags set that allow cash entities to register as touching to return true, but they usually only have SF_TRIGGER_ALLOW_CLIENTS
set.
Description
The PR #618, merged in 52e568b happened to introduce a bug in
CCurrencyPack::ComeToRest()
that this PR aims to address:PointIsWithin()
instead ofWorldSpaceSurroundingBounds()
so that complex trigger shapes are accounted for.This PR also fixes some other minor bugs in this method:
m_bDistributed
check so that red money can be auto-collected if it drops outside the playable space.GetCollisionOrigin()
andGetAbsOrigin()
usage asGetAbsOrigin()
.