What blocks TShock 5?

[hakusaro]

In one of many discussions with Wolfje, I pointed out that it would be worth developing TShock 5 along side Orion as fast as possible to get momentum going to answer questions like "what actually needs to be in Orion?" The general feedback I got was that development on TShock 5 shouldn't start until a lot of the underlying Orion structure is done, but this poses a problem: how do you develop a framework for a plugin with requirements that don't exist?

To start, I've created a label called "Blocks TShock 5," which should go on issues that completely block starting development on TShock 5. In other words, these are issues that, without being completed, we can't even have a stupid plugin that initializes and says "Hi I'm TShock 5" on Orion without it being completely useless.

Issues that fall under this scope are core, critical bits of functionality like commands, logging and how to properly setup and define an Orion plugin. I'm going to be making issues for things like this and continuing to ask for direction here.

Why? Right now, as a TShock developer who hasn't kept up with Orion development fully, it's still basically impossible for me to contribute useful code to the project because it's unclear what needs to be done and how the design works. I know how it works in an abstract sense but I can't with concrete 100% certainty say where I should start. I'd say this goes for anyone who hasn't submitted pull requests to Orion already. In other words, Orion development is limited to a very small subset of developers, all of which don't necessarily have all the free time in the world to keep development going during slow periods.

Some high level goals also get attached to this issue:

• Update the documentation so that new developers can start working on things without having to interview every Orion team developer to figure out how Orion works.
• Create small, bite size issues & stories with a clear focus so that new developers can start working on things faster. Don't leave people guessing as to what needs to be done: define it.
• Create a process guide on how to properly implement parts of Orion and how to create service definitions. Make a checklist for what needs to be modified, how tests work, etc.
• Provide clear examples of what goes in Orion and what doesn't. Make it stupid easy to determine if something should be in Orion or if it should be in a plugin.
• Document how to actually write a plugin for Orion. Yes, the documentation will change. Yes, the spec isn't complete. But it's pointless to have everything built months in advance and undocumented if it isn't going to change from now to release. If it's going to change from now to release, change it and document it. Make it so that Orion can "go live" sooner by having a nice, well defined, up to date set of documentation and examples to start writing your own plugins.
• Encourage development and answer questions. If you don't answer questions asked by people on issues, then Orion won't go anywhere. If question keeps getting repeated this is a sign that it needs to be documented on the wiki or in some other location.
• Give examples of best practices. If our end goal is to not have service implementations in Orion, service implementations shouldn't be in Orion. Full stop. Yes, it's convenient for development, but it does nothing to help clarify what's going on or what goes where. It's confusing.

If Orion never gets TShock 5 running on it, it will be a waste. If a we keep having to update the Terraria Server API because of new Terraria releases while Orion development crawls along, Orion is a waste.

Why am I making this issue? Because it's not clear to me, looking at the issue list and reading the current wiki, where I can even dive in and help. I've certainly asked a lot of questions and gotten a basic grasp, but I don't even know where to start. If I don't know where to start, then I doubt many other people outside of the core group here do.

Right now it's pretty clear that the people who can start working on fixing these problems are: @MarioE, @tylerjwatson, @WhiTexz, and @DeathCradle. These fundamental issues need to be resolved because if I start contributing right now, it's going to be the blind leading the blind.

[hakusaro]

@DeathCradle, @MarioE, @tylerjwatson, and @WhiTexz, your thoughts, opinions, critiques and general commentary on this essay are appreciated, as well as, if possible, some progress on the aforementioned goals, so that people like me, outside collaborators, looking in, can start helping push our little spaceship from TSAPI to Orion at a little bit faster than 0kph.

[tylerjwatson]

I'm not actually sure what you want. Is this a request for documentation? Its an open source project and I think this is completely unreasonable to expect this level of project management at this stage.

Its a culmination of how I would design a large scale application simply because nobody else was willing to contribute any sort of concrete direction, so I took the lead. I'm not going to repeat the service oriented software design from other people as its not new. It involves basic inversion of control and the design simply stipulates that it's better to interact with program components through interfaces that are handed to you rather than directly through dependencies you control yourself.

It doesn't stipulate how things are to be implemented. As far as I can go is the service architecture documentation which I've done my best in alresdy.

The reason for the 0kph momentum is that it's subject to the donation of time people have to invest into it as they don't get paid and have day jobs and lives. From the consensus in my discussions people aren't really that well versed in low level frameworks so they leave it up to people like Mario and myself to figure out so that people can build on top of it when it gets to the more Terraria related things.

You have to start somewhere, and we should worry about the slab before we worry about the building -- What I'm hearing is its now too hard to pick up; in which case it is better to start again with a plain architecture that is more newcomer friendly? I'm willing to step down if that's the case.

Failing that, read the source, I didn't think it was that hard.

[hakusaro]

The reason for the 0kph momentum is that it's subject to the donation of time people have to invest into it as they don't get paid and have day jobs and lives.

I have lots of time I want to donate to this project. A lot of time. Here's my biggest fear: spending a week implementing something and find out I've been doing it the entire wrong way. So...

Create small, bite size issues & stories with a clear focus so that new developers can start working on things faster. Don't leave people guessing as to what needs to be done: define it.

This is the most important thing, because it gives me something I can sink my teeth into, start working, and see where the train tracks go in the future. If I botch implementation of something tiny, it won't phase me at all! I just want to know I'm screwing up something tiny, that's needed, because it provides a good example for how to not do something or how to do it.

I'm basically an unemployed student who wants to have a lot of fun making some software, I just don't want to waste my time on something silly. That's all!

So, actionable thing time: could you make 1-3, small, bite sized issues that have a pattern as to what they are, so I can start working on them? We talked a lot about the hypothetical player teleport method: is this a good example of "the smallest possible unit of work" so that I could maybe run through the process and see if it works? I can start pushing for more of these to be added too.

Wolfje, you're my senpai ✨ , and I don't want to scare you off. In many ways, for me, this is much more about learning how to properly do software development at this scale right than it is actually providing a shippable product. At least for now.

[hakusaro]

I'm actually quite fond of having you mentor me in how to not write static shock again Wolfje, so consider this more like a love story about wanting to help you push this forward in any way I can. I can start checking off my own list if I have an idea of what's actionable.

[tylerjwatson]

Maybe a webcast Style thing would be a cool idea where people can ask questions in real time and we can figure out how to document this stuff together in a format that is understandable and get rid of some of the silo? I have no problem talking through it

[hakusaro]

@tylerjwatson I like that idea a lot. We could record + transcribe it so that we're not stuck in the same circles repeating things over and over too. Would probably solve a lot of problems at once.