[crafting]

The code below was used to make the ammo HUD (like for Primary/Secondary) to show up on a Melee weapon to act like a counter.


// ammo counter shenanigans
SetEntProp(meleeWeapon, Prop_Send, "m_iClip1", 0);
SetEntProp(meleeWeapon, Prop_Data, "m_iPrimaryAmmoType", 4);


void SetClientJumpCounter(int client) {
int meleeWeapon = GetPlayerWeaponSlot(client, 2);
if (IsValidEntity(meleeWeapon)
&& TF2_GetItemDefinitionIndex(meleeWeapon) == TF_ECON_DEFINDEX_ATOMIZER) {
SetEntProp(meleeWeapon, Prop_Send, "m_iClip1", g_nAirDashOverride[client]);
}


From this example, we need to have a way to trigger other HUD elements for other classes. Here's some of the HUD meters I am looking for to use is....
1) Head (from Eyelander and/or Bazaar Bargain)
2) KILLS (from Air Strike)
3) CRITS (from Manmelter and/or Diamondback)
4) REVENGE (from Frontier Justice)

I don't need to use all of them listed above, just something if possible. I don't need to rename the text (which is probably not possible), but that would be fine. Additional, if this HUD triggering is possible, we will then use it as a counter for a custom element.

[crafting]

This is just an update. I am still needing the information to get what I need working. I can pay someone for the information if this HUD-related stuff is possible.

[Pelipoika]

If someone made an extension or something to work with string attributes this might be possible using the string attribute 2058

"2058"
{
	"name"					"meter_label"
	"attribute_type"		"string"
	"hidden"				"1"
}

it would (in theory, i haven't tested) let you use any translation string.

This is how it looks on The Sandvich

{
	"defindex": 2058,
	"value": "#TF_Sandwich"
},

or

{
	"defindex": 2058,
	"value": "#TF_Unique_Backstab_Shield"
},

on The Razorback

[Powerlord]

My understanding is that some meters are tied to specific weapons while some are tied to specific weapon attributes.

[crafting]

Originally Posted by Pelipoika If someone made an extension or something to work with string attributes this might be possible using the string attribute 2058

Ok so where should I post this "request"? In the "Plugin/Gameplay Ideas and Requests" forum or in the "Extensions" forum?

I am somewhat desperate for the help. And will pay hopefully well enough for the help.

[nosoop]

I don't believe these particular string attributes are networked from game servers per this topic.

For those that want to do a deep dive into the client binary (i.e., the land of no debugging symbols), do an x-ref for the string "HudItemEffectMeter" and see if you can figure out what happens in one of those two functions -- the strings in one function reference all the class item effect meter resource files in a switch table (so I'd assume it's loaded based on the current class), the strings in the other seem like it's for setting up the panel.

[Benoist3012]

They're not networked I believe so too, for instance the string attribute defining pipe bomb models for the iron bomber or quickie bomb launchers is only read on the client's end. Despite changing it server side I could observe no effects on the projectile model.
(Ps: there are two attributes defining the proj model I'm talking about the latest one added by valve)

[nosoop]

Minor follow-up on this topic, since the leak exists.

This is effectively not possible. As of the pre-Jungle Inferno code leak, the visibility is controlled on the client in CHudItemEffectMeter_Weapon<T>::IsEnabled, and it'll only render the meter if the player is the correct class and has a weapon of that particular type.

The meters are instanced and created / removed in response to the post_inventory_application / localplayer_pickup_weapon events.

In theory you might be able to fake a class change and get a specific meter working if you don't care about the other meters for your existing class, but I can't be bothered to test. And it'd be wiped on resupply / item pickup, so it'd be kind of pointless.

Originally Posted by Benoist3012 They're not networked I believe so too, for instance the string attribute defining pipe bomb models for the iron bomber or quickie bomb launchers is only read on the client's end. Despite changing it server side I could observe no effects on the projectile model. [...]

Minor correction - the projectile models are only read on the server, not the client.

I'm working on adding string attribute support to (my fork of) TF2Attributes; an experimental release + announcement will be available soon, after I get a few remaining things sorted out.