This module should be used over my old hitbox module that utilize GetPartBoundInBox. This one has more accurate hitboxes and is more performant.
Intro
Currently version 0 . 1 . 5
HitQuery provides accurate part detection achieved with Roblox’s GetPartInPart Method. This will allow for different combat and weapon systems to be created easily.
https://create.roblox.com/store/asset/127558091475994/HitQuery
Usage
Of course, there are many other hitbox alternatives available that work perfectly fine. But this module is made for you to have full control of the hitbox and everything that happens with it. This allows you to create different style hitboxes with different hit patterns utilizing HitQuery’s simple, yet optimized API.
API
There is a wiki on github explaining each of the features of the module and some examples of how it can be used.
IMPORTANT
Currently, a lot of hitbox modules use velocity prediction for more accurate hitboxes. To elaborate, this predicts where the hitbox is going to be so it does not lag behind. My main concern with this is demonstrated in the video below:
As demonstrated in the video, when the sign of the velocity flips or zeros, it tends to overshoot. Lowering the prediction scalar will reduce overshoot, but also reduce accuracy.
For now I will keep this feature out, but plan to figure out a more accurate method to achieve this in the future.
8 Likes
Very helpful resource, but it’s locked, did you forget to make it on sale or is it still processing moderation? Thank you for this by the way. 
2 Likes
oh my bad forgot to put it on sale sorry 
2 Likes
After a long period of inactivity on this module, I’ve decided to return and continue updating and improving it. Below is the latest release.
Version 0.1.4
The Destroy function has been fixed to properly disconnect all internal connections, clear references, and release any allocated resources. This prevents lingering objects and ensures that hitboxes are not kept in memory after they are no longer needed.
Memory management throughout the module has also been improved, reducing unnecessary allocations and resolving a memory leak that could occur during repeated hitbox creation and destruction. These changes make the module more suitable for combat systems and other high-frequency use cases where hitboxes are created and destroyed often.
Overall, this update improves long-term performance, stability, and safety when using the hitbox module in live experiences and extended play sessions.
Summary of changes
- Improved internal memory management
- Fixed
Destroy function cleanup logic
- Resolved memory leak during hitbox disposal
- Increased stability for repeated hitbox usage
1 Like
Potential Future Plans
I’ve recently been experimenting with position prediction and plan to integrate it in a future release. In addition, I aim to provide developers with more control over the hitbox system by exposing lower-level logic. This includes:
- More explicit lifecycle states for better control and debugging
- Advanced filtering and targeting options
- Higher-quality validation for hit detection
- Richer metadata returns from hits for greater flexibility in gameplay systems
These improvements will allow for more sophisticated combat mechanics and give developers greater insight and control when using the hitbox module.
Summary of Planned Features
- Enhanced validation
- More in-depth filtering and targeting
- Explicit lifecycle states
- Lower-level hit metadata
Why did you drop GetPartsBoundsInBox to use GetPartsInPart?
I have tested that getpartboundsinbox is more faster do to it using axis aligned box approach so it doesnt have to evaluate the extra geometry of a part but, my main reason for getpartsinpart is for more flexibility when creating hitboxes because of the Shape property of parts. This is so more complex hitboxes can be achieved.
Another handy feature of parts is welds. This can allow for server position predictioning; accurate hitboxes without relying on client input.
I have created a way for server position predicting without the use of welds but there are some edge cases that i still need to handle with that.
1 Like
Future Feature
Server Authority
I plan to add server authority by creating validation logic on the server. This will use a lag-compensation–style approach to account for latency, allowing the server to verify actions based on past states. This improves accuracy, consistency across different pings, and overall security by preventing client-side manipulation.