like that but you got it mixed, I would recommend prioritizing ragdoll time over velocity since if there is still velocity left for a certain amount of time the ragdoll should need to stand up
Keep us updated Barto! Have you fixed the problem yet?
Also If you are open to suggestions, would you be open to adding texture support in the future? (I.e. parts keep the texture when broken, and maintain it once voxelized)
1 Like
I am currently putting 100% of my time into a personal project, which will be nearly complete soon. I will resume updates to the module once I have some free time, which should be in a week or two. And the texture thing is already half implemented, its just bugged at the moment.
2 Likes
Roblox Teardown Time!
Your module is outstanding. Would it be worth using greedy meshing to reduce the part count further after using the hitbox method?
Perhaps an optional parameter for that could be a future update.
1 Like
I’ve considered greedy meshing, and tried implementing it in a previous version of the module. But unfortunately, I’m not super familiar with greedy meshing algorithms, and the module I tried using didn’t seem to work at all. I’ll try to look into it in the future, and if anyone has any resources on greedy meshing that would help a bit.
Theoretically, if it did work, it may help with performance. It’s very likely I’ll have to make my own algorithm here, as I’ll have to avoid greedy meshing voxels created by hitboxes. And if I do get it working, along with part cache, then there could be some major improvements in performance.
It would be awesome if the GitHub repository could be created soon! 
how do you make the parts go like that?
By using the weldto function implemented inside the module itself to weld on the humanoidrootpart
1 Like
If its possible it may be best to specify the amount of collisions allowed through your mover mechanic, velocity itself can be unreliable because there are certain actions like dashing, falling, leaping etc. which increase velocity but you wouldn’t want a collision for.
I’d advise on using a counter to specify the amount of collisions you would want as to avoid complications. This also stops players from tunneling into large parts.
This is a voxel module I’ve made myself so I’m not sure a counter would work with your scripts.
2 Likes
Have you considered open sourcing your voxel module?
I intended to before I started working on it, I will release it soon.
Im actually already using this idea, and it works pretty well. You can use the built in .Touched event for moveable hitboxes. Then, with a predefined number variable that specifies how many walls/floors the hitbox can touch, for each touched event you would lower the variable by one, and repeat until it reaches zero.
wow, this problem was actually pretty simple. I didnt expect that networkownership could really improve it.
Also have you made any progress o improving and fixing bugs in the voxbreaker module yet??
This module works really great actually and I used a couple tricks to get good destruction with minimal lag.
One question I have though is whats the need for this delay when resetting the block?
It causes a annoying flicker the the block resets. Commenting this out makes it seamless. I assume its to prevent some sort of race condition. But I’m sure there is a way better way of doing this using signals than just repeat waiting until the model container is destroyed.
1 Like
I only added the delay in an early build of the module because of some weird interactions where the models would delete and the original part would not be reset. If it works fine now then I’ll remove it.
Ill be working on the module in a few days, sorry for the delays but like I said before ive been developing my own game so I havent had the time. But do keep in mind that my game also uses VoxBreaker, so updating the module is pretty crucial for me as well.
Having this weird quirk where the voxels just pause for a brief moment for some reason. This ruins the smooth feeling of the destruction and i have no clue how to fix it.
Look at the chunks and notice how they just dont move for a few frames before falling.
This is all im doing in the code:
1 Like
Seems like there is a bit of a delay when creating voxels on the server.
I tried your script on the client and it works fine:
But when it comes to doing it on the server, there is a delay like you said:
This is likely due to physics calculations on the server, specifically with applyImpulse being somewhat costly for performance, and you get that brief pause.
I recommend firing the table on the server back to all clients, destroying them on the server, then cloning them on the client, and the delay is gone:
Here’s the scripts for that as well:
--Local Script
local UIS = game:GetService("UserInputService")
local VoxBreaker = require(game.ReplicatedStorage.VoxBreaker)
local mouse = game.Players.LocalPlayer:GetMouse()
UIS.InputBegan:Connect(function(input,gpe)
if gpe then return end
if input.UserInputType == Enum.UserInputType.MouseButton1 then
local cframe = mouse.Hit
game.ReplicatedStorage.RemoteEvent:FireServer(cframe)
end
end)
game.ReplicatedStorage.RemoteEvent.OnClientEvent:Connect(function(voxels,cframe)
for _,voxel in voxels do
local clone = voxel:Clone()
clone.Parent = workspace
clone.Anchored = false
local velocity = CFrame.lookAt(clone.Position,cframe.Position).LookVector * (-50 * (clone.Mass))
clone:ApplyImpulse(velocity)
clone:ApplyAngularImpulse(velocity)
end
end)
--Server Script
local VoxBreaker = require(game.ReplicatedStorage.VoxBreaker)
local remote = game.ReplicatedStorage.RemoteEvent
remote.OnServerEvent:Connect(function(player,cframe)
local voxels = VoxBreaker:CreateHitbox(Vector3.new(10,10,10),cframe,Enum.PartType.Ball,4,30)
for _,voxel in voxels do
voxel.Parent = game.ReplicatedStorage --Parent voxels to replicated storage so that the client can see them
end
remote:FireAllClients(voxels,frame) --Fire the table back to the client before destroying them on the server
for _,voxel in voxels do
voxel:Destroy()
end
end)
3 Likes