Just add a limit? Not that difficult to verify data.
You should have both, but keep a lot of the checking in server scripts.
If I do a move, let’s say M1 or something basic like an ‘E’ spell/move, it should first locally check if I have a cooldown, and if the cooldown is inactive then it fires a remote event, which when the server gets it, it checks that the player is able to firstly, do that move, and secondly, is not on a cooldown.
Keeping player input on the server is generally bad practice and I suggest calculating most of the other aspects like damage, cooldown, knockback, etc, all on the server since it will be more universally ‘true’ than the client.
You’ll need to add too many limits and checks:
- Is the sword touching the player?
- Is the value low enough to be real?
- Has damage been applied to other players or this player recently?
OR you can do everything in a server script and not having to do all these checks for exploiters.
1 Like
Yup! The more you have, the more secure your game is!
Jesus Christ this definitely became my most replied post overnight
1 Like
I have one question. How would I play certain sounds? I want swing and hit sounds to be heard by everyone in the server. But since animations are client sided how could I possibly sync up sounds with the swinging animations? I also want my kill sound (only heard by the killer) to be local, clashing sound to be heard by everyone in the server, and level up sound to be local.
There’s this post that explains I can pretty much insert the sound into the animations themselves, which means syncing isn’t an issue for swings, but since animations are being played locally it means no one will hear them. Can I play animations on the server? Or for a better question can I use the tutorial video linked in the post and just convert it to server instead of client? Because pretty much how he makes it work so everyone can see stuff despite it being client is sending a data dictionary to the server. I feel like this could not only cause lag but be a nightmare for laggy mobile players. So in the end would it just be better to do the combat system on a server script?
Wait nevermind server sided just seems better overall in general
Yeah controls will be client sided. I’m gonna use context action service for the whole system. When a weapon is equipped it fires a remote event that binds the unsheath button. Then when a player clicks unsheath it fires a remote event to unbind unsheath then bind sheath to the same exact key/button and also binds all the combat action functions. So when those keys/buttons are pressed it’ll run the combat function for that (for example slashing).
That would mean no one else in the server would be able to see the animations… I don’t think that’s how it’s supposed to work.
It is possible by firing the data to the server but it’s just inefficient and bad for lag. Server sided just seems better for everything
1 Like
Genuine fear from hearing that before realizing you accidently mixed up your words. 
Client side hitbox + effects with server sided verification (Performant, fast, but can lead to some false positives or super weird hits/slightly advantageous exploited hits)
Client side hitbox + effects + vertication (Very bad, don’t do verification on client and trust it immediately)
Client side hitbox with server sided effects and verification (Laggy due to effects being on server)
Server sided hitbox and verification with client sided effects (Most “accurate” in terms of verifying which player should do what, issue is that ping becomes a major part in breaking this system and input lag is very pronouced)
Client sided hitbox with verification and effects and server sided verification (Have clients check the attack and verify with eachother if accurate, then check on server to be dubiously sure)
TL:DR
Client side: For effects for sure
Server side: For verification
Hitbox: Both for fast registration as well as verification from server standpoint, requires a little client prediction and math to get it working but should be mostly fine… I think
1 Like
Player animations are replicated regardless of where they are ran. You can run an animation on a client and it will be replicated because of network ownership.
Hit detection will need to be done on server for security. Exploiters can manipulate the results of a raycast if its done on client. Sounds will also need to be done on server, this makes it easier.
Effects need to be registered on the client that fired and then sent out from server. We can fire all clients to show effects except for the client that did the attack, that makes the effect look cleaner.
client sided animations are replicated to the server
in fact, it is recommended to do animations client sided, doing it in the server can cause some issues
For example?
notenoughcharsahhh
No, this is still bad practice. Even with limits, an exploiter can make every attack do maximum and give themselves a huge advantage. There is no reasonable performance trade-off on the server that makes calculating damage on the client viable.
Tl:Dr Server > Client in every way
This isn’t necessarily correct either. I would still recommend handling things like visual effects and moving parts on the client: if you leave it to the server they will look choppy on the client’s end and will take up a lot of unnecessary processing on the server.
How would I replicate effects to the server so they can see it? For example a clash effect when someone hits a block
Have the client listen to a remote event. When it is fired from server-side, run the clash effect function. You can pass any necessary parameters like which block was it from the server.
Okay I’m reviving this real quick because I need help. So I’m going to make this whole system in the video (linked below) server sided. That way it can’t be exploited and everyone in the server can see everything. However I can’t use context action service in a server script, meaning I can’t bind these functions to input. Does anyone have a solution?