Rewrite AAlsCharacter to UAlsComponent

[broly]

AAlsCharacter is very incovinient for prototyping. Composition is better than inheritance.

[Drakynfly]

While its true that composition is usually better, in this case there are distinct reasons for keeping most stuff in the Character class.

• Some overrides are only available on the character class.
• RPCs are slightly cheaper when going directly through actors, instead of routing through a components owner. (This is why CMC is bound to the character class like it is)

Some parts, like Mantling, would be nice to be a separate component, but as for entirely removing AAlsCharacter, I don't think it'd be possible or desirable.

[broly]

Some overrides are only available on the character class.

Yes, but

• Character can call owned component's function to pass required info (from overrides)
• Component can use delegates to call to character
  (Provide this possibility to user)

RPCs are slightly cheaper when going directly through actors, instead of routing through a components owner. (This is why CMC is bound to the character class like it is)

RPC in component is little more expensive, but UAlsComponent can provide setter of pointer-to-member-function of character (if set, character's RPC will be called and redirected to component)
As for replicated variables, I think there is same solution

So, Character can still exist in plugin, but code should be minimized to demonstrate how to set up component in character.
A lot of projects have own character and inheritance can be a really problematic. Giving possibility to manually setup component will simplify integration.

[watsonsong]

It seems the AlsCharacter_Actions.cpp is a good part to seperate into components. Rolling, Mantling and Ragdoll can divide into three different components.

[Sixze]

I agree, it would be nice to have everything in a component rather than an actor class, but as mentioned, there are some obstacles that prevent this.

For now, I only plan to integrate Gameplay Ability System and migrate all existing locomotion actions to it.

However, Epic is developing some interesting plugin that I think will get rid of the ACharacter class completely, but it looks like it won't be anytime soon.

[ghost]

https://github.com/oivio/GASCompanionDemoALS-3.1.0-5.1
Here someone has made a bridge connecting GAS Companion to your project, but in an older version. But it is clear that it would be better to integrate with pure GAS, so that anyone interested could use it :-)