Lightyear's input handling has had me stuck for a good time, and part of that was because I could not find out how the server actually defines an entity to be receiving and processing input from a particular client. So I was very confused when I found out that, yeah, it simply doesn't. Clients place an InputMarker component on an entity, and when receiving an input message, the server simply inserts an InputBuffer component onto the entity. (And as a result I believe ActionState will be added as well.)
There is no verification whether this client is supposed to be able to control the entity, nor that the entity is able to handle and process this particular type of input. I believe this isn't very "server-authoritative" and should instead be handled by default, without requiring manual verification by the developer, and I think the building blocks are already here:
ControlledBy component
This already exists, and its naming in my opinion heavily implies that it could have a hand in input handling. What else would it mean to "control" an entity? A check to ensure the entity an input message targets has a ControlledBy component with its owner being the client who sent the message would be trivial in the receive_input_message system.
(If this is not the purpose of ControlledBy then I suggest renaming it to OwnedBy.)
ActionState component
To ensure that an entity is even able to receive (and thus handle) a certain type of input, I would suggest that it has ActionState or similar added to it by the server. This could automatically replicate InputMarker onto the client, requiring exactly the same amount of code but moving it to the server and making it more server-authoritative. Having an ActionState on an entity that can handle inputs as soon at it is spawned rather than waiting for a client to send their first input seems sensible to me, as well.
I'm unsure how the different input systems' ActionState components are handled, so I'm unsure how difficult this is to implement. I'm also realizing I'm not sure how this interacts with predicted entities and timelines.
Alternatives
In this related discussion it was suggested that there should be a hook to manually verify incoming input messages. This could solve the problem, but it would require additional querying for entities that are already being queried anyway. It would also still leave Lightyear as being "client authoritative" by default when it comes to input, requiring extra work to validate.
Lightyear's input handling has had me stuck for a good time, and part of that was because I could not find out how the server actually defines an entity to be receiving and processing input from a particular client. So I was very confused when I found out that, yeah, it simply doesn't. Clients place an
InputMarkercomponent on an entity, and when receiving an input message, the server simply inserts anInputBuffercomponent onto the entity. (And as a result I believeActionStatewill be added as well.)There is no verification whether this client is supposed to be able to control the entity, nor that the entity is able to handle and process this particular type of input. I believe this isn't very "server-authoritative" and should instead be handled by default, without requiring manual verification by the developer, and I think the building blocks are already here:
ControlledBycomponentThis already exists, and its naming in my opinion heavily implies that it could have a hand in input handling. What else would it mean to "control" an entity? A check to ensure the entity an input message targets has a
ControlledBycomponent with itsownerbeing the client who sent the message would be trivial in thereceive_input_messagesystem.(If this is not the purpose of
ControlledBythen I suggest renaming it toOwnedBy.)ActionStatecomponentTo ensure that an entity is even able to receive (and thus handle) a certain type of input, I would suggest that it has
ActionStateor similar added to it by the server. This could automatically replicateInputMarkeronto the client, requiring exactly the same amount of code but moving it to the server and making it more server-authoritative. Having anActionStateon an entity that can handle inputs as soon at it is spawned rather than waiting for a client to send their first input seems sensible to me, as well.I'm unsure how the different input systems'
ActionStatecomponents are handled, so I'm unsure how difficult this is to implement. I'm also realizing I'm not sure how this interacts with predicted entities and timelines.Alternatives
In this related discussion it was suggested that there should be a hook to manually verify incoming input messages. This could solve the problem, but it would require additional querying for entities that are already being queried anyway. It would also still leave Lightyear as being "client authoritative" by default when it comes to input, requiring extra work to validate.