[KWo]

Well - I have enough bug reports as "Run time Error - invalid player" - causing by any AFK plugins. I don't see the reason to put in all possible plugins and in all functions the check if the user is still there or not. The problem is always the same - if there is some AFK plugin it may ALWAYS happen , that someone gets kicked which confuses all plugins. That check (as safety code) is done in AMX code (got that info from Orangutanz) - why it cannot be done the same way in AMX X?
Note - if we want to keep the performance - doing all these checks in PAWN if the user is still there (is_user_connected) will cause slowing down work of the plugins more than doing the same in core (somewhere that check must to be done).

[Orangutanz]

I suppose this is something to review for AMXModX 1.77.
To speed up AMXModX's performance a little more and to add a suppression system so you can ignore warnings

To be honest with you KWo I just reviewed amxmodx.cpp and its near enough the same as AMX Mod, the only difference is I created a function to handle the client checking which in turn can display the warnings or not dependant on a CVAR setting.

[BAILOPAN]

What on Earth are you talking about? AFK plugins? Since when is a plugin away or near a keyboard?

The run-time errors are there to prevent you from accidentally making mistakes. If you request the name of a user who isn't connected, AMX Mod X halts the plugin because obviously it is going to try to do something with the name.

[Brad]

Obviously the only right thing to do here is make it return, "Gaben", when it can't otherwise determine a name.

[Orangutanz]

Originally Posted by BAILOPAN The run-time errors are there to prevent you from accidentally making mistakes. If you request the name of a user who isn't connected, AMX Mod X halts the plugin because obviously it is going to try to do something with the name.

Still need a suppressing system implemented, yes warnings etc are good can't argue about that. However server providers don't really need to see these warnings, which is why in turn they end up coming on these forums and reporting bugs to plugins in this section which you don't want

[BAILOPAN]

They SHOULD be reporting bugs, but to the respective authors. If they want to suppress errors, they should turn logging off. I honestly don't see the purpose of this report. If you write proper code, you won't get errors. If you're running an old plugin, those errors need to be caught because otherwise its mysterious faults will pop up and no one will know what's wrong.

[KWo]

Originally Posted by BAILOPAN If you write proper code, you won't get errors.

Because I cannot predict when someone will get kicked by some AFK plugin the users are using, it means to write "proper code" I should use ALWAYS in any function I'll write the check

if (!is_user_connected(id))
   return PLUGIN_HANDLED

before I'll use such functions - get_user_name, get_user_team, get_user_weapon etc. Otherwise I may expect some day someone will write me the bug report because these natives will return invalid player. Imagine the plugin is using 10 functions, each with 1 of these natives. Then imagine You have 10 plugins using these natives the same way (10 functions, each using one of these natives). To have "proper code" I need to put 10*10 = 100 is_user_connected checks at the top of each function (well, maybe there are aslo some other natives I should do the same check before using them). It means I need to add in sma 100 times is_user_connected and I'm stilll not sure what function before and how many I need to add that check. Finally probably we will get about 200 times a need to use is_user_connected in sma codes (of these 10 plugins).
What "on Earth" I'm trying to say is this - that check (is_user_connected) should happen inside these natives in some *.cpp files with the result as return PLUGIN_HANDLED. It's because of 2 reasons - 1. I cannot predict all possible situations I should really add them (to be sure - as I wrote above - I should write that check before all these natives - which will look completly crazy in code), 2. Doing it in *dll - will execute it faster than in *amxx.

Another thing - there is something missing even for the native client_disconnect. It looks like inside that forward function in sma I cannot use get_user_name (to say "Our friend Roger left us"), I cannot use cs_get_user_team to count some weapons they can be used for the team the user just left etc. Maybe the problem is - the info about the player is cleared too fast - that's maybe the reason we have the problem when some AFK plugin is used? We do have the id of the player, but we cannot use any info about him (as get_user_xxxxx).

[BAILOPAN]

You're still not making any sense at all. Very few natives in Core (I only count two or three) actually check whether a player is in game. The actual "invalid player" message comes from passing an index which goes above the number of max players. That is a serious bug in code and should never be silently ignored.

is_user_connected() is designed to check if a given player is put in server, or "in game." This error check is only done on natives where the native would otherwise crash. To avoid calling a native each time, you can do this:

bool:g_ValidPlayers[33]

public client_putinserver(id)
{
   g_ValidPlayers[id] = true
}

public client_disconnect(id)
{
   g_ValidPlayers[id] = false
}

Code correctly and you won't run into these problems. If you have a specific question about a specific native, feel free to ask questions about it in the Scripting section (and I will try to reply as best I can).

The error messages will not be removed unless a specific native, after careful consideration, is determined to not need the in-game checks. The invalid index checks will never be removed. Feel free to post a request about certain natives and they will be looked into.

[VEN]

Notes:

1. On user's disconnect you actually can get his name using get_user_name
2. cs_get_user_team has a check for client connect, but actually you are able to get the user's team even oh his disconnect using get_pdata_int and corresponding offset (see cstrike.h).
3. As for other information - you have to cache it, so you will be able to retrieve it from your cache on client's disconnect.

And i agree with Bail - errors is the coders' fault. Coder should know when it's necessary to do a corresponding check. For example i can't remember when i had the problem related to the topic, and probably because i know when i should perform such checks...

EDIT:

And, Bail, is_user_connected could return true even before client put in server.

EDIT2: no, it's not...

[XxAvalanchexX]

You said you don't want these runtime errors to be displayed. I don't have much experience with this native, but can't you use set_error_filter to do just that?

The any times you should really need to check if a user is connected at the top of the function, in case of AFK kickers or something, is for functions that are run from a task. Not every single one of your functions.