AlliedModders

AlliedModders (https://forums.alliedmods.net/index.php)
-   Scripting Help (https://forums.alliedmods.net/forumdisplay.php?f=11)
-   -   Teoretical Help (https://forums.alliedmods.net/showthread.php?t=159680)

bafak 06-20-2011 07:05

Teoretical Help
 
Hi,
I've got only one question:

What is the best way to make 2 or more plugins co-op?

1 - Put they into one plugin (in my case cca 4000 lines)
2 - Make a .inc file
3 - Ohter way ?

thanks

I know. My English is bad.

Nyuszy 06-20-2011 11:30

Re: Teoretical Help
 
2 - Make a .inc file

Hunter-Digital 06-20-2011 11:57

Re: Teoretical Help
 
There are various possibilities:

- includes to share various constants on compile
- natives, usefull for making functions that can be called from sub-plugins (requires a include file)
- forwards, usefull if you want to hook something from the main plugin (I think it requries includes, see tutorials to be sure)
- xvars to share variables to other plugins like pcvars, only that you set the variable in the main plugin rather than using functions, this method is fast and I think it doesn't require includes.
- callfunc_* functions to call a function from a plugin, doesn't require a include or anything but I think it's pretty slow.

And ofc server cvars and commands, but those aren't really internal.

I belive you can change/remove tasks from another plugin, didn't really try it but there's a "outside" variable in change_task(), task_exists() and remove_task().

There are tutorials for all these methods.

If you have somehing specific you want to make, please do tell so we can help you pick the most efficient methods.

SnoW 06-20-2011 16:58

Re: Teoretical Help
 
Quote:

Originally Posted by Nyuszy (Post 1492239)
2 - Make a .inc file

False, you just cannot achieve anything with an include file.

Quote:

Originally Posted by Hunter-Digital (Post 1492259)
There are various possibilities:

- includes to share various constants on compile
- natives, usefull for making functions that can be called from sub-plugins (requires a include file)
- forwards, usefull if you want to hook something from the main plugin (I think it requries includes, see tutorials to be sure)
- xvars to share variables to other plugins like pcvars, only that you set the variable in the main plugin rather than using functions, this method is fast and I think it doesn't require includes.
- callfunc_* functions to call a function from a plugin, doesn't require a include or anything but I think it's pretty slow.

And ofc server cvars and commands, but those aren't really internal.

I belive you can change/remove tasks from another plugin, didn't really try it but there's a "outside" variable in change_task(), task_exists() and remove_task().

There are tutorials for all these methods.

If you have somehing specific you want to make, please do tell so we can help you pick the most efficient methods.

It seems that you do not understand the concept of including a file. It just adds source code what you could write yourself, so it simply does not make any sense that something would require include file and something would not. For example using xvars you can use includes or declare the natives yourself, just how you will.
It also does not make any sense to use natives to make plugins func together, there is already natives for variables and function calls between plugins, why would you write the natives again? You would write new natives only if you needed something you could not achieve in the plugin environment.

In the end it is much easier to add the plugins to the same source code if there is a lot of common work to be done. In the other hand if the plugins are really separate and function something different forwards, functions and variables can indeed be used from and between separate plugins. ( By saying 'can be' I mean that there is available modules done already )

Exolent[jNr] 06-20-2011 17:35

Re: Teoretical Help
 
Quote:

Originally Posted by SnoW (Post 1492448)
False, you just cannot achieve anything with an include file.

I think he was just referring to the idea of dynamic natives and/or forwards.

Quote:

Originally Posted by SnoW (Post 1492448)
It seems that you do not understand the concept of including a file. It just adds source code what you could write yourself, so it simply does not make any sense that something would require include file and something would not. For example using xvars you can use includes or declare the natives yourself, just how you will.

While include files may not be required for things like this, they are still a good idea to keep things in a central place and easy to make changes.
You will only need to add #include <yourinclude> to the plugins rather than everything that is inside of them.
Also, adding, deleting, and changing the contents of the include file would be much easier than to change all plugins that would use it.

Quote:

Originally Posted by SnoW (Post 1492448)
It also does not make any sense to use natives to make plugins func together, there is already natives for variables and function calls between plugins, why would you write the natives again? You would write new natives only if you needed something you could not achieve in the plugin environment.

If you are only talking about variable sharing, then you would be correct.
However, natives do much more than just variable sharing, such as decisions.

Quote:

Originally Posted by SnoW (Post 1492448)
In the end it is much easier to add the plugins to the same source code if there is a lot of common work to be done. In the other hand if the plugins are really separate and function something different forwards, functions and variables can indeed be used from and between separate plugins. ( By saying 'can be' I mean that there is available modules done already )

I agree with what you said here, however if you do merge plugins A & B, where A is a more centralized core type of plugin and B is more of an extension, it would be more work to merge plugin C, another extension.
If you were to keep them separate and develop some sort of API for extensions, it would be much easier for new extensions.

bafak 06-21-2011 01:08

Re: Teoretical Help
 
Big thanks to all, but I'm really confused now.

I remaking jailbreaks plugins now.
I've got this plugins:(I'm sorry I don't going to share it, because I delete ML support and i think that nobody here can speek Czech or Slovak)

JoRoPiTo's JailBreak Extreme (edited - mods, simon menu, last request, etc)
MaNuCs's JailBreak Shop (edited and optimalized - extended and rewrited)
JailBreak Football (I - Bafak)
JailBreak FreeKill (I - Bafak)

I have the .inc file which contains natives & stocks now.
For example I can give JBPacks(in Shop) from FreeKill or JB extreme.

But I think that if I make only one plugin it will be better, faster and less buggy.

SO, what is the best way?
Thanks

SnoW 06-21-2011 15:57

Re: Teoretical Help
 
Quote:

Originally Posted by Exolent[jNr] (Post 1492469)
I think he was just referring to the idea of dynamic natives and/or forwards.

I usually say what I refer to and not something else. Well everyone with their own style, I guess.
Quote:

Originally Posted by Exolent[jNr] (Post 1492469)
While include files may not be required for things like this, they are still a good idea to keep things in a central place and easy to make changes.
You will only need to add #include <yourinclude> to the plugins rather than everything that is inside of them.
Also, adding, deleting, and changing the contents of the include file would be much easier than to change all plugins that would use it.

Who are you keeping this lesson to? Hopefully not to me.
Quote:

Originally Posted by Exolent[jNr] (Post 1492469)
If you are only talking about variable sharing, then you would be correct.
However, natives do much more than just variable sharing, such as decisions.

I do not get your point. Do you seriously mean he should use natives to make the plugins func together? Not just in variable sharing but in general he should not create new natives.

Exolent[jNr] 06-22-2011 00:17

Re: Teoretical Help
 
Quote:

Originally Posted by SnoW (Post 1493053)
I do not get your point. Do you seriously mean he should use natives to make the plugins func together? Not just in variable sharing but in general he should not create new natives.

After some profiling, natives are proven to be faster than callfuncs.

Code:

date: Tue Jun 21 22:57:35 2011 map: de_dust
type |                            name |      calls | time / min / max
-------------------------------------------------------------------
  n |                      test_native |      10000 | 0.032491 / 0.000002 / 0.003416
  f |                    test_callfunc |      10000 | 0.054404 / 0.000004 / 0.001982

  n |                test_native_ints |      10000 | 0.030858 / 0.000002 / 0.001723
  f |              test_callfunc_ints |      10000 | 0.089962 / 0.000007 / 0.004380

  n |              test_native_floats |      10000 | 0.028812 / 0.000002 / 0.000865
  f |            test_callfunc_floats |      10000 | 0.084756 / 0.000007 / 0.002068

  n |              test_native_strings |      10000 | 0.034963 / 0.000002 / 0.005082
  f |            test_callfunc_strings |      10000 | 0.116257 / 0.000009 / 0.001790
1 natives, 0 public callbacks, 12 function calls were not executed.

Here is the code that was used to test:

PHP Code:

#include < amxmodx >

native test_native();
native test_native_ints(int1int2);
native Float:test_native_floats(Float:float1Float:float2);
native test_native_strings(const str1[], const str2[], output[], len);

stock test_callfunc()
{
    new 
funcid get_func_id("_test_callfunc");
    
    if(
funcid != -1)
    {
        
callfunc_begin_i(funcid);
        return 
callfunc_end();
    }
    
    return 
0;
}

stock test_callfunc_ints(int1int2)
{
    new 
funcid get_func_id("_test_callfunc_ints");
    
    if(
funcid != -1)
    {
        
callfunc_begin_i(funcid);
        
callfunc_push_int(int1);
        
callfunc_push_int(int2);
        return 
callfunc_end();
    }
    
    return 
0;
}

stock Float:test_callfunc_floats(Float:float1Float:float2)
{
    new 
funcid get_func_id("_test_callfunc_floats");
    
    if(
funcid != -1)
    {
        
callfunc_begin_i(funcid);
        
callfunc_push_float(float1);
        
callfunc_push_float(float2);
        return 
Float:callfunc_end();
    }
    
    return 
0.0;
}

stock test_callfunc_strings(const str1[], const str2[], output[], len)
{
    new 
funcid get_func_id("_test_callfunc_strings");
    
    if(
funcid != -1)
    {
        
callfunc_begin_i(funcid);
        
callfunc_push_str(str1false);
        
callfunc_push_str(str2false);
        
callfunc_push_str(output);
        
callfunc_push_int(len);
        return 
callfunc_end();
    }
    
    return 
0;
}

public 
plugin_init( )
{
    
register_plugin"Profiler Test""0.0.1""Exolent" );
    
    
register_srvcmd"profile""CmdProfile" );
}

public 
plugin_natives( )
{
    
register_native"test_native""_test_native" );
    
register_native"test_native_ints""_test_native_ints" );
    
