I have been developing my world-building game Wubby for some time now, and the worst problem I stumbled upon was getting the proper grid calculations when the player had to place down blocks. With this open-source module, I want everyone to have a perfectly calculated, lightweight, and intuitive experience to avoid more people from descending into the rabbit hole I went through.
Every other grid module I found is either very limiting, too complex to use, or just not what I’m looking for. I swear, I would’ve loved that a module like this existed while I was first developing Wubby.
LibreGrid emulates surface-based placement (like the one that Roblox Studio offers), getting rid of all the math-related headaches that would take coding it yourself, with support for both BaseParts and Models. Moreover, it allows for more customizations that developers can change in real-time to their liking. This means that, using LibreGrid, you can achieve a block-placing system (like Minecraft’s), a furniture placement system (2D placement), or a Roblox Studio-like experience.
This module is the result from months, if not years, of trial and error while developing Wubby.
hey there, i’m sorry if you didn’t like this resource. however, there’s a lot of reasons to use this module:
developers would use this module because it was meant to get rid of all the math-related issues that coding a grid system conveys. modules are made to avoid coding again what someone already did, specially if the task in question is a tedious one. trust me, it’s not “really simple” math if you’re coding a complicated system, like Studio’s.
LibreGrid is super good at customization and it’s intended to adapt to any workflow. moreover, it allows you to input your own custom RaycastParams when running the function, which allows developers to whitelist/blacklist certain parts. LibreGrid even returns a RaycastResult after an operation is done if you want to customize it even further.
a placement system requires raycasts. you cannot make a grid system w/out raycasts…
Of course, I never said it didn’t require raycasts — rather, my point was that the grid math was minimal, so your module is 70% raycasting rather than the actual grid system.
On the positive side, it’s well made, has a good post, and is useful to numerous people. Keep going!
A placement system does not “require” raycasts as it does not only happen on the client. Your module fails to account for the developer’s need to validate and ensure the position the client has provided is grid-aligned. The functions to grid-align & perform raycasts should be decoupled for this reason.
Correcting this since I did not realize that your module does actually have separate methods for raycasting and grid alignment. Though I still stand by the opinion that raycasts are not a requirement for a grid system.
Also as an FYI, this resource would be a bit more useful to developers if the Github repository was properly setup to work with Rojo.
thanks for your suggestions! ill try setting up rojo although i have never tried it before :3
also, if you’re worried about the grid alignment server-side, instead of sending the cframe over, you could send every parameter needed to replicate the function there. although it might be a little bit complicated to figure out the ray if you’re using GetCFrameAtMousePosition, i’ll probably add better support for this in the future. thank you! :3
you could use the NormalBased configuration (as explained in the documentation) which makes placement relative to normals instead of the ray hit for this use case :3
though, now that i’m realizing it, i forgot to add support for smaller sizes while this is turned on. i will try to add support for it asap!
How would I disable the overlapping of the block? like, if I aim at the front area of the wedge, it’ll clip into the white wedge [or the top], but any other area it’d build below.
Also this:
Whenever I rotate my block, it offsets now.