Debugging - Revision history

Prox: /* Debug console */ clear the debug view

2022-07-04T08:56:19Z

Debug console: clear the debug view

← Older revision		Revision as of 08:56, 4 July 2022
Line 43:		Line 43:

	Of course, this is just an example and I've only skimmed the surface of error messages. There are plenty of other messages and scenarios, but you should get a general idea.		Of course, this is just an example and I've only skimmed the surface of error messages. There are plenty of other messages and scenarios, but you should get a general idea.

			===Clears the debug view===
			By typing '''cleardebug'''

	==Server & client debug logging==		==Server & client debug logging==

Haxardous at 19:45, 19 April 2020

2020-04-19T19:45:49Z

← Older revision		Revision as of 19:45, 19 April 2020
Line 42:		Line 42:
	</syntaxhighlight>		</syntaxhighlight>

	Of course, this is just an example and I've only skimmed the surface of error messages. There are plenty of other messages and scenarios, but you should get ~~the~~ general idea.		Of course, this is just an example and I've only skimmed the surface of error messages. There are plenty of other messages and scenarios, but you should get a general idea.

	==Server & client debug logging==		==Server & client debug logging==
Line 52:		Line 52:
	*The local.conf is the settings for the "host game" menu item in the main menu of MTA. This is a quick and easy way of starting a temporary server from inside the client. When the client is turned off the server will also turn off.		*The local.conf is the settings for the "host game" menu item in the main menu of MTA. This is a quick and easy way of starting a temporary server from inside the client. When the client is turned off the server will also turn off.

	*The mtaserver.conf is used when "MTA Server.exe" is executed from (MTA root folder)>server. This runs the server in its own console window which does not need the client to exist or to be run. This is can be useful if you're interested in hosting servers for a longer time period or if you want to experiment with a real world console.		*The mtaserver.conf is used when "MTA Server.exe" is executed from (MTA root folder)>server. This runs the server in its own console window which does not need the client to exist or to be run. This is can be useful if you're interested in hosting servers for a longer time period or if you want to experiment with a real-world console.

	Depending on which way you host, you will want to edit those files. The settings in question are:		Depending on which way you host, you will want to edit those files. The settings in question are:

	<syntaxhighlight lang="xml"><!-- Specifies the location and name of the debugscript log file. If left blank, server won't be saving this file. -->		<syntaxhighlight lang="xml"><!-- Specifies the location and name of the debugscript log file. If left blank, the server won't be saving this file. -->
	<scriptdebuglogfile>logs/scripts.log</scriptdebuglogfile>		<scriptdebuglogfile>logs/scripts.log</scriptdebuglogfile>

Line 62:		Line 62:
	<scriptdebugloglevel>0</scriptdebugloglevel></syntaxhighlight>		<scriptdebugloglevel>0</scriptdebugloglevel></syntaxhighlight>

	You want to make sure you have a log name specified. Also you want to specify what level of errors will be logged. If it is 0 nothing will be logged. The levels were explained at the top of this article. If the logging level was changed to 3, then in this case all '''serverside''' script errors log to (MTA root folder)>server>mods>deathmatch>logs>scripts.log		You want to make sure you have a log name specified. Also, you want to specify what level of errors will be logged. If it is 0 nothing will be logged. The levels were explained at the top of this article. If the logging level was changed to 3, then, in this case, all '''serverside''' script errors log to (MTA root folder)>server>mods>deathmatch>logs>scripts.log

	====Client====		====Client====
Line 70:		Line 70:

	==Debug strategies==		==Debug strategies==
	There are several strategies that support finding errors, apart from going through the code. Most of them include outputting debug messages, with have different information depending on the ~~situtation~~.		There are several strategies that support finding errors, apart from going through the code. Most of them include outputting debug messages, with have different information depending on the situation.

	===Useful functions===		===Useful functions===
