Why the hell it counts big floor as a debris???
Ok what the hell:
As long as parts are anchored and the attribute is set correctly then there should be no odd occurrences. If the floor is being broken then that means its either parented to an instance which has the attribute or it has the attribute itself.
Turn gridlock off if you don’t want very thin pieces, its an unexpected result from floating point decimals, kind of a tricky thing to fix. Gridlock was intended for neatness so its not a necessary feature to use anyway and I may just remove it.
I updated the model with a bug fix that should bring any lag down so try it if you haven’t already.
no each part is separated and is not parented to other parts so i dont know whar are you talkin about
Hey real question here about the module,
So I’ve been trying to use the .hitbox() function and after doing extensive research it’s still giving me a lot of trouble (maybe I missed crucial info? I’ve been at this the entire night and I can’t get it working)
Essentially the problem is that whenever I use the .hitbox() function on an already existing object (in this case, module) and I move it with the tools provided by studio, it works perfectly fine
Code sample and the structure of the object^
When I load the game in Run mode, or Play mode, whichever,
and I drag it with the tools given by the studio, it works perfectly fine and breaks any surface it comes in contact with
The problem arises when I try to do the same but from an already existing script, which happens to be a module (used for the combat system of my game)
By executing the exact same identical code, after cloning the object, it seems to not be capable of breaking anything, and doesn’t detect any collisions;
Possibly important facts:
The projectile within the module script uses body velocity to move
I’ve given the already existing target object body velocity, and it seemed to work just fine with it, as long as it is not made by the module script
Duplicating the server script while it is inside the object, and enabling it after it’s created within the module doesn’t work either, only seems to work if the Object wasn’t created by the module script
Cloning, duplicating, anchoring, unanchoring the object doesn’t seem to affect it at all as long as it hasn’t been created by the module script
Using the module script for the creation of the object is crucial.
Here’s a gif demonstrating the difference in activity;
It might be hard to see after snapping to the player perspective, but the projectile does not break the wall or interact with it in any way at all despite being 1:1 identical to the one used at the beginning of the demonstration gif
Why?
edit,
After multiple tests and grasping at straws I found out that the .hitbox() function only and ONLY performs while I am in SERVER view inside STUDIO
final edit and solution for people who are potentially struggling with this
the problem was that the .hitbox() function utilized BindToRenderStep which only functions on a client script, since the server can’t use .RenderStepped() as it requires to detect the rendering frames
line ~893 in main module^
this explains why it only worked in studio’s server view as the server got an active observer (renderer) when you switched to it, allowing BindToRenderStep to work
my solution was to rebind it to HeartBeat which the server is cool with, although I can’t vouch for how good of an alternative that is
Why do you spawn effects on server its network expensive
Ah, I never even thought about this, thanks for letting me know! Yes, remove the bind wrapper and the line to unbind it. I’m not even sure why I added that? It must have served some purpose, but as far as I know it will work without it.
I’ve been trying to fix this bug for a while now, I believe it has something to do with the greedy mesher. The bug causes parts to protrude and also causes some parts to be erased which shouldn’t be happening. I haven’t been able to fix this by myself, if anyone knows anything about this feel free to throw some ideas around.
Yeah it’s working great now, thank you!
how can i get the debris parts if i wanted to add something to them, i havent seen anything of this topic in the thread unless i missed it
If you’re using .destroy(), calling the method returns a table of debris and then a table of wall parts. If you’re using .hitbox() you’ll need to use the hitbox events .Stopped and .Collision. These methods returns a table of debris and a table of wall parts too except .Collision will return debris for that collision and .Stopped will return all the debris from the hitbox when its stopped. Keep in mind if you are removing debris or destroying them or returning them to cache you may end up with some nil data in your debris table, just make sure to check that the debris in the table are not nil. Remember to use the .cleanup method on debris instead of destroying them since they need to be returned to cache. Hope this helps!
So… I’ve been having this strange issue with the module where for some unknown reason, occasionally, both :destroy() and :hitbox() cause a massive lagspike followed by creation of several hundred, up to thousands of segments of walls,
^the amount of BreakablePieces spawned after using the .hitbox() function
the amount can range from 1000 to 20000+ depending on the occasion
for weeks and weeks now I’ve been trying to figure out what could be the cause of this but I can’t seem to get a solid grasp on it, any ideas?
Thanks for letting me know!
This is one of the bugs I haven’t had time to fix, there’s an issue with the meshing that I haven’t sorted out, I’ll try to have fix it soon.
Apologies for the inconvenience.
@WindBrine, I published a new version resolving a merge bug. Try using this version and let me know if the problem persists. I am curious to know why wall parts in the image have instances underneath them- this wasn’t an intended result.
If the issue persists, may you please provide your code and let me know what instances are children of your wall part’s. Thanks!
i recommend using this rather than PartCache since it has lesser script activities
The instances underneath the wall parts are the segmented parts I believe which are created during the destruction process
ok after thorough testing for an extender period of time it seems like the lag issue i’ve spoken of is gone, thank you.
hey, in your opinion would you say this is a better alternative to voxbreaker, performance wise etc
Is there any uncopylocked testing places for this module, or a how-to video? I think that would be helpful for beginners such as myself.
I can make a how-to right after I release the next update, that’s a nice suggestion! For now, read the documentation and the example code and let me know if you have any questions.
Sent you a PM, wondering if you can help me out. All good if not.