Introduction
Technically, PAWN supports plugins natively, but there was never an SDK for them released for SA:MP. Back before the main SA:MP plugin SDK was released someone was working on it but they never finished and I had no clue what was going on. Since then, however, I have learnt a vast amount more and discovered that using these plugins wasn't actually that hard - so I wrote this library to use them. Well, I more combined existing bits of code from the SA:MP plugin SDK and the open-source implementation of PAWN 3.2.3664 found here.

Use
There are some minor differences between using this system and the original SA:MP plugin SDK for the main server, and I'll detail them all here. Note that this is mostly for development on WINDOWS - I've not made a Linux version yet but doing so won't be hard.

• Naming

I've simplified dll naming. Previously, you had to edit "helloworld" in a couple of places to change the name of the plugin - now everything is tied to the Visual Studio PROJECT name (note that this may be the same as the SOLUTION name, but that doesn't matter in the slightest):


In this example the plugin is called "npcdll" (for fairly obvious reasons), and the project is set up assuming that your plugin's directory is in "npcmodes/". This will create a file called "../../amxnpcdll.dll" (PAWN requires "amx<plugin name>.dll"), which should put it in the server root directory. I.e, my layout is:
If you put the plugin's project folder somewhere else, make sure you move the resulting .dll file to the server root (the same directory as "samp-npc.exe").

• Includes

The trick to this system is "#pragma library". Some of you may have seen this in "a_samp.inc" and other files, but its use in there is actually wrong. What that directive does is to instruct PAWN to load that library. Since our library is called "npcdll" and provides just one native, this is our include file:

• Natives

There is one small difference between SA:MP plugin natives and NPC plugin natives - "const":

SA:MP:
NPC:
Notice the second one is "cell const" instead of "cell". Practically this makes no difference since you don't actually change those values anyway, even with reference parameters (since then the value of "params" is a pointer not the value itself), but it does make copying code awkward.

• Load Functions

For compatability with SA:MP plugins, there are two other functions in these plugins:
You do standard setup such as registering natives in here as normal. The main difference here is that the functions "Supports", "Load", "Unload", and "ProcessTick" don't exist. The first one isn't needed, the next two can be easily simulated with "DllMain" (standard in windows dlls), and I'm sure there's a solution for the final one but I don't know it yet.

• Printing

"printf" does nothing, neither does the non-existant "logprintf". If you want to output debug information from your plugin, use "OutputDebugString" as such (note the use of "L"):
This outputs a Windows debug string that can be read using a program such as DebugView.

• Finally

That's it. If you use the solution in the download everything should work just fine. To make a new one just copy the whole solution directory. If you want to make your own solution then I suggest you read the "Advanced" section below...


Download
Get the basic project for Visual Studio here:

http://dl.dropbox.com/u/21683085/npcdll.rar

Advanced
As I said, this is a collection of several systems combined together to make it look as much as possible like standard SA:MP plugins, but it isn't really:

• Normal plugins are given handles to the PAWN internal functions such as "amx_GetPublic" (which is how the SA:MP GDK works); however, these plugins are NOT given these handles so instead have copies of the entire code, making the whole plugin much larger.
• The functions "AmxLoad" and "AmxUnload" are not actually called that - macros internal to Visual Studio rename them to their internal names of "amx_<project name>Init" and "amx_<project name>Cleanup". This is done just so that you don't need to rename the functions for every new project, instead everything is controlled centrally.
• In addition to the previous point, the ".def" file is still required due to incompatibilities between "__declspec(dllexport)" and "__stdcall" in Visual Studio. This again is generated at compile time with the correct function names based on the project name (see "Build Events").
• While the "SDK" includes in the project look the same as the standard SA:MP ones, they are not. "plugincommon.h" has been cut down, "amx.h" and "amx.c" are from the PAWN toolkit directly (hence the change to "const"), "osdefs.h" has been added, everything else is the same.

All of those things are trivial to do from a makefile on Linux, but I've not done so yet.

Credits
Full credits to ******.

Originally Posted by RyderX What the heck i was searching for Howto make a simple fucked npc thx crystal

Originally Posted by oMa37 But this tutorial is talking about how to write plugins for NPC scripts ...

Originally Posted by iLearner Put it somewhere in your siggy & stop bumping it... Not everyone who reads it replies to it.