[WildCard65]

Originally Posted by VoiDeD 1) FF2 shouldn't be loading them.

That is what I want to change, which is why I want ff2 to care if the loaded plugin can call natives meant for subplugins only

[rswallen]

Checking to see if a plugin is loaded is fairly simple in SourcePawn

Spoiler

PHP Code:

/* stuff found in the core plugin */
new Handle:g_fwdPluginPingTest;

public OnPluginStart()
{
    g_fwdPluginPingTest = CreateGlobalForward("AreYouStillThere", ET_Event, Param_Cell);
}

bool:IsPluginActive(Handle:plugin)
{
    new Action:result = Plugin_Continue;
    Call_StartForward(g_fwdPluginPingTest);
    Call_PushCell(plugin);
    Call_Finish(result);
    
    return (result ==  Plugin_Handled);
}

/* stuff found in the sub-plugin */
public Action:AreYouStillThere(Handle:plugin)
{
    if (plugin == GetMyHandle())
    {
        return Plugin_Handled;
    }
    return Plugin_Continue;
} 


Yes, it does require that the plugin you want to test contains this extra function, but if you're rewriting the core plugin, API changes are inevitable

As for the issue of late-loaded plugin info caching, use a native (FF2_RegSubPlugin or similar)

[WildCard65]

Originally Posted by rswallen Checking to see if a plugin is loaded is fairly simple in SourcePawn Spoiler PHP Code: /* stuff found in the core plugin */ new Handle:g_fwdPluginPingTest; public OnPluginStart() {     g_fwdPluginPingTest = CreateGlobalForward("AreYouStillThere", ET_Event, Param_Cell); } bool:IsPluginActive(Handle:plugin) {     new Action:result = Plugin_Continue;     Call_StartForward(g_fwdPluginPingTest);     Call_PushCell(plugin);     Call_Finish(result);          return (result ==  Plugin_Handled); } /* stuff found in the sub-plugin */ public Action:AreYouStillThere(Handle:plugin) {     if (plugin == GetMyHandle())     {         return Plugin_Handled;     }     return Plugin_Continue; }  Yes, it does require that the plugin you want to test contains this extra function, but if you're rewriting the core plugin, API changes are inevitable As for the issue of late-loaded plugin info caching, use a native (FF2_RegSubPlugin or similar)

Ya but I don't want to use functions like OnPluginStart, OnPluginEnd in subplugins and instead have different functions that are only called when ff2 wants the plugins to believe they are loaded. So natives won't work in core plugin, and I don't want a timer checking a forward all the time because they is no garuntee that you know which plugin returned the handled return or not.

[VoiDeD]

Originally Posted by WildCard65 Ya but I don't want to use functions like OnPluginStart, OnPluginEnd in subplugins and instead have different functions that are only called when ff2 wants the plugins to believe they are loaded. So natives won't work in core plugin, and I don't want a timer checking a forward all the time because they is no garuntee that you know which plugin returned the handled return or not.

You want to ignore the standard plugin model in SM? Why?

[WildCard65]

Originally Posted by VoiDeD You want to ignore the standard plugin model in SM? Why?

I find it just makes a plugin feel like it belongs as a ff2 subplugin instead of justing feeling like a std sm plugin.

I also want to avoid SM telling the subplugin that it's loaded/unloaded just to be able to keep things flowing in a nice way.

In english: I have it all planned out in a way that I can't wrap words to it.

[rswallen]

Originally Posted by WildCard65 Ya but I don't want to use functions like OnPluginStart, OnPluginEnd in subplugins and instead have different functions that are only called when ff2 wants the plugins to believe they are loaded

Why not use both? Use the standard forwards to setup things like convars, then use the custom forwards to activate/deactivate the plugin (akin to setting "sm_plugin_enabled" to 0/1).

Furthermore, if you want to stop the natives from being called, check the caller plugin handle against those cached - if not cached or set inactive, ThrowNativeError();

Originally Posted by WildCard65 I don't want a timer checking a forward all the time because they is no garuntee that you know which plugin returned the handled return or not.

That's not how it works. Just call that forward whenever you need to check if a plugin is loaded. By supplying the handle of the plugin you want to check, you will either get Plugin_Handled (in which case the plugin is loaded) or Plugin_continue (in which case it is not loaded or is paused)

[WildCard65]

Originally Posted by rswallen That's not how it works. Just call that forward whenever you need to check if a plugin is loaded. By supplying the handle of the plugin you want to check, you will either get Plugin_Handled (in which case the plugin is loaded) or Plugin_continue (in which case it is not loaded or is paused)

Do you even know how forwards work? When you call a forward handle, it calls EVERY function linked to the forward.

[VoiDeD]

Originally Posted by WildCard65 I find it just makes a plugin feel like it belongs as a ff2 subplugin instead of justing feeling like a std sm plugin. I also want to avoid SM telling the subplugin that it's loaded/unloaded just to be able to keep things flowing in a nice way. In english: I have it all planned out in a way that I can't wrap words to it.

Here's what I've gathered from this entire conversation:

1) You are beyond stubborn and do not care for what is proper or correct, even when multiple people are informing you that what you're doing is downright stupid.
2) Your complete lack of domain knowledge in SM, extensions, and c++ somehow does not phase you when people with domain knowledge are trying to guide you to the correct path.
3) You are going to fail.

Best of luck to you.

[rswallen]

Originally Posted by WildCard65 Do you even know how forwards work? When you call a forward handle, it calls EVERY function linked to the forward.

Did even you look at the code I provided?

[Powerlord]

Originally Posted by WildCard65 Do you even know how forwards work? When you call a forward handle, it calls EVERY function linked to the forward.

You can have a private forward with just one function in it. That's how NativeVotes VoteManger branch works.

I could go into more detail, but I seem to recall you ignored it when I suggested it to you months ago, even when I mentioned that's how the FF2 rewrite I was originally planning was going to work.