Scripting Tips - Revision history

Arran Fortuna: /* Server Performance */

2025-04-26T08:03:01Z

Server Performance

← Older revision		Revision as of 08:03, 26 April 2025
Line 69:		Line 69:
	* Try to be efficient, but if what you're doing is too time consuming or complex, is it really efficient?		* Try to be efficient, but if what you're doing is too time consuming or complex, is it really efficient?
	* Unless you have hundreds of players, don't worry about making little optimizations, check ''performancebrowser'' or ''ipb'' (ingame performancebrowser) and make sure no resource is using significantly more than the others.		* Unless you have hundreds of players, don't worry about making little optimizations, check ''performancebrowser'' or ''ipb'' (ingame performancebrowser) and make sure no resource is using significantly more than the others.
	* It's much more efficient to [[SetElementHealth]] ~~and~~ [[setElementRotation]] on a player client side (doing it server side sends an RPC to all players) consider a client event all your server scripts can call to set a players ~~health~~ on their client and their client will then update the server via puresync and that change is then relayed to clients via the next puresync or lightsync packet.		* It's much more efficient to [[SetElementHealth]] [[setElementRotation]] [[setPedArmor]] on a player client side (doing it server side sends an RPC to all players) consider a client event all your server scripts can call to set a players stat on their client and their client will then update the server via puresync and that change is then relayed to clients via the next puresync or lightsync packet. Note that doing this for position client isn't advised as the refresh rate for lightsync is low so would take a few seconds for remote players in another part of the map to see the player's new position.

	== Client Performance ==		== Client Performance ==

Arran Fortuna: Re-added something Srslyyyy removed as it is not "misleading information"

2025-04-26T07:59:21Z

Re-added something Srslyyyy removed as it is not "misleading information"

← Older revision		Revision as of 07:59, 26 April 2025
Line 69:		Line 69:
	* Try to be efficient, but if what you're doing is too time consuming or complex, is it really efficient?		* Try to be efficient, but if what you're doing is too time consuming or complex, is it really efficient?
	* Unless you have hundreds of players, don't worry about making little optimizations, check ''performancebrowser'' or ''ipb'' (ingame performancebrowser) and make sure no resource is using significantly more than the others.		* Unless you have hundreds of players, don't worry about making little optimizations, check ''performancebrowser'' or ''ipb'' (ingame performancebrowser) and make sure no resource is using significantly more than the others.
			* It's much more efficient to [[SetElementHealth]] and [[setElementRotation]] on a player client side (doing it server side sends an RPC to all players) consider a client event all your server scripts can call to set a players health on their client and their client will then update the server via puresync and that change is then relayed to clients via the next puresync or lightsync packet.

	== Client Performance ==		== Client Performance ==

Srslyyyy: Fix misleading information & add information about RT

2025-04-22T21:21:49Z

Fix misleading information & add information about RT

