[MPNumB]

Description:
This plugin adds a trail after the grenade. Each type of grenade has an unique color what can be changed by cvar. Unlike other grenade trail plugins, this one has two major differences. First is that trails are actually made out of arrows what show direction in what grenade is moving (so now if you came out of corner and see a trail - you can instantly tell where to expect grenade to be). Second and most important one is that by default only team mates can see trails of your thrown grenades (this gives you and your team mates advantage from misunderstandings - no more guessing did any of those 10 noobs behind you thrown flashes or what; but when it comes to enemy grenades - you still must spot the model of the grenade to see and identify grenade type).


Requires:
CStrike
CSX


Cvars:

* "amx_grentrail_status" - who can see the trail.
- "3" - everyone.
- "2" - team and everyone who's dead.
- "1" - only team. [default]
- "0" - plugin disabled.

* "amx_grentrail_color_fb" - flashbang trail color [rrrgggbbb].
- "000255255" - red 0; 255 green; 255 blue [default].

* "amx_grentrail_color_he" - explosive trail color [rrrgggbbb].
- "255063000" - red 255; 63 green; 0 blue [default].

* "amx_grentrail_color_sg" - smokegren trail color [rrrgggbbb].
- "031255127" - red 31; 255 green; 127 blue [default].

* "amx_grentrail_team_color" - extra trail line with owners team color.
- "1" - enabled.
- "0" - disabled. [default]


Additional info:
Tested in Counter-Strike 1.6 with amxmodx 1.8.2 (dev build hg21).


Credits:
Original idea came from AssKicR's plugin what was published in 2004/May/05. Method of showing trails taken from jim_yang's plugin what was published in 2007/Jan/21.


Change-Log:

* 1.2
- Added: Support for team color trail (this is another smaller trail what has no effect on the main one).
- Changed: Improved plugin performance.
- Changed: Renamed "amx_grentrail_team" cvar to "amx_grentrail_status".
- Changed: Renamed "amx_grentrail_color_sm" cvar to "amx_grentrail_color_sg".

* 1.1
- Fixed: An issue with team detection once player team was changed by some custom plugin.

* 1.0
- First release.

[ConnorMcLeod]

I would prefer to see get_players instead of this loop, but it is acceptable.
If you don't use cs_get_user_team you gonna have false results for get_user_team, so in that case you should really use get_players + teamname because you gonna have same false results so you won't need to check any team or alive status.

If you want a free from bugs plugin, then use cs_get_user_team.

End, i think that not reliable msg dest would be better as default setting.

[MPNumB]

Originally Posted by ConnorMcLeod I would prefer to see get_players instead of this loop, but it is acceptable. If you don't use cs_get_user_team you gonna have false results for get_user_team, so in that case you should really use get_players + teamname because you gonna have same false results so you won't need to check any team or alive status. If you want a free from bugs plugin, then use cs_get_user_team. End, i think that not reliable msg dest would be better as default setting.

I am aware of that bug, that when changing team it will result in some problems, due to get_user_team() issues. About get_players() - same problem, but you cannot select there dead or in specific team, so I would have to loop twice. In other words I do agree about cs_get_user_team() being a better solution - think will change to it after all in next update (I did actually think about this problem, but just didn't want to include FM or cstrike).

About message types... I don't know, I had experience in the past that MSG_ONE_UNRELIABLE and MSG_BRODCAST didn't reach the client, so here I'm quite skeptical.


// EDIT:


Updated to 1.1
Fixed: An issue with team detection once player team was changed by some custom plugin.

[ConnorMcLeod]

Originally Posted by MPNumB About message types... I don't know, I had experience in the past that MSG_ONE_UNRELIABLE and MSG_BRODCAST didn't reach the client, so here I'm quite skeptical.

You are right, but in those cases, reliable msgs would have made clients to be disconnected in some situations (i don't know which ones exactly), so i think that for such visual effects, it's not a problem if players don't see them and it's still better than being disconnected.

About get_players, you would still save some is_user_connected native calls and you could also filter bots and hltvs.

[MPNumB]

Originally Posted by ConnorMcLeod You are right, but in those cases, reliable msgs would have made clients to be disconnected in some situations (i don't know which ones exactly), so i think that for such visual effects, it's not a problem if players don't see them and it's still better than being disconnected. About get_players, you would still save some is_user_connected native calls and you could also filter bots and hltvs.

About MSG types one I must disagree. For example my HotVision plugin used to have MSG_ONE_UNRELIABLE and radar updates were random... Now by default it uses MSG_ONE and radar always gets updated, and no crash reports afaik. If I would use get_players() I would still have to filter team outside of it. Plus grenades aren't thrown every frame, so I think it's at least is acceptable that I filter alive and connected manually. If get_players() would have fixed team, than I would agree with you that it would be logical to use get_players() instead of making all filters myself. And just a little note, hltv shouldn't be filtered out if main cvar of my plugin is set to 2.

Being honest my loop method doesn't add an extra massive CPU load - it's simple, doesn't take much power, plus event isn't called that often anyway. =P

In fact if you'd insist on it, I'd simply use Bit system and when user connects/disconnects would get is it hltv or bot, and set connected/disconnected status. I just don't trust find get_players() as being an efficient method of filtering if you are using various modules.

[ConnorMcLeod]

About get_players, we agree, i told in my first post that the loop is acceptable (because of the frequency it gonna be called). I would use get_player though

About reliable msgs, i said that only in some situation i will kick players, and i coul'nt tell in which situations, so considering that the plugin only add some visual features that won't break the game if they are not sent, i really think it would be better to use non reliable msgs by default, that's not a must though.

Approval will depend on legitimity to release a plugin that has already 2 similar plugins and new features yours offers.

[MPNumB]

Well yep, I do agree with you about get_players(), but still before implanting it if it would be fixed I'd ask information for a method of pre-saved filters (what would be faster - checking information saved in variables or using get_players()). =)

Yes, I understand that sometimes they do crash the client, though I don't think this will be the case - it's not a new round event. However I must disagree - this visual effect does effect the gameplay. If grenade wont have a trail, player will tend to think that grenade owner is an enemy. Plus reason behind why I made this plugin, is so people will have advantage over noobed team mates who don't care about their friendlies being blind, or under explosion, or confused by sg bounce sound.

I am aware that there are two other plugins just like this. I wouldn't make and submit my version if I wouldn't see a big enough potential of what is improved in my version. Average and/or less skilled player wont care much about the difference, but for skilled players playing with less skilled people (so to speak) it will be a major difference on the gameplay (much less worrying that probability of death from actions of friendly is higher than from enemy). =)

[matsi]

Looks nice...

GJ

[MPNumB]

Updated to 1.2
Added: Support for team color trail (this is another smaller trail what has no effect on the main one).
Changed: Improved plugin performance.
Changed: Renamed "amx_grentrail_team" cvar to "amx_grentrail_status".
Changed: Renamed "amx_grentrail_color_sm" cvar to "amx_grentrail_color_sg".

[vato loco [GE-S]]

gj plugin looks nice