Merge TShockAPI and TerrariaServer-API

[AxeelAnder]

Reasons:

• There's no demands on running tsapi alone
• TShockAPI clearly is different from normal plugins, its order should be pulled up
• It makes plugin development and server maintenance easier

[hakusaro]

I'm personally mixed on this. I would honestly rather make all of the "API things" that TShock does separate from TShock. We provide a lot of hooks and things that really should be in TSAPI but aren't. The fact that TShockAPI is called TShockAPI is because it was originally to distinguish between TShock (not on the Terraria Server API) and TShock (on the TSAPI). We just never really changed the DLL name because once you have it installed, if you were to drag TShock.dll into the folder you'd have two TShocks running.

[hakusaro]

I would take either. I view TShock as primarily a system of nice to have commands with a whole bunch of misfit API features that shouldn't live inside it but really need to be in a different component. The "features" that TShock provides out of the box that a user actually benefits from should be what people know as "TShock."

Maybe we could call them different things?

1. TShock Foundation (replaces TSAPI, all game related hooks and APIs)
2. TShock Plugin Helpers (non-game related APIs, like perms, commands, hooks related to internal items)
3. TShock Omakase (actual implementation details of commands, item bans, bans, MOTD, etc)

In the Orion world, Orion is the first and second thing on this list.

[AxeelAnder]

The "Plugin Helpers" sounds really weird and Omakase lol.
My true purpose of this discussion is to get the future direction of this project, as I have enough passion to push it forward now but without an roadmap.

[hakusaro]

To be perfectly honest, I think that a roadmap is really something that we don't have because we have two real conflicting things:

1. 1.4 will drop in < a week and that's going to mandate patching and updating and all that.
2. Realistically speaking people have finite time and motivation to work on this codebase.

The dream is Orion. @kevzhao2 has a lot of plans for Orion that make sense but we haven't been able to get to a point where we can can muster the strength to pull through a full codebase rewrite or division of work. I'm personally restarting small with #1595 and getting that ready for review and working through a bit of the codebase that bothers me. I personally think it's easier to slowly refactor things into pieces that make sense so that moving them around is easier. Right now, for example, you can't really just take out item bans without ripping apart all of the code. I want to change that so that every component is isolated. Not saying OOP yet, but at least isolated. We can go full OOP and perfection after we get to the point where you can say "ah yes, that's the antihack system and that's the ban system and that's the anticheat system" etc.

If your preference is to combine TShock and TSAPI so that they're the same thing as a temporary jumping off point, I'm actually inclined to agree with you, as long as the resulting spaghetti comes out with the feature stuff on top.

[AxeelAnder]

I'm not really want to mix them up, in fact my point is same with you, we need smooth transitions now other than complete reboot. But including tsapi in tshock repo as a submodule is a pain to me, it makes many things complicated and ungraceful. If there's a clear blueprint indicating better project architecture, I can work with it step by step.

[hakusaro]

So on submodules, you could try: git config push.recurseSubmodules on-demand and git config submodule.recurse true. This basically automates getting the submodules in place and lets you commit inside the submodule and push it at the same time. Newer versions of git on the command line rock: https://git-scm.com/book/en/v2/Git-Tools-Submodules

Edit: may want to use --global with those

[AxeelAnder]

Back to this topic again. More precisely, my plan is converting tsapi and tshockapi to .netstandard libs, then create a launcher to start the server, the launcher using two libs. With this we can have these merits:

• Able to publish a single file self contained binary
• Plugins can just target to .netstd rather than .netfx and .netcore
• Easy to build tshockapi, it has a lot references thus the copying process are complicated and the plugin directory will be in mess, if it's no more a plugin that can be avoided.
• It may makes tshock refactoring easier

[bartico6]

Compromise: Keep the projects separate, but ILRepack the binaries into one during compilation/deployment.