register_native"test_native_floats""_test_native_floats" );
    
register_native"test_native_strings""_test_native_strings");
}

public 
_test_nativeiPluginiParams )
{
    return 
1;
}

public 
_test_native_intsiPluginiParams )
{
    return ( 
get_param) + get_param) );
}

public 
Float:_test_native_floatsiPluginiParams )
{
    return ( 
get_param_f) + get_param_f) );
}

public 
_test_native_stringsszString1[ ], szString2[ ], szOutput[ ], iLen )
{
    
param_convert);
    
param_convert);
    
param_convert);
    
    return 
formatexszOutputiLen"%s %s"szString1szString2 );
}

public 
_test_callfunc( )
{
    return 
1;
}

public 
_test_callfunc_intsiInt1iInt2 )
{
    return ( 
iInt1 iInt2 );
}

public 
Float:_test_callfunc_floatsFloat:flFloat1Float:flFloat2 )
{
    return ( 
flFloat1 flFloat2 );
}

public 
_test_callfunc_stringsszString1[ ], szString2[ ], szOutput[ ], iLen )
{
    return 
formatexszOutputiLen"%s %s"szString1szString2 );
}

public 
CmdProfile( )
{
    new 
output[32];
    for( new 
010000i++ )
    {
        
test_native();
        
test_native_ints(12);
        
test_native_floats(1.02.0);
        
test_native_strings("Ohhai""there"outputcharsmax(output));
        
test_callfunc();
        
test_callfunc_ints(12);
        
test_callfunc_floats(1.02.0);
        
test_callfunc_strings("Ohhai""there"outputcharsmax(output));
    }
    
    
log_amx"Finished Profile" );
    
    return 
