[HamletEagle]

No, no. I just had a bad day yesterday, not related to you or with this plugin. Excuse me, I really apreciate that you are speding your time with me, cause I learned so much things from that. Sorry again.

Changes:
1. Throw effect fixed.
2. Support to amxmodx 1.8.3 added

Please check it again, this time I think everything is fine

[Arkshine]

No problem.

I'm starting to be out of suggestion, but don't worry I've still some in my pocket.

• First, just seen but you forgot to support linux and you current windows is awful long and not reliable.
  Linux :

  _ZN8CGrenade18ShootSatchelChargeEP9entvars_s6VectorS2_

  windows :

  83 ? ? 53 56 57 FF ? ? ? ? ? 33 (lazy to format myself!)

  And since we're using Okapi, let's use a treemap, which should work whatever windows/linux/old version and such.
  

  JTG.=hC'.Pr7.(~I.[_C'.Lq/&.fbA. ).)y!.p!Q$.k?m{.s9s{.N8='.*ml{.*aG$.lim{.C@9.!kl{.zbt{.w4I$.*C='.0n='._!Z$.L-A2

  You can use all, this should improve availability, and most likely it should work for all game versions.
  You can use something like that (of course feel free to adapt code it as you wish)
  
  PHP Code:

  public plugin_init()
{
    // CGrenade *CGrenade::ShootSatchelCharge(entvars_t *pevOwner, Vector vecStart, Vector vecVelocity)
    new const signature[] = { 0x83, 0xDEF, 0xDEF, 0x53, 0x56, 0x57, 0xFF, 0xDEF, 0xDEF, 0xDEF, 0xDEF, 0xDEF, 0x33 }; // 83 ? ? 53 56 57 FF ? ? ? ? ? 33
    new const treemap[]   = "JTG.=hC'.Pr7.(~I.[_C'.Lq/&.fbA. ).)y!.p!Q$.k?m{.s9s{.N8='.*ml{.*aG$.lim{.C@9.!kl{.zbt{.w4I$.*C='.0n='._!Z$.L-A2";
    new const symbol[]    = "_ZN8CGrenade18ShootSatchelChargeEP9entvars_s6VectorS2_";
   
    new bandle = okapi_get_function_ptr(symbol, treemap, signature);
    okapi_add_hook(okapi_build_function(bandle, arg_cbase, arg_entvars, arg_vec, arg_vec ), "OnShootSatchelCharge", .post = 1 )
}

stock okapi_get_function_ptr(const symbol[], const treemap[] = "", const signature[] = "", signatureLen = sizeof signature)
{
    new handle;

    if ((handle = okapi_mod_get_symbol_ptr(symbol)) || 
        (handle = okapi_get_treemap_ptr(treemap))  ||
        (handle = okapi_mod_find_sig(signature, signatureLen)))
    {
        return handle;
    }
    
    set_fail_state("ShootSatchelCharge() could not be initialized");
    return 0;
} 

• This code:

  while( ( iTarget = find_ent_by_class( iTarget , "func_bomb_target" ) ) ) 
      {
          iCount ++
      }

  You don't need to loop, just calling one time is enough to return a value. (Meaning if at least one entity exists).
  You should also check for "info_bomb_target" because you can have one of among both, or both at the same time.
  "func_bomb_target" is an entity which defines a touch zone. If such entity doesn't exist, it will check 250u around "info_bomb_target".
  Basically something like that should be enough:
  

      if (find_ent_by_class(-1 , "func_bomb_target") > 0 || find_ent_by_class(-1 , "info_bomb_target") > 0)
      {
          log_amx("Plugin paused, not a bomb map");
          pause("a");
      }

  As side note, with 1.8.3, a native has been introduced to check map objective and you could also do:
  

      if (!(get_map_objectives() & MapObjective_Bomb))
      {
          log_amx("Plugin paused, not a bomb map");
          pause("a");
      }

• this code:
  

      static id; id = pev( iEnt, pev_owner )
      static Buttons; Buttons = pev( id, pev_button )
      
      if( ( Buttons & IN_ATTACK2 ) ) //did player pressed IN_ATTACK2 button ? 

  This function is called often, you don't need to create variable for pev_button, and player's id retrieval should be done inside check. Picky suggestion but there is no reason to not retrieve data logically.
• I think you should use pev_origin instead of SetOrigin ; because the latter is used to link entity to the world, and that's something which has been done already when you call ShootSatchelCharge(), so pev_origin is enough and it will run less code internally.
• I will bother you again with 1.8.3 lol, but I would like you use amxclient_cmd if compiling with 1.8.3. This natives is the same, but allows others plugins to hook this "drop". This could be useful as such is often hooked.
• For safety reason, I think you should add a check if weapon is valid, and if g_iC4Id is valid as well before calling these 2 natives. This doesn't hurt to add this and prevent any error if others plugins remove c4 or if grenade creation is blocked, for example.

I guess my pocket is empty now.

[HamletEagle]

You are having a very big pocket, but not too big for me
I need the index for pev_button, so it should be there.
Btw, so much changes in 1.8.3, will be a pleasure to use it, I like the new datapacks features

[Arkshine]

Sorry about player's index, overlooked that. Glad to see you follow me \o/.

Ah! My pocket has a hole, and some things have tried to escape.

• static Float: ; at this point, code should be called one time and you are not going to throw a bomb each second. static is misused here, you should use new.
• You could add support for plugin pause/unpause (plugin_pause() and plugin_unpause()), where you would just enabling/disabling forwards.
• I'm concerned about BombDrop event. Like said, it's fired right after ShootSatchelCharge() is called, with the player's current origin. From radar point of view, it should not really matter ; but I know plugin which hooks bomb origin from this event ; hmm what to do. Well, if we want to do things properly, ideally you should block the original message (set_msg_block?) and resending one (emessage) with proper origin. Here, you could use actually TraceToss so you won't need to hook Touch. Well test & see what you can do?
• You don't <fun> and you will need <csx> for get_map_objectives() (don't forget define as well).
• Oh shit, I don't anything to say

[HamletEagle]

Due to so many updates the fun line remained there, I forgot to remove it. Yeah, I tested with TraceToss and it seems that's working well.

New version uploaded

[Arkshine]

Some things fell inside my shoes:

• You forgot something: all static inside bomb zone check should be new
• Game uses MSG_ALL, so do the same. Such message should be reliable anyway.
• That's a bad idea to block BombDrop from OnShootSatchelCharge because you will block such message if bomb is planted the normal way.
• The first #if AMXX_VERSION_NUM < 183 is wrong, you should define >= 183.
• No point to redefine MapObjective_Bomb
• It reminds me you did not readd rotation. I think it would be ok, but only on y axis.
• And that's all.
• Really.
• No joking.

[HamletEagle]

Done everything. About rotation, I decided to not re-add it.

[Arkshine]

What to say now...

Well, code is now good as it is.

I have still 2 things in my mind, but doesn't affect approval.

• You might want to let people customize how is thrown the bomb (factor and max velocity)
• More a personal opinion/experience: Your coding style is awful: hungarian notation doesn't make sense in pawn, you use too much spaces, and your variables are badly named. About the notation, pawn doesn't have type and plugins are short, such notation has no meaning and make code less readable. Especially if you would name properly your variables, it would be become even more redundant. The only notation which makes sense is g_ for global. Personally, anything global starts with an upper-case letter. But the most important is if variables were named properly, that's make the code comfortable to read, and you would understand relying on such notation is redundant. Well, I can't blame you because at the start I had the tendency to use a lot of spaces, with such notations ; but at the end you understand it's silly as hell. Just my cent.

About your presentation in first post:

• For now it doesn't have cvars, the explosion time is taken from mp_c4timer. I didn't addded a defusion system( yet ) but I'm planning to do it.

  This is kind of obsolete to say that.

• Open modules.ini and add at the end okapi.

  No you don't need to do that. Modules are auto-loaded depending the needs. The only exceptions where you need to enable manually are either for mysql/sqllite or if you have an AMXX module without pawn plugin associated (with a library).
• Your FAQ is not up-to-date
• About your 2 first sentences in Support ; well, it's not like you should support that, but technically your plugin should work on most of game versions ; and dproto should not matter anyway. You do what you want, but I would rephraze just that if by change the function is not found, that you won't support it.

Anyway, I think I can instant-approve this now. \o/

[HamletEagle]

Fixed the post, hehe, it was from the first version. Nothing to say, thx for approval. But, why you are saying that my vars are badly named ? Could you give me an example ?

[Arkshine]

I was meant because of the hungarian notation, but some are weird.
Some example how hungarian is silly:

_CBasePlayer_ItemDeploy : _ is weird ; and it doesn't tell you what it is. You could for example name ItemDeployHook or whatever which includes hook or forward. You get the idea.
szWindowsSign ; an example how this notation is stupid. Such var is used just few lines below. How does it help to use "sz"? It offers nothing, you know already what it does, that's not even a string. It's more natural to name simply signature. A signature implies a signature of bytes. A symbol is not a signature.
iHandle : you know already it's an integer. Handle can't be something else. Here 'i' is redundant. Actually I think it should be named address or functionAddress.
fVelocity : "f" alone doesn't make sense. You should use at least "vec". But you know that velocity can be only a vector, so velocity is enough. Or to be consistent playerVelocity. Another example how such notation is redundant.

Etc. etc.

The point is you may want to take time to properly name your variables, as it helps greatly for readability and you understand faster what code does.