Fixed commands not registering properly when given strings are not persistent

[satoon101]

Fixed names starting with / and ! (and probably others, as well) not being registered properly.

I'm not entirely sure this is the best way to fix, which is why I created a pull request instead of just merging into master. It does work properly, though, for my testing with GunGame.

Before this fix, none of my say commands that started with ! or / were working. I added some debug messages in src/core/modules/commands/commands.h where the comparisons are made, and all of the say commands that started with / or ! showed as a bunch of weird symbols. That led me to believe that I needed to make copies before registering.

I believe I could also do this by storing all of these as attributes in GunGame itself, so they persist. However, I don't necessarily believe that is the correct action to take in this instance as others might easily end up in my situation in the future without a permanent fix in SP itself.

[jordanbriere]

This is introducing a memory leak. strdup is allocating memory that you need to release yourself. This would probably be a better approach:

//-----------------------------------------------------------------------------
// CSayCommandManager constructor.
//-----------------------------------------------------------------------------
CSayCommandManager::CSayCommandManager(const char* szName)
{
	m_Name = strdup(szName);
}

//-----------------------------------------------------------------------------
// CSayCommandManager destructor.
//-----------------------------------------------------------------------------
CSayCommandManager::~CSayCommandManager()
{
	free(m_Name);
}

And replace:

g_SayCommandMap.insert(std::make_pair(szNameCopy, manager));

With:

g_SayCommandMap.insert(std::make_pair(manager->m_Name, manager));

[Ayuto]

I agree with L'In20Cible. Though, we already create a copy. We just never use (and never free it).

[satoon101]

Ok, thank you both! I have updated the code with that fix. I also went ahead and made the same fix for client/server commands, as they likely suffer from the same issue.

[Ayuto]

Looks good!