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.
1 Like
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.
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
I actually made this even more smooth by just doing it both on the client and server but making the server delete the voxels. This is slightly more faster and smoother because there is no cloning involved.
Honestly though props for this module. I was able to replicate the lag free destruction in Jujustu Shenanigans in only a few lines of code.
2 Likes
Yeah, it’s got nothing to do with the module. It’s just apply impulse. It’s an awful function that still has a long replication delay. This applies to all new movers too, like linear velocity. We are still, after many months, waiting for @DrCherenkov to fix this garbage.
1 Like
yeah I’m still relying on bodyVelocity for pretty much all use cases of moving parts. Pretty baffling to me how we still don’t really have any good alternatives.
1 Like
Yeah, he keeps claiming he’s “working with other developers so the change isn’t breaking”, but uh, dunno if he realizes this, currently, it’s broken for everyone. So, whoever these special cringelords that are apparently holding back the change because “waaah I can’t get my car from 2016 working using this system!!!” They should just update whatever ancient garbage they are holding onto instead of holding us all back.
2 Likes