refactor(player): factor out LocalPlayerControlSystem

[antag99]

Contains

LocalPlayerControlSystem now handles input events, LocalPlayerSystem still handles sending character movement events. Current motion control state is stored in a component (LocalPlayerControlComponent).

Introduces a tag component (LocalPlayerComponent) for the local player, along with a DoNotPersist annotation to ensure the component only lasts for the current session.

Both LocalPlayerSystem and LocalPlayerControlSystem use the tag component to find the local player. I think this is easier and less error-prone than having a LocalPlayer object that may or may not be in the correct state. The tag component can also be used for filtering events.

Draft, input needed before further work is done.

Tested locally but not with local multiplayer server.

How to test

Not yet.

[keturn]

As someone who just started familiarizing themselves with how movement inputs work the other day, this Sounds Good To Me.

But I have neither the experience with the ECS system nor the familiarity with how far-reaching changes to the LocalPlayerSystem would be to able to give much more intelligent feedback than that.

[antag99]

There are some points with regards to this draft that needs to be considered,

• Is it good to have components on the local player that live as long as the in-game-session, facilated via a DoNotPersist annotation?
• Is it good to have a tag component for the local player?
• Is it good to factor out input handling in LocalPlayerSystem?

If the answer to these are yes, then the general idea in this draft is good. However these are three different things that would really have to be done in separare pull requests, and the implementation of the DoNotPersist annotation as well as the adding of the tag component for the local player would need a bit of cleanup.

[DarkWeird]

@antag99
Sorry for long waiting

Is it good to have a tag component for the local player?
Yeah. it is ECS.
Tag components it is normal (also prefer tag components then using component with boolean)

Is it good to factor out input handling in LocalPlayerSystem?
Decoupled systems - that nice too.

Is it good to have components on the local player that live as long as the in-game-session, facilated via a DoNotPersist annotation?

Components can have any life time. (one tick, or infinity via persistance)

I updated code, a bit choring annotations and some idea issues.

And then detects that player cannot moves in multiplayer.
Are you check this at multiplayer?

[antag99]

@antag99
Sorry for long waiting

Thanks for taking a look!

I updated code, a bit choring annotations and some idea issues.

And then detects that player cannot moves in multiplayer.
Are you check this at multiplayer?

No, I have not tested the patch on multiplayer if i remember correctly. I do not have the time to work on this for the time being, so I will close this PR and open a new one if I get back to working on it. I remember the most tricky part was to get the tag component added whenever the local player appeared, and I think there may be a lot of work (and testing) to get this done properly.