The two tests you did are different from eachother. It is also unclear if the raycast module would pick up all of the touch events that are actually happening. If Roblox is already doing the collision detection in the backend as part of the physics engine, surely firing a signal is less expensive than actually raycasting every frame.
Pick up all of the touch events that are happening? Also 3D math + physics isn’t cheaper than 1D math? Yes raycasting is indeed 1D bc for something to be classified as a 2D shape it has to have a width which rays don’t have. Wym 2 tests?
I don’t think that’s a valid comparison to make because your hitbox doesn’t even do collision detection in the example comparison place you gave.
https://gyazo.com/ce79f58d3702a8637998e2e9141f686e
https://gyazo.com/dfe6fcdd85aaec59845df82ac63ea1e9
https://gyazo.com/d3d2157386325e783e851d2367ff6bc5
comparison.rbxl (42.0 KB)
As you see in the first example it prints, in your example ‘blacklist’ it doesn’t. Both of them also have print statements when the signal happens.
1 Like
I guess it is somewhat unfair to print since printing is pretty expensive bc of who knows y.
I think you misunderstood what I was saying BOTH had a print statement on the event which I put.
https://gyazo.com/efc6db8f99269821de4486001477b495
https://gyazo.com/7e1c67ce70584c5acc95179678778d26
However your .Signal event didn’t fire while swordphies .OnHit signal did fire.
Basically what VitalWinter is saying, but your .Signal event was picking up on nothing.
I’m trying to test it rn, but weirdly enough none of them are even picking up the dummy.
I think you forgot to put a print statement because swordphines does actually pick up on it.
comparison.rbxl (42.1 KB)
(This one has prints, the one I included on the top I forgot to save the file so it doesn’t include the prints this version does.)
I think u mistook mine for swordphin’s. Mine is actually working fine
https://gyazo.com/ad3ed641a88f60526eb496ab8db8b0e5
Edit : actually even tho it isn’t printing anything, it has higher activity than mine. 
Then that isn’t a fair comparsion either, make sure both of them work if you want to compare something.
Not really, it isn’t picking up anything and has more activity which is very odd.
Maybe because you did something wrong in setting up swordphins module. You can’t really call that a fair comparasion until both work, it could likely be your misusing the API of the other module causing it not to work propertly, making it have a larger script activity.
HOWEVER, i’m not saying your module is less performant or vice versa, i’m just saying you should do a fair comparison if you want to compare something.
Can you setup swordphins’ module then? I haven’t used his in so long since I’ve been using my friend’s until I made mine recently.
I don’t know how to do it. I’m not a fan of using public resources so I don’t use them. But I think you can surely find someone who can do it.
Ok so I had to sacrifice some performance(Using heartbeat wouldn’t work so I had to use wait() 
). But these are the results
comparison.rbxl (42.1 KB)
Results
Roblox is already doing the physics, whether you are listening for touch events or not. Surely having it fire those events is less expensive than also running dozens of raycasts per object every frame.
It almost feels like you are trolling me when you say that raycasting in 3D onto 3D objects is not 3D math but 1D math.
It is possible that an object could miss one of the rays, since it isn’t doing volume collision detection.
That is y u cast multiple rays 
. Also raycasting wouldn’t had been recognized as the best hitbox method by ppl with big names for such a long time without a reason.
My point is that rays are a discrete representation of a moving surface or volume, unlike the math that is going on in the physics engine for the surfaces/volumes.
Here’s the deal probably with weird shapes you’ll need more raycasts, raycats are continous collisions which are usually more expensive then discrere collisions. Discrete collisions is what the roblox physcis engine does.
However .Touched isn’t good for fast moving objects since it introduces the problem of tunneling.While continous collision implementations like raycasting solve this. But the tradeoff is performance.
Underneath the hood the physcis engine is constantly checking for collisions and when a collision is found it fires .Touched event. Even if you connect to it or not those parts are being checked for collisions, so .Touched isn’t less performant because if it was we would be seeing that lag in a game with lots of parts. Collision checks are already running in the backround what is expensive is what you connect when .Touched Happens.
I think the question of why this should be used over RaycastHitbox has still been left unanswered or at least to a detailed degree, after I’ve gone through the thread. I’m just seeing a bunch of back-and-forth but I want to be able to see the points in a condensed post.
Could you explain what significant changes this boasts over that module and why you felt they were better suited as an independent module over having suggested these changes to RaycastHitbox? There is a GitHub repository if you want to contribute and the thread’s replies are also viable for providing feedback and suggestions for improvement, not just for getting help.
Contributing to original source code (in this case, RaycastHitbox) would better help that developer improve on their resource and in turn allow more developers to have access to those improvements and changes if they’re actually necessary.
For reference: I use RaycastHitbox in my game, and want to know if it’s worth changing over to yours and why. I use it and the other developers on the team are familiar with it as well, so it’d be nice to know if the switch is worth and what can be gotten out of it.
Additionally, @Gojinhan, I think you’re confusing overengineering and the like with accessibility and I’m not fully confident you know what you’re talking about, rather finding a reason to pick a bone with big name developers for the sake of doing so. That’s not welcome here.
The Resources category is meant to contain resources that are accessible to developers of all skill levels and the inclusion of the extra materials is to help extensibility and tooling, from novices to power users. Extra configuration methods are not pointless and being modular is absolutely not pointless (so I have zero clue what you’re talking about here).
When you provide more methods and modules, you grant developers more freedom to tailor a resource to suit their needs and to make clear distinctions around in your code. Two examples:
-
MockDataStore contains modules to split up the functionality between a mock GlobalDataStore and a mock OrderedDataStore: those need to be there and should not be amalgamated. They also contain DataStore constants (a large table of values intended to help emulate DataStores in Studio), DataStorePages emulation and other goodies to bring everything together.
-
CameraShaker splits into three modules, one of which helps developers pick presets for how their explosions should look. This saves you time of having to spend hours experimenting with values just to find one you like. The other one is mostly internal. Then the last one is the actual module itself, which is meant for… shaking cameras.
I won’t disagree with you that a big name does not automatically render the developer’s resource efficient, but nine times out of ten they will know what they’re doing. Even then, they often open up contributions so developers can help them improve on their resources. That’s what we should be encouraging on this category: helping build upon things, be it knowledge or free assets.
As for being against “pointless inclusion of other modules” or “useless methods”, I encourage you to get into a serious well-structured project on or off the platform. Most of them will be split up into many different modules, each responsible for tackling a different system or subsystem which are all brought together to form a whole application. Frameworks are literally based on everything being in modules and you absolutely do not want to minimise in that scenario. Things will get lost, readability will be hampered and you won’t have much of a clear grasp on the distinction and division of systems.
I’d also encourage you to read up on the single-responsibility principle which is an actual software development concept. Amalgamating things is an anti-pattern, splitting systems up is good. You can still be wary of performance, negligible or not, while writing a program that supports many methods and modules in it.
More methods and modules could just mean that a developer wants to cater to a larger variety of use cases out there, that they want to show how systems are worked together to establish the system or to make working with it easier. Having more methods and modules has nothing to do with anything: performance doesn’t slow down just because you have more of those, lol. Performance is based on the work that something actually does.
12 Likes
I agree with what you said and I’ll read further into it. One thing I disagree with is this;
I’m not fully confident you know what you’re talking about, rather finding a reason to pick a bone with big name developers for the sake of doing so. That’s not welcome here.
Thats quite presumptuous, I don’t like the way they write their modules but I have nothing personally against them nor is it baseless because it’s just my opinion on how they write them. I’m not sure where you got that from.
Extra configuration methods are not pointless and being modular is absolutely not pointless
Believe it or not a couple hours later after my original reply I learned the other side of the coin and know why people make those “pointless methods”. But once again, I’m not sure where you’re getting some of this from? I don’t hate being modular at all? In my personal projects it’s pretty much entirely modules just being modular. I don’t usually write code that I don’t intend to be modular.
As for being against “pointless inclusion of other modules” or “useless methods”, I encourage you to get into a serious well-structured project on or off the platform. Most of them will be split up into many different modules, each responsible for tackling a different system or subsystem which are all brought together to form a whole application. Frameworks are literally based on everything being in modules
So you bring up that I should go into a personal project to know why people add so many “useless” methods? I’ll admit I’ve never gotten very far into development, the furthest I have gotten is having wrote 80% of the core mechanics for one of my projects. But this seems sort of contradictory, in a personal project you don’t need those extra methods, you don’t need the extra “bloat” that like you said module devs use for ease of use when they post resources. So this makes no sense, in a personal project where I am writing core modules and I know exactly how and when they will be used, why would I add more? I understand why I would add “bloat” if I were making some sort of hitbox module, that would make sense because the result and functionality wouldn’t be consistent, but you’re talking about modules in general.
Having more methods and modules has nothing to do with anything: performance doesn’t slow down just because you have more of those, lol. Performance is based on the work that something actually does.
It’s not always about performance. And when I evaluate modules, it usually isn’t, what you said is true; performance does not slow down just because you have bloat. it’s dependent on the work it does, however I follow my own personal principle, if I will never need it; I will never have it. saves memory and potential processing that could have gone into the main work. (e.g calling a bloat function)
Overall good argument, I learned some things I didn’t know; but i think you’re assuming a little more about me than you know.