[WATCH_DOGS UNITED]

Reply to the fucking post instead of leaving without replying. Its hard to say that plugins are no longer being approved because this is not necessary?.

[HamletEagle]

Firstly, regarding "optimization" I was only talking about this specific line in your changelog:
"Optimized from <cstrike> to <fakemeta_util>". I never reffered to any features you may have added or modified, try to understand the topic that is discussed before replying and confusing everyone. With fakemeta you set am offset which is the same thing cstrike does under the hood, hence this is not an optimization. An optimization is making your plugin run faster or use less memory during runtime(NOT the file size on disk).

Secondly, with such an attitude your plugin is not likely to be reviewed for approval anytime soon. I suggest you calm down. I was going to reply anyway so there is absolutely no reason to loose your temper like that.
The staff here is made out of volunteers and anything we do is on our free time. You don't get to decide what and when something is done. Asking nicely is always appreciated.

Plugins are still reviewed, just at an insanely slow pace becausw people have lives outside this forum, you know?

[WATCH_DOGS UNITED]

Right. Everyone knows that, we wouldn't want this plugin not to be approved as it uses less code and works perfectly, different from others and doesn't take more than 5 minutes to know about it.

Why haven't you brought up the subject of the HUD effect yet? When using <cstrike> the HUD effect is not the same green as the original, it is yellowish. With <fakemeta> the effect is exactly the same as the original so how can we not call this optimization if it improves plugin quality? That's the main reason on the table, the result in the game's HUD.

[HamletEagle]

Truth be told, your plugin is actually way too simple to be approved. I believe this plugin falls under the following rule:

Do not post plugins "just for the sake of it". ... Please take the time to expand your knowledge and produce some quality work.

Also, the archive format is breaking the rules:

For packages, use only zip, [tar.]gz, [tar.]bz2. Plugins using other compression formats should not be approved, this includes RAR and 7z.

For reference: https://forums.alliedmods.net/showthread.php?t=21956

The code, as short as it is, contains several issues: ResetHUD should not be used to detect spawn. You have Ham_Spawn for that. Do not access cvar values inside a loop, retrieve them before. OFFSET_MONEY is not the correct offset name, it should be m_iAccount - this helps people better understand the code and find out what the offset is supposed to do/how it is supposed to be used(one can take the offset name and search in a project like regamedll to learn more).

Unapproved for now, if you do decide to add more features PM me to request a review. As a side note, try to not lose your temper this time. I don't have the energy or willingness to deal with such behavior.

[WATCH_DOGS UNITED]

For packages, use only zip, [tar.]gz, [tar.]bz2. Plugins using other compression formats should not be approved, this includes RAR and 7z.

Do you mean that AlliedMods.net prefers to store 1000MB .zip than 500MB 7z ? That's the dumbest thing we've seen on this forum.

[HamletEagle]

I'm not actually sure why that is, but there must be a reason.

[Mordekay]

As someone explained: All files must be available without the need of extra software. Zip-archives are readable by default by any OS. 7z requires, well, 7zip.

[WATCH_DOGS UNITED]

Originally Posted by Mordekay As someone explained: All files must be available without the need of extra software. Zip-archives are readable by default by any OS. 7z requires, well, 7zip.

Done.

Originally Posted by HamletEagle ResetHUD should not be used to detect spawn. You have Ham_Spawn for that. Do not access cvar values inside a loop, retrieve them before.

Originally Posted by HamletEagle OFFSET_MONEY is not the correct offset name, it should be m_iAccount - this helps people better understand the code and find out what the offset is supposed to do/how it is supposed to be used(one can take the offset name and search in a project like regamedll to learn more).

ResetHUD was not used exclusively for spawning but to deliver money to players as quickly as possible. This is not a problem as the ResetHUD function in that case will only be called once, not multiple times and it depends on the event and OFFSET you are using. We already know about Ham_Spawn and HLTV and we also know that they are ineffective ways to detect spawn as the functions are only called in a short amount of time which is based on the first player to appear and not each player. An example of how this is a problem: in the first or second round when you program with Ham_Spawn / HLTV to deliver weapons / money or anything else to players only the first ones to spawn will be affected while others who are still connecting will not be. That's because the role is not based on each player it is based on the first [ and the ones that are present in the time interval ].

