Multiple Add-On Hosting Services / Mod Managers

[Greek2me]

For years the only place to host mods was RTB, and all was well. Then RTB died and there was nothing. Now there's three different services (in varying stages of completion):

https://github.com/BlocklandGlass/BlocklandGlass (BLG)
https://github.com/LiquidProcessor/Blockland-Revised (BRV)
https://github.com/McTwist/Blockland-Repository (BLR)

I think it's great that there's competition - it should keep things innovative. However, we need to figure out how these services are going to work together. This will make things simpler for both add-on developers and users.

There's already a bit of collaboration on add-on updates. Both Blockland Glass and Blockland Repository use Support_Updater to provide updates, ensuring that there aren't any conflicts and reducing user confusion. Blockland Revised is considering doing the same.

How else can they work together? One idea I had is that they can all create a common in-game mod manager, which would allow people to choose what source to get their add-ons from. Lower overall development cost and less potential for conflicts.

I want to see these all succeed. What ideas do you have to make that happen?

[Ad Bot]

[Scout31]

I agree that it's a problem. Each team/project is perfectly qualified, and while competition is positive, we either need to have defined differences so that we're not all just clones of eachother, or work together.

[TheBlackParrot]

I personally think there should just be 1 repository, and every addon manager just pulls from this repository. You'd just upload your addon via BLG, BRV, BLR, etc. and it would be pushed out to the other 2 managers hassle-free.

Of course that would stifle competition, shoot.

[TristanLuigi]

I personally think there should just be 1 repository, and every addon manager just pulls from this repository. You'd just upload your addon via BLG, BRV, BLR, etc. and it would be pushed out to the other 2 managers hassle-free.

Of course that would stifle competition, shoot.

no, the competition would just be in design rather than add-ons

this is an extremely good idea. PLEASE do this

[Scout31]

I personally think there should just be 1 repository, and every addon manager just pulls from this repository. You'd just upload your addon via BLG, BRV, BLR, etc. and it would be pushed out to the other 2 managers hassle-free.

Of course that would stifle competition, shoot.

I think that would work out.

Add-Ons uploaded to one may not have full features on the others, but they certainly could still be listed, for the user's sake. The hosting service will be the developer's choice for their feature suite, and the users can pick which add-on that has the features they want.

Competition would be maximized, the community would have the most choice, but there wouldn't be clash of user base.

I think we should plan some sort of summit to bring together the three projects' heads to discuss these things in real time, either voice or text. Greek2Me could be the head of it, since he seems to be the middle man of all.

[Greek2me]

I can organize a group call after next week.

I like the idea of having the systems share add-ons. Upload it to one service and the other services would host it as well.

[Alkatjo]

I personally think there should just be 1 repository

1 is all you need, not 2, not 3, but 1 reliable host.

[mctwist]

From the very beginning when I figured out BLR, I had several things in mind, which included, but was not limited to:

• Make use of other add-ons by only providing server source
• Collaborate with other servers, either directly through the hosts, or indirectly by the users linking to other servers. This includes the ability to find the closest host available and balance server usage
• Make it easy to release an add-on: Just upload the package and the system will fill in what the add-on have already and what it needs
• Don't limit the users by delaying release due to validation, that is up to the community to decide

However, for now it will only provide a way to host add-ons.

As I'm mostly for technical solutions, it would be great to have more people in the project that could provide designs.

[Greek2me]

So McTwist and Scout, you'd both be onboard with BLG and BLR? Good, that's 2/3.

It would be good to hear from one of the BRV people. I'll be unavailable until next weekend at least but it would help if you guys send me your contact info in a PM. (Steam/Skype)

[TristanLuigi]

So McTwist and Scout, you'd both be onboard with BLG and BLR? Good, that's 2/3.

It would be good to hear from one of the BRV people. I'll be unavailable until next weekend at least but it would help if you guys send me your contact info in a PM. (Steam/Skype)

I've got Misha/Honno on Steam, I could ask about it.

[TheBlackParrot]

If we can get all 3 on board, I'll jump in and help.

[Zeblote]

I don't think having multiple hosting services around makes any sense at all, it will only confuse the user and waste time developing all features twice.
A year ago, if you needed add-ons it was obvious you'd go to RTB. It should be like that again in the future.

It looks like BLG is good on track, so I would consider dropping the brv project all together (I haven't spent nearly as much time on it as Jincux on his)

[Ipquarx]

• Don't limit the users by delaying release due to validation, that is up to the community to decide

This is exactly what caused the master server spam a couple weeks ago
an exploit went unnoticed for probably over a year and then was heavily abused

[mctwist]

This is exactly what caused the master server spam a couple weeks ago
an exploit went unnoticed for probably over a year and then was heavily abused

This is something that cannot be fixed easily. Even by restricting the users to such extent will only trouble them even more. It's like putting a DRM on a game because it makes it harder to copy it. Users still find ways around to give out their add-ons. Users will still download any add-on, as long as it sounds appealing, without thinking if it contains an exploit or not.

However, thank you for bringing it up as that got me thinking even more on this issue. I've had something in mind to prevent people to abuse the system, and I'm still trying to figure out how to allow anyone to still upload freely, but limit the access to that uploaded add-on. Both relying on a fully automated system or a group of reviewers is flawed and is not a solution, but could be a tool to help out. The more power to the community, the lesser the chance of these exploits will be raised.
That's why I wont bother that much about restricting distributions of add-ons. It's a bit of a naive thinking, but I can't bother thinking about that in first hand as that isn't my goal with this project right now.

I can also mention that my code is fully open source, so anyone can modify to add such a feature if they think it's of utter importance.

On-topic
I don't mind a collaboration. Either through automatic sharing of add-ons, or merging of functionality. Rather, if possible, I'd suggest that each one of us to work on a specific part of each system. Hosting(E.g. web, backend, chat server); Mod manager; Community functionalities(E.g. chat client, prefs). This way a huge projects will be split up in separate pieces, making it smaller and more specific people can work with each piece without having to bother about the other one(For the most part).

[Scout31]

I think a problem with splitting up so much functionality is that development is greatly slowed. If you're making the chat client, you gotta wait for the chat server to develop, or visa versa. I think one of my biggest advantages with Glass is that I have the API code open on half my screen and the client script open on the other half.

Long-term for glass, I'm pretty sure that the next feature I'm going to tackle is a save gallery/cloud saving system. It's the next logical step from add-ons. I'm also planning on bringing back in my features from the BLG I developed around 3 years ago. I'd love to collaborate and bring other developers on-board for Glass, but splitting up functionality so far that we each have a dedicated "system" seems like it would slow production.