Author Topic: Multiple Add-On Hosting Services / Mod Managers  (Read 4562 times)

It's tempting to make a chat server out of websockets, but I'm not exactly sure how well Blockland would handle it.
Could you just use a TCP connection object?

Could also just use IRC, but I dunno.

...y'know actually we could make the whole thing dynamic if we went that route, hmm

I've made blockland chat systems before, way back years ago. It's not all that complicated. DC4F/Nullable and I used a Java server I believe, though something more lightweight would probably be ideal. Node.js or Python probably.

Basically, my thinking with BLG is that when I finish the features I'm working on, I'll move on to another one that I feel the community needs, assuming nobody else is working on it. I'm not here for competition, but I'm not afraid to move forward. Add-on hosting is only the beginning. In the past, I've announced too many features at once, and that's led to the project failing, which is why I haven't made any large commitments outside of add-on hosting yet. If someone else comes along and starts to develop, that's fantastic, I'll work with them and try to integrate things where they make sense.

I'm with you that splitting up might be a bother as you wont have that much control on it, and it could also halt production. However, most big project that contains many people usually split up the work between them and try to keep specific tasks to specialized workers. Even BRV have split up into several positions to easier make each part without having to bother that much about each other. It might delay the project, but it wont slow it down to a halt if everyone is up to it. And even if it would, then someone else can go in and take over the part that is missing.

If we do this in a smart way, we first try to design the API or solve any communication between each system, limiting any delays that may occur. Later on there might come up problems, but as long as we're all working against wrappers, our internal system will work the same nonetheless. You don't need live data to be able to figure out if a system works correctly. However, you may need it in the final stages to find eventual bugs.

I think splitting up work could work just fine as long there is frequent communication between the developers.

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 disagree. In my opinion you should first be working with the low level background stuff before moving on to higher level things like user interface.

I agree with that, but if you have somebody dedicated to doing high-level stuff, they're probably going to spend a lot of time waiting around. Even low-end stuff could be waiting for other low-end stuff.

I wasn't saying that you should do an another split of the project by dividing that far. However, if such happens, either that person needs to look for new tasks to finish, or the communication is really bad. Each programmer works differently. Some works from the ground up, while others works from top down. It's even common that mixing those two by doing a tiny line for a first start that expands from the underlaying service to the client code, and then expand the features from there to the sides.

I am back in town so I will try to arrange something in the next few days. I still need to hear from Honno/Zeblote.

I am back in town so I will try to arrange something in the next few days. I still need to hear from Honno/Zeblote.

Zeblote left the project. I'll listen to the call before I decide anything.

A bunch of IRL stuff popped up recently and I haven't had time for this. Is anybody else willing to organize?

Such unfortunate. I could take care of it, but it's better if it could be someone that is not biased toward anyone of us.

Please, send me your information by PM. I am fine to do either Steam, Skype, Teamspeak or Mumble. Either of them can be in text or by voice. I'll send you who send me information where we're going to meet, depending on all those that send.

Disclaimer: It does only matter those that is working on at least one of these projects mentioned in the first post.