Discussion: Current State of Orion about orion-core HOT 10 CLOSED

One main question I have is whether to continue sticking stuff like IAccountService, ICommandService, IRestService, etc. in Orion. @tylerjwatson @Ijwu @hakusaro @QuiCM @AxisKriel

Shouldn't this now be TShock's job? Why do we need these definitions in Orion now?

from orion-core.

Agreed - account and user management services fall outside the scope of Orion. I believe account/rest/command were originally included so that any tshock alternatives would have base services out of the box that they could use and override/extend if necessary, rather than having to create the entirety of those services themselves

from orion-core.

Agreed - account and user management services fall outside the scope of Orion. I believe account/rest/command were originally included so that any tshock alternatives would have base services out of the box that they could use and override/extend if necessary, rather than having to create the entirety of those services themselves

I see. To be honest, I'm not sure there's any point in doing that any more. If TShock alternatives would like to override them, then they probably wanted an entirely different mechanism. I think extensions are possible as long as we provide events for these services.

from orion-core.

For example, as long as the command service provides an ExecutingCommand event, then a permission service could hook that and handle the event if the user is determined to not have the required permissions.

from orion-core.

Yep. Sounds reasonable

from orion-core.

For the most part, abstracting for "TShock Alternatives" that don't exist yet it is not a good use of anyone's time. In fact, dare I say that most abstraction that's done before the existence or need of alternatives is not a good plan.

I believe the goal should be to be like Bukkit + CraftBukkit. While an abstract API exists, it at least has one shipping implementation that someone would want to use. That means that we shouldn't create a ton of interfaces with prototype implementations that nobody actually would actually use. I would even go so far as to say that this is part of the problem with the project in general. It is certainly advantageous to create interfaces for the purposes of mocking BS from Terraria and testing, but it is also a very big problem to only create interfaces with no concrete implementation and then to call it a day.

from orion-core.

Yeah, I definitely agree. There's a trade-off between time and "programming pureness". In this case, all of the current (reboot) definitions have real implementations, and most of them (barring the network service, which is a pretty painful thing to write tests for, since Terraria network functionality is basically untestable) have tests.

Stuff like logging, which we were thinking of whipping our own solution for, has already been solved countless times by other people. There's no point in re-creating what Serilog can do, for example. There's also no point in trying to pass ILoggers and everything around.

from orion-core.

IAgree.

from orion-core.

While I'm not certain if that is "in plans" or not, I would like to repeat that tShock and its ecosystem should move away from nethooks & nethook usage should be strictly discouraged unless you know what you're doing and you need to mess with netcode directly.

This is because things ideally would be using events, even if they're naive wrappers around nethooks, since in many cases it would be convenient to have events (that other plugins can raise) rather than nethooks and nothing else.

A case study of this is an anticheat I have developed & tested in the past N months - every single check (which is based on packets received) is delayed until more data is available and then those events would be either validated & pushed through or rejected and rolled back. However, for events that pass through at a later date, notifying other plugins (including tshock) is completely impossible because without creating a new message buffer, pushing data into it and running checkbytes or whatever on it you cannot manually fire hooks in other plugins.

from orion-core.

Yep, that makes sense. I think Orion should expose events for actually everything, tbh. It should expose block breaking, player teleporting, etc.

from orion-core.