SA-MP Forums

Go Back   SA-MP Forums > SA-MP Scripting and Plugins > Plugin Development

Reply
 
Thread Tools Display Modes
Old 13/02/2019, 05:44 PM   #1
Y_Less
Beta Tester
 
Y_Less's Avatar
 
Join Date: Jun 2008
Location: 629 - git.io/Y
Posts: 15,673
Reputation: 3220
Default Run-time plugin feature detection

Plugins provide natives to do things. This is great, but if you write a library sometimes you want to do one thing if the plugin exists and another thing if it doesn’t. Until now the best way was to include (or tryinclude) the plugin’s include and use them, but this would cause issues if a user had the include but didn’t load the plugin. Simply calling the native won’t work - all the natives are checked for existence prior to the script starting - hence all the famous runtime error 19s, and nativecheckers. The goal has always been to be able to detect which natives exist at run-time, use them if they do, but not error out if they don’t. I finally figured out a way to do this based on an obscure AMX feature - you can use negative native indexes to not put them in the AMX header:

Code:
#define NATIVE_PrintAmxBacktrace (-5)

native PrintAmxBacktrace() = NATIVE_PrintAmxBacktrace;

main()
{
    if (QueryNative(NATIVE_PrintAmxBacktrace)) PrintAmxBacktrace();
}
There are at least two possible ways to write QueryNative while being backwards-compatible.

V1:

Code:
stock QueryNative(id)
{
    #emit LOAD.S.alt id
    #emit ZERO.pri
    #emit LCTRL 10
    #emit RETN
    return 0;
}
LCTRL 10 would be a new control register, somehow hooked by every plugin, that returns 1 if the specified native index exists. This would require a lot of AMX_Exec hooking though.

V2:

Code:
#define QueryNative(%0) getproperty(.id = 0x504C5547, .value = (%0)) // !"PLUG"
This is simpler - just a hook of the getproperty native looking for a special domain (id) for plugin natives.

I’ve not worked out all the details of either yet, since every negative ID will need to be unique among plugins, and they should only respond to their own IDs, or pass along the chain otherwise. This implies some sort of global registry, at least of ranges - allocated say 100 at once, so -500 – -599 = mysql, -600 – -699 = streamer, etc (-1 – -99 probably reserved for local testing and errors).
Y_Less is offline   Reply With Quote
Old 13/02/2019, 06:34 PM   #2
IllidanS4
Huge Clucker
 
IllidanS4's Avatar
 
Join Date: Feb 2013
Posts: 342
Reputation: 230
Default Re: Run-time plugin feature detection

While this would work with specially made plugins that support this mechanism, I think a better solution exists that is compatible with already existing plugins and standard means of exporting natives, yet still possible to use without any plugins at all.

I like using negative ids and hooking an already existing standard function, but the ids could be unique to the script:
pawn Code:
const NATIVE_PrintAmxBacktrace = /* unique via macros/enums */;
native PrintAmxBacktrace() = NATIVE_PrintAmxBacktrace;

#define MapNative(%0,%1) getproperty(.id = 0x504C5547, .name = (%0), .value = (%1))

main()
{
    new bool:exists = MapNative("PrintAmxBacktrace", NATIVE_PrintAmxBacktrace);
    if(exists) PrintAmxBacktrace();
}

A plugin like Native Fallback would hook getproperty and look into the table of all exported functions to the script, then create a local mapping between the native and its script-local id. Calling such a native function would lead to amx->callback in the plugin that would simply check the id and find the correct native function based on the mapping.

Without any plugins, getproperty simply returns 0, so all is fine if you ensure the optional native isn't called (without any plugins, it crashes).

This has the advantage of working with all plugins that use names when registering natives (the vast majority of them), and still works without any plugins, so you don't need to introduce any dependency at all. New plugins do not have to implement any special mechanisms for optional natives.
__________________
PawnPlus
YSF
Yet Another Lua Plugin
Long Function Names
• i_quat.inc •


kingsofsa.cz:8888 running Cinematic Mode

Last edited by IllidanS4; 14/02/2019 at 10:34 AM.
IllidanS4 is online now   Reply With Quote
Old 13/02/2019, 07:32 PM   #3
Y_Less
Beta Tester
 
Y_Less's Avatar
 
Join Date: Jun 2008
Location: 629 - git.io/Y
Posts: 15,673
Reputation: 3220
Default Re: Run-time plugin feature detection

After quite a debate, I do see the point of using a plugin to detect plugins, especially when as you say it means existing plugins are already compatible.

Side note, I already tried enums for the IDs and they don't work.
Y_Less is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
[Help] Zone Time Detection [+Rep] Arxalan Scripting Help 2 21/01/2015 12:57 PM
Collision Detection (Plugin) Deduction Scripting Help 0 27/12/2013 05:24 AM
Mute command with time feature. Lozzy Scripting Help 1 27/11/2013 08:01 AM
Creating a per player plugin detection method RajatPawar Scripting Help 3 02/11/2013 05:49 PM
How would someone add the time feature? aa14 General 2 21/07/2013 06:58 AM


All times are GMT. The time now is 06:39 PM.


Powered by vBulletin® Version 3.8.6
Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.