Previously it was stated by BAILOPAN that logs were now blockable via the plugin_log forward.
(Post is here:
http://forums.alliedmods.net/showthread.php?p=60677)
However, I've noticed this isn't the case.
For instance:
Code:
public plugin_log() {
return PLUGIN_HANDLED
}
That should logically block all log messages, but it does not. Try it out yourself.
Personally I would like this blocking functionality without having to use FakeMeta. So after investigating the code, I think I've figured out a way to fix this.
All the following changes would take place in meta_api.cpp, btw.
First line 1252 in GetEngineFunctions_Post should be removed or commented.
Code:
meta_engfuncs_post.pfnAlertMessage = C_AlertMessage_Post;
And C_AlertMessage should be added to the meta_engfunc in GetEngineFunctions after line 1234 like so:
Code:
meta_engfuncs.pfnAlertMessage = C_AlertMessage;
Next the entire C_AlertMessage_Post function (which starts on line 964) needs to be removed and replaced with a new function for C_AlertMessage like so:
Code:
void C_AlertMessage(ALERT_TYPE atype, char *szFmt, ...)
{
if (atype != at_logged)
RETURN_META(MRES_IGNORED);
/* There are also more messages but we want only logs
at_notice,
at_console, // same as at_notice, but forces a ConPrintf, not a message box
at_aiconsole, // same as at_console, but only shown if developer level is 2!
at_warning,
at_error,
at_logged // Server print to console ( only in multiplayer games ).
*/
// execute logevents and plugin_log forward
if (g_logevents.logEventsExist() || FF_PluginLog >= 0)
{
va_list logArgPtr;
va_start ( logArgPtr , szFmt );
g_logevents.setLogString( szFmt , logArgPtr );
va_end ( logArgPtr );
g_logevents.parseLogString( );
if (g_logevents.logEventsExist())
g_logevents.executeLogEvents( );
cell retVal = executeForwards(FF_PluginLog);
if (retVal)
RETURN_META(MRES_SUPERCEDE);
}
RETURN_META(MRES_IGNORED);
}
You see the problem was that trying to block logs via the post function just won't work as it's called after the actual AlertMessage is called. This is why the code needed to be transferred to C_AlertMessage instead of C_AlertMessage_Post. Also MRES_SUPERCEDE needed to be used instead of MRES_HANDLED after the plugin_log return value was checked, because that was really the only way to block the log messages.
After testing a newly compiled DLL with these code changes, everything seems to be working as it should. Retuning PLUGIN_HANDLED in plugin_log would indeed block the log message. And returing PLUGIN_CONTINUE would still let the log message go through.