sorry for the long response time. after a while of testing, I can’t seem to replicate it by just setting mover properties at a fast rate in a blank baseplate. but I can still give you the placefile. I use roblox-ts with Flamework, so some of the output may be jumbled.
included this here for completeness because I use an animation solver which I run during onSimulation; wanted to capture all places that could contribute to the problem.
can provide the repository’s typescript code if necessary. K to apply knockback to the local player. knockback velocity is applied on LMB.
edit:
it legitimately seems to get worse if i sit still and do nothing alt-tabbed and then try to do something afterwards (this applies to just walking around an entity that i do not own - walking by itself isn’t the problem, but walking near an entity is a big problem)
A key limitation right now is the lack of support for custom humanoid animations. There’s no clean way to modify the default Animate module or provide a custom animation set. The only workaround seems to be cloning and replacing the script at runtime, which feels unreliable and not in line with best practices.
An official way to override or extend the animation system, for example registering custom animation sets would make this much more usable.
Server Authority also lacks clear documentation on best practices. This makes it harder to adopt properly without trial and error.
Useful areas to cover would be:
Animation handling
How animations should be managed and replicated in a server-authoritative setup.
Combat systems (melee / firearms)
Recommended approaches for hit detection and syncing.
Networking patterns
General guidance on structuring systems efficiently under server authority.
Overall, the system is already at a good stage, but needs better extensibility (especially for animations) and clearer documentation would make it far more practical to use.
Thank you for the feedback – you’ve brought up some great points!
Regarding animations specifically:
To use override the default movement animations (e.g., run/walk/swim/idle) with custom animations, you can enter custom animation IDs under Avatar Settings → Animation Clips → Custom Clips. You can do this without having to fork the default Animate script.
EDIT: ^ This bullet point has been updated, sorry for any confusion caused by my previous incorrect statement.
There are a few important differences for animations in server authority, but we hope that it isn’t too different overall from existing approaches. These differences are:
On the client side, do not hold onto animation track handles between simulation steps/frames. These track handles can become invalidated if the client’s animation is changed due to a misprediction+rollback. Instead, query Animator for the latest track handle if you need to make updates to tracks. We recommend using the new Animator::getTrackByAnimationId() API to help with fetching track handles.
As with any other core gameplay logic in SAuth, logic that controls animations on a predicted Animator should happen identically on both server and predicted clients.
If animations aren’t playing the first time you try to use them, try making a call to LoadAnimation ahead of time so that the animation gets cached. This is helpful in non-SAuth games as well, but it is especially important for SAuth since animations are now sync-ed between server and clients. Delays in downloading/loading animations may lead to the animation not playing and additional mispredictions.
We are still working to improve our documentation. Note that our guidance may change, especially as we continue our work to support animation graphs in server authority.
any ideas as to what’s going on here? (this uses physics-based controllers)
movement actually works really well once i iron out the kinks, but cpu load becomes INSANE when forces are being applied to the character that aren’t from an immediate movement (like deceleration, colliding with a movable object)
secondly:
it legitimately seems to get worse if i sit still and do nothing alt-tabbed and then try to do something afterwards
my suspicion has been proven correct, just under a minute of waiting and my game EXPLODES:
edit: it seems that the big condition is keeping focus on the studio window, if i switch focus to another window then thats when problems start to arise with frame drops during mispredictions
I tried the forked method under StarterCharacterScripts, however, using this approach doesn’t work when it has scripts under it that don’t use legacy run-context as they will somewhy run in StarterCharacterScripts or, well, any place, I assume however they are loaded internally by Server-Authority prevents them from running in StarterCharacterScripts and StarterPlayerScripts.
Replacing the child Animation instances also has no effect as the script, Server-Authority version and legacy Animate both don’t hook into their children, it’s just a waste of memory, the only true place that effects them is the animation id table within the Animate script/Module.
The perf spike looks like it happens when Misprediction is happening. When misprediction happens, we roll back state to the servers correction and then we simulate ahead to get back into latest predicted timestamp. This will usually be around 1 RTT, meaning if your round trip time from Client to Server back to Client is 200ms, when you mispredict you will resimulate 200ms worth of physics, compared to the usual 16ms.
Can you look at what your workload looks like in the microprofiler and what your studio latency simulation settings are set to?
I tried the forked method under StarterCharacterScripts, however, using this approach doesn’t work when it has scripts under it that don’t use legacy run-context as they will somewhy run in StarterCharacterScripts or, well, any place, I assume however they are loaded internally by Server-Authority prevents them from running in StarterCharacterScripts and StarterPlayerScripts.
If you’re referring to warnings like:
Warning: The script 'RunAnimate.Server' with a non-legacy RunContext is parented to a container 'StarterCharacterScripts', which will cause it to run multiple times.
that’s expected right now for the forked Animate / RunAnimate script.
It should be okay to ignore the warning for now for forked Animate scripts/modules. In an upcoming release we’ll update the script so that module.setupAnimation() early-outs when the script isn’t attached to an actual character, which will prevent the setup code from running in non-character contexts.
Replacing the child Animation instances also has no effect as the script, Server-Authority version and legacy Animate both don’t hook into their children, it’s just a waste of memory, the only true place that effects them is the animation id table within the Animate script/Module.
Ah yeah sorry, I gave an incorrect explanation earlier. For the default movement set (run / walk / idle, etc.) used by the built-in Animate pipeline, the effective IDs are driven by your experience’s Avatar Settings → Animation Clips → Custom Clips. You can set custom IDs there without forking Animate at all. This is true in both server-authority and non-server-authority experiences.
I will edit my previous response to avoid further confusion.
no clue what’s making runtime seemingly take that much frametime when moving because all that’s happening at that time are state checks and changes (setting the State attribute):
I am testing the new Server Authority configuration and ran into a practical issue: the settings are visible in Studio under Workspace > Server Authority , but normal game scripts cannot safely inspect whether they are enabled at runtime.
The properties I am referring to are the Server Authority-related Workspace settings such as:
It would also be great to have a more forkable PlayerModule in general, most of the time you have to layer extra logic in another place over the camera for example, I dont see a reason why you shouldnt be able to customize variables at runtime within the modules.
Not to distract from all of the discussion going on in this thread, I made a little Deep-Dive post in a different part of the forum if anyone is interested!
no clue what’s making runtime seemingly take that much frametime when moving because all that’s happening at that time are state checks and changes (setting the State attribute):
Can you PM me the fixed game again? I think you sent me the crash repro, but I wasn’t able to get this far with it. It does look like the “runtime” script is causing huge perf issues, and I’d like to understand why. It’d be easier for me to debug it locally with all the tools I have here!
Can’t figure out how to send a personal message on the devforum (i’m barely here these days), but I don’t mind dropping the source. Too early in development for it to matter anyway (plus, to most people it’s just transpiled garbage anyway and most of those who actually can work with it are far too talented to steal)
Is this intended? It doesn’t trigger a rollback event. I know the Server Authority Techniques page says the instance gets “merged”, but I thought the attributes would be predicted (unless I’m misinterpreting this).
Hey, are tools and the backpack expected to be broken right now? Can’t see that in known issues or FAQ. The toolnone animation does not play by default (even when parented by the server), and the default Backpack script does not correctly handle tool equips. All of this is causing me a lot of headaches trying to port our game to be server authority compatible, and moving tool equips to be entirely server side with input lag isn’t an acceptable trade off for a competitive game like ours.