← Older revision		Revision as of 21:21, 22 April 2025
Line 20:		Line 20:
	You can also use this outside of any function:		You can also use this outside of any function:
	<syntaxhighlight lang="lua">outputChatBox("The resource " .. getResourceName(resource) .. " has just started!", 0, 255, 0)</syntaxhighlight>		<syntaxhighlight lang="lua">outputChatBox("The resource " .. getResourceName(resource) .. " has just started!", 0, 255, 0)</syntaxhighlight>
	~~And~~ the result ~~will~~ be the same, because ~~Lua executes every instruction~~ in ~~every script file of a resource when~~ it ~~starts~~.		However the result won't be exactly the same, as onClientResourceStart gets called only when all resource scripts are fully loaded, whilst code outside of it will be ran once '''this specific''' script is loaded. This is important, because load order of scripts exists, and you might want to call other script function (which gets loaded into memory afterwards), resulting in '''attempt to call global''' error. By using this specific event you have reliable time-frame to call it.
	* string.dump produces unsigned compiled Lua code which is not allowed for security reasons. The only way to transport code now is by using the source code. e.g.:		* string.dump produces unsigned compiled Lua code which is not allowed for security reasons. The only way to transport code now is by using the source code. e.g.:
	<syntaxhighlight lang="lua">exampleFunction = [===[		<syntaxhighlight lang="lua">exampleFunction = [===[
Line 66:		Line 66:
	== Server Performance ==		== Server Performance ==
	* Server lagging? Check [[Debugging#Debugging_Performance_Issues\|this page of debugging performance issues]]		* Server lagging? Check [[Debugging#Debugging_Performance_Issues\|this page of debugging performance issues]]
	* Using resourceRoot in ~~event handlers~~ for events ~~from clients~~ is much more efficient than using root.		* Using '''localPlayer''' (or if not possible: '''resourceRoot''') in '''2nd''' argument of triggerServer(Client)Event for events is much more efficient than using root.
	* Try to be efficient, but if what you're doing is too time consuming or complex, is it really efficient?		* Try to be efficient, but if what you're doing is too time consuming or complex, is it really efficient?
	* It's much more efficient to [[SetElementHealth]] and [[setElementRotation]] on a player client side, consider a client event all your server scripts can call to set a players health.
	* Unless you have hundreds of players, don't worry about making little optimizations, check ''performancebrowser'' or ''ipb'' (ingame performancebrowser) and make sure no resource is using significantly more than the others.		* Unless you have hundreds of players, don't worry about making little optimizations, check ''performancebrowser'' or ''ipb'' (ingame performancebrowser) and make sure no resource is using significantly more than the others.

	== Client Performance ==		== Client Performance ==
	* The biggest cause of client script CPU usage is anything done in onClient/Pre/~~Hud~~/Render because it is called ~~so often~~. For example if you have a script which calls dxDrawLine3D 20 times, 60 times a second, if those lines are only in 1 part of the map, consider adding a [[getDistanceBetweenPoints3D]] check between the local player and the general area that those lines are in and if they're no where near the player, don't draw the lines.		* The biggest cause of client script CPU usage is anything done in onClient/Pre/HUD/Render because it is called every frame. For example if you have a script which calls dxDrawLine3D 20 times, 60 times a second, if those lines are only in 1 part of the map, consider adding a [[getDistanceBetweenPoints3D]] check between the local player and the general area that those lines are in and if they're no where near the player, don't draw the lines.
			* '''dxDraw*''' functions can be highly optimised by using [https://wiki.multitheftauto.com/wiki/DxCreateRenderTarget dxCreateRenderTarget], which will merge them into one single '''dxDrawImage''' resulting in much less calls. This can be applied to parts of interface which are static, or updated periodically.
	* Another thing that gets called a lot and could therefore be quite consuming if not careful are events like [[onClientPlayerWeaponFire]] and [[onClientPlayerDamage]] so any scripts that use these should only be bound to the necessary elements (such as localPlayer instead of root) and run the simplest if statements for example if you wanted to handle a certain weapon being fired in a certain dimension it's better to check weapon first as that's a simple weaponID == x rather than getElementDimension(source) == y.		* Another thing that gets called a lot and could therefore be quite consuming if not careful are events like [[onClientPlayerWeaponFire]] and [[onClientPlayerDamage]] so any scripts that use these should only be bound to the necessary elements (such as localPlayer instead of root) and run the simplest if statements for example if you wanted to handle a certain weapon being fired in a certain dimension it's better to check weapon first as that's a simple weaponID == x rather than getElementDimension(source) == y.

Arran Fortuna: /* General Lua */

2023-08-02T17:30:14Z

General Lua

← Older revision		Revision as of 17:30, 2 August 2023
Line 5:		Line 5:
	* Be careful when looping a table where you intend to delete multiple rows, if 2 of them are in a row the 2nd one will get skipped! You must loop the table backwards (reverse ipairs). For example: ''for i = #table, 1, -1 do''		* Be careful when looping a table where you intend to delete multiple rows, if 2 of them are in a row the 2nd one will get skipped! You must loop the table backwards (reverse ipairs). For example: ''for i = #table, 1, -1 do''
	* Rather than having if checks inside if checks inside if checks, consider using ''return'' for example ''if (not ready) then return false end''		* Rather than having if checks inside if checks inside if checks, consider using ''return'' for example ''if (not ready) then return false end''
			* A quick way to clamp a number between a lower and upper value: math.min(math.max(x, min), max) and easy to remember, just think: "min max min max"

	== MTA Scripting ==		== MTA Scripting ==

Arran Fortuna at 17:22, 31 October 2022

2022-10-31T17:22:08Z

← Older revision		Revision as of 17:22, 31 October 2022
Line 5:		Line 5:
	* Be careful when looping a table where you intend to delete multiple rows, if 2 of them are in a row the 2nd one will get skipped! You must loop the table backwards (reverse ipairs). For example: ''for i = #table, 1, -1 do''		* Be careful when looping a table where you intend to delete multiple rows, if 2 of them are in a row the 2nd one will get skipped! You must loop the table backwards (reverse ipairs). For example: ''for i = #table, 1, -1 do''
	* Rather than having if checks inside if checks inside if checks, consider using ''return'' for example ''if (not ready) then return false end''		* Rather than having if checks inside if checks inside if checks, consider using ''return'' for example ''if (not ready) then return false end''
	* Keep event, variable & function names short but understandable - longer names will make the file larger in size. In client files, this will increase download time.
	* Remember that 'false' boolean has a value - If you want to delete a variable or element/account data, use 'nil' instead - this will reduce memory and disk usage (minuscule optimization, only notable on larger servers)

	== MTA Scripting ==		== MTA Scripting ==
			* Remember that 'false' boolean has a value - If you want to delete a variable or element/account data, use 'nil' instead - this will reduce memory and disk usage (minuscule optimization, only notable on larger servers)
	* Remember that 99% of the time it's a bug in your script, not an MTA bug! Don't report something to GitHub Issues until you're absolutely certain the bug can be reproduced with a small piece of script.		* Remember that 99% of the time it's a bug in your script, not an MTA bug! Don't report something to GitHub Issues until you're absolutely certain the bug can be reproduced with a small piece of script.
	* As MTA already has so many functions and events virtually everything you want to do is already possible, as long as you're willing to do the work! You'll find better solutions to problems as there are many ways to achieve the same thing as long as you know all the functions and events.		* As MTA already has so many functions and events virtually everything you want to do is already possible, as long as you're willing to do the work! You'll find better solutions to problems as there are many ways to achieve the same thing as long as you know all the functions and events.
Line 74:		Line 73:
	* The biggest cause of client script CPU usage is anything done in onClient/Pre/Hud/Render because it is called so often. For example if you have a script which calls dxDrawLine3D 20 times, 60 times a second, if those lines are only in 1 part of the map, consider adding a [[getDistanceBetweenPoints3D]] check between the local player and the general area that those lines are in and if they're no where near the player, don't draw the lines.		* The biggest cause of client script CPU usage is anything done in onClient/Pre/Hud/Render because it is called so often. For example if you have a script which calls dxDrawLine3D 20 times, 60 times a second, if those lines are only in 1 part of the map, consider adding a [[getDistanceBetweenPoints3D]] check between the local player and the general area that those lines are in and if they're no where near the player, don't draw the lines.
	* Another thing that gets called a lot and could therefore be quite consuming if not careful are events like [[onClientPlayerWeaponFire]] and [[onClientPlayerDamage]] so any scripts that use these should only be bound to the necessary elements (such as localPlayer instead of root) and run the simplest if statements for example if you wanted to handle a certain weapon being fired in a certain dimension it's better to check weapon first as that's a simple weaponID == x rather than getElementDimension(source) == y.		* Another thing that gets called a lot and could therefore be quite consuming if not careful are events like [[onClientPlayerWeaponFire]] and [[onClientPlayerDamage]] so any scripts that use these should only be bound to the necessary elements (such as localPlayer instead of root) and run the simplest if statements for example if you wanted to handle a certain weapon being fired in a certain dimension it's better to check weapon first as that's a simple weaponID == x rather than getElementDimension(source) == y.
	* Start checking variables since least aggravating. Example, first do simple checks: interior, dimension, distance, then check elementDatas, exports etc.

	== Speed comparison between local and global variables ==		== Speed comparison between local and global variables ==

CrosRoad95: /* Speed comparison between structural and OOP scripting */

2021-01-05T20:56:09Z

Speed comparison between structural and OOP scripting

← Older revision		Revision as of 20:56, 5 January 2021
Line 110:		Line 110:
	end		end
	stop = getTickCount()		stop = getTickCount()
	print("variable", stop - start ) -- more ~~then~~ 1500ms		print("variable", stop - start ) -- more than 1500ms
	</syntaxhighlight>		</syntaxhighlight>
	=== Faster ===		=== Faster ===
Line 120:		Line 120:
	end		end
	stop = getTickCount()		stop = getTickCount()
	print("structural", stop - start ) -- less ~~then~~ 200ms		print("structural", stop - start ) -- less than 200ms
	</syntaxhighlight>		</syntaxhighlight>

CrosRoad95: fix typo, then -> than

2021-01-05T20:55:58Z

fix typo, then -> than

← Older revision		Revision as of 20:55, 5 January 2021
Line 88:		Line 88:
	end		end
	stop = getTickCount()		stop = getTickCount()
	print("global", stop - start ) -- more ~~then~~ 500ms		print("global", stop - start ) -- more than 500ms
	</syntaxhighlight>		</syntaxhighlight>
	=== Faster ===		=== Faster ===
Line 98:		Line 98:
	end		end
	stop = getTickCount()		stop = getTickCount()
	print("local", stop - start ) -- less ~~then~~ 200ms		print("local", stop - start ) -- less than 200ms
	</syntaxhighlight>		</syntaxhighlight>

StrixG at 15:45, 1 May 2019

2019-05-01T15:45:13Z

← Older revision		Revision as of 15:45, 1 May 2019
Line 9:		Line 9:

	== MTA Scripting ==		== MTA Scripting ==
	* Remember that 99% of the time it's a bug in your script, not an MTA bug! Don't report something to ~~the mantis~~ until you're absolutely certain the bug can be reproduced with a small piece of script.		* Remember that 99% of the time it's a bug in your script, not an MTA bug! Don't report something to GitHub Issues until you're absolutely certain the bug can be reproduced with a small piece of script.
	* As MTA already has so many functions and events virtually everything you want to do is already possible, as long as you're willing to do the work! You'll find better solutions to problems as there are many ways to achieve the same thing as long as you know all the functions and events.		* As MTA already has so many functions and events virtually everything you want to do is already possible, as long as you're willing to do the work! You'll find better solutions to problems as there are many ways to achieve the same thing as long as you know all the functions and events.
	* If a script is getting too complicated, try putting back-end stuff in another file so the main script calls the functions in the 2nd one. For example rather than having meaningless things like ''vehicleTable[vehicle][7]'' in the main file, put that in a function in the 2nd file and have the main file call a meaningfully named function so rather than seeing a useless ''7'' you'd see something like ''getFuel'' and although this might take longer to set-up you'll save time in the long run as you'll spend less time being confused when you come back to it in a weeks time to debug a problem.		* If a script is getting too complicated, try putting back-end stuff in another file so the main script calls the functions in the 2nd one. For example rather than having meaningless things like ''vehicleTable[vehicle][7]'' in the main file, put that in a function in the 2nd file and have the main file call a meaningfully named function so rather than seeing a useless ''7'' you'd see something like ''getFuel'' and although this might take longer to set-up you'll save time in the long run as you'll spend less time being confused when you come back to it in a weeks time to debug a problem.

CrosRoad95: /* Client Performance */

2018-03-31T10:49:41Z

Client Performance

← Older revision		Revision as of 10:49, 31 March 2018
Line 74:		Line 74:
	* The biggest cause of client script CPU usage is anything done in onClient/Pre/Hud/Render because it is called so often. For example if you have a script which calls dxDrawLine3D 20 times, 60 times a second, if those lines are only in 1 part of the map, consider adding a [[getDistanceBetweenPoints3D]] check between the local player and the general area that those lines are in and if they're no where near the player, don't draw the lines.		* The biggest cause of client script CPU usage is anything done in onClient/Pre/Hud/Render because it is called so often. For example if you have a script which calls dxDrawLine3D 20 times, 60 times a second, if those lines are only in 1 part of the map, consider adding a [[getDistanceBetweenPoints3D]] check between the local player and the general area that those lines are in and if they're no where near the player, don't draw the lines.
	* Another thing that gets called a lot and could therefore be quite consuming if not careful are events like [[onClientPlayerWeaponFire]] and [[onClientPlayerDamage]] so any scripts that use these should only be bound to the necessary elements (such as localPlayer instead of root) and run the simplest if statements for example if you wanted to handle a certain weapon being fired in a certain dimension it's better to check weapon first as that's a simple weaponID == x rather than getElementDimension(source) == y.		* Another thing that gets called a lot and could therefore be quite consuming if not careful are events like [[onClientPlayerWeaponFire]] and [[onClientPlayerDamage]] so any scripts that use these should only be bound to the necessary elements (such as localPlayer instead of root) and run the simplest if statements for example if you wanted to handle a certain weapon being fired in a certain dimension it's better to check weapon first as that's a simple weaponID == x rather than getElementDimension(source) == y.
			* Start checking variables since least aggravating. Example, first do simple checks: interior, dimension, distance, then check elementDatas, exports etc.

	== Speed comparison between local and global variables ==		== Speed comparison between local and global variables ==

CrosRoad95 at 10:42, 31 March 2018

2018-03-31T10:42:35Z

← Older revision		Revision as of 10:42, 31 March 2018
Line 74:		Line 74:
	* The biggest cause of client script CPU usage is anything done in onClient/Pre/Hud/Render because it is called so often. For example if you have a script which calls dxDrawLine3D 20 times, 60 times a second, if those lines are only in 1 part of the map, consider adding a [[getDistanceBetweenPoints3D]] check between the local player and the general area that those lines are in and if they're no where near the player, don't draw the lines.		* The biggest cause of client script CPU usage is anything done in onClient/Pre/Hud/Render because it is called so often. For example if you have a script which calls dxDrawLine3D 20 times, 60 times a second, if those lines are only in 1 part of the map, consider adding a [[getDistanceBetweenPoints3D]] check between the local player and the general area that those lines are in and if they're no where near the player, don't draw the lines.
	* Another thing that gets called a lot and could therefore be quite consuming if not careful are events like [[onClientPlayerWeaponFire]] and [[onClientPlayerDamage]] so any scripts that use these should only be bound to the necessary elements (such as localPlayer instead of root) and run the simplest if statements for example if you wanted to handle a certain weapon being fired in a certain dimension it's better to check weapon first as that's a simple weaponID == x rather than getElementDimension(source) == y.		* Another thing that gets called a lot and could therefore be quite consuming if not careful are events like [[onClientPlayerWeaponFire]] and [[onClientPlayerDamage]] so any scripts that use these should only be bound to the necessary elements (such as localPlayer instead of root) and run the simplest if statements for example if you wanted to handle a certain weapon being fired in a certain dimension it's better to check weapon first as that's a simple weaponID == x rather than getElementDimension(source) == y.

			== Speed comparison between local and global variables ==

			=== Slower ===

			<syntaxhighlight lang="lua">

			start = getTickCount()
			a = 1
			for i=1,10000000 do
			a = 1
			end
			stop = getTickCount()
			print("global", stop - start ) -- more then 500ms
			</syntaxhighlight>
			=== Faster ===
			<syntaxhighlight lang="lua">
			start = getTickCount()
			local b = 1
			for i=1,10000000 do
			b = 1
			end
			stop = getTickCount()
			print("local", stop - start ) -- less then 200ms
			</syntaxhighlight>

			== Speed comparison between structural and OOP scripting ==
			=== Slower ===
			<syntaxhighlight lang="lua">
			start = getTickCount()
			a = 1
			for i=1,1000000 do
			a = localPlayer.position
			end
			stop = getTickCount()
			print("variable", stop - start ) -- more then 1500ms
			</syntaxhighlight>
			=== Faster ===
			<syntaxhighlight lang="lua">
			start = getTickCount()
			b = nil
			for i=1,1000000 do
			b = getElementPosition(localPlayer)
			end
			stop = getTickCount()
			print("structural", stop - start ) -- less then 200ms
			</syntaxhighlight>