In that case, would you say that dot product & magnitude checks are sufficient for security or do you have any suggestions for other security methods?
Yo man, I’ve tried adding an ungodly amount of attachments to the swords in my game, and the hitbox is still facing reliability issues. It basically only happens when the character is standing still. If you jimmy the camera a bit when you swing(there’s mouselock in my game so that rotates the character), it works perfectly.
I’m running the hitboxes on the client, but the attachments are created on the server. Any clue what’s going on?
(I tried giving one of the swords 200+ attachments and that still did not solve reliability issues.)
1 Like
@VirtualButFake Dot Product + Magnitude is a good start, and may even be enough depending on what your game is. I would combine it with raycasts as well if you care at all about the player/enemy hitting through walls. It’s difficult to really “recommend” security methods, since it depends on what your game is and what makes sense in your game. If you can describe what your game is about for me, I’ll be more than happy to give some tailored security suggestions afterwards.
@skywildsaturn Unfortunately, this is the nature of raycasts in general. If you are standing still, there is not enough distance for the rays to detect anything. In addition, rays cast from inside a part will not register a hit, only when the ray is cast from outside a part will it detect a hit. When you are standing still with your sword inside the target, the rays are being cast from the inside. I believe this is a problem in other game engines as well, like Unity. This is not just a Roblox problem.
Here are some examples of what I’m talking about.
Summary
Let’s take this image for example.
Gray brick: This is our target
Blue brick: This is where our rays start casting from, or in RaycastHitbox’s case, the attachment position
Red brick: This is the direction the ray is casting to. Of course, the distance is a bit exaggerated but it’s basically how the module works.
When the start point blue brick is inside a part (the gray brick), and starts casting a ray, it will not register a hit. I’m not sure why it doesn’t, but it’s probably for performance reasons with mesh occlusion.
If we move the Start point outside of the target, our rays will now start detecting hits.
This is the same reliability issue you are experiencing but on a much, much smaller scale. If you are unmoving, and your raycast points are inside the target, the raycasts will never detect anything. Unless Roblox designs another type of raycast system that ignores occlusion culling, this is unfortunately not possible to fix (or at least, in a way that doesn’t require much work). This module has a LinkAttachment feature that you can try in combination with your current attachment setup. It basically draws a ray between two points, and it may work for what you are trying to accomplish. Have a point on the handle, and then the other at the tip, and if your target isn’t too big, your hit detection should be better while standing still.
Due to the nature of this module, even if you are standing still and your target comes towards you, it may not guarantee a hit since the rays in this module requires distance and velocity (hence why it works when you swing). Adding a minimum raycast distance as well won’t work either since the above reliability issue will make that change meaningless.
Should I :Initialize() on a “attacking” event? and then :Deinitialize() when its completed, or should I :Initialize() when the player’s character is added, then do :HitStart() and :HitStop() when the event is called?
The latter. Spamming Initialize or Deinitialize will affect performance. Only do them when you create the hitbox/no longer need them. Treat them like instancing or destroying and you will be set.
1 Like
Hey I think something might be wrong with the code with the initialize function. I’ve set it up the same way you did on github but the error still appears. I checked the modules code and I’ve noticed that the first line under the initialize function has an error.
ps. Sorry if I didn’t format it correctly This is only my first post on the forum
1 Like
The github formatting is slightly wrong due to me not being able to put descendants like you can do with studio. In the future i will convert it to rojo compatible to make it easier to import to projects.
Make sure all the contents of raycast-src is under RaycastHitbox.lua.
- RaycastHitbox.lua
-
- CastLogics
-
- Tools
-
- MainHandler.lua
-
- HitboxObject.lua
If it still errors with this formatting, let me know.
This is perfect! I feel bad for using this even if it is community resource so I donated too. Hope its enough!
Keep up the hard work dude!
6 Likes
EDIT: I’m using v3.2, since I just returned to this from earlier February. Will update soon enough.
Hey Swordphin! I am making a fighting game with various martial arts, and I came across two issues while making a boxing tools with set-points using the actual left/right arms of the character.
I will demonstrate the left arm only since the right arm is a copy and a near-duplicate of the left.
I apologize if I have overlooked anything, and I consider your work to be magnificent.
I would post code blocks but I don’t know how, and I apologize.
-I have tried RemovePoints()
-I have tried turning DebugMode off on unequip, and on during equip
Sorry if I don’t explain it clearly but, I feel like my code might need to be improved on since when setting new set-points with c["Left Arm] then the following:
- positive and negative version of c[“Left Arm”].Position.X/2 in the X position of the first pair of Vector3s
- +/- versions of c[“Left Arm”].Position.Y/2 in the Y position of the second pair of Vector3s
- +/- versions of c[“Left Arm”].Position.Z/2 in the Z position of the third pair Vector3s
This is the first issue that arises:
- Relative to the person’s left arm’s position in the initial spawn position without a spawn location,
the set-points seems to work for Y although it floats off the actual object (which is neither good or bad), and the set-points works for one of the other vectors (not sure if it’s X or Z, it seems to be X that works based off the 3d-space cube with the axises, but it could be Z) but not both of the horizontal axises.
-Gyazo link- One of the axises are missing on left arm, ignore the right arm.
For illustration, the above picture [at ZERO,ZERO] added four new -Y vector3s with added +/- Xs in the X part in the new first pair, and +/- Zs in the Z part in the second pair. Intentionally there should be a dotted cross formation there, but all there is is a dot stream to the left and right of the arm, but not to the front or back of it. The -Ys were graphed in their intentional place, while one of the other horizontal axises were as well but not both.
This is the second issue that arises:
When the character re-equips his tool anywhere away from the initial spawn, any distance, something scales the set-points and their debug trails further away from my arm.
I assume that the area where the drift from the arm is minimal is the “ZERO,ZERO” of this emergent scaling.
I tested with and without a spawn location to see if ZERO,ZERO changed. it did not. The initial spawn without the spawn location seems to be the only area where set-point drift is at its minimal.
I would have a question about why the gap between the set-point and the axis.Position/2 exists at all,
but if the second issue did not exist, I would just scale it using a number higher than two to reduce the gap, and all that would remain is why one of the horizontal axises didn’t translate properly.
Thank you for reading, and I thank you for being helpful as much as you’ve been.
Use this Code block!
Use three backticks followed by the word ‘lua’. Then paste your code right after. You can then end it off with an additional three backticks at the end of the script. This should format the code for readability.
It’s a little hard to follow without having a reference on how you are setting up SetPoints but from what I’ve hopefully gathered trying to piece the puzzles together is that
- SetPoints is not accurately putting the points where they need to be.
- Equipping/unequipping will reposition the points in space with progressively worst results
What is [ZERO, ZERO] referring to exactly? Is this a Vector2 point? I’m not exactly experienced with tools (I haven’t used them in over 7 years) but if you have a simple repro place that you can DM me that demonstrates the issue, I can try to diagnose it for you. From the experiences you highlighted, it may also be possible that RaycastModule has a bug with Setpoints specifically.
2 Likes
I would be willing to send you a copy of my place, but where can I send you a copy privately, if possible?
If not, then I’ll do it publicly, I’m not that good at coding anyway.
EDIT: “ZERO, ZERO” or more realistically “ZERO, ZERO?, ZERO” isn’t a confirmed coordinate like 0,0,0. It was just a shorthand for me explaining where I spawned (aka ZERO,?,ZERO ~> my spawnpoint without a spawn location) in the game seemingly having the minimal amount of drift. The actual numbers of the position in 3d space is unknown. Like I spawn in, activate it, and it has less drift than if I walk somewhere away from my spawn then activate it. It’s kind of like “X marks the spot” but flipped on its head.
TL;DR It was just a shorthand I thought off the top of my head.
ZERO,ZERO ~=~ the place with the least drift:
Where my character spawns is the least drift or “ZERO,ZERO”
I found the issue I used a . instead of a : sorry about that.
1 Like
Hey Swordphin, I managed to get past the issue that you mentioned earlier. Thanks for the quick responses.
I’ve actually got another issue, and it has to do with hitbox detection when NPCs in my game attack players. Since the hitbox is dependent on the position of swords(or a part hitbox welded to the NPC’s hands, in this case), I figured that it would be a good idea to play only an NPC’s attack animations on the server while the rest of it’s animations are played client-side.
While this made your hit detection system work perfectly(it was being called on the server), playing animations on the server came with a huge issue. After a short period of time, most NPCs would freeze on every client(I know for a fact that they froze on each client rather than the server. The server was running fine and was not experiencing any lag). They would just run in place, sometimes floating in the air. I narrowed the problem down to the server-side animations. As soon as I removed them, the issue stopped.
So the dilemma I’m facing is the fact that this hit detection system is essentially tied to the swing animation that’s played. One solution I thought of was going with the usual client-sided NPC animations and detecting damage with your module on each client(each player will detect if the NPC hits them). I initially wanted to have the NPC hit detection be completely server-side, but this seems like the only solution.
I noticed that you use NPCs in your game. Is this how you solve this issue, or do you do things differently?
1 Like
If this is going to be any serious long term game project, please do not make clients listen if they get hit. This is a big security flaw and you will have massive headaches later. I speak from experience.
I would try to find the root cause of what freezes your NPCs (unfortunately i do not know your game systems well enough to suggest any solutions) instead of relying on workarounds that would ultimately risk exploitations.
For how I do it, all my enemy hit detection are server-sided so they aren’t anything special. Visual effects (like particles) are drawn on client side afterwards.
2 Likes
Hey, I love your hitbox module it’s awesome! Easily one of the best things on here.
I see to be having a problem with it though, for some reason when players are teleported the hitbox itself will skew entirely and not be moved with the player.
This happens when the HumanoidRootPart’s position or orientation is changed in any way, and results in the hitbox staying where it was before the teleportation and being sort of welded to the player and stuck in that position.
Is there any way I can fix this?
If possible, can you show any video footage of it happening? If the hitbox is created on the server side, I suspect it may be a Roblox replication bug that is out of the scope of the module (though will need to check to confirm if it is). The only fix that I know of if this is your case is to move the hitbox logic to the client.
Also let me know if you are using attachments and/or setpoints.
1 Like
My computer is too garbage to record video but i can provide examples.
The hitbox is created on the server, and attachments are used for the damage points.
Lets say for example I am using a tool with this implemented, a basic sword. If I set the CFrame of the HumanoidRootPart to turn the charactera certain direction, the hitbox will now be offset at the angle I had set for the player, only in the opposite direction.
Another example is if i set the CFrame of the root to a different position to teleport the character, the hitbox will now be offset the distance that teleport was from where the player was originally.
i made some code to make the attachments on the weps u cn put this in the cmd line to use-
local part = game.Workspace.Tool.Hitbox;
local attachcount = math.floor( part.Size.Y);
for i= part.Position.Y - part.Size.Y/2, part.Position.Y + part.Size.Y/2,0.5 do
local currattach = Instance.new("Attachment");
currattach.Name = "DmgPoint";
currattach.Parent = part;
currattach.WorldPosition = Vector3.new(currattach.WorldPosition.X,i,currattach.WorldPosition.Z);
end
So even if I were to have hundreds of npcs using a raycast hitbox, the performance would be better than Touched? Is touched fired even if you do not connect to it in the backend?
Need help with serverside raycasting. There always seems to be a delay on the clients side everytime I try to use it.
For reference: https://cdn.discordapp.com/attachments/797876906862182430/823305914424492032/clientvsserver480p.mov (serverside raycasting from the clients perspective)
Also for reference: https://cdn.discordapp.com/attachments/780904700873932870/823213960182235156/test.mov (How other players view it)
You can see that the clients perspective shows a delay (probably because the raycasts are being ran serverside). Is there anyway I can remedy this AND keep the rays serversided?