Release Notes for 672

Thank you! I did not see the bullet point for the studio UI. I was also unaware of the announcement.

I see why they would push this UI replacement, but they could have at least made the default new ui look somewhat similar to the one I’m so used to to avoid this confusion. The UI seems like a good thing, but looked confusing.

2 Likes

@deprecated attribute went live but it still doesn’t do anything
image

4 Likes

Local multiplayer might finally be a reality!

2 Likes


Huh… How would this look? Seems interesting!

4 Likes

no why would you say that?, lua is fine

3 Likes

and that Will Never Happen, Lua is Used by Everyone in roblox studio

3 Likes

I agree not to mention there are literally buttons missing like the 3d model texture generator

1 Like

its for type functions, as previously in a type function you’d need to do types.intersection(T, types.singleton(nil)) now you can just do types.optional(T)

6 Likes

@BlueDeveloper24 why Should they change the programming language?

1 Like

This update has broken a lot of the typechecker autofill annotations for me. I do not use strict typechecking, but I use some annotations to get the autofill working. Because of that, my type annotations are obviously incorrect and would raise a bunch of strict typechecking errors, but i don’t have strict turned on, but up until recently, the autofill would still work at least

--example of what broke

type entry = {
    property1: boolean,
    thing2: CFrame,
    num: number,
}

local list :{entry} = {}

list[1] = {
    --when i start typing "p..." here property1 autofills
    thing2 --this never autofills, seems to break for any non-boolean values
    --num also never autofills
}

i can still get the autofill to work but not in that clean “construct and fill” table way, instead i gotta restate the thing a gazillion times

list[1] = {}
list[1].property1 = false
list[1].thing2 = CFrame.new()
list[1].num = 5

--OR
local thingy = {} ::entry
thingy.property1 = false
...
list[1] = thingy

both of these are so much uglier than just doing the “fill construct”


EDIT: i have no clue whats going on
the root of the problem doesnt seem to be the types being booleans or not booleans, for some reason some certain string keys cause the typechecker to blow up, cant seem to find a pattern
for some reason string keys like
“ItemId” autofill, “DmgReductionRatio”, “IsArmor”, work
ones that break it are “Added”??

1 Like

Lua sucks. its very limiting both the language and the game. There are way better languages with actual OOP.

Please realize that not one paradigm for programming is a “magic bullet” as you are claiming OOP is. You wouldn’t use a hammer to get a screw out, you’d use a screwdriver.

5 Likes

No and no, ROBLOX is completely messed up. we are limited for their own classes. everything is premade, Too much workarounds, a lot of missing features just because lua cant achieve that. We get premade objects confused double property cases and the new developer wont understand the depth of it.

Lua is one of the easiest languages yet no serious company is using it, and there is a reason for that.

So what more do you want? A simple language to use, and obviously it will be limited in terms of optimization because it’s an interpreter, and if you’re referring to classes, libraries… You’re right, but not to the point of calling it a disaster.

4 Likes

Still it would be better to approach it differently. If roblox wants to be a professional game creating platform that attracts high quality developers and companies they would have to apply a more logical approach. Classes are easy and initiative as they speak for themselves and less if they added that alongside with making less premade things it would be better. For an example the bad side is that we cant have an empty template and we are forced to have a template with tons of scripts and items to hold the player and the character and other automatic things that not all of us want. To remove that we would have to add another script, a script in order to remove a script. Also you would have to create a script inside each zombie/character in order to animate it and give its behaviour instead of one script that controls all, or you would be struggling with the silly workaround called Metatables where it does not exist in any other language.

it doesn’t need to be professional game creating platform

Metatables is not a workaround, but an exact feature that you need.

Luau uses OOP style called Prototype-Based Programming that you can find more info on in the wiki.
It is actually used by many languages, including JavaScript/TypeScript, which is very popular and widely used.

5 Likes

Not sure if this is the correct place to say this but will the recently added occlusion culling also cull shadows and lighting soon? i believe it would really help games with realistic lighting and shadows.

2 Likes

Metatables are confusing and i didnt see soemthing like that anywhere else. There is the class stracture and inheritance but within roblox it doesnt feel like that.

Also ROBLOX has a thing against an actual classes. For example in unreal engine what you do is you create a zombie class, make the code and after you done that you drag and drop the class into the workspace, this is way better and easier because we wont be editting 10 scripts if you have 10 npcs, we can command or give behaviour for some or all agents within a single script. And while we appriciate the built in classes, these does seem to bug sometimes or have some functionsthat we do not want for the game to which causes extra overload about performance, we have no control over built in classes.

You can definitely use tags, and organized folders to create a system where one script controls all npcs. as I have done. Also, you can load a asset during runtime, require the modules code once, and delete the module. A easy way to convert a script to a tagged system is to create a module that says

 return function(script) 
--your code here
end   
local taggedinstead=require(functionscript)
game.CollectionService:GetInstanceAddedSignal("TaggedScript"):Connect(taggedinstead)

Management of connections is trivial.
I have converted most of my npcs to be locally animated with one script and it runs very efficiently. Additionally, on the server I have all of my npcs running on one single function that has variable behavior based on attributes. I could write a function in the command line to convert this data to any configuration have it as one copy and not even have this attributed object eliminate the performance bottleneck of GetAttribute() and just use a hash table.
Bindable functions, are great for communication between scripts. a common approach I take is

local requiredmodule=require(modulehere)
BindableFunction.OnInvoke=function(key,payload) --BindableFunction:Invoke("Key",{character,player,true,false})
return requiredmodule[key](payload[1],payload[2],payload[3],payload[4],payload[5],payload[6])--however many variables your functions use
end

You can make incredible things staying organized is key, a style of programming where you repeat your code as little as possible is the best. Recently did a new project, simplified and modularized everything that is repeated, a touch signal, a damage brick, trampoline, spinning objects, clothing items that don’t overlap, moving platforms. So neat when I can copy and paste my touchsignal module, define a couple variables a payload function and not have to create an efficient and functional touch signal gate over and over, return the signals, disconnect them when the time is right.

3 Likes