SUGGESTION: Ability to use this plugin directly in a sampGDK gamemode (?) about fixes-plugin HOT 1 CLOSED

OK, that seems like about 7 different issues in one, so I'll try answer them all:

1. Using this directly. I've actually mostly enabled this already, by (half accidentally) writing a generic system for defining natives, you can just do:

// In your header:
NATIVE_DEFN(SetPlayerPosAndAngle, bool(int playerid, float x, float y, float z, float a));

// In your code:
NATIVE_DECL(SetPlayerPosAndAngle, bool(int playerid, float x, float y, float z, float a))
{
	// Implementation here...
	SetPlayerPos(playerid, x, y, z);
	return SetPlayerFacingAngle(playerid, a);
}

That example is already in the code, just as a test. You don't even need to do anything else to add the native to the AMX, it is done via global object static initialisation. You can either just use that as a normal PAWN function, and could access it via sampgdk, or more directly by adding this to your plugin:

PLUGIN_NATIVE(SetPlayerPosAndAngle, bool(int playerid, float x, float y, float z, float a));

That will create an import symbol to access the native directly. You might also notice that there is no mention there of AMX * amx, cell * params - all the casting is done automatically by a wrapper (which is bypassed when using the import from another plugin). I'll write more about that later if I can be bothered, but they can be accessed (they will both be NULL if called from a plugin), and you can do varargs as well.

2. I'm not using AMX redirects - they are too order dependent, instead I'm using subhook redirects, which are much lower-level.

3. Namespaces I'm still playing about with - I'm thinking of making the import/export/hook/natives thing I wrote a separate library so that any plugin can declare their natives quickly and export them. Possibly change it to use namespaces as:

NATIVE_DEFN(fixes, SetPlayerPosAndAngle, bool(int playerid, float x, float y, float z, float a));

4. Can you expand on the logcore problems please? I've not used it much, but it seemed like a good solution (assuming it worked) for compatability with other plugins.

5. No. One of my least favourite things about the PAWN fixes include was the use of a single file. There was a good reason for it and it couldn't be changed: it made download and inclusion very easy - just get one file and you are done, which was important. However, it made the code horrible. This is not a multiple-million line project, there is no need to worry about compile times, which will be sub-one-second. I'm currently more worried about server startup time, loading this plugin seems to stall the server for about 20 seconds (but I've got a feeling that's actually caused by my AV not liking the fact that a .dll is constantly changing and doing strange things with code manipulation, so shouldn't be a problem for release).

6. I'm not sure what you're talking about with the callbacks. If you were using this from another plugin, you wouldn't need to call them directly, since sampgdk would take care of that. If you are talking about within this plugin, the callbacks aren't really Internal, since they are a vital part of the plugin itself.

7. Kalcor isn't going to do anything, but I'm quite happy with my new solution for hooking, declaring, and calling natives. You can also hook them in an almost identical way to the code for declaring them above:

// In your header:
HOOK_DEFN(SetPlayerPos, bool(int playerid, float x, float y, float z));

// In your code:
HOOK_DECL(SetPlayerPos, bool(int playerid, float x, float y, float z))
{
	// Implementation here...
	return SetPlayerPos(playerid, x, y, z + 6.6);
}

I have just realised that DEFN and DECL are the wrong way round though - the definition is declaring it, and the declaration is defining it. You can also use the exact same method for importing this hook in to another plugin and calling it directly:

PLUGIN_NATIVE(SetPlayerPos, bool(int playerid, float x, float y, float z));

Using the same macro for importing both natives and hooks is important - it means that the author of the other plugin doesn't need to worry about which it is (or know which, or care if it changes). Currently that import has no namespace, but I'll fix that as I wrote above.

from fixes-plugin.