Everyone always asks “where buffer” but no one ever asks “how’s buffer?”
soon™
43 Likes
Now this would’ve been interesting if left untouched.
4 Likes
Woo I missed these, great changes.
2 Likes
Wow these change are amazing. We utilize a lot of dynamic math.pi based computation for our tunnel based world generator so this will have a significant impact on our game.
Another area I hope could get some improvements down the road is math.random efficiency. Random world gens require quite a bit of random based efficiency
2 Likes
I just love the fact you can use math operators on Vector3’s. Unfortunately this won’t work for CFrame, Color3, UDim2, etc… not that I personally need such things but I have experimented in the past and someone might find it useful.
CFrames for example, you will need to use math on a Vector3 and then pass it into a CFrame.new like so:
CFrame.new(Vector3.new(1,2,3) // 2)
Because doing:
CFrame.new(1,2,3) // 2
will error saying you can’t use that operation on a CFrame.
I assume there is a valid reason behind this not being a viable option, or perhaps it was just an oversight? Either way, at least it works for Vector3 which is very helpful. Otherwise we would have to do things the long way, with manually updating each axis argument individually, similar to what we have to do for Color3.
Since we are on the topic of Color3, would be nice to also have a built in Random() for them similar to how BrickColor has one. Doing Color3.Random() would be very helpful, since right now the current method is to write a function similar to:
local Rand = Random.new()
local function getRandomColor3(r,g,b)
r = math.clamp(Rand:NextInteger(1, tonumber(r) or 1), 0, 255)
g = math.clamp(Rand:NextInteger(1, tonumber(g) or 1), 0, 255)
b = math.clamp(Rand:NextInteger(1, tonumber(b) or 1), 0, 255)
return Color3.fromRGB(r,g,b)
end
And even better if CFrame, and Vector3 had this too. This will be helpful for when you need to set a random offset to things, in my particular case it’s teleporting players to locations and making sure they dont all spawn inside eachother at the same CFrame, which can cause players to get flung or glitch into the ground.
7 Likes
I have been waiting for this, I am surpised it wasnt in luau to begin with.
I saw this on the luau-lang website about a week ago but didnt take the hint they were about to add it.
4 Likes
Alright, how’s buffer? They been having a good time or a bad time
3 Likes
Hows our good buddy buffer doing
2 Likes
The reason I would assume that it doesn’t work on CFrames is because of the rotational properties of the CFrame. In many cases an arbitrary CFrame will not be axis parallel, so all of the matrices of rotation will be (and must be) unit vectors but each individual component of each rotation vector will be less than 1. If you try doing floor division on a vector3 whose axes are <1 then the result is 0, 0, 0. Then when the vector is provided to the CFrame and normalized (rotVec.Unit) you’d end up with a nan vector. So for that reason, to me, it wouldn’t really make sense to allow a CFrame to support the floor div operator.
2 Likes
Super excited about this. Thanks for the update!
6 Likes
A potential idea is a ceiling division operator, which would be of great help to the developing community.
The syntax is simple:
local x = 10 /^ 3 -- x == 4
x /^= 3 -- y == 2
4 Likes
You can somewhat already do this with
local x = -(-10 // 3)
Introducing more operators only increases complexity, plus I don’t necessarily think that a ceiling division operator would do much? At least for me, I use floor way more than ceil–almost to the point of never using it. I don’t think I’ve seen the ceiling division operator in any other language either.
But since I’m curious, how often do you use ceil?
1 Like
I only have to use ceil division Once, Literally Once.
I also believe Ceil division can be done by
Ceil=a//b+1
1 Like
We’re trying to have parity with vanilla Lua, not add random stuff. Flooring is more useful than ceiling 99% of the time.
1 Like
Could be intentional because Vector3 is “special” for being the only vector primitive in Roblox. You know this is true because similar Vector3s give the same hash:
print( ( {[Vector3.new(1,2,3)]=true} ) [Vector3.new(1,2,3)] ) --> true
This won’t work for any of the other datatypes unless it is the same exact object, so you can expect a similar quirk with floor division 
2 Likes
Reminder that floor division is an extension of regular division, so if those datatypes don’t support regular division (which they don’t), by no means should they support floor division
It does exist for Vector3s lol
You can easily extend this to CFrames if you give it these random Vector3s too
local rand = Random.new()
local vec: Vector3 = rand:NextUnitVector()
Historically, math.ceil has appeared equally as much as math.floor in my algorithms. It’s just situationally the desired rounding. In standard execution, the workaround you’ve supplied (while still cheap given the nature of these operations), is significantly slower than plain floor division. And this is really the problem with any workaround that uses arithmetic, due to the additional operations implied. What makes this one exceptional however, is that in native execution, where these kinds of micro-optimizations matter most, there doesn’t seem to be any recordable performance difference. I’ll be using it; thank you.
2 Likes
// is a good thing, but when ++ and --?
2 Likes
Never; -- is already used and ++ is pointless without a companion.
Just use -=1 and +=1.
2 Likes
it’s because I think they’re cool >:c
2 Likes