Line 76:		Line 76:
	* [[outputDebugString]] or [[outputChatBox]] for outputting any information (use outputDebugString for technical output)		* [[outputDebugString]] or [[outputChatBox]] for outputting any information (use outputDebugString for technical output)
	* [http://www.lua.org/manual/5.1/manual.html#pdf-tostring tostring()] on a variable to turn the value into a string. Useful if the value is not a number or string.		* [http://www.lua.org/manual/5.1/manual.html#pdf-tostring tostring()] on a variable to turn the value into a string. Useful if the value is not a number or string.
	* [[inspect]] returns a useful human readable string notation of any datatype including tables, non-element userdatas such as ACL groups, accounts, etc, and elements.		* [[inspect]] returns a useful human-readable string notation of any datatype including tables, non-element userdatas such as ACL groups, accounts, etc, and elements.
	* [[iprint]] similar to inspect, except it takes in as many arguments as desired and outputs them into debugscript.		* [[iprint]] similar to inspect, except it takes in as many arguments as desired and outputs them into debugscript.
	* [[getElementType]] to check the type of the MTA element.		* [[getElementType]] to check the type of the MTA element.
Line 90:		Line 90:
	</syntaxhighlight>		</syntaxhighlight>

	Another application would be to check when variable values are modified. First search for all ~~occurences~~ of the variable being edited and add a message just beside it.		Another application would be to check when variable values are modified. First search for all occurrences of the variable being edited and add a message just beside it.

	===Add debugmessages to check the ''value'' of a variable===		===Add debugmessages to check the ''value'' of a variable===
Line 145:		Line 145:

	===A more inconspicuous error===		===A more inconspicuous error===
	But for some reason the message gets outputted twice when you stay in the colcircle while in a vehicle. Since it would appear some code is executed twice, we add debug messages to check this.		But for some reason, the message gets outputted twice when you stay in the colcircle while in a vehicle. Since it would appear some code is executed twice, we add debug messages to check this.

	<syntaxhighlight lang="lua">		<syntaxhighlight lang="lua">
Line 169:		Line 169:
	</syntaxhighlight>		</syntaxhighlight>

	Now we notice that both handler functions get executed twice when we are in a vehicle, but only once when we are on-foot. It would appear the vehicle triggers the colshape as well. To confirm this theory, we ensure that the ''player'' variable actually holds a reference to a player element.		Now we notice that both handler functions get executed twice when we are in a vehicle, but only once when we are on foot. It would appear the vehicle triggers the colshape as well. To confirm this theory, we ensure that the ''player'' variable actually holds a reference to a player element.

	<syntaxhighlight lang="lua">		<syntaxhighlight lang="lua">
Line 193:		Line 193:
	</syntaxhighlight>		</syntaxhighlight>

	The debug messages tell us that one of the ''player'' variables is a player and that the other one is a vehicle element. Since we only want to react when a player enters the colshape, we add an ''if'' that will end the execution of the function if it's '''not''' an player element.		The debug messages tell us that one of the ''player'' variables is a player and that the other one is a vehicle element. Since we only want to react when a player enters the colshape, we add an ''if'' that will end the execution of the function if it's '''not''' a player element.

	<syntaxhighlight lang="lua">		<syntaxhighlight lang="lua">
Line 260:		Line 260:
	==Debugging Performance Issues==		==Debugging Performance Issues==

	If your server is using up more resources than it should or you just want to make sure your scripts are efficient, you can find the source of the issue by using a great tool that comes with the default resource package called [[Resource:Performancebrowser\|performancebrowser]]. You can start it with ''''start performancebrowser''''. If it doesn't exist then you can get the latest resources from the [https://github.com/multitheftauto/mtasa-resources GitHub repository]. This tool provides an incredible amount of information for performance debugging. Memory leaks, element leaks and CPU intensive scripts are all easily findable via performancebrowser. If you use the ''''d'''' option in Lua timing you can see which functions are using up the CPU.		If your server is using up more resources than it should or you just want to make sure your scripts are efficient, you can find the source of the issue by using a great tool that comes with the default resource package called [[Resource:Performancebrowser\|performancebrowser]]. You can start it with ''''start performancebrowser''''. If it doesn't exist then you can get the latest resources from the [https://github.com/multitheftauto/mtasa-resources GitHub repository]. This tool provides an incredible amount of information for performance debugging. Memory leaks, element leaks, and CPU intensive scripts are all easily findable via performancebrowser. If you use the ''''d'''' option in Lua timing you can see which functions are using up the CPU.

	To access performancebrowser you will need to go to your web browser and enter the address: http://serverIPHere:serverHTTPPortHere/performancebrowser/ Note that the / at the end is required. So for example: http://127.0.0.1:22005/performancebrowser/ You will then need to login with an in-game admin account or any account that has access to ''''resource.performancebrowser.http'''' and ''''resource.ajax.http''''. Most of the information you will need ~~are~~ in the categories Lua timing and Lua memory, look for values that are much higher than other values.		To access performancebrowser you will need to go to your web browser and enter the address: http://serverIPHere:serverHTTPPortHere/performancebrowser/ Note that the / at the end is required. So for example: http://127.0.0.1:22005/performancebrowser/ You will then need to login with an in-game admin account or any account that has access to ''''resource.performancebrowser.http'''' and ''''resource.ajax.http''''. Most of the information you will need is in the categories Lua timing and Lua memory, look for values that are much higher than other values.

	===Examples of scripts that could cause performance problems===		===Examples of scripts that could cause performance problems===
Line 285:		Line 285:
	destroyElement(col)		destroyElement(col)
	end		end
	-- But sometimes it didn't so the script ended but the collision area remained and ~~over time~~		-- But sometimes it didn't so the script ended but the collision area remained and overtime
	-- you may end up with hundreds to thousands of pointless collision areas.		-- you may end up with hundreds to thousands of pointless collision areas.
	-- The Lua timing tab allows you to see the ~~amount~~ of elements each script has created.		-- The Lua timing tab allows you to see the number of elements each script has created.
	end		end
	</syntaxhighlight>		</syntaxhighlight>

	High CPU usage resulting in the server FPS dropping so much that the server is unplayable. In under 24 hours this can create havoc on a very busy server. The amount of "refs" in the Lua timing detect this type of build up, surprisingly the Lua timing tab didn't help in this case but Lua memory did.		High CPU usage resulting in the server FPS dropping so much that the server is unplayable. In under 24 hours, this can create havoc on a very busy server. The amount of "refs" in the Lua timing detect this type of build-up, surprisingly the Lua timing tab didn't help in this case but Lua memory did.
	<syntaxhighlight lang="lua">		<syntaxhighlight lang="lua">
	addEventHandler("onPlayerJoin", root, function()		addEventHandler("onPlayerJoin", root, function()
Line 302:		Line 302:
	</syntaxhighlight>		</syntaxhighlight>

	A function uses up a lot of your CPU because whatever it does takes a long time. This is just some function that takes a long time to complete. Without performancebrowser you'd have no idea its the cause but with performancebrowser you can see that a resource is using lots of CPU in the Lua timing tab. If you then enter: ''''d'''' into the options edit box it will even tell you what file name and first line of the function that is using up so much CPU.		A function uses up a lot of your CPU because whatever it does takes a long time. This is just some function that takes a long time to complete. Without performancebrowser you'd have no idea its the cause but with performancebrowser you can see that a resource is using lots of CPU in the Lua timing tab. If you then enter: ''''d'''' into the options edit box it will even tell you what file name and the first line of the function that is using up so much CPU.
	<syntaxhighlight lang="lua">		<syntaxhighlight lang="lua">
	function someDodgyCode()		function someDodgyCode()

StrixG at 08:35, 18 January 2020

2020-01-18T08:35:24Z

← Older revision		Revision as of 08:35, 18 January 2020
Line 65:		Line 65:

	====Client====		====Client====
	Navigate to: ''(MTA root folder)>~~server~~>clientscript.log''		Navigate to: ''(MTA root folder)>MTA>logs>clientscript.log''

	This file logs all '''clientside''' script errors. This is set to log by default, no setup required.		This file logs all '''clientside''' script errors. This is set to log by default, no setup required.

LordHenry: /* Debug console */

2019-06-22T00:00:01Z

Debug console

← Older revision		Revision as of 00:00, 22 June 2019
Line 3:		Line 3:
	==Debug console==		==Debug console==
	MTA features a built-in debug console that shows debug messages output from MTA functions or from scripts. Keeping it mind that you should have administrator access (unless you modify the ACL to change this), you can open the debug console by typing ''debugscript x'' in the console, where ''x'' is the debug level:		MTA features a built-in debug console that shows debug messages output from MTA functions or from scripts. Keeping it mind that you should have administrator access (unless you modify the ACL to change this), you can open the debug console by typing ''debugscript x'' in the console, where ''x'' is the debug level:
			* '''0:''' close debug console
	* '''1:''' only errors		* '''1:''' only errors
	* '''2:''' errors and warnings		* '''2:''' errors and warnings

Myonlake: Undo revision 58213 by WolfPiotrK2 (talk)

2018-08-16T12:49:02Z

Undo revision 58213 by WolfPiotrK2 (talk)

Show changes

WolfPiotrK2: Replaced content with "Image:mtapl.jpg"

2018-08-16T12:45:52Z

Replaced content with "Image:mtapl.jpg"

Show changes

Surge at 12:56, 30 July 2018

2018-07-30T12:56:55Z

← Older revision		Revision as of 12:56, 30 July 2018
Line 310:		Line 310:
	</syntaxhighlight>		</syntaxhighlight>

	[[hu:~~Hibakeresés~~]]		[[hu:Debugging]]
	[[it:Guida al Debug]]		[[it:Guida al Debug]]
	[[Category:Scripting Concepts]]		[[Category:Scripting Concepts]]

Surge at 12:56, 30 July 2018

2018-07-30T12:56:41Z

← Older revision		Revision as of 12:56, 30 July 2018
Line 310:		Line 310:
	</syntaxhighlight>		</syntaxhighlight>

			[[hu:Hibakeresés]]
	[[it:Guida al Debug]]		[[it:Guida al Debug]]
	[[Category:Scripting Concepts]]		[[Category:Scripting Concepts]]

MrTasty: /* Useful functions */ added inspect and iprint

2018-06-24T10:34:54Z

Useful functions: added inspect and iprint

← Older revision		Revision as of 10:34, 24 June 2018
Line 75:		Line 75:
	* [[outputDebugString]] or [[outputChatBox]] for outputting any information (use outputDebugString for technical output)		* [[outputDebugString]] or [[outputChatBox]] for outputting any information (use outputDebugString for technical output)
	* [http://www.lua.org/manual/5.1/manual.html#pdf-tostring tostring()] on a variable to turn the value into a string. Useful if the value is not a number or string.		* [http://www.lua.org/manual/5.1/manual.html#pdf-tostring tostring()] on a variable to turn the value into a string. Useful if the value is not a number or string.
			* [[inspect]] returns a useful human readable string notation of any datatype including tables, non-element userdatas such as ACL groups, accounts, etc, and elements.
			* [[iprint]] similar to inspect, except it takes in as many arguments as desired and outputs them into debugscript.
	* [[getElementType]] to check the type of the MTA element.		* [[getElementType]] to check the type of the MTA element.
	* [[isElement]] to check if the MTA element exists.		* [[isElement]] to check if the MTA element exists.

StrixG at 16:37, 15 April 2017

2017-04-15T16:37:31Z

Show changes