Behavior where InputContexts under a Player Instance not replicating unless server authority is enabled means that it’s incredibly tedious to create a system that will work with server authority in the future. In addition, the mechanics of being able to code intent-based custom serverside logic is helpful and should be an opt-in feature for those who intend to take advantage of it, without needing to rely on server authority necessarily.
7 Likes
that would just bloat the engine and create confusion
Cant be so hard to fire a remote event
Not to mention that the way whole input replication is structured… well lets just say its NOT good
I’m not sure how an opt-in feature for existing behavior would bloat the engine or create confusion. The input replication of Input-Objects under a Player Instance replicating to the server is intuitive behavior as well, there’s nothing weird about it unless you have some knowledge that I don’t.
For my use case, I have some state architecture which works with both server authority enabled and disabled, because server authority is currently too unstable to fully opt-into for a lot of people including myself. But gatekeeping logic like this behind server authority means that this requires a lot of unnecessary extra work.
I support this! The separation of concerns that this would provide for code not using server authority will be helpful. Rather than being forced to trace the execution path would be really helpful, and, with native support, could end up being more performant than manually firing remotes off with their added baggage.
1 Like