ResetHUD is only a problem when doing multiple operations at the same time, it is not the case here, it is not always the case; if it were, the players would receive and receive money several times, something that doesn't happen. Even if that were the case it's possible to fix this simply with a reset_count++ and set the function to only occur on the first count. We know this works because we've already done it in a function of another plugin that handed out money multiple times to players. So just to make it clear that both Ham_Spawn and HLTV are still ineffective means but we believe there is a solution for that.

About caching cvars we don't know what you mean by that.

About OFFSET_MONEY, the code is very small and someone can easily understand that this is m_iAccount by looking at 115 in #define.

[HamletEagle]

about Ham_Spawn and HLTV and we also know that they are ineffective ways to detect spawn as the functions are only called in a short amount of time which is based on the first player to appear and not each player

HLTV is a global event, that's true. But Ham_Spawn is called for each individual player. Moreover, Ham_Spawn is a hook for CBasePlayer::Spawn which is the function the game actually uses to spawn players. For this reason, it can not be ineffective, it's literally the code used by the game to spawn players.
What you said after that makes absolutely no sense, unless it's caused by bugs in your code and if so, then that's on you: fix your code.
Please do not insist Ham_Spawn is bugged, it is not. Again, it is a hook for the function from within the cs mod dll. Ham_Spawn is not ineffective, it is the only PROPER way to detect when a player is spawned.
All hamsandwich functions are just hooks of the corresponding functions from the game's code. All of them work exactly how they are supposed to work and can not be bugged.

Caching cvars means to not do get_pcvar_num multiple times in a loop, this is not needed. Cache them into a variable. See below:

PHP Code:

new cvarValue = get_pcvar_num(cvar)
for(...)
{
//use cvarValue , not get_pcvar_num
} 


It does not matter the code is short. The problem is that people may not know what that offset is or what it's supposed to do. Also, the value doesn't help in any way - is everyone supposed to remember all offset values? By using the proper name they can either search that name in this forum and quickly learn about it or check regamedll on github to see how the offset is used inside the game and understand it on a deeper level.
Plus, it isn't just about this particular offset. Good coding practices should always be applied, even if in some cases it doesn't make as big of a difference as in other cases. Tho readability is always important so please do no sacrifice it.

[WATCH_DOGS UNITED]

Thanks for explaining about caching cvars.

As for Ham_Spawn we at no time say it is buggy we say it is inefficient and in fact it is. You said that we can fix the code we used to fix the problem but the code we used was not created by us, we asked Bugsy for help and he did the complete code to give AWP for players:

PHP Code:

#include <amxmodx>
#include <cstrike>
#include <fun>
#include <hamsandwich>


#define OFFSET_AWP_AMMO 377

public plugin_init()
{
    register_plugin( "Only AWP MOD" , "0.1" , "N/A" );
    RegisterHam(Ham_Spawn, "player", "e_Player_Spawn", 1);
} 

public e_Player_Spawn()
{
    set_task( 1.0 , "Strip_And_Give" );
}

public Strip_And_Give()
{
    new iPlayers[ 32 ] , iNum , iPlayer;

    get_players( iPlayers , iNum , "a" );

    for ( new i = 0 ; i < iNum ; i++ )
    {
        iPlayer = iPlayers[ i ];

        if ( CS_TEAM_T <= cs_get_user_team( iPlayer ) <= CS_TEAM_CT )
        { 
            strip_user_weapons( iPlayer );

            give_item( iPlayer , "weapon_knife" );
            give_item( iPlayer , "weapon_awp" );

            cs_set_user_bpammo( iPlayer , CSW_AWP , 30 );
        }
    }
} 


If you are willing, check if the plugin will deliver AWP to all players in the first and second round who are connecting. This is frustrating and what we say about the time gap does make perfect sense, this is the reason for the problem not to occur in the next rounds since all players spawn at the same time.