Skip to content

Spy disguised as any class other than spy then disguising as enemy spy causes T-pose due to incomplete m_hDisguiseWeaponList + links to fix. #8

@BringBackQuickPlay

Description

@BringBackQuickPlay

This is about your reverts plugin.
The Spy T-pose issues happens in it too and not only Castaways version.

A fix has been made available here: https://github.com/rsedxcftvgyhbujnkiqwe/castaway-plugins/pull/330/commits

Descriptions of the issue:
rsedxcftvgyhbujnkiqwe/castaway-plugins#27
asherkin/TF2Items#12

TL;DR TF2Items defaults to setting bForce false instead of taking into account what parameter settings GiveNamedItem was actually called with.
TF2Items contains a FORCE_GENERATION flag one can use to set bForce to true.

When spy disguises as someone else, copies are made of their disguisetarget's weapons and placed into m_hDisguiseWeaponList
Even with TF2Items setting bForce to false, this does not cause issues as long as you do not disguise as enemy spy
because the spy does not already own those weapons.
But once you do disguise as the enemy spy, that m_hDisguiseWeaponList is empty of ANY spy weapon you modified with TF2Items
in TF2Items_OnGiveNamedItem, since a copy will not be taken since the Spy already owns the weapon type.

This causes the game to fallback to LastDisguiseWeapon, and this causes the T-pose.
By making sure we detect when it's reasonable for GiveNamedItem to have been called when it's filling out the m_hDisguiseWeaponList (i.e: Client is alive, is a spy, and has disguised condition), we can set bForce to true when using TF2Items_CreateItem by including the FORCE_GENERATION flag. (Or SetFlag method).
The fix contains more comments about it.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions