Basically, the way I have it, server tells client to play animation, vfx, and do hitreg (I’m using raycasthitbox).
Server gives client info in a table.
Server also creates an entry to a table, which contains the current timestamp, and the timestamp when the attack is predicted to end.
(For example, a one second swing animation is predicted to end in one second on the server).
When client reports a hit, send it to the server. Again on the server, we check if the timestamp, minus THREE whole seconds (Will probably be less in the final state of the game) for ping/latency, is lesser than the time the attack was predicted to end, if so, then do the according damage, else we do infinite damage (since they’re probably exploiting).
Code example:
OnServerEvent(plr, data)
local AttackTable = data.Table
local Id = data.RemoteID
if workspace:GetServerTimeNow() - 3 < AttackTable[Id].AttackEnded then
DoRegularDamage(plr)
else
DoInfiniteDamage(plr)
end
end
so what’s the problem? is it not registering the hits?
2 Likes
It is, just checking if there’s a better way to do it
1 Like
well at the end of the day i think it just comes down to what’s better for your game. like there isn’t one correct way to do this kind of stuff. that being said i do think there’s something that could be improved, it looks like you have an unnecessary step of the server needing to tell the client to attack.
the client should be able to perform an attack after receiving an input without the need for the server at all.
also you may want to consider adding an extra check for hitreg on the server after the client reports a hit. its usually good practice to have a hitreg on both the client and server to prevent exploiters from just sending false hit reports to the server.
one more thing is that I’m a little confused as to why your tracking the length of each attack? if it is just to make sure exploiters are not spamming attacks very quickly then i guess i dont understand the function of this code. it looks as though when the client reports a hit (what i assume this event tracks) the server deals damage to the client that is attacking. obviously thats not the case so im guessing that these functions are actually to damage the NPC but if that were true then why would you want to deal infinite damage to the npc if the player is exploiting. i am kind of just confused as to the overall purpose of this function so some background info on what its supposed to do exactly and where/when its called would be helpful.
It’s to deal damage to the player, like when an AI enemy attacks you. The player is being damaged by the NPC, the attack length is being tracked for the sanity check (so exploiters cant set the NPC’s state to a weak attack that happened in the past to nullify a strong one)
unless the npc’s are handled on the client then exploiters can not change the npc’s properties as its handled on the server. the only time this is a problem is if hitreg is handled on the client and not the server, witch in this case i guess it is. i would recommend that if the npc is attacking you handle all the hitreg and damage on the server and pass to the client the results. this way exploiters cant tamper with how fast/slow an attack is.
basically do something like this
(npc attempts to attack - server) → (check if attack landed and calculate/deal damage - server)
you don’t need to involve the client at all during this except for maybe showing attack vfx and anims after an attack is landed witch should be replicated to all clients.
the only things exploiters have access to is local scripts and things on the client. if the exploiter changes properties of something in workspace (like an npc) it will only change it for them, on the server the npc will remain unchanged and hitreg should be unaffected.
by doing all the hitreg on the server you wont need to check the length of an attack because exploiters wont be able to change it if its on the server.
I’m aware, but on the server, the game becomes unplayable because of delay, because you can’t precisely dodge or parry anymore. Parry and dodge windows are gonna be small. I guess I’ll just have to suck it up, the only thing I’m really concerned about is exploiters ruining other players UX, but I might have a votekick system in place for that
Checking the length of an attack is not too much of an issue for me, it’s really a two/three minute job for each attack
This is an issue with other games too, most RPG games on roblox just use .touched events with the network player set to the server, which is the same as clientside hitreg
if your worried about the timing being off on the client then i guess a middle ground approach would be to use your current method where the client deos the hitreg and only reports potential hits to the server, then on the server you can keep the system you have right now where you time each attack but also i think you should at least include some sort of validation that can check wether or not the attack missed or connected because an exploiter could simply make it so all of the hit regs fail regardless of wether or not the attack lands.