[pizzahut]

Map specific configs are loaded with a 6.1s delay by AMXX. I know the function ("delayed_load") used to be in admin.sma with AMXX 1.8.x, and was later moved into CoreConfig.cpp and configured in meta_api.cpp with AMXX 1.9 (functions "CoreConfig::ExecuteMapConfig", "CoreConfig::OnMapConfigTimer" and "CoreConfig::SetMapConfigTimer" / CoreCfg.SetMapConfigTimer).

The simple work-around (in order to change the delay) is to copy the delayed_load function from an old admin.sma file to a new plugin, which would probably lead to the map configs being executed twice (by the plugin and by AMXX's CoreConfig.cpp).

I wonder, can the C function SetMapConfigTimer which is in CoreConfig.cpp be called by a plugin? So that AMXX's CoreConfig executes the map configs at a different time. I guess it would require writing a module, this plugin didn't do anything:

#include <amxmodx>

// Function names from https://github.com/alliedmodders/amxmodx/search?q=SetMapConfigTimer

//native CoreCfg.SetMapConfigTimer(const Float:time);
//native CoreConfig::SetMapConfigTimer(const Float:time);
native SetMapConfigTimer(const Float:time);

public plugin_init()
{
  register_plugin("SetMapConfigTimer", "1", "pizzahut")
}

public plugin_cfg()
{
  SetMapConfigTimer(0.1)
}

Also does anyone know why there is a 6.1s delay in the first place? IMO it could have been zero in old admin.sma, because plugin_cfg is called after plugin_init of all plugins has been executed (AFAIK). So all plugin cvars should be registered already.

[fysiks]

It is not exported as a native available to plugins. In theory, yes, it could be but I would expect it to require modifying AMX Mod X itself to give access to it. That delay does seem quite strange, I never knew this.

I browsed the code a little and it looks like if you use server_cmd() with the string "/maps" in it (anywhere) before this 6.1 second delay, it will prevent the map-specific configs from being executed ever. This then also prevents the OnConfigsExecuted() forward from being executed. Bizarre. I would think this would be a bug.

Part of me wonders if there is some valid reason for the 6.1 second delay. Then I wonder, maybe that reason isn't valid anymore?

[McTavish]

Originally Posted by fysiks It is not exported as a native available to plugins. In theory, yes, it could be but I would expect it to require modifying AMX Mod X itself to give access to it. That delay does seem quite strange, I never knew this. I browsed the code a little and it looks like if you use server_cmd() with the string "/maps" in it (anywhere) before this 6.1 second delay, it will prevent the map-specific configs from being executed ever. This then also prevents the OnConfigsExecuted() forward from being executed. Bizarre. I would think this would be a bug. Part of me wonders if there is some valid reason for the 6.1 second delay. Then I wonder, maybe that reason isn't valid anymore?

It is possible that the 6.1 second delay was added for a specific reason, but it is not clear to me what that reason would be based on the information you have provided. It could be worth looking into the commit history of the AMXX codebase to see if any information can be gleaned from the commit messages or code changes around the time that the delay was introduced.

As for calling the SetMapConfigTimer function from a plugin, it would require modifying AMX Mod X itself to make this function available to plugins as a native. This would involve adding an export for the function in the AMX Mod X source code and then rebuilding the binary.

It is not recommended to modify the AMX Mod X binary unless you are very familiar with the codebase and know exactly what you are doing, as it can lead to instability and other issues if done incorrectly. It may be better to consider alternative ways of achieving your goal, such as using a separate plugin to execute the map-specific configs at the desired time.

[pizzahut]

Originally Posted by McTavish It could be worth looking into the commit history of the AMXX codebase to see if any information can be gleaned from the commit messages or code changes around the time that the delay was introduced.

https://github.com/alliedmodders/amx...b4bfc5bb343362
Not much info there. Added a comment to the commit.

AMXX 0.20 RC7 changes don't mention it. https://forums.alliedmods.net/showthread.php?t=7178

Also searched Bugzilla to no avail.

Edit: Received a reply at GitHub:

No, sorry, I don't remember this magic number from 18 years ago It could be a fudge factor to deal with some kind of asynchronous behavior, eg to make sure a command "definitely" occurs after another. SourceMod injects special tokens into the command buffer instead.

[shayan123]

The 6.1s delay is in place to give all plugins time to initialize and register their cvars before the map config is executed. This way, any cvars that are set in the map config will not overwrite any values that were set by plugins during initialization.

It is not possible to call the C function SetMapConfigTimer from a plugin, as it is a part of AMXX's internal code and cannot be accessed by external plugins. The plugin you have provided does not work as it does not call the correct function.

A possible work-around for this issue would be to use the plugin_cfg() function in your plugin to set cvars to their desired values after the map config has been executed, or to use a plugin that allows for dynamic configuration reloading such as "Dynamic Configs" which allows you to reload the configs with a command.