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.
@deprecated attribute went live but it still doesn’t do anything
Local multiplayer might finally be a reality!
no why would you say that?, lua is fine
and that Will Never Happen, Lua is Used by Everyone in roblox studio
I agree not to mention there are literally buttons missing like the 3d model texture generator
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)
@BlueDeveloper24 why Should they change the programming language?
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”??
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.
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.
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.
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.
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.