[klippy]

They don't cause crashes, and packed arrays (for saving memory) have some use in scripting (like in that code, but bit fields would work better anyway). Packed strings are the ones that don't work properly. They won't cause crashes, but you can't use packed strings in AMXX to save memory, as they are not supported by natives. They can't be properly formatted and/or printed.

[fysiks]

Originally Posted by Bugsy Unfortunately the AMX-X string natives are not built to use packed strings.

It is not unfortunate actually. UTF-8 requires up to 4 bytes to store certain characters. If using packed strings, you would be limited to ASCII.

[Bugsy]

Originally Posted by Depresie what do you mean by this ? "Unfortunately the AMX-X string natives are not built to use packed strings" It could cause server crash? or something? because i encounter server crashes on linux with no error logs running the plugin containing that code, and i couldn't find a solution for several weeks link here: https://forums.alliedmods.net/showthread.php?t=270179

No, it means that when you use copy/formatex/format/client_print/get_user_name/get_user_authid etc, it expects strings in the non-packed format because that is how it was programmed.

Assume '1' is a character in a string and you need to store 4 characters, they are stored as listed below for each type:
non-packed: 0001 0001 0001 0001
packed: 1111

The only thing that happens when you use char is it reduces the number of cells that are declared because the compiler thinks you will be using every byte within the cell. So if you did szName[ 32 char ] you are doing the same as szName[ 8 ]. Now if you tried to use get_user_name() with szName, you would only have enough room for 8 characters, not 32.

[Depresie]

oh, i understood
i have another question, what does this do exactly ?
i know it seems quite obvious, but i want to know for sure and i couldnt find anything about it around

set_pev( Snark, pev_enemy, NULL_ENT );

[fysiks]

It appears to set your enemy to the null entity (which is probably 0 which is also known as "worldspawn"). As for what pev_enemy actually means, you'd probably have to look at the context of it's usage (assuming it's used in an actual working plugin).

[aron9forever]

Originally Posted by fysiks It appears to set your enemy to the null entity (which is probably 0 which is also known as "worldspawn"). As for what pev_enemy actually means, you'd probably have to look at the context of it's usage (assuming it's used in an actual working plugin).

I've looked around and it seems to be conected to zombie AI
pev_enemy being the player the monster follows/attacks/whatever
it also seems to be originally from half life AI

so I guess setting it to null means the monster is not attacking anyone

some questions need to be asked in context

[Depresie]

yes, indeed is a monster who is hunting humans, sorry for placing it out of context, thanks for the answer

i also have one more question about these two functions, why i get run time errors index out of bound ?

what checks i should add in these two cases ( fwd_touch + prethink, and the trace_attack ) to not get run time errors about index out of bounds?

im sorry for posting this in the same thread, but i think it is be better than creating multiple topics for this kind of questions

public fwd_touch(id, world)
{

    if(!is_user_alive(id))
             return FMRES_IGNORED
        
    if(zp_core_is_zombie(id) && zp_class_assassin_get(id))    
    {
               pev(id, pev_origin, g_wallorigin[id])
    }

return FMRES_IGNORED
}

public fw_PlayerPreThink
{

        if(zp_core_is_zombie(id) && zp_class_assassin_get(id))    
            {
        static Float:gameTime = 0.0, Float:VAngle[3], Float:Forward[3];
        gameTime = get_gametime();
        
        static Float:origin[3]
        pev(id, pev_origin, origin)
        
        if(get_distance_f(origin, g_wallorigin[id]) > 25.0)
            return FMRES_IGNORED  // if not near wall
        }

    return FMRES_IGNORED
}

public fw_TraceAttack(victim, attacker, Float:damage, direction[3], traceresult, dmgbits)
{
    if(item_have_bat[attacker] && is_user_alive(victim))
    {
        switch(random_num(1,100))
        {
            case 1..15: 
            {
                set_tr2(traceresult, TR_iHitgroup, HIT_HEAD)
            }

        }
    }
}

[klippy]

"Index out of bounds" happens when you try to index an elemental in an array outside its range/size. So if you have

PHP Code:

new PlayerArray[33]; 


It will throw an error if you try to index it with a negative number or a number higher than 32.

So just a check if the player is alive, connected or between 1(inclusive) and maxplayers(also inclusive) should save you from that error (if you are dealing with player arrays, like in your case).
fw_PlayerPreThink (your are missing function parameters in your post) *should* always be called on a player, so such check is probably redundant, but I would always add it just to be safe.

[Depresie]

i undestood, also, if i use is_user_alive it won't be needed to use is_user_connected anymore, right?

[HamletEagle]

Yes. A user can't be alive without being connected.