Raised This Month: $51 Target: $400
 12% 

[CORE] Blocking Logs Problem


  
 
 
Thread Tools Display Modes
Author Message
DS
SourceMod Developer
Join Date: Sep 2004
Location: WI, USA
Old 10-12-2004 , 20:02   [CORE] Blocking Logs Problem
#1

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.
DS is offline
BAILOPAN
Join Date: Jan 2004
Old 10-12-2004 , 20:04  
#2

yeah this was already known from a talk with firestorm after RC6, I haven't decided whether people should be using fakemeta yet

personally they should as I'd like to keep core clean in this respect, it depends on the demand for the capability
__________________
egg
BAILOPAN is offline
BAILOPAN
Join Date: Jan 2004
Old 10-12-2004 , 20:06  
#3

reference:

http://forums.alliedmods.net/showthr...?t=6499&page=2
__________________
egg
BAILOPAN is offline
 



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -4. The time now is 09:12.


Powered by vBulletin®
Copyright ©2000 - 2024, vBulletin Solutions, Inc.
Theme made by Freecode