Working on this issue now. Can I ask, are you using this on a part that is unanchored or has cancollide set to false?
im trying to figure out how to use this module, but most of the times when i use it, the hitboxs and its parts get sent to position 0, 100000000, 0, and it spawns alot of parts with it for some reason
i even tried vox breaker, but the same thing happened
That is what should be happening if you have the usePartCache setting enabled, which it is enabled by default. Parts remain in place until cleaned up with the .cleanup() method, both debris and pieces that make up a broken part are cleaned up this way. If you want to mess around with your debris put code above the line that cleans up the debris. Check the example on this thread to see how debris are cleaned up after some time.
This is the PartCache implementation in effect, the feature works by caching parts far away which forces physics to ignore the parts. The module is useful for cutting down on lag as instancing new parts many times per second ends up being memory intensive. Iād recommend keeping this feature turned on in the settings module.
Parts are intended to be cleaned up after being used as seen in the documentation on this thread as well as in the example.
To cleanup a part or table of parts (which your returned debris is a table of parts) use:
vox.cleanup(debris)
This should be called instead of using :Destroy() on a part.
If you share more about what you are trying to do with your debris/wall pieces before they get cleaned up and returned to cache then I can assist you further.
oh okay, thanks for informing me, but i tried testing it out by setting the hitboxās cframe into a part but nothing happens, and i made a attribute called āBreakableā for it to work but nothing happened still for some odd reason
never mind, i already figured out what i have done wrong
Is this a model youāre trying to turn into a hitbox?
No I just used ur example code and positioned the hitbox at my mouse.hit.position. I destroyed the tree and it didnāt position it correctly.
I didnāt code anything into the module to position hitboxes, the issue may be coming from positioning the hitbox at your mouse.
You should be using :PivotTo() on the model using the previous orientation like so, this way it retains the position of how you had it originally. Positioning models requires this extra step unlike parts.
local orientation = model:GetPivot().Rotation
model:PivotTo(CFrame.new(mousePosition) * orientation)
-- model:PivotTo(orientation + mousePosition) -- This works too
Where model is the tree, and mousePosition is your mouse position.
Let me know if that works, if not I will look into the issue on my end. If it doesnāt work then reply with your code. Hope this helps!
what but i donāt want to use the model as the hitbox. i destroyed the tree and it didnāt position correctly after it reset
Do you have the attributes to make breakable parts set on all of the parts inside of the tree or is it set on the tree model itself? Or both? Is the model fully anchored?
I just checked yeah a lot of the parts are unanchored. I do have attributes but does having it unanchored affect it?
I should have made some sort of check to anchor parts while they break then return them to their previous anchored state. As of right now any part you want to be destructible must be anchored, but I will change the module so that you can break unanchored parts soon.
Also if you want to make an entire model destructible you can put the attribute only on the model and all parts which are descendants of that model will be destructible. Iām not sure if having the attribute on parts and the model causes problems but for now just keep it only on the model itself.
Sorry about that, I should have clarified this in the doc and I will add a fix for these soon.
I actually did think about it, Iām assuming its better than PartCache, if its able to relieve some of the gittering look of positioning parts Iāll implement it with the next version.
1 Like
Canāt guarantee it but itās code is more optimal and less cluttered than partcache, and it has bulkmoveto built in, so it should have noticeably better performance if you implement it right
I think this is a interested related effect for those who wish to do shatter physics. I intend to use this to make smashable windows.
Alright everyone, I usually donāt ask any questions about updates as I already know what I need to add but I plan on rolling out a decently large update and want to include any ideas sooner than later. I will be replacing part cache with object cache, including features for mesh part support for making hitboxes, wedge breakable parts, breaking unanchored objects, a crack/shatter method as @Magus_ArtStudios suggested for glass, and my most anticipated- a weld feature allowing breakable parts to drop welded collections of less mass.
If there are any features that you would like to see or think would benefit others reply with them and I will consider including them in V2.
3 Likes
not really, probably just set up a test place with pre-made tools like voxbreaker so people can test your module without having to set it up themself