FastHumanoid is a fast and deterministic player character controller that uses Actors, UnreliableRemoteEvents and buffer serialization to make sure that it is the fastest it can be
I made this module after seeing how slow physics-based Humanoids can be with alot of players, and is overall just a proof of concept of what can be.
I do not recommend using this module for anything other than experimenting/small games for now as it is still being developed and as I said still pretty much just a proof of concept.
Flaws
Character movement is not replicated to the server.
This is because of server-client replication, since the client is already setting their characters CFrame on their side, setting it again on the server would cause stuttering.
However, the FastHumanoid module has a .CFrame property which lets you see where the player is based on information from the client
Known Issues
Currently there is this weird bug where the FastHumanoid ModuleScript isn’t being cached after being required by the inner scripts Client and Server, so if you for example try to do this in an outside script:
I understand that UnreliableRemoteEvents is used for this to optimize the character replication, but UnreliableRemoteEvents have a chance of failing which is fine but not ideal for pvp games
heartbeat passes a delta time argument which can be used to make the jump height the same across any fps
Oof, did you change the .CFrame value in the module? It is initialised to the first spawn location, I would also disable any scripts affecting the position of the Character as it may or may not interfere with how the module works.
I didn’t use the lerp method before but you should multiply dt it by 60 instead of 3
Summary
if you are running on 60 fps then (dt * 60) will be 1 but it will run 60 times per second
if you are running on 120 fps then (dt * 60) will be .5 but it will run 120 times per second
if you are running on 240 fps then (dt * 60) will be .25 but it will run 240times per second
etc…
