[bibu]

Why does this give 2 tag mismatches for the float one? Or am I thinking wrong??

PHP Code:

#include <amxmodx>

new iVar[33], bool:bVar[33], Float:flVar[33]

public plugin_init()
{
    arrayset(iVar, 0, 32)
    arrayset(bVar, false, 32)
    arrayset(flVar, 0.0, 32)
} 


[fysiks]

Look at the definition of the function. Are the args declared as floats?

[Backstabnoob]

You cannot use arrayset for floats, just do

PHP Code:

arrayset_f( Float: Array[ ], Float: value, size )
{
     for( new i; i < size; i ++ )
     {
          Array[ i ] = value
     }
} 


[bibu]

Originally Posted by fysiks Are the args declared as floats?

You're right.

Thanks for the function backstab.

[hleV]

PHP Code:

arrayset(_:flVar, _:0.0, sizeof(flVar)); 


[Backstabnoob]

Or he just uses the function I posted which looks way more clean.

[hleV]

Why would he declare an additional function in his plugin when there's a built-in AMXX native for that? For large arrays it will be way more efficient.

All I did was negate your statement that you cannot use the native for floats.

[Backstabnoob]

Originally Posted by hleV For large arrays it will be way more efficient.

No, not really.

PHP Code:

static cell AMX_NATIVE_CALL arrayset(AMX *amx, cell *params)
{
    cell value = params[2];

    if (!value)
    {
        memset(get_amxaddr(amx, params[1]), 0, params[3] * sizeof(cell));
    } else {
        int size = params[3];
        cell *addr = get_amxaddr(amx, params[1]);
        for (int i=0; i<size; i++)
        {
            addr[i] = value;
        }
    }

    return 1;
} 


I doubt there's any noticeable difference between a for( ) loop and an old assembler function memset. Also, you're saving one native call too, so if there IS any difference, this will likely negate that.

Originally Posted by hleV All I did was negate your statement that you cannot use the native for floats.

Sorry if I offended you in some way, but I'm just saying it makes way more sense to have an arrayset_f instead of using a built-in native at the cost of lost readability.

[hleV]

You're the one who seems offended, hence your first reply to me which makes no sense.

Assigning values of a large array in a module will be more efficient than in a plugin, and tagging/detagging variables is a part of Pawn language and it in no way makes it less readable (unless you're new to it?), let alone worth coming up with less efficient ways of doing the same.

If _: makes it unreadable to you, then why not just

PHP Code:

#define arrayset_f(%1,%2,%3) arrayset(_:%1, _:%2, %3) 


I answered the OP's question. It's a better answer than yours. Move on.

[Backstabnoob]

I'm in no way new to Pawn and I do think that detagging floats might be confusing for a whole lot of people. I agree that your answer is better, but you just use some arguments which don't make much sense. Worrying about speed is kind of silly when you're talking about something like this.

PHP Code:

#include < amxmodx >


public plugin_init( )
{
    new Float:aArray[ 512 ]
    
    arrayset( _:aArray, _:0.0, sizeof aArray )
    arrayset_f( aArray, 0.0, sizeof aArray )
}



arrayset_f( Float: aArray[ ], Float: value, size )
{
     for( new i; i < size; i ++ )
     {
          aArray[ i ] = value
     }
} 


type |                             name |      calls | time / min / max
-------------------------------------------------------------------
   n |                         arrayset |          1 | 0.000001 / 0.000001 / 0.000001
   p |                      plugin_init |          1 | 0.000001 / 0.000001 / 0.000001
   f |                       arrayset_f |          1 | 0.000002 / 0.000002 / 0.000002
0 natives, 0 public callbacks, 1 function calls were not executed.

512 is already a lot unless you want to use the array for a string, in which case you can just set the first cell to EOS. Let's just leave the "this is more efficient" argument completely out. If you need to null a 512-cell array in pawn then you're probably doing something wrong to begin with.

@OP: Use either detagging or define, it's a better solution as hleV said, however I still stand behind my argument being that what I posted is not wrong either and it probably doesn't matter at all which you use.