theres a bug where if you break a part with a materialvariant the voxels and the destroyed part will be reset to the default material without the variant
for some reason it says “attempt to compare table < number” any idea how to fix?
local collectionservice = game:GetService("CollectionService")
local damage = script.Parent.Configuration.Damage.Value
local Attack =nil
local attacking = false
local voxel = require(game.ServerStorage.VoxBreaker)
local editeddamage = damage
local debris = game:GetService("Debris")
local hitbox = voxel:CreateMoveableHitbox(0,script.Parent.Sword.ChopPoints.Size,script.Parent.Sword.ChopPoints.CFrame,Enum.PartType.Block)
script.Parent.Activated:Connect(function()
attacking = true
local moveDirection = script.Parent.Parent.HumanoidRootPart.CFrame:VectorToObjectSpace(script.Parent.Parent.Humanoid.MoveDirection)
if moveDirection.X > 0.2 then
Attack = script.Parent.Parent.Humanoid:LoadAnimation(script.Parent.Animations.AttackRight)
print("left")
elseif moveDirection.X < -0.2 then
Attack = script.Parent.Parent.Humanoid:LoadAnimation(script.Parent.Animations.AttackLeft)
print("right")
else
Attack = script.Parent.Parent.Humanoid:LoadAnimation(script.Parent.Animations.Attack)
end
hitbox:Start()
hitbox:WeldTo(script.Parent.Sword.ChopPoints)
Attack:Play(0.1,3,0.7)
script.Parent.Handle.Swing:Play()
Attack.Ended:Wait()
attacking = false
hitbox:Stop()
end)
hitbox.Touched:Connect(function(part)
end)
Thats another bug. Sorry for the update delays ive been a bit busy
that’s fine, i havent had any other problems with the module and this was just a minor one
how can i make a hitbox that enables from knockback performant
i made it so whenever somebody gets ragdolled usually from knockback it starts doing raycasts in the direction of movement
and if it finds a result it places a hitbox there but it makes my frames drop like crazy so idk how to improve it
Im expriencing a bug where sometimes the part thats being destroyed flashes
UPDATE
Features
-
By the request of @crolaa , VoxBreaker now supports MeshParts as shapes. You can now insert an existing meshpart into the shape parameter of either hitbox function, and the module will clone them to be used as hitboxes. Here’s a showcase:
-
Added type annotations to voxel tables for convenience.
Bug Fixes
-
Fixed material variants and surface types not being applied to voxels.
-
Made voxel resetting nearly seemless. The parts flashing should be less noticeable now.
-
Fixed setting reset time below zero not working. Setting reset times to below zero now makes it so that voxels will just never reset.
-
Various small logic changes for better optimization
Other
-
There is still one bug that I for the life of me cannot figure out. Mentioned in this post, for some unexplicable reason, voxels that are way bigger than they should be are being returned. The reason why I’m having trouble with it is because this only occurs when firing parts to the client. When I print out the part sizes on the server, they all appear the same size, but when fired to the client, some parts may be expanded for some unknown reason. This issue only happens when partcache is enabled, and I will be continuing to look for a fix.
-
New division algorithm will be coming in the next update. I didn’t include it here as it would be a pretty large change and I’m pretty short on time for this module.
-
I’m looking for ways to fix the brief flash that sometimes occurs when you initially voxelize a part. As you can see here.. I’ve tried making the original part have a slight delay before becoming transparent, but that results in some pretty ugly looking delay when breaking parts which makes the module feel laggy. And if I make the delay too short, then it just doesn’t work to fix the flash. If anyone has any ideas for fixes, do lmk.
Github Repo and Test Place have been updated to support the new version
Amazing Update!!!, Ive been waiting patiently
Seems like parts are a little inconsistent when breaking now
Here the parts are much thinner than they should be when broken
Here the parts are much bigger than they should be
combination of both
Its very performant though now
sometimes it just ignores minimum part size
I think it might be the same bug you were talking about with fireallclients
I solved most of this by turning part cache off but minimum size still seems to be off, even without part cache this module runs extremely well.
I completely fixed this by doing this in the DivideBlock() function:
there is pretty much zero delay and the flashing disappears completely.
This is probably being caused by this segment of code:
You can delete that and it should work like normal. I only put that on there to try and see if it would fix the bug I mentioned before, but it obviously didn’t so I would just delete it for now. I’ll remove it in the next update.
I did try this, but I did find an issue where large chunks of parts would get cut out for some reason. Though this only happens when partcache is enabled.
Also, I still see a bit of a flash when I use this method, not sure how it looks for you though.
Oh I havent used the part cache version of this module since I am doing alot of client sided things with the voxels and destroying them.
I dont mean to be rude but ever since you implemented PartCache, this module has been getting a bit worse. Hopefully the new algorithm will solve these issues but for now here is my modified version of this module. Ive re-formatted it and it works like a breeze. Just make sure to send over the voxels to the client and its pretty much seamless and does not use PartCache.
VoxBreakerCustom.lua (38.4 KB)
Here is how I handle the voxels on the client:
Its in TypeScript but im sure anyone can understand the ideas here.
I’ll agree with you there to some degree. The inclusion of PartCache did sort’ve complicate the module, and my code got a little bit messy. But that’s the reason why I left PartCache on as an option that can be toggled in the module settings, as you may come across issues with replication due to how PartCache works. But overall it does help with performance to some extent. But hopefully the new algorithm I’m introducing will alleviate the need for PartCache to some extent. Other than that, the only big optimization changes I could make are swapping attributes to tags, and adding greedy meshing. (those may or may not be coming in the next update.)
should i be cloning voxels to the client or just using the module on the client because i kind of want to make it so i can interact with voxels more than once but idk how id do that with cloning them to the client
when wanting to interact a voxel debris when cloned i recommend liek putting it in a table to store the amount of voxels in the client and have the server fire a event which makes the cloned voxels detect if they are inside a hitbox in order to interact client cloned voxels
Absolutely love this module. Like CompletedLoop said, PartCache is a little wonky, but besides that flaw, this module has been an absolute lifesaver for me! So glad I didn’t have to make my own module to do destruction physics
How would i implement layers for how my voxels will react for example having a inner layer which if a voxelpart hits it gets destroyed and having a outer layer make debris out of voxel parts??
Excuse me, for some reason when i use the module to break some parts with a hitbox, it always seems to freeze/lag, why is that? (Multiple people tested)