PLUGIN_HANDLED;


Here is a profile of them in separate plugins (even a little advantage for callfunc with the plugin/funcid caching):
Code:

date: Tue Jun 21 23:07:41 2011 map: de_dust
type |                            name |      calls | time / min / max
-------------------------------------------------------------------
  n |                      test_native |      10000 | 0.018990 / 0.000001 / 0.004626
  f |                    test_callfunc |      10000 | 0.041347 / 0.000003 / 0.001377

  n |                test_native_ints |      10000 | 0.016021 / 0.000001 / 0.001074
  f |              test_callfunc_ints |      10000 | 0.070727 / 0.000006 / 0.001660

  n |              test_native_floats |      10000 | 0.019196 / 0.000001 / 0.001857
  f |            test_callfunc_floats |      10000 | 0.078072 / 0.000006 / 0.001907

  n |              test_native_strings |      10000 | 0.019567 / 0.000001 / 0.001247
  f |            test_callfunc_strings |      10000 | 0.115104 / 0.000008 / 0.005962
0 natives, 0 public callbacks, 3 function calls were not executed.

Here are the 2 test plugins that were used:

PHP Code:

#include < amxmodx >
#include < profiler >

native test_native();
native test_native_ints(int1int2);
native Float:test_native_floats(Float:float1Float:float2);
native test_native_strings(const str1[], const str2[], output[], len);

new 
g_callfunc_plugin = -1;
new 
g_callfunc_func = -1;
new 
g_callfunc_func_ints = -1;
new 
g_callfunc_func_floats = -1;
new 
g_callfunc_func_strings = -1;

stock test_callfunc()
{
    if(
g_callfunc_func != -1)
    {
        
callfunc_begin_i(g_callfunc_funcg_callfunc_plugin);
        return 
callfunc_end();
    }
    
    return 
0;
}

