[Backstabnoob]

Is there any way to simply share array handle through dynamic natives or do I have to copy the entire array? Something like this is possible with SQLx for example, where you can simply do

PHP Code:

public Handle: native_handler( iPlugin, iParams )
{
    return g_iSqlHandle
} 


However, if I do the same thing with a dynamic array, the calling plugin gets an invalid handle provided error.

PHP Code:

new Array: g_aArray

public plugin_init( )
{
   g_aArray = ArrayCreate( )
}

public Array: native_handler( iPlugin, iParams )
{
   return g_aArray
} 


[Black Rose]

#include <amxmodx>
#include <cellarray>

new Array:g_hArray;

public plugin_init() {
    register_plugin("Test Plugin 1", "", "");
    
    g_hArray = ArrayCreate();
}

public plugin_natives() {
    register_native("get_arrayhandle", "native_get_arrayhandle");
}

public Array:native_get_arrayhandle() {
    return g_hArray;
}

#include <amxmodx>
#include <cellarray>

native Array:get_arrayhandle();

public plugin_init() {
    register_plugin("Test Plugin 2", "", "");
    
    set_task(1.0, "test");
}

public test() {
    new Array:hArray = get_arrayhandle();
    
    ArrayPushCell(hArray, 666);
}

#include <amxmodx>
#include <cellarray>

native Array:get_arrayhandle();

public plugin_init() {
    register_plugin("Test Plugin 3", "", "");
    
    set_task(2.0, "test");
}

public test() {
    new Array:hArray = get_arrayhandle();
    
    server_print("Array test: %d", ArrayGetCell(hArray, 0));
}

Array test: 666

Problem?

[Backstabnoob]

Weird, I have it done exactly the same way and it just refuses to work. Might be something with the array not being initialized soon enough (it did say that the handle integer was 0, which I had found mysterious).

I'll look it over tomorrow again, thanks for the reply.

[Black Rose]

Since hdls.exe is single threaded, if the plugins are in the correct order there should be no problem.
I tried again without set_task() delay and initializing the array on both plugin_natives and plugin_init. No problem.

Forwards are called in this order:

plugin_natives
plugin_precache
plugin_init
plugin_cfg
...
plugin_end

plugin_modules is deprecated and no longer called.

Since you can initialize the array on plugin_natives, just to be safe I suggest you do that.
That way, no matter the order of plugins.ini the array will always be initialized for any plugin using the native in plugin_init.

[fysiks]

tl;dr

I think you should be able to use xvars would eliminate natives.

[Backstabnoob]

Originally Posted by fysiks tl;dr I think you should be able to use xvars would eliminate natives.

Not really, the result would probably be exactly the same. You'd be better off reading the thread next time.


Edit: Now that I think of it, I'd be better off to copy the array anyway, since I don't want other plugins to push additional data into it.

PHP Code:

public Array: _ac_get_achievements( Plugin, Params )
{
    if( DEBUG & DEBUG_NATIVE_CALLS )
    {
        log_amx( "DEBUG_NATIVE_CALLS (_ac_get_achievements(%d,%d)): NATIVE CALLED", Plugin, Params )
    }
    
    new Array: iArrayHandle = ArrayCreate( AchievementData )
    

    new aAchievement[ AchievementData ]
    
    for( new i; i < ArraySize( g_aAchievements ); i ++ )
    {
        ArrayGetArray( g_aAchievements, i, aAchievement )
        
        ArrayPushArray( iArrayHandle, aAchievement )
    }
    return iArrayHandle
} 


I don't like the solution, but it works fine.

[Arkshine]

To share an integer, xvar would be simple and appropriate to use.

[Backstabnoob]

I'd rather have everything in one place and more understandable than a couple percent increased performance in one call.

It's aimed at complete newbies too and additional steps, such as caching the XVar's ID might be confusing for the end user.


About simplicity,

PHP Code:

new Array: Achievements = ac_get_achievements( ) 


seems simple enough to me.


My point about xvars in this thread was that fysiks suggested me to use them without actually reading the thread, since his response doesn't seem any relevant to this thread's purpose.

[fysiks]

Originally Posted by Backstabnoob Not really, the result would probably be exactly the same. You'd be better off reading the thread next time.

I read the original post just fine. I suggested a valid solution. I didn't say it would eliminate ALL natives but it would eliminate all natives created to solve this problem.

Originally Posted by Backstabnoob It's aimed at complete newbies too and additional steps, such as caching the XVar's ID might be confusing for the end user.

The end user should not ever need to touch the code. Also, it's not a hard concept and "newbies" probably can't understand half of the other stuff going on. If they can, they can easily learn this.

[Backstabnoob]

I just don't see how using an xvar would solve this, both the native and an xvar would return the same integer. The only difference is that xvar is a little bit more complex to use than standard natives, where you literally need one line to get exactly where you want to.

It is aimed for people who are willing to make their own achievements. The API, while being really large, is also extremely easy to use and that's what I want to keep. I don't really need 30 natives and one xvar, I'd rather have 31 natives.

I'm not saying xvars are more efficient or super hard to use compared to natives, but the majority of people don't even know such a thing exists and would rather use what they've been using for the last couple of years.

All in all, what I have works just fine and also protects the main array from being edited from within other sub plugins, which is what I was looking for. Unless there's anything I can do to improve the code I have right now - which is copying the entire array in order to prevent the sub-plugins from directly editing the main array, I think that further discussion is unnecessary.