[PartialCloning]

The update_index parameter seems to cause a few issues when used.

Here's a simple test plugin.

PHP Code:

#include <amxmodx>
#include <amxmisc>
#include <cstrike>

public plugin_precache()
{
    precache_model("models/player/vip/vip.mdl");
}

public plugin_init()
{
    register_concmd("amx_model", "cmdModel", ADMIN_ALL, "<name or #userid> [value]");
}

public cmdModel(id, level, cid)
{
    if(!cmd_access(id, level, cid, 2))
        return PLUGIN_HANDLED;

    new user[32]; read_argv(1, user, charsmax(user));
    new player = cmd_target(id, user, CMDTARGET_ALLOW_SELF);
    
    if(!player)
        return PLUGIN_HANDLED;

    new value[32]; read_argv(2, value, charsmax(value));

    switch(value[0])
    {
        case '0': cs_set_user_model(player, "vip", false);
        case '1': cs_set_user_model(player, "vip", true);
        default: cs_reset_user_model(player);
    }

    client_print(id, print_center, "User: %n || Value: %c", player, value[0]);

    return PLUGIN_HANDLED;
} 


If you go on cs_assault, use the command amx_model name 0 to set your model without updating the index, use the cameras, then use amx_model name 2 to reset your model, again use the cameras, everything should work fine. Use amx_model name 1, which sets the model and updates the index and use the cameras, the camera origin will either bug out or the server will crash if you try it multiple times.


While we're on the subject of models, I'd also like to request a new native.

PHP Code:

/**
 * Returns if a model-lock is set on the client by a previous cs_set_user_model() call.
 *
 * @param index     Client index
 *
 * @noreturn        1 if a model-lock is set, 0 otherwise
 * @error           If the client index is not within the range of 1 to
 *                  MaxClients, or the client is not connected, an error will be
 *                  thrown.
 */
native cs_get_user_model_lock(index); 


[Arkshine]

Thanks for the report. Just found the silly error after testing. EDIT: PR #370

Looks like when setting the new model with SetModel, I forgot to allocate the string in the engine. If you don't do that, once native is executed, its memory is freed and when the game tries to access to pev_model to set camera model with the activator's, it contains garbage and the engine doesn't like that because it could not find the model in the precache list.

[PartialCloning]

Alright thanks. Would the cs_get_user_model_lock native be considered at all?

[Arkshine]

I don't know, Give me some usage example?

[PartialCloning]

https://forums.alliedmods.net/showthread.php?p=958925
https://forums.alliedmods.net/showthread.php?t=250244

Any plugin that enforces models using methods other than cs_set_user_model. If another plugin then uses cs_set_user_model the cpu usage will skyrocket as both the model plugin and the cs_set_user_model lock will be trying to set the model continuously. A simple cs_get_user_model_lock check would allow both to co exist peacefully.

[Arkshine]

If you have a model A set by some plugins, calling next several times cs_set_user_model with model A will do nothing. Also, SetClientKeyValue sent from cstrike module will not trigger hook from Fakemeta, so it's unlikely you would have such behavior. Did you try?

[PartialCloning]

It triggers the SetClientKeyValue hook for me.

PHP Code:

#include <amxmodx>
#include <amxmisc>
#include <cstrike>
#include <fakemeta>

public plugin_precache()
{
    precache_model("models/player/vip/vip.mdl");
}

public plugin_init()
{
    register_concmd("amx_model", "cmdModel", ADMIN_ALL, "<name or #userid> [value]");
    register_forward(FM_SetClientKeyValue, "SetClientKeyValue");
}

public cmdModel(id, level, cid)
{
    if(!cmd_access(id, level, cid, 2))
        return PLUGIN_HANDLED;

    new user[32]; read_argv(1, user, charsmax(user));
    new player = cmd_target(id, user, CMDTARGET_ALLOW_SELF);
    
    if(!player)
        return PLUGIN_HANDLED;

    new value[32]; read_argv(2, value, charsmax(value));

    switch(value[0])
    {
        case '0': cs_set_user_model(player, "vip", false);
        case '1': cs_set_user_model(player, "vip", true);
        default: cs_reset_user_model(player);
    }

    client_print(id, print_center, "User: %n || Value: %c", player, value[0]);

    return PLUGIN_HANDLED;
}

public SetClientKeyValue(id, const info[], const key[], const value[])
{
    if(equal(key, "model") && is_user_connected(id))
    {
        client_print(id, print_chat, "SetClientKeyValue 1:");

        if(1 <= get_user_team(id) <= 2)
        {
            if(!equal(value, "arctic"))
            {
                client_print(id, print_chat, "SetClientKeyValue 2:");

                set_user_info(id, "model", "arctic");
                return FMRES_SUPERCEDE;
            }
        }
    }

    return FMRES_IGNORED;
} 


Use amx_model name 2 to call cs_reset_user_model(), it'll trigger the hook which will then change your model to arctic again after it was reset by the cs_ native. Then do amx_model name 0, to trigger cs_set_user_model("vip"), thus setting a model lock on the player with the vip model. It'll also trigger SetClientKeyValue and the server will continuously call the SetClientKeyValue function as I assume it tries to set the model to arctic while cs_set_user_model sets it to vip.

[Arkshine]

It's a call from the game. When you set a new model, ClientUserInfoChanged is triggered in the game. In cstrike module, the model can be updated in ClientUserInfoChanged if needed, and any calls for SetClientKeyValuel is blocked if you have a model set by the native.

But yeah I guess it's expected you would get some infinite loop. By calling set_user_info(), you trigger ClientUserInfoChanged, model will be updated, game will trigger SetClientKeyValue, you set the model, etc.

The thing about these plugins is they are using such method because cs_set_user_model was generating issues. Mixing both ways, even before the fix in dev, would generate conflicts (there are not billion of ways to detect/update a model). That's why such behavior is expected and you are not supposed to do that. Adding a native for that reason/context that you are not supposed to do doesn't seem right. if you're using dev with such plugins specifically designed to fix a native, when next AMXX will be out, they will be eventually updated. The logic course would be you update those plugins to use the native everywhere.

Nothing is set in stone, I'm just giving you my thoughts.

[PartialCloning]

Another usage is to check if the user has a custom model set before applying another model? In cases where you do not want to override a player's model set by another plugin unless they have a default model. As the default model name could be changed using orpheu, checking if the model name equals a default cs model [terror, gign ..etc] won't always work.

For example plugin A is like the plugins I linked above, sets a permanent player model for a team or a player. But Plugin B sets a model for the player with the most kills. Plugin A checking if there is a model lock before applying the models would allow both to co exist, rather than plugin A overriding plugin B.