refactor EntitySystem proxy into its own class, give proxy to BUIs

[deltanedas]

• replaced EntitySystem.Proxy.cs with abstract class EntManProxy, and moved RaiseLocalEvent etc to it as well
• this is inherited by EntitySystem and BoundUserInterface, you can now do TryComp and stuff in BUIs
• PlayerManager is also protected so systems can stop adding it as dependency
• anything in content can use it too with IoCManager.InjectDependencies(this); and it just works, as long as there is no other parent class. BUI and EntitySystem had no base class so it works for them

no breaking changes, BUI still has EntMan to get the entity manager so code doesnt need changing

[deltanedas]

unless this could cause performance issues somehow pls merge 🙏

[PJB3005]

Yeah I'm not a fan of this approach. If BUIs need to be able to access these, I think it would be better if BUIs somehow became a subtype of EntitySystem instead.

[deltanedas]

not just buis need this, things like entity effects are ugly because they cant use proxy

[PJB3005]

not just buis need this, things like entity effects are ugly because they cant use proxy

Aren't those also things that really should be entity systems instead?

[ElectroJr]

There's been a few other instances where I've wished that a non-system class had access to the same helper/proxy methods without having to re-write all of them. E.g., all the helper methods in ToolshedCommand.Entities.cs, integration tests, and S/CSI. But IMO making everything inherit from the same base class just to get them seems fishy and just doesn't feel right.

Making things systems wherever possible (or I guess in the case of toolshed commands, allowing systems to easily turn methods into commands) is probably a better approach, but wouldn't help with some cases, like integration tests.

Maybe a better approach would be some kinda source generator? So that you can take any class that has an entity manager field, make it partial, and auto-generate the proxy methods? That way you'd still only need to write them once, but you also wouldn't need everything to inherit from the same base class.

[deltanedas]

that would be ideal but:

• never made a source generator
• might bloat the engine assembly sizes?

[ElectroJr]

I'm not very familiar with source generators either, but there already are some in the project that could be a starting point if you want to learn (though I have no idea if they're good examples). E.g., ComponentNetworkGenerator.

might bloat the engine assembly sizes?

Again, not all that familiar with source generators, but I assume it'd just be equivalent to writing out the code, so it shouldn't bloat it? To be clear, it definitely shouldn't generate the methods for each and every system class, only the base system class and likewise for other types.

[PJB3005]

Yeah source gens would probably be the best choice here. Furthermore, since this would be a pretty simple generator, it should have completely negligible compiler performance impact.