[NiHiLaNTh]

if you are using any kind of custom weapon system, those stocks are pretty useful than.

[Kowalsky]

Originally Posted by HamletEagle This way of thinking appears over and over and over and over ..... It's wrong, and I'm tired of hearing it. Including one module, even for one function used used only in one place is perfectly fine as long as it does the job better than any other tool, and the difference is not trivial.

Let me present my logics here and argue a little bit.

Let's take a simple example where we wanna get some user's team, we can do this with cs_get_user_team native, right! Would I enable cstrike module for that? No! Because we can get this user's team with the same amount of native calls (=1), which is either get_user_team or get_pdata... (fakemeta way). Same would go to cs_get_user_money and many many many other natives. Why would I want to load a heavy module library with tonns of natives just to use one of them when I can achieve the same result with some other module I'm already using with the same amount of native calls, which in our example case is equal to 1?

[Arkshine]

Your logic doesn't make sense much. What do you mean by "heavy module"? Do you know and understand the difference between get_user_team and cs_get_user_team? Are you running a server with few Mo of ram?

[klippy]

If any of your plugins already uses cstrike (and at least one probably does), cstrike is already enabled and running, and you lose nothing by including it.

[Kowalsky]

Originally Posted by Arkshine Your logic doesn't make sense much. What do you mean by "heavy module"? Do you know and understand the difference between get_user_team and cs_get_user_team? Are you running a server with few Mo of ram?

Yes I do. In cs_get_user_team and fm_get_user_team the offset is being "taken". However in get_user_team - teamID entity. It is believed that get_user_team might return a wrong index in certain situations. Anyways, I am usually using the fakemeta way of getting a user's team (which is an identical replacement of cstrike native). And answering your question regarding ram, yes, I do have quite limited amount of RAM available.

Klippy, I am not using cstrike module, it is not used anywhere, I do not run so many plugins..

No, but for real for me it doesn't maje sense to include a module just to use one native. A module with huge library like fun/cstrike...

[Arkshine]

No you don't, and you don't answer at all, but I understand now you don't know really what you're talking about.

Module memory footprint is trivial. What do you mean by "huge library"?

get_user_team is generic and based on TeamInfo event. Any known issue with it should be solved in dev build. Depending the context native might be unreliable (a team can be changed without this event from a third-party plugin).
cs_get_user_team is based on the player's private data. Internally, It basically retrieves the value of m_iTeam member of CBasePlayer class. More reliable in a way. The whole point having a module with such natives is because in 1.8.2 it requires "offsets" which are hard-coded in the module and could be changed if the game is updated. If it happens only module needs to be updated. So using fakemeta for example without valid reasons to retrieve such team value and hard-coding offset in a plugin is really silly. Note that in dev build, game data are now hard coded in config files.

The only reason you would want to avoid a module be loaded is if there is a known issue about it, which is not the case.
The only reason you would want to convert a specific native is because you need more control on what it does.

If the concern is the CPU, most of the modules do nothing when loaded. Some are doing things by hooking engine/mod functions, but stuff done there is usually only checks or information retrieval. It makes no difference. If you are scared of that, you should probably uninstall AMXX because the core is doing much more than you could imagine and more than the modules.

To know what are the modules loaded, check from console:
- amx_showrcon meta list
- amx_showrcon amxx modules