[imindfreak]

Greetings,

I'm having issues with a set command in one of my point based plugins.

In my library include -

PHP Code:

#pragma reqlib "pointsystem"

/* called when points need to be retrieved */
native _get_points(id)

/* called when points need to be set */
native _set_points(id, amount) 


In main plugin -

PHP Code:


public plugin_natives()
{
    register_library("pointsystem")
    
    register_native("get_points","_get_points");
    register_native("set_points","_set_points");
}

public _get_points(iPlugin,iParams)
{
    if(iParams != 1)
        return PLUGIN_CONTINUE
        
    new id = get_param(1)
    if(!id)
        return PLUGIN_CONTINUE
        
    return g_iPoints[id];
}

public _set_points(iPlugin,iParams)
{
    if(iParams != 1)
        return PLUGIN_CONTINUE
        
    new id = get_param(1)
    if(!id)
        return PLUGIN_CONTINUE
    
    new amount = get_param(2)
    g_iPoints[id] = amount;
    cmdSavePoints(id); //vault based saving.
    
    return 1
} 


Example use for set command on another plugin because I'm using the two commands as natives.

PHP Code:

public somecommand(id)
{
    new points = get_points(id);
    set_points(id, points + 100);
} 


When I try out the command, it doesn't alter my points at all.
Not sure why it's not passing the int value assigning to g_iPoints[id].
Anyone know why? I'll do my best to answer any questions.

Thank you everyone!

[fysiks]

Does get_param(2) give you the value that you gave the native?

[imindfreak]

Problem solved, a small mistake, thank you Emp`!

Here was the problem, my native takes two params.

PHP Code:

public _set_points(iPlugin,iParams)
{
    if(iParams != 1) //<-- This was the issue, this native has two parameters.
        return PLUGIN_CONTINUE //Therefore, it was never executed past this.
        
    new id = get_param(1)
    if(!id)
        return PLUGIN_CONTINUE
    
    new amount = get_param(2)
    g_iPoints[id] = amount;
    cmdSavePoints(id); //vault based saving.
    
    return 1 


Changed

PHP Code:

 if(iParams != 1) 


to

PHP Code:

if(iParams != 2) 


and it works as expected.

[fysiks]

There is no reason to check the number of parameters in your case (because it's a fixed number of arguments defined in your prototype. The only time you really need to check is if you have the possibility of having a variable number of arguments (usually achieved with "any:..." in the function prototype).

[Nextra]

The bigger mistake is actually having your natives fail silently.

There are three major categories of input here (I think!). You need to look at what your natives are supposed to do and clearly distinguish between these cases.

1. Your native receives input that your plugin can fully or partially ignore, as it doesn't change it's state, at least not for the outside.
   -> You can shortcut out of execution with an early return. The native pretends to have done everything it needed to.
2. Your native encounters an issue that it can gracefully handle and signal.
   -> You introduce well defined error codes, either by using appropriate return values or by writing to a byref value or buffer. The native humbly apologizes and hands the problem back to the user.
3. Your native receives invalid input, either by the user ignoring input restrictions or by the input causing invalid state.
   -> You always, always abort using log_error(). The native blames the user for getting it all wrong.

Having your natives fail silently will just lead to more cases where either your input/state validation is broken or where you have bugs in plugins using your API and you are none the wiser in either case.

In this example your native could look something like this:

public _set_points(iPlugin, iParams)
{
    if(iParams != 1)
    {
        log_error(AMX_ERR_PARAMS, "%d parameter(s) required.", 1)
        return 1
    }

    new id = get_param(1)
    if(!is_user_connected(id))
    {
        // This can be expanded to treat the range and connected check separately
        log_error(AMX_ERR_BOUNDS, "Invalid client index '%d'.", id)
        return 1
    }

    new amount = get_param(2)
    if(amount == g_iPoints[id])
    {
       /* This is just an example for a do nothing case. You can abort
          silently, because for the "outside" nothing changes if you skip
          writing to the vault here */

        return 0
    }

    g_iPoints[id] = amount

    if(!cmdSavePoints(id))
    {
       /* Let's assume that not being able to save to the database is an error
          you want to handle gracefully. The points have been updated in 
          the plugin, they just haven't been saved yet. We return a separate
          error code for this, informing the user to what happened. */
       return 2
    }

    return 0
}

Keep in mind that all of this is very much up to your API design. You can theoretically move all of #3 into #2 as you did in your original example, but this requires very thorough checking of return values. Usually this is unnecessary, as passing invalid client ids or parameter counts is the result of a bug in the calling plugin, and should therefore be treated with a fatal error.

Originally Posted by fysiks There is no reason to check the number of parameters in your case.

I like having that in there for debugging purposes. APIs can and will rapidly change in development, and it's useful to have stuff error out on you.

[fysiks]

Originally Posted by Nextra I like having that in there for debugging purposes. APIs can and will rapidly change in development, and it's useful to have stuff error out on you.

Yeah, that's a good point.

[HamletEagle]

Or if someone is stupid enough to change include file.

[fysiks]

Originally Posted by HamletEagle Or if someone is stupid enough to change include file.

Which is the same as someone going in an changing the source code of the function to make it not work.