[XxAvalanchexX]

Thanks everyone. I believe I implemented all the recommended optimizations, as well as added two forwards (frostnades_player_chilled and frostnades_player_frozen). Please let me know if I didn't do that right. It seems to work, though.

That forward thing is really neat, ha! I never knew about that. How long has it been in AMXX--a while?

Ava

[xPaw]

Originally Posted by XxAvalanchexX Thanks everyone. I believe I implemented all the recommended optimizations, as well as added two forwards (frostnades_player_chilled and frostnades_player_frozen). Please let me know if I didn't do that right. It seems to work, though. That forward thing is really neat, ha! I never knew about that. How long has it been in AMXX--a while? Ava

You could get rid of fakemeta_util, and then this plugin will be able to be compiled with forum compiler.
You use only 2 natives from that include: fm_set_user_maxspeed and fm_find_ent_by_owner

[Arkshine]

xPaw, this include is official and provided by default in the amxx package, so, it's available too for the webcompiler.

[Arkshine]

To answer Ava', yes, fairly a while !

Sorry, I would like to bother again on some others details :

• About fm_find_ent_by_owner. Don't use that, it's slow and not appropriate here. You want to know the active item index of a player, simply use : get_pdata_cbase( id, 373 ), that's all. It's a player's offset, and it's recommended to create a constant like const m_pActiveItem = 373; (or using a define if you prefer) so you get : get_pdata_cbase( id, m_pActiveItem ).
• About fm_set_user_maxspeed, now you use fun, use directly set_user_maxspeed. Faster. And btw you can remove fakemeta_util.
• About the colors stored in rgb used in a message. You use floatround. It's really unneeded. Color is a integer value between 0 and 255. Simply cast the float. It will be considered as an integer and will take the value before the '.', so like : write( _:rgb[0] ). Simple optimization.
• To control the player's speed, you better hook Ham_Player_ResetMaxSpeed, it's called when it's needed and set_user_chillfreeze_speed should be called only there. No need to reset speed more than necessary.
• event_ammox, event_curweapon, event_flashed and event_hideweapon are kind of inappropriate/useless. It's called more than necessary and therefore update speed/icon more than necessary. You should replace them by Ham_Item_Deploy and Ham_Item_Holster (both as post). Since speed will be managed by ResetMaxSpeed, all you have to do is to manage icon/ammo. In Deploy, to activate the flash status and in Holster to set on/off status and checking ammo. (You can use pev_weapons since the bit is removed when no ammo, so you can set icon to on/off depending the result of the check).
  About the end of flashbang, there is a way to get it through some player's offsets. For reference :
  

  float	m_flFlashedUntil;		// 514/519  
  float	m_flFlashedAt;			// 515/520
  float	m_flFlashDuration;		// 516/521
  float	m_flFlashHoldTime;		// 517/522
  int	m_iFlashAlpha;			// 518/523

  m_flFlashedUntil holds the game time where you are not blind anymore, it means actually that's not the real end of the flashbang, it's a bit before. CS does that : m_flFlashedUntil = GameTime + ( m_flFlashHoldTime * 0.33 ). Since in your case you need to get the real end of the flashbang, you have to do : EndOfFlashbang = m_flFlashedUntil + ( m_flFlashHoldTime - ( m_flFlashHoldTime * 0.33 ) ).. Offsets are more reliable than hooking ScreenFade, though hooking CBasePlayer::Blind() (Ham_CS_Player_Blind in the unofficial version) would be the most reliable. (Btw, the offsets are set inside this function)
• About fwdRetVal, I would do instead fwdRetVal >= PLUGIN_HANDLED, so any positive value would work.

Well, start with that.

[Nextra]

Things changed while this plugin was sitting unapproved ^^

Another thing: You could use set_user_rendering from the fun module, instead of setting the parameters by four separate set_pev calls. I believe that would be better aswell.

[XxAvalanchexX]

Originally Posted by Arkshine About fm_find_ent_by_owner. Don't use that, it's slow and not appropriate here. You want to know the active item index of a player, simply use : get_pdata_cbase( id, 373 ), that's all. It's a player's offset, and it's recommended to create a constant like const m_pActiveItem = 373; (or using a define if you prefer) so you get : get_pdata_cbase( id, m_pActiveItem ).

OK, I've done that. Is it get_pdata_cbase because it returns a CBaseEntity index?

Originally Posted by Arkshine About fm_set_user_maxspeed, now you use fun, use directly set_user_maxspeed. Faster. And btw you can remove fakemeta_util.

OK, done.

Originally Posted by Arkshine About the colors stored in rgb used in a message. You use floatround. It's really unneeded. Color is a integer value between 0 and 255. Simply cast the float. It will be considered as an integer and will take the value before the '.', so like : write( _:rgb[0] ). Simple optimization.

Also taken care of, I think. I ended up changing it to retrieve the cvar as integers instead of floats in most cases, but I did use _: instead of floatround for a couple other cases.

I know _: is like a cast to integer, but what does it really do? That is, does it really convert the number's representation, or does it just let you pass a float around like an integer without the compiler yelling at you?

The reason I ask is because using this same method (_: instead of floatround) using set_user_rendering did not work as expected. For instance, doing a set_user_rendering glow shell with amount = _: (1.0) had the effect as if the amount was 255. Also, if this truly converts numbers, why is there a "float" native, instead of just using Float: ? But if it doesn't truly convert the numbers, why does it work for messages?

Originally Posted by Arkshine To control the player's speed, you better hook Ham_Player_ResetMaxSpeed, it's called when it's needed and set_user_chillfreeze_speed should be called only there. No need to reset speed more than necessary.

Thanks, done.

Originally Posted by Arkshine event_ammox, event_curweapon, event_flashed and event_hideweapon are kind of inappropriate/useless. It's called more than necessary and therefore update speed/icon more than necessary. You should replace them by Ham_Item_Deploy and Ham_Item_Holster (both as post). Since speed will be managed by ResetMaxSpeed, all you have to do is to manage icon/ammo. In Deploy, to activate the flash status and in Holster to set on/off status and checking ammo. (You can use pev_weapons since the bit is removed when no ammo, so you can set icon to on/off depending the result of the check).

Well, I experimented with this a bit, and it didn't quite work as well as I'd like.

Neither Ham_Item_Deploy nor Ham_Item_Holster are called when the player buys a new grenade, which event I need to detect for the sake of the icon. Also, Ham_Item_Deploy is not called in all cases--for instance, if you pick up a grenade from an armoury_entity with auto weapon switch, it isn't called, which is a problem. Am I doing something wrong? UPDATE: See this post about Deploy and cl_autowepswitch.

Since I need to detect when the player switches weapons and when his grenade ammo changes, I stuck with the CurWeapon and AmmoX events, which I believe correspond to these events pretty well. Do you think that's acceptable? I did add a check in CurWeapon to avoid re-doing the icon every time the player shoots, however (which calls CurWeapon each time).

Originally Posted by Arkshine About the end of flashbang, there is a way to get it through some player's offsets. For reference : float m_flFlashedUntil; // 514/519 float m_flFlashedAt; // 515/520 float m_flFlashDuration; // 516/521 float m_flFlashHoldTime; // 517/522 int m_iFlashAlpha; // 518/523 m_flFlashedUntil holds the game time where you are not blind anymore, it means actually that's not the real end of the flashbang, it's a bit before. CS does that : m_flFlashedUntil = GameTime + ( m_flFlashHoldTime * 0.33 ). Since in your case you need to get the real end of the flashbang, you have to do : EndOfFlashbang = m_flFlashedUntil + ( m_flFlashHoldTime - ( m_flFlashHoldTime * 0.33 ) ).. Offsets are more reliable than hooking ScreenFade, though hooking CBasePlayer::Blind() (Ham_CS_Player_Blind in the unofficial version) would be the most reliable. (Btw, the offsets are set inside this function)

Thanks--I changed it to check the offsets. I think that works best for what I had in mind with the flashbang stuff.

Originally Posted by Arkshine About fwdRetVal, I would do instead fwdRetVal >= PLUGIN_HANDLED, so any positive value would work.

I do see your reasoning there. I think the reason I chose not to do it that way is because I was viewing the PLUGIN_* defines like an enum. That is, that I should not rely on their literal values--e.g. what if they add PLUGIN_CONTINUE_RAINBOWS = 3 in the future? But they didn't actually use an enum, so is it OK to rely on their values in this case? Also, do you think someone would ever intentionally return a value greater than PLUGIN_HANDLED_MAIN?

Originally Posted by Nextra Another thing: You could use set_user_rendering from the fun module, instead of setting the parameters by four separate set_pev calls. I believe that would be better aswell.

Thanks, done.

[jim_yang]

you can't simply use _: to cast a float to int, or use Float: to cast an int to float, because the bit patterns of int and float are different.
example
0011 1111 1010 0000 0000 0000 0000 0000 (mem) = 1067450368 (int) = 1.25 (float)
new a = 1067450368;
Float:a = 1.25;

new Float:a = 1.25;
_:a = 1067450368;

use float() or floatround() is ok, because amxx has a compiling optimizer, it will replace these functions with system code if your machine supports. so it will cast the number directly instead of the function call.
just like C does the something like this:
int a = 10;
float b = a;
here b = 10.0

[Arkshine]

My bad about the _:, I've confused with something else. Jim is right. So, Ava, where you have used _:, back to floatround.

About the icon, you're right, I did not think about getting a grenade. What you have done is a bit better but sorry still not acceptable. Look, with your way, you are sending a message at each weapon switch whatever you have a grenade or not.
To hook when a player gets a grenade whatever the situation, I guess Ham_Item_AddToPlayer would do the job. It would avoid to rely on event called often. So :
- Ham_Item_AddToPlayer ; to know when a player gets a new grenade (on)
- Ham_Item_Deploy ; to know when player holds a grenade (flash)
- Ham_Item_Holster ; to know when player uses all his grenades (off) or has still ammo and switch weapon (on)

About fwdRetVal, it was just in case where people would use var which holds some value > 0 and could write for example : return myvar[id]; directly. So it would allow player using PLUGIN_HANDLED or any others positives values. Just a small thing. In your code, you just need to know if you block or not, so it would make sense to consider <= 0 doesn't block, > 0 blocks. What I mean is it doesn't hurt to be more flexible here, even though at the end it's just to have less code to write. Anyway, both is are fine, just a detail.

[XxAvalanchexX]

Thanks guys.

Originally Posted by Arkshine About the icon, you're right, I did not think about getting a grenade. What you have done is a bit better but sorry still not acceptable. Look, with your way, you are sending a message at each weapon switch whatever you have a grenade or not. To hook when a player gets a grenade whatever the situation, I guess Ham_Item_AddToPlayer would do the job. It would avoid to rely on event called often. So : - Ham_Item_AddToPlayer ; to know when a player gets a new grenade (on) - Ham_Item_Deploy ; to know when player holds a grenade (flash) - Ham_Item_Holster ; to know when player uses all his grenades (off) or has still ammo and switch weapon (on)

I see. But how should I handle the case where Ham_Item_Deploy apparently isn't called when picking up a grenade from armoury_entity?

[bibu]

Originally Posted by XxAvalanchexX isn't called when picking up a grenade from armoury_entity?

register_touch ?