602 Release notes are FIRE
Man, when I get free time, I can not wait to create a VR game.
602 Release notes are FIRE
Man, when I get free time, I can not wait to create a VR game.
A nice few bits and bobs for this update.
The new warning for numbers being too big doesn’t account for scientific notation.
Also nice to see some more VR updates, makes developing in VR just that bit easier.
I’m wondering though, could a “VRBottomBar” option with a configTable
be added to StarterGui:SetCore()
& StarterGui:GetCore()
so the UI can be customized a bit, such as transparency and colour? A few callback functions for the buttons on the VR Bottom Bar (like the minimize & chat buttons) would be appreciated too.
At the moment, the only thing that can be changed with the VR Bottom Bar is to unparent the part that the SurfaceGui is on (BottomBar_Part).
I keep seeing “buffer” everywhere but I can’t find anything about it, can someone point me in the right direction please?
Easily the most level headed opinion I’ve seen.
Yeah but I know for a fact the “physics” they’re preserving don’t include the many bugs and glitches that make many R6 games possible. R6 is fine as is in my opinion and they can sorta just let it be without any issues from what I know. Their current combability layer setup is total dog and everyone agrees.
Roblox can’t just ‘let systems be’. They fall out of date relative to the rest of the engine. Look at what happened to VR after 2016 when they ‘let it be’ and it slowly broke under the weight of half a decade of updates.
Product management isn’t as simple as that.
Buffer is a new Luau type. You can read the RFC for it here, though it might be more technically oriented than you’re used to.
The TL;DR is that it’s a mutable byte array, which means that it’ll be very efficient for stuff like networking because we’ll have a datatype that’s 1:1 with bytes that’s also mutable.
You must understand that relying on bugs and glitches isn’t at all futureproof. You shouldn’t be relying on these exploits for your game to function. And when they get patched, as with the case now, there really isn’t a reason to complain that this behavior is removed.
I do like R6 better than R15, but I’m quite happy that they’ve created an alternative for R6 that is supposedly supposed to replicate the same (non-buggy) behavior as the original R6. The old R6 had many problems, one of which were just the terrible naming of all the limbs, as well as the incompatibility with a variety of marketplace avatar items.
Off topic, but - was the buffer created partially in response to the limitations of manipulating large amounts of smooth terrain?
Such a levelheaded take, cheers honestly. I regained a few braincells today.
Hyper realistic roblox VR car game??!!
Yes, we received requests and examples where an ability to work with native types in a binary blob can help, like working with terrain data, sound data, custom replication and even compiling WASM to Luau.
Later, more internal cases came up for use in future APIs in various areas of the engine.
Please guys, don’t jump to conclusions:
The system doesn’t work for non-R15 rigs because the AI was trained on them, now it’ll be more obvious that that’s the case instead of it just giving you a junk, broken animation.
“ACE” in the context of Roblox Studio is short for “Animation Clip Editor”, a built-in plugin that let’s you animate rigs within Studio, not “Arbitrary Code Execution”. The page tries to clarify that by having "ACE - " at the beginning, to say that “This specific change is for the ACE (Animation Clip Editor)”, not “We fixed an ACE (Arbitrary Code Execution… exploit)”.
Oh my god, this is perfection and will fit nicely for my RISC-V VM on roblox. Tables have a lot of overheard when I benchmarked them and the fact buffers have a built in API for reading several data types makes it even better.
Totally fair, however I still think minimal updates like they’ve been doing for years could still work, the whole compatibility layer system from what I’ve seen just doesn’t work well enough at the moment to justify any kind of switch.
I have the same emulation use case, and tables have a element limit, which forces you to chunk up tables into 64mb chunks. Currently it takes my chunked table implementation 0.5 - 1 second to create a table, but it uses a ton of memory. Buffers will solve all of this, and it will make my code more optimized (thanks to readu8, readu16, readu32, readu64)
This is intentional for now; we could flag these but we haven’t seen these result in bugs, so for now we warn only on decimal inputs and any syntax that implies floating point awareness (e for scientific notation or decimal separator) disables the warning even though technically there might still be a roundoff or overflow issue.
My apologies for the confusion! And thanks for clarifying it
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.