Lone bots deploy detpack ambush at ghost#1795
Lone bots deploy detpack ambush at ghost#1795sunzenshen wants to merge 2 commits intoNeotokyoRebuild:masterfrom
Conversation
| surfacedata_t *psurface, float fvol, bool force ) | ||
| { | ||
| // Bots in ambush behavior pay more attention to player sounds | ||
| CSoundEnt::InsertSound(SOUND_PLAYER, GetAbsOrigin(), 300, 0.2, this); |
There was a problem hiding this comment.
Honestly not sure if 300 is too big or small, but my perception this whole time is that footstep sounds are really loud.
| } | ||
|
|
||
| // Cloak activation is intentionally loud; bots investigate this as a combat sound. | ||
| CSoundEnt::InsertSound(SOUND_COMBAT, GetAbsOrigin(), 600, 0.2, this); |
There was a problem hiding this comment.
Bots already react to gunshots, so I think this classification makes sense as bots should consider enemy cloak sounds as combat sounds as well.
|
|
||
| // Notify bots after pressing keypad since reacting immediately to press fire is unforgiving | ||
| // especially since the sound clip has some silence at the beginning | ||
| CSoundEnt::InsertSound(SOUND_COMBAT, pPlayer->GetAbsOrigin(), SOUNDENT_VOLUME_EMPTY, 0.2, pPlayer, SOUNDENT_CHANNEL_WEAPON); |
There was a problem hiding this comment.
This sound triggers after the keypad initiation sequence, which to be honest might be kind of late, but I didn't want to mess with delay or think timers. Plus there's a comedic timing if one bot tries to set a detpack, and when they are done arming they get blown up by an earlier trap.
There was a problem hiding this comment.
The alternative was at the start of pressing the fire button, but that timing felt like the earlier trapping bot was psychic and triggered the remote immediately at the latter's intention. That appearance may be exacerbated by an initial silence in the detpack arming sound.
Plus you could argue that a bot is waiting for the arming sound to end, as the other player may be moving while arming, and will be closest at their arming target at the end of the sound.
|
The easiest way to test the behavior for me was honestly to give all players GiveDet in neo_player.cpp, and to set up a game with 2 players. You can either watch the two bots try to plant the det on the ghost, or you can use |
d719ba9 to
c9d1a81
Compare
|
|
||
| if ( NEORules()->m_pGhostCaps.Count() > 0 ) | ||
| { | ||
| const Vector& vecStart = me->IsCarryingGhost() ? me->GetAbsOrigin() : ( m_hGhost.Get() ? m_hGhost->GetAbsOrigin() : me->GetAbsOrigin() ); |
There was a problem hiding this comment.
I don't know how expensive m_hGhost.Get() is but the ghost's absorigin should be the same as the move parent's abs origin, so m_hGhost->GetAbsOrigin can be used if IsCarryingGhost, saving us from iterating through all the weapons. At any rate it would make the statement simpler, if can get ghost return the ghost origin otherwise return my origin
There was a problem hiding this comment.
Actually the ghosts' abs origin z component is higher, so if that messes up with the pathfinding algorithm then better to leave as is. Although could check if the ghost has a moveparent and then use the moveparent abs origin which would still save us from iterating through all the weapons
There was a problem hiding this comment.
also if m_hGhost is only stored here to get its position, might be better to just call NEORules()->GetGhostPos which also has a pointer to the ghost. (technically the ghost capture points can be captured with any ghost, but doing so while m_ighosterplayer isnt updated (nobody picks up the original ghost yet) crashes the game).
|
In verifying a code review pass, I realized that there was a defect with the case where bots do not have a detpack and are waiting, which I didn't notice because it was boring to watch the wait behavior. I think I need to take this behavior to the drawing board and test out some potential restructuring of the behavior. |
Description
Consolidated bot ambush logic into its own behavior class and added the ability for bots to plant detpacks in such scenarios.
Toolchain