stock test_callfunc_ints(int1int2)
{
    if(
g_callfunc_func_ints != -1)
    {
        
callfunc_begin_i(g_callfunc_func_intsg_callfunc_plugin);
        
callfunc_push_int(int1);
        
callfunc_push_int(int2);
        return 
callfunc_end();
    }
    
    return 
0;
}

stock Float:test_callfunc_floats(Float:float1Float:float2)
{
    if(
g_callfunc_func_floats != -1)
    {
        
callfunc_begin_i(g_callfunc_func_floatsg_callfunc_plugin);
        
callfunc_push_float(float1);
        
callfunc_push_float(float2);
        return 
Float:callfunc_end();
    }
    
    return 
0.0;
}

stock test_callfunc_strings(const str1[], const str2[], output[], len)
{
    if(
g_callfunc_func_strings != -1)
    {
        
callfunc_begin_i(g_callfunc_func_stringsg_callfunc_plugin);
        
callfunc_push_str(str1false);
        
callfunc_push_str(str2false);
        
callfunc_push_str(output);
        
callfunc_push_int(len);
        return 
callfunc_end();
    }
    
    return 
0;
}

public 
plugin_init( )
{
    
register_plugin"Profiler Test""0.0.1""Exolent" );
    
    
register_srvcmd"profile""CmdProfile" );
    
    new 
pluginsnum get_pluginsnum( );
    
    for( new 
0pluginsnumi++ )
    {
        
g_callfunc_func get_func_id"test_callfunc");
        
        if( 
g_callfunc_func != -)
        {
            
g_callfunc_plugin i;
            
g_callfunc_func_ints get_func_id"test_callfunc_ints");
            
g_callfunc_func_floats get_func_id"test_callfunc_floats");
            
g_callfunc_func_strings get_func_id"test_callfunc_strings");
            
            break;
        }
    }
}

public 
CmdProfile( )
{
    new 
output[32];
    for( new 
010000i++ )
    {
        
test_native();
        
test_native_ints(12);
        
test_native_floats(1.02.0);
        
test_native_strings("Ohhai""there"outputcharsmax(output));
        
test_callfunc();
        
test_callfunc_ints(12);
        
test_callfunc_floats(1.02.0);
        
test_callfunc_strings("Ohhai""there"outputcharsmax(output));
    }
    
    
log_amx"Finished Profile" );
    
    return 
PLUGIN_HANDLED;


PHP Code:

#include < amxmodx >

public plugin_init()
{
    
register_plugin"Profiler Native Helper""0.0.1""Exolent" );
}

public 
plugin_natives( )
{
    
register_native"test_native""_test_native" );
    
register_native"test_native_ints""_test_native_ints" );
    
register_native"test_native_floats""_test_native_floats" );
    
register_native"test_native_strings""_test_native_strings");
}

public 
_test_nativeiPluginiParams )
{
    return 
1;
}

public 
_test_native_intsiPluginiParams )
{
    return ( 
get_param) + get_param) );
}

public 
Float:_test_native_floatsiPluginiParams )
{
    return ( 
get_param_f) + get_param_f) );
}

public 
_test_native_stringsszString1[ ], szString2[ ], szOutput[ ], iLen )
{
    
param_convert);
    
param_convert);
    
param_convert);
    
    return 
formatexszOutputiLen"%s %s"szString1szString2 );
}

public 
test_callfunc( )
{
    return 
1;
}

public 
test_callfunc_intsiInt1iInt2 )
{
    return ( 
iInt1 iInt2 );
}

public 
Float:test_callfunc_floatsFloat:flFloat1Float:flFloat2 )
{
    return ( 
flFloat1 flFloat2 );
}

public 
test_callfunc_stringsszString1[ ], szString2[ ], szOutput[ ], iLen )
{
    return 
formatexszOutputiLen"%s %s"szString1szString2 );



SnoW 06-22-2011 06:47

Re: Teoretical Help
 
I admit that you could achieve something with fake natives, but you must understand that they are really different from natives. I never neither did you talk about those, so obviously it is totally different thing.

Exolent[jNr] 06-22-2011 10:29

Re: Teoretical Help
 
Quote:

Originally Posted by SnoW (Post 1493379)
I admit that you could achieve something with fake natives, but you must understand that they are really different from natives. I never neither did you talk about those, so obviously it is totally different thing.

You said that natives already exist to communicate between plugins and that new natives wouldn't be needed.
If you weren't talking about callfuncs, then what were you talking about?


All times are GMT -4. The time now is 23:35.

Powered by vBulletin®
Copyright ©2000 - 2024, vBulletin Solutions, Inc.