Coding things you probably didn't know (part 1)

Resources Community Resources
#93

really what was the output??? and also the varibles are not equal to the same thing and i am pretty sure when your using shared you put it in a table {}

1 Like
#98

Didn’t know about Shared aswell!

1 Like
#99

didnt know either till @iamtryingtofindname told me a fun fact

#100

I knew this one. But these others are interesting!

1 Like
#101

i am planning to make part 2 very soon so share any coding thing you prob didnt know to be shared in part 2

#102

This is amazing! Thanks for all these tips!

1 Like
#103

This is definitely more known than the next function, but thought I’d add this as I still see people doing this.
Instead of doing:

local variable1 = nil
local variable2 = nil
local variable3 = nil

You can shorten it by doing:

local variable1,variable2,variable3

That’s not all, you could still do something like this:

local variable1,variable2,variable3,variable4,variable5 = true,false,true,true,false

It makes lines a little longer, but at least you don’t have to run a Marathon with your finger by scrolling down forever in your script.

Another one I just thought of as I finished typing that:
Do you ever do something like this?

local deb = true
something:Connect(function()
     if deb then
        deb = false      
        --function here that's one time use for the whole game session
     end
end)

This is a great alternative too, and it saves memory:

local func
func = something:Connect(function()
    func:Disconnect()
    --function here that's one time use for the whole game session
end)
1 Like
#104

thx dude I’ve learned alot on the forum but lemme tell you a little secret :shushing_face: im making a part two about building! and its prob gonna come out today all i need is ne more thing that builders prob dont so if you know any please tell me!!!

#105

ay that’s awesome! good luck dude!

1 Like
#106

thx i need it i need one more fact

#110

I don’t understand why would any programmer not know that you can error a table to the output, but all right.

Adding more onto your post though; did you know you can do this?

error{1, 2, 3};
#111

Now, you may have noticed that you can call functions like print without parenthesis:

print 'Hello!'

You can actually remove the parenthesis if you are passing a single argument as a string or table literal!

But did you know that you can utilize curried functions to take this a step further?

function CreateObject(ClassName)
    return function(ObjectData)
        local Object = Instance.new(ClassName)
        Object.Name = ObjectData.Name
    end
end

CreateObject "Part" {
  Name = "PartOne"
}

Still one of my favorite pieces of Lua sugar! :smiley:

#112

I have known that this was possible
but is it possible if there are more then one arguments?

I tried a long time ago and it failed, I’m guessing no

EDIT: yes I saw your last example, but I mean using one function only

1 Like
#113

Unfortunately no. To avoid parenthesis, You must use a single argument that is a string or table literal.

#114

oh ok, well that makes sense
thanks

#116

I literally printed a boolean, number, string, and a table with no problems(I used error())

https://www.lua.org/demo.html
only strings seem to show what line had the error

#117

Where?

https://www.lua.org/manual/5.4/manual.html#pdf-error

Raises an error (see §2.3) with @{message} as the error object. This function never returns.

https://www.lua.org/manual/5.4/manual.html#2.3

Whenever there is an error, an error object is propagated with information about the error. Lua itself only generates errors whose error object is a string, but programs may generate errors with any value as the error object. It is up to the Lua program or its host to handle such error objects. For historical reasons, an error object is often called an error message , even though it does not have to be a string.

These state that an error object can be of any value, and that the first argument of error is used as an error object. Also, error has an optional 2nd argument.

#118

Part 2 when??? :eyes: ‎ ‎ ‎ ‎ ‎ ‎ ‎

1 Like
#119

shared and _G aren’t the best way to share values accross scripts.
Modules are much better and they are faster, as when you require a module multiple times, the tables save because it requires the module from memory after the first require

Example:

local tbl = {}

local module = {}

function module.Add(value)
    table.insert(tbl, value)
end

function module.Get()
    return tbl
end

return module

script 1:

require(module).Add('Hello')

script 2:

print(require(module).Get()) --> {'Hello'}
1 Like
#120

Yeah ik but that one was just there cuz it was some a lot of ppl don’t know yk lol

Forgot this post existed :sob:

1 Like