Hi I was messing around with your module and it is really good but I have an issue where if I perform destroying the voxels on a server script the parts don’t reset to their original form but on a local script they do is there a way to make it so they also reset on back to normal on a server script and sorry if this a dumb question
I havent seen this in my testing, but i will look further into it. The module has several issues right now and i will be updating it soon
I also have one suggestion if at all possible but can you implement some system to disable decals or surface guis when a part is voxalized. I had to create my own make shift solution that works as of now but it would be nice to have it be a built in feature.
This is an amazing resource! Would it be possible to create a GitHub repository accepting pull requests? I’d like to contribute to slightly improving performance and using newer features in the Luau language.
Didn’t consider it, but now that you’ve reminded me, I’ll work on setting one up tomorrow, along with some updates to the module.
he (Dev of Jujutsu Shenanigans) modified and optimized another voxel destruction module, Vex, to the point he stated it wasn’t even like the original module anymore
That is actually the module I used as a basis here as well, but for reasons I’ve stated in previous posts, Vex is incredibly unoptimized and not really fit for the purposes I had intended on using this module for. Interesting though.
UPDATE
-
Module should now work perfectly on both the server and client.
-
Added functionality so that module will make textures, surface GUIs, and decals on parts invisible until voxels reset.
-
Fixed a bug where the .Touched() event would fire for parts that have already been touched. Now, the .Touched() event will only fire when new voxels are touched.
-
Added a :Start() function and :Destroy() function to moveable hitboxes. Now, hitboxes must be called with :Start() in order to activate. And :Destroy() must be called to fully destroy the hitbox. And because of this, you can now pause and resume the hitbox whenever you’d like. Also, if you don’t want to call :Start(), I’ve added a toggle in the settings which makes moveable hitboxes start automatically without having to call :Start().
Added new example tool to test place:
test place has been updated
will be setting up github repository later
If anyone is still having any issues with the module, please let me know,
Also, I’m working on implementing the module into my own games, and it seems to be working on the server without issues:
(The debris are made on the client using remote events, the actual voxels on the server are destroyed)
So if you run into issues on the server, it is likely because you are using larger destruction, which may cause some performance issues.
can you explain the process? Like when you knockback a person do you create a normal or movable hitbox and etc, i’m trying to use this module for my game but i’m not sure on how to go on about it.
edit: i figured out how to create the debris on the client while deleting it on the server but i’m still wondering which hitbox you used for knockback impacts
Hi im still having the issue with the server not having it work properly its likely me doing something incorrectly in the video I showed whats happening and I do have the newest version of the module
here the part of the code that uses the module
local VoxBreaker = require(game.ReplicatedStorage.VoxBreaker)
local Size = Vector3.new(10,10,10)
local Cframe = humRp.CFrame
local Shape = Enum.PartType.Ball
local MinimumSize = 5
local Seconds = 5
local Voxels = VoxBreaker:CreateHitbox(Size,Cframe,Shape,MinimumSize,Seconds)
for i, v in pairs(Voxels) do
v:Destroy()
end
So it kind of depends on your use case. If you want to blast someone through multiple walls like in the videos i shared, then heres how you would do it:
-Create a moveable hitbox (i did so on the server)
-Then, using a while loop, make the hitbox move with the targets velocity:
local moveable = voxBreaker.CreateMoveableHitbox(3,20,Vector3.new(5,5,5),CFrame.new(),Enum.PartType.Ball)
moveable:Start()
local connection
local touched = {}
connection = moveable.Touched:Connect(function(Parts)
for i,v:Part in pairs(Parts) do
v.Parent = script
end
Remote:FireAllClients(Parts,Character.Instance.HumanoidRootPart.Velocity/2)
for i,v:Part in pairs(Parts) do
if table.find(touched,v) == nil then
v:Destroy()
table.insert(touched,v)
end
end
end)
while true do
moveable.Part.Position = Character.HumanoidRootPart.Position + Character.HumanoidRootPart.Velocity / 12
task.wait()
end
Then you can disable the hitbox whenever you’d like. Visually, it looks like this:
So if you could turn the visualizer on in your module settings, that would help, as I don’t really know why it’s not working for you here. I’m using the same script and it works just fine:
sorry for the cropped video had to do that to fit the file size limit
Here’s an example rbxl file, that uses basically the same code.
vb.rbxl (65.0 KB)
Try to compare it with your own code, and see if that helps
I figured out the issue was nothing to do with scripts and that it was just the part not being anchored
Thank god for this, you’ve saved me weeks of pain and misery. Now I can make a proper destructible map for my game.
Do you ever think you will make it so the part debris will be a built-in feature for the module? Like as a parameter whenever using the module?
So, in the example you are asking about, I’m creating the voxels on the server and then cloning them on the client. My intention was to have something that can work either on the server or the client, and then you can choose to use remote events and the like to transfer data about the voxels between the server and client. Now, incorporating that functionality into the module wouldn’t be super difficult, but I would like to keep the module simple enough to where you have full control over the client-server interactions. And really, doing that isn’t super difficult. Just fire a table to the client containing all the voxels and just loop through it to clone them. If more people ask though I might consider it.
Would it possible to remove attributes from this system and use instead metatables, or tags to store data better? Or simply implement support for raycast params. I might implement it myself if i have time tho.