I tested both modules which can be seen in this message.
Btw, I’m starting and stopping the hitbox via HitStart and HitStop with Raycast Hitbox and my versions of them, not creating a new hitbox every frame(that would leak to memory leak xdd).
I tested both modules which can be seen in this message.
Btw, I’m starting and stopping the hitbox via HitStart and HitStop with Raycast Hitbox and my versions of them, not creating a new hitbox every frame(that would leak to memory leak xdd).
I appreciate the reply, but that’s almost exclusively against what I’ve posted. I’m not just interested in the performance of your module, I’m interested in what significant benefits this provides in contrast to RaycastHitbox and whether making a switch is worth it.
What else does your module support in the way of API and such that RaycastHitbox doesn’t? Could you please read the post again and answer beyond comparing performance? It’s not really that critical for me, but I’d like to know if the same use cases are supported.
There isn’t a lot of benefit from using my module other than code shortness and performance unfortunately(which would be one of if not the only reason I’d switch modules). I’m pretty sure my module can do anything that raycast hitbox can(excluding debug rays ill make them eventually).I appreciate that u appreciated my reply .
Hey, I really like how simplified HitboxCaster is and I’m glad you found the inspiration to try and improve my module with your own interpretations. Even if the low chance that you weren’t inspired by my own module, I hope it can still be a resource to you to improve your own and make HitboxCaster your own identity with its own unique features that every developer can enjoy.
I’m sure there is still going to be questions and comparisons between our modules from curious onlookers, so let’s end that today. To add to @0Shank 's request for fair comparisons, I have compiled a list of benchmarks comparing both modules in similar environments for readers.
I do have to preface that HitboxCaster currently has a glaring inaccuracy bug that I’m unsure is intentional. Before we get to the benchmarks, HitboxCaster seems to be detecting hits even when the attachment points are nowhere near the designated subject. Video footage can be seen below. The code was used from the original thread post (and comparison place). Regardless, even if this bug was fixed, the performance data should still be relatively the same.
(the one being moved is using HitboxCaster)
For these benchmarks, I have used the most recent versions of both RaycastHitbox and HitboxCaster for the best accurate data possible. HitboxCaster seems to be listening for each part hit so I will be enabling RaycastHitbox’s PartMode to reflect the similar functionality. Each benchmark will have its own .rbxl file. My computer is running a Ryzen 3700x, 1070 TI so there should be no performance skewing due to studio.
I dislike this test specifically because it’s a bit misleading. No developers will realistically enable / disable the hitbox within a frame of each other constantly. That is not how the module is supposed to be used and should be discouraged. However, for the sake of comparisons and to end the misconceptions that RaycastHitbox module utilizes more script activity, I will be utilizing the same tests as your earlier comparisons.
As a game owner that has AIs in the dozens at one time, it is an absolute requirement for me to have the module be able to smoothly detect a large number of humanoids. I will be tweening this part with 30 DmgPoints through 50 humanoids.
HitboxCaster Test
Tweening through 50 AIs in 2 seconds allowed both modules to get all targets. However, tweening faster than that, HitboxCaster will have an accuracy advantage as it detects more targets than RaycastHitbox. Do note that, since HitboxCaster still has that inaccuracy bug listed above, take this benchmark with a grain of salt.
benchmark2.rbxl (52.1 KB)
Raycasts are light and performant, and our modules should be made to reflect that quality. I will be reusing the test and code from Benchmark 1 for this one.
HitboxCaster Test
RaycastHitbox Test
From the tests, RaycastHitbox did not seem to drop any frames while HitboxCaster capped the micro profiler, dropping frames. This is a good example that you should not rely entirely on HitStart/HitStop performance and that using real-world benchmarks can go a long way to prove your point.
benchmark3.rbxl (41.9 KB)
Overall, I hope you can keep improving on this module as I know a lot of developers do value smaller resources. Many developers dislike RaycastHitbox for the same reasons and HitboxCaster seems like it would be a great alternative for those people. Keep it up, and if you need any pointers, I’ll be more than happy to give a few tips or suggestions.
Thank you so much for the feedback, I didn’t think you’d be talking about my module. I’ll make sure it gets better.
Hey, can I get an update when the inaccuracy bug will be fixed?
Before I use this, I want to ask one question, would this be a good module to use when making an fps game? I’m probably gonna use this for the projectiles, but I wanna know if it’ll be a good design choice.
I don’t recommend using stuff like these for projectiles, projectiles are usually more lightweight and require lots of them being made in seconds. Using attachments in projectiles get’s memory-hungry, hitboxes are only ideal for things that will last long, such as swords.
Projectiles have a very short lifespan, what I recommend for projectiles is updating the projectile manually via CFrame and casting a ray to the next point, or using fast cast which does this for you.
I think I’m better off staying with RaycastHitbox.
Try using the latest version and check if it’s inaccurate or not.
The performance benefit of this now seems useless because of a fairly recent update to Raycast Hitbox.
Can you make a tutorial on HitboxCaster? Because I have no idea what I’m looking at but I’m interested
That would be possibly except I’d like to focus on revamping the code beforehand.