System for your scripts
In this tutorial I will help you out with making a system for your scripts.
I am not meaning a system, I am meaning more alike an order for everything, meaning easier to read the script.
Local
Local can be used in many ways, and I usually use it to make it easier to modify some little things such as radius', positions or messages.
Notepad++
Notepad++ is an excellent editor for scripting and programming. I use this in Multi Theft Auto, because it has a plug-in for LUA code, making it easier to read your parts there. I am not sure if there's any official Multi Theft Auto LUA plug-in for Notepad++ yet, that it would show all function names and event handlers with color. However, I suggest this program.
Get your own copy here.
Tabulator button
Tabulator (TAB -button) is a good way of organizing your codes in different 'dimensions'. It makes it easier for you to read specific lines. I am sure many other scripters use tabulator button while scripting.
Parts
We're going to start with the folder here. Create a folder at your 'resources' main folder at your server files. After you've successfully created the folder, click it open and create a new notebook file there with right clicking the interior, selecting 'New', and click 'Text Document'. Now black the whole name, including the .txt end. Make the name like: meta.xml. Now press enter and it's a new XML file.
Meta.xml is your resource's main file, which includes stuff like exports, files, settings and resource info.
Create a new file for 'server.lua' with the same tactic as I showed you above.
Right click the 'meta.xml' file and select 'Edit with Notepad++'. Notepad++ will automaticly change the file code to XML, if it didn't do that (cannot see any colors when you do the below things), select 'Language' from the menu bar and select 'XML'.
Now let's setup the meta.xml interior. Create the main meta-tags like below.
<meta>
</meta>
We'll now put in the info meta-tag, it's not required to let the script work, but some scripts/gamemodes might bug without it to be inserted.
<meta>
<info author="" name="" description="" type="" version=""></info>
</meta>
You can set anything you want into those empty quotation marks, except the 'info type'. You can put in: gamemode, script, map, misc. Let's put in the 'script' one because it's a script, right?
Now let's proceed to the script meta-tag. It's required if you want your script to work.
<meta>
<info author="" name="" description="" type="" version=""></info>
<script src="" type=""></script>
</meta>
Now here's the tricky part. Which type should I put in, server or client? Well I told you before to create a file named server.lua, but it still doesn't say that why should you put it to server?
Well, let me explain you the differences between client- and server-side.
Client-Side
Client-side lets the client (player) download the file(s) to their own computer. It can be read and even copied. However, don't panic. There is a possibility of two things.
First we're able to change the script to server-side. Many functions that you'd use on client-side work aswell in the server-side. You can check out all the client- and server-side functions/events here: client-side functions, client-side events, server-side functions, server-side events.
That's not the only way of surviving from the 'catastrofic stuff'. Only people who might want to copy your scripts are newbies like you (if you're a newbie..) who doesn't want to script themselves as they're lazy and cannot enjoy the fun of scripting and Multi Theft Auto in general.
We're able to compile your scripts. Meaning that the code gets 'hashed' and being unable to be read and copied. It can be uncompiled, but there aren't many who can/want to do that. You see, uncompilators cannot read all functions. Meaning that they will fail with uncompiling it fully. However, always keep another copy of the scripts on your computer. You can keep them safely in the same folder with a different name as long as the meta.xml doesn't include those files like showed before.
After 1.3.4 Multi Theft Auto released its own compilation system that you are forced to use. You can find this system here »
Server-Side
Instead of the client downloading the file, the server downloads it. Meaning that client is unable to read the file as it will not be uploaded into his computer. No need for compiling unless you share the code in community.multitheftauto.com. However, server-side can be more laggy than client-side in some things. That's why bigger scripts that use client a lot, should be left to the client-side, however it's not a must either...
Back to the scripting part.
<meta>
<info author="MTA:SA" name="Testing Script" description="I am testing a tutorial!" type="script" version="1.0.0"></info>
<script src="server.lua" type="server"></script>
</meta>
Good! Now we're ready for the scripting with LUA. Open up the 'server.lua' file. Now if the file doesn't highlight (set colors) on the script while scripting, then it haven't recognized the language. Do the same thing as I told you to do with the meta file. So, select 'Language' from the menu bar, then select 'L > Lua'. Now it's changed to Lua code.
We're going to script something really simple, like a command to get full health script.
Starting with the locals I told you about.
local cooldown = 300
'cooldown' is the cool down in seconds when you're able to use the upcoming health command again. 300 seconds is five minutes.
If you want to know how did I know 5 minutes is 300 seconds, look at this thing:
- Open up Google
- Write in: 5 minutes in seconds
- Cool isn't it? Try this: 5 minutes in milliseconds
That's right, Google can be used as a calculator aswell!
Let's continue with the script.
Now I create the actual function, which is made with a name: giveFullHealth.
local cooldown = 300
function giveFullHealth()
end
Now I have the function there.. but I still need the command handler there with it's arguments.
Function arguments for commands:
- player: executor of the command
- cmd: command
- optional arguments: you do not need any more arguments than player and cmd. Optional arguments are those arguments that are used within the command like: /kick . The player part there. If you want the command to have more than one argument, just add one argument more after the other one etc. It would be like this: (player, cmd, target).
local cooldown = 300
function giveFullHealth(player, cmd)
end
addCommandHandler("fullhealth", giveFullHealth)
Now I have all the arguments within the function. I also added the command handler (command name: fullhealth).
Let's make more locals for the upcoming functions to make it easier to modify them without not much look into the script.
Dataname: elementdata name.
Commandname: name of the command.
Note_restored: chatbox message about when health is restored successfully.
Note_info: chatbox message about when cooldown ends.
Note_active: chatbox message about that the cooldown is still active.
local cooldown = 300
local dataname = "health.cooldown"
local commandname = "fullhealth"
local note_restored = "Health restored successfully."
local note_info = "You need to wait 5 minutes before you can do this again."
local note_active = "Cooldown is still active, please wait."
function giveFullHealth(player, cmd)
end
addCommandHandler(commandname, giveFullHealth)
I hope you understand what I mean with a system or organizing your scripts. It's easier to modify, right?
Let's continue to the check-part. I created a check for if the cooldown is still active when the player tries to give full health to him/herself.
local cooldown = 300
local dataname = "health.cooldown"
local commandname = "fullhealth"
local note_restored = "Health restored successfully."
local note_info = "You need to wait 5 minutes before you can do this again."
local note_active = "Cooldown is still active, please wait."
function giveFullHealth(player, cmd)
local timer = getElementData(player, dataname)
if not timer then
else
end
end
addCommandHandler(commandname, giveFullHealth)
Good, now the only thing we need is to make the timer and messages, plus the element data for the player when command is executed.
setTimer is counted in milliseconds (ms), which is less than a second. It means that we need to count the real time. Well, we do not need to put in the actual time, we just put a star icon (*) after the 'cooldown', then put thousand after the star icon.
It counts the actual milliseconds there.
I am removing the element data (removeElementData) from the player after the cooldown is over, allowing them to do the command again.
local cooldown = 300
local dataname = "health.cooldown"
local commandname = "fullhealth"
local note_restored = "Health restored successfully."
local note_info = "You need to wait 5 minutes before you can do this again."
local note_active = "Cooldown is still active, please wait."
function giveFullHealth(player, cmd)
local timer = getElementData(player, dataname)
if not timer then
outputChatBox(note_restored, player, 0, 255, 0, false)
outputChatBox(note_info, player, 220, 220, 0, false)
setElementData(player, dataname, true)
setElementHealth(player, 100)
setTimer(removeElementData, cooldown * 1000, 1, player, dataname)
else
outputChatBox(note_active, player, 255, 0, 0, false)
end
end
addCommandHandler(commandname, giveFullHealth)
Timer's arguments are the following:
setTimer(function/function name/MTA function, milliseconds, times executed, [optional arguments])
Function: an actual function inside a timer like this the following. It shows a message in the chatbox after one second for all clients in the server. However this is not to be used in cases like these. More alike when you have a lot of functions in this.
setTimer(function()
outputChatBox("Hello world!", getRootElement())
end, 1000, 1)
Function name: i.e. a function name like we did earlier the full health script. Function name was 'giveFullHealth'.
MTA function: the previous timer I showed you should be made like this as it's just a one MTA function in there.
setTimer(outputChatBox, 1000, 1, "Hello world!", getRootElement())
Times executed: 0 = repeatedly, 1+ = times
----
Thanks for reading my small tutorial, more tutorials coming up, and I am using this system in them aswell.
