optimize slap script #18
Labels
No Label
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: SquiedInk/Slap#18
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
-Added the ReturnsHandler (In replicated storage)
· Slap script
-Optimized the hitboxes from heartbeat to .touched event for connected parts
-Optimized humanoid enabled states from heartbeat to event
-reworked returns into the returnshandler
-added some concerned comments (--♥♥)
(!) todo: make sure .touched doesnt invoke the function unless slapping is happening eith slapboxx
exploit prevention (theres a send to the server but honestly idk what it does, and it jss no debounce)
the invoke for slapping is so the server has to essentially "approve" the slap, preventing laggy players from slapping people 50 fucking metres from them during a lagspike. it does nothing but return true, the fastest thing to return
you can also use that as a way to determine when the player is slapping to approve requests from the hit remote, and apply debounce, and shit. antiexploit wont be too difficult i hope! i can apply some project hera principles aswell because ph had one of the best anticheats in the project game market
the deltas are solely because im used to actual gamedev where things are done frame by frame and ive been trying to apply it in more places because its easy for me but its sloppy... however in some cases it works really well (check out camerahandler for the killcam! very good use of deltas there)
that is to say that you have been fixing things very well! thank you! i responded to your comments
thanks for the response, so if im getting it right the invoke part of the script isnt done - itll have have some checks as exploit prevention. Thats for later to tackle, im making a column for that now.
-Slapbox works through events now!
-replaced "nil" with "Player" in all :HasState calls in slap script, i'm not sure if its right but it makes sense to me? Doesnt seem to break anything.
-Reworked new setstates for ragdoll into events
-Added humanoidenabled states to ragdoll modulescript, makes more sense to handle it there
-uncommented the setstate change prevention... its really minor it just prevents exploiters from enabling/disabling some states but perhaps itll have some merit
-added new states per the heartbeat to the prevention
-added (unused?) to ragdolling, seems to be a less cleaned up duplicate of ragdoll, please delete it if thats true
when you trigger statehandler from the client, it already knows the player its for, because, well, its on the client. but i dont know how to make those function params change dynamically, so instead of defining player, i just define nil. doesnt make a difference because on the client it doesnt use that player variable
that ragdolling is used! its for the client to know that theyre ragdolled and enable the physics state. i have now renamed it to ragdollingClient. i made a new "doKnockback" module in visualshandler (temporarily stored there because visualshandler makes sending client data easy) and thats where its applied
setting state to physics on server does not seem to work. i tested it and it doesnt
in regards to using heartbeat for the fallingdown state removal,
it does not work very well in your way. im still capable of entering the falling down state through rolling myself into walls
i will revert it until a better method is found