RBLX Luau Guide 1 - Prints and variables

Resources Community Tutorials
,
#1

NOTICE

This isn’t 100% correct and i don’t know how to explain so many things. Some stuff that i note is basically taken of google or it’s utilizing on my knowledge. I’m just trying to help you! (this is a past notice)

Introduction to Luau

Luau is a fast, small, safe, gradually typed embeddable scripting language derived from Lua. It is designed to be backwards compatible with Lua 5.1, as well as incorporating some features from future Lua releases, but also expands the feature set (most notably with type annotations).

Luau is made for roblox with lots of modifications with the scripting language Lua.

Hello World!

To start with simple stuff about scripting, You will require a script.

If you create a script and double-click it you will see the following line:

print("Hello World!")

This line will send a message to the output and the server (since it’s a serverscript).

It’s really useful on debugging your code to check if it’s working or not.

There are other types of prints such as

warn("Hello World!")

error("Hello World!")

Warn will print a yellow message to the server to serve as a warning.

Error will do the same thing as Warn and print (but with a red color) but you cannot add any more line after that. (except for ends)

You can write code after a error if inbetween there is a end (in this case a function which is gonna be later explained in the next post.)

Variables

Variables are stuff to store values such as the location of a part.

Here’s a example of a variable:

local variable = 3

You can use it in so much stuff to determine a value, And yes, It’s editable in the script by a line.

local variable = 3

variable = 2 --Changes the variable to 2 instead of keeping it as 3.

Variables + Prints

You can print a variable as soon it is classified as a string.

local variable = "Hello!" --in this case it will be a string type (note that numbers are still classified as a printable way)

print(variable)

You can change the name of the variable by editing it. Not just being “variable”

local Message
local ItsAVariable
local HiDevforum

--Variables without a value is classified as nil.

Prologue

I hope this helps on scripting, If you want more, Tell me in the replies. You can rate it if you want, It’s really simple!

5 Likes
#2

Great tutorial for beginners, you should move this to #resources:community-tutorials.

1 Like
#3

Oh thanks for seeing that i put in the wrong category.

#4

I use normal variables rather than local variables.

Like:

part = game.Workspace.Part

This tutorial really fits for newbies.

#5

Then ur referencing it as global variable, and it is a really crappy practice. Only use global variable when it is referenced in different functions.

Local variables are obtained faster than global variables because they’re integrated into the environment in which they were created. If possible, you should always use local variables over global variables, unless there’s a specific reason otherwise.

3 Likes
#6

They basically do the same thing.

#7

U r wrong. Pls read the section on variable scope in this website.

1 Like
#8

Well i still dont see why i shouldnt use global variables…

#9

  • Although it may seem convenient to use global scope throughout a script, note the following:

  • Because global variables and functions must be accessed by a hash lookup, they can be expensive to use in terms of performance. In fact, a global variable accessed in a time-critical loop can perform 10% slower (or worse) than a local variable in the same loop.

  • As noted earlier, global variables and functions are only accessible within the associated script, not between multiple scripts. Thus, a global variable/function doesn’t provide any benefit over an in-scope local equivalent or a forward declaration.*

Read more about variabke scope here.

TL;DR Global variables affect performance, up to 10% slower.

1 Like
#10

what about this script?

deadlyPart = game.Workspace.DeadlyPart

function DeadlyPart(otherPart)
	partParent = otherPart.Parent
	humanoid = partParent:FindFirstChild("Humanoid")
	if humanoid then
		humanoid.Health = 0
	end
end

deadlyPart.Touched:Connect(DeadlyPart)
#11

Local variables only affect the scope or context they’re in, take this for example:

function a()
    variable = “hello world”
end

a()

Since variable was defined globally it belongs to a collection that can be referenced from anywhere, which can be a security flaw in itself.

— module script
print(getfenv(2).variable) — hello world
return nil

— script
variable = “hello world”
require(module.location.here)

Global variables take longer to read and write to too because of their vast index. Do note: A global variable is NOT the same as _G or shared. _G and shared are different scopes in themselves, practically “partitions” in their own ways. Meanwhile _G and shared are tables that do not co-exist in each other, global variables are not. All of them can be required with the correct global scope the way they were created.

A global variable acts weird in the sense it can only be read by scripts that have any connection in context, if you want a variable to be read in multiple scripts use a global table like shared. Again, that’s assuming the use case makes sense and there’s not a single way around it (which there is).

shared.variable = “hello world”
_G.variable = 72
variable = false

— these all are in their own scope

Typically, shy away from these as much as possible. Security reasons, performant reasons, idiomatic reasons, et cetera. Please structure your code more idiomatic in future reference.

2 Likes
#12

Using local is much more efficient in this piece of code.

local deadlyPart = game.Workspace.DeadlyPart

function DeadlyPart(otherPart)
	local partParent = otherPart.Parent
	local humanoid = partParent:FindFirstChild("Humanoid")
	if humanoid then
		humanoid.Health = 0
	end
end

deadlyPart.Touched:Connect(DeadlyPart)

Take a look at @alexinite post.

#13

You forgot to localize inner-context variables.

#14

Then i understand why it is common practice to always use local.

#15

Random note: use workspace instead of game.Workspace.