Why inherit from actor?

[brifsttar]

Hi,

First of all, thanks for this plugin, it works perfectly fine and has been very useful for us.

I'm just wondering why you chose to inherit from AActor instead of UActorComponent (or USceneComponent)? For my point of view, it's much more modular to have such features as components, that way you can have multiple TCP connection per actor, or add such components to custom classes which can't inherit from ATcpSocketConnection (e.g. controllers). You could also make a proxy actor that would have the same interface as the existing ATcpSocketConnection, but would forward everything to its TCP component.

Anyway, I think I'll try to do that, but I'm wondering if a) there's a good reason against it that I didn't see and b) you'd be interested in a PR once that's done.

Bertrand

[CodeSpartan]

Hey,

I haven't worked with UE4 in many years, so I don't know if I had any reasons to make it an Actor. Probably for the simplicity of just throwing an Actor into the scene. I don't think the conceptual difference between an Actor and an ActorComponent or SceneComponent is significant enough on its own to introduce the change, because I don't want to introduce breaking changes to existing projects for very little benefit. It's already hard enough to keep projects up to date with UE versions without plugins breaking down on you.

However, a point has been brought up a few times that making an Actor survive the transition between Levels is difficult. I wonder if making it an ActorComponent and attaching it to an Actor that survives the transition, such as PlayerState, would make the connection survive as well? (I'm writing this purely speculatively, as I don't remember what actors survive a level transition, if any. It's been a long time.)
If ActorComponents have an easier time surviving level transitions, then it'd be something interesting. But again, would probably break all existing projects and require them a lot of refactoring? I don't suppose there's a way to make it both Actor and ActorComponent without almost total code duplication?

[brifsttar]

Hi,

Thanks for you quick answer.

However, a point has been brought up a few times that making an Actor survive the transition between Levels is difficult

I don't think switching from Actor to Component would solve that issue. AFAIK, only the Game Instance (and associated subsystems) are persistent between levels, and those don't accept components (as they aren't actors).

But again, would probably break all existing projects and require them a lot of refactoring? I don't suppose there's a way to make it both Actor and ActorComponent without almost total code duplication?

That's why I suggested keeping the ATcpSocketConnection with its existing interface, but changing the implementation to instead rely on a component that actually has the features (with more or less the same interface). That way, all existing implementation using the actor should still work, but the TCP features would also be available as a component.

However, if we actually want to solve the lifetime issue, it would be a bit more complex than that; because as mentioned above, neither actor nor component can survive level transition. An idea could be to move the TCP features to a game instance (or engine) subsystem, and have both the TCP actor and component using the underlying TCP subsystem. That way, users could choose between actors (traditional), components (modular) or subsystem (persistent) to do their TCP communication.

But that would add way too much complexity to a plugin that shines by being simple and just working. So I think neither this nor the "proxy actor with TCP component" are great ideas. I'll go ahead with the component change on my fork, but I won't make a PR for it, as it'll bring changes that don't actually fix the most common user issue (lifetime).

Thanks again for your answer and your work.