[Jhob94]

I'll not be explaining the basic stuff, you have the search button available.
This tutorial is made for intermediate-advanced level scripters.

I keep watching people talking non-sense on scripting help so i am here to give some explanations. First i did a little research to figure out why there are so many people wrong and i found a Tutorial made by Hawk552. This tutorial is old and is not accurate.

Originally Posted by Hawk552 set_task can sometimes be an extremely useful function, but other times it is really overkill. What few people know is that it is a very expensive operation, the CPU has to literally check every cycle if it is time for the set_task to be executed. Usually, there are ways around a set_task.

This information is False.

It will check every cycle even if you are not using tasks. So using a task will not overkill anything. It is completly fine to use and you should use it as long as it fits your needs the best.


So, when should you not use a task?

• When you need the cycle to be checked in less than 0.1 seconds, this way you should use an entity think.
• When you want to retrieve accurate data. This way you should create a float and play with it. Like i did on my Harry Potter mod, i've used g_fSkillTime[id] so i could later get it's value to display on Hud.

And this brings us to the other myth:

When should we use task_exists?
Many people think that this function exists to remove a task safely. This is also False.

This function allows you not to waste memory while playing with Task Id. Instead of using a bool to define something true/false on the task you can just use task_exists to know if the user has the temporary tool.
Also you don't need to check if the task exists in order to remove it. The remove_task function already checks if it exists. Actually there is no harm on checking if the task exists, but you are making a repeated unnecessary step.

[lexzor]

people should keep in mind some topics are from ancient times where almost everything could be considered as a overkill for server hardware enviroment

set_task could be a overkill, depends on what you do on it

[Jhob94]

Originally Posted by lexzor set_task could be a overkill, depends on what you do on it

It will always check for tasks. Using a task will not overkill anything.

[Bugsy]

I recall reading that it was not the task running that was expensive, it was the creation of the task. Granted, computers have come a long way since 2010 so this likely doesn't matter anymore assuming you are not calling set_task() a million times. In the past I have used a thinking entity opposed to set_task() based on this mindset, but set_task() is certainly easier.

[Jhob94]

@Bugsy maybe back in the days it was somehow expensive, but i am not so sure. This looks fine to me

static cell AMX_NATIVE_CALL set_task(AMX *amx, cell *params) /* 2 param */
{

	CPluginMngr::CPlugin *plugin = g_plugins.findPluginFast(amx);

	int a, iFunc;

	char* stemp = get_amxstring(amx, params[2], 1, a);

	if (params[5])
	{
		iFunc = registerSPForwardByName(amx, stemp, FP_ARRAY, FP_CELL, FP_DONE);
	} else {
		iFunc = registerSPForwardByName(amx, stemp, FP_CELL, FP_DONE);
	}

	if (iFunc == -1)
	{
		LogError(amx, AMX_ERR_NATIVE, "Function is not present (function \"%s\") (plugin \"%s\")", stemp, plugin->getName());
		return 0;
	}

	float base = amx_ctof(params[1]);

	if (base < 0.1f)
		base = 0.1f;

	char* temp = get_amxstring(amx, params[6], 0, a);

	g_tasksMngr.registerTask(plugin, iFunc, UTIL_ReadFlags(temp), params[3], base, params[5], get_amxaddr(amx, params[4]), params[7]);

	return 1;
}

void CTaskMngr::registerTask(CPluginMngr::CPlugin *pPlugin, int iFunc, int iFlags, cell iId, float fBase, int iParamsLen, const cell *pParams, int iRepeat)
{
	// first, search for free tasks
	for (auto &task : m_Tasks)
	{
		if (task->isFree() && !task->inExecute())
		{
			// found: reuse it
			task->set(pPlugin, iFunc, iFlags, iId, fBase, iParamsLen, pParams, iRepeat, *m_pTmr_CurrentTime);
			return;
		}
	}
	// not found: make a new one
	auto task = ke::AutoPtr<CTask>(new CTask);
		
	if (!task)
		return;
		
	task->set(pPlugin, iFunc, iFlags, iId, fBase, iParamsLen, pParams, iRepeat, *m_pTmr_CurrentTime);
	m_Tasks.append(ke::Move(task));
}

But back in 2005 maybe it was an expensive operation. My first computer was a laptop, i am not sure what year it was but it was around 2005-2008 and it had finger print scan in order to login. Computers were not so bad back then, but who knows. Personally i believe this was a missconception, amxx was too fresh, it's normal to get some stuff wrong.

[Bugsy]

I don't know, I'm only the messenger. I've personally never had any problems using set_task() so I wouldn't hesitate to use it going forward. Granted, I still try to use it sparingly, as you should with all code/natives - eg. if you need a task to do XYZ on a player, create a single repeating task and perform XYZ on player(s) when conditions are met.

[rtxa]

According to IgnacioFDM https://github.com/alliedmodders/amxmodx/pull/380, set_task has some performance issues, like using a linked list instead of std::vector or not ordering tasks by execution time instead so you don't iterate over the entire task list every frame. Unfortunately, the PR has never been finished and it also fixes some precision issues. With today's computer will be this an issue? I don't think so, it all depends on what the set_task is being used for.

[mlibre]

It was believed that these tasks were expensive in terms of memory and CPU requirements, but it seems that it no longer matters, technology has advanced, another piece of information, if you need to execute a task less than 0.1, It will not be your alternative

PHP Code:

if (base < 0.1f)
        base = 0.1f; 


[meTaLiCroSS]

Are you aware that set_task algorithm has changed since 2006, the year that topic was made? You can find many of "nonsense" on Scripting Help talking about what to optimize or not, but today's machine are not aware at all of that kind of comsumption wasting. I assume you're looking today's AMXX source code, which is fine to refute in nowadays; but that can't be assumed as false, since it WAS a reality those days.

If you're an intermediate-expert AMXX code you'll notice that everything in the past is vastly considered "expensive/unoptimized", like, skipping function calls, avoid native calls, engine > fakemeta (because a few decimals in benchmarkings), the typical new vs static argument, variable size reductions, etcetera.

set_task should be avoided if you want to be accurate and that's all, you can use timers and think functions instead, everything else is upon coder's decisions.

[Jhob94]

The reason why i created this topic is because there was still a lot of people missinformed at scripting help.
I’ve no idea how it was in 2006, it doesn’t matter, UP TO THIS DATE, people were providing wrong information.
About what you said on when tasks should be avoided, it is already mentioned on the thread.

Anyway, good to see you active. I hope you are staying.