21.12.2017, 11:28
(
Последний раз редактировалось Whitetiger; 21.12.2017 в 13:18.
)
Quote:
What is the performance impact of this? The point of using natives is that they can be very fast, since they are written in a native language, with run-time optimisation to replace each native call with a direct reference to the function in the in-memory p-code. This removes all of that and replaces it with a string lookup, which could be significant overhead for short natives (especially since you appear to be using a linear string search).
Given the relatively tiny (IMHO) problems caused by a missing plugin, this seems like a huge price to pay to "fix" them. Edit: Re-read and better understood what is going on. I still wonder about the performance hit, but not about the other issues I previously had. Edit 2: Since you are using "GetGravity" by default, your "IsPluginLoaded" example won't work. If the plugin isn't loaded, then the original will be called and return the current non-zero gravity, which this will interpret as "plugin loaded". |
The problems are pretty small but can be useful to automatically enable or disable functionality when you want your game mode to run with or without a plugin. Most people now are not doing any verification if a plugin is loaded and that can cause problems if a sa-mp version is updated and a plugin doesn't support a new sa-mp version. You can keep your game mode or filterscript working as you wait for a plugin developer to update.
This should work on new versions of sa-mp released without any modifications.
I'm not sure what you meant by your last paragraph. IsPluginLoaded has to be defined as a comparison function. See here:
pawn Код:
native plugin_gateway_param0(func[]) = GetGravity;
#define IsPluginLoaded() ((_:GetGravity()) != plugin_gateway_param0("IsPluginLoaded"))
That plugin really isn't what this topic is about, but you can find out more about it from the website that's linking it.