Jump to content

Changes to mangos one


Auntie Mangos
 Share

Recommended Posts

  • 41 years later...

The intention is to provide one spot for the user to go to in case he/she is looking for code, help, etc. We're not trying to fork scripting or database development, we're just trying to bundle that since it seems to trouble many users where to find that stuff.

We're trying to make the project a little more usable, and accessible.

Link to comment
Share on other sites

The intention is to provide one spot for the user to go to in case he/she is looking for code, help, etc. We're not trying to fork scripting or database development, we're just trying to bundle that since it seems to trouble many users where to find that stuff.

We're trying to make the project a little more usable, and accessible.

So basicly all work from TBC-DB and ScriptDev will just be merged into the repos?

EDIT: What about applying the "MaNGOS One Patch" to the repo by default so people doesnt have to do it themselves? (I dont use SD but anyways)

- LilleCarl

Link to comment
Share on other sites

This is at least what I have in mind..

but there are in my opinion two problems:

- I don't like the name scriptdev1, this just doesn't fit

- Someone would be needed who volunteers to do the main backporting job (not that it will be much); a few exclusive things should be done for sd2-tbc, and I am not interested in doing them.

Edit: I already opened a new topic to lookout for volunteers: http://www.scriptdev2.com/showthread.php?p=38304#post38304

Link to comment
Share on other sites

I don't think that it is a bad idea of having the different parts splitted actually.

It might prevent n00bs from using mangos(et al), but on the sun side I feel that it helps focusing on the problems, and not always have to deal with everything else.

Especially I cannot see how it should be reasonable to bring the main database providers (udb, ytdb, psdb) in one place without having their databases merged; and I cannot see how this could work actually.

Link to comment
Share on other sites

Agreed. In "Merging" I mean this by where the forums are located. To Co-Locate the forums for the Core and DB in one location would be a move in the right direction (In my opinion).

The Luda brings a good point... The questions is right now "Where" the work should continue and move forward from this point.

The Original theory was that we were to keep the 3 distinct parts of the community separate (Core/DB/Scripting) for various reasons I will not go into. But as has been seen with other projects there appears to be no problems with having all projects/sections co-located.

With the community getting smaller overall, it makes sense to bring the smaller groups all together into one larger community.

Link to comment
Share on other sites

100% agreed with X-Savior. In my early days of being a seed (a newbie if you must...), I really didnt know where to start actually. Compiled it without sd2 and without proper database. The result was obviously a disaster... Having everything in one place would ease up the access to the whole project and gather the community in one place instead of three or even more. Also, a special forum branch for custom forks of mangos would be really appreciated. For example Mangosr2.

Link to comment
Share on other sites

Bringing the core elements of MaNGOS into one community would be a marvelous idea and indeed make that first step for newbies simpler. They would be able to easily see that there are three parts to creating a more complete server, rather than making the mistake of picking up a database or scripts that are incompatible, if they even knew that much.

It can be a lot to digest just learning enough of Git, diff-merge, and compilers to create your first server. Anything that simplifies how you can get the information you need is a good thing.

Custom repos can look after themselves. If they have code to contribute, then it can be done through the usual channels. I don't see how R2 or any other independent groups having their own forum section could add anything more to the community. It would benefit them tremendously, of course, by giving them a tacit endorsement in having their presence here in this project. However, these custom core groups obviously possess differing views on what constitutes "proper" development. Otherwise, they'd be on board with Vladimir and the rest of the core dev team.

I'd rather not see another situation develop like the one that lead to the birth of Trinity.

Link to comment
Share on other sites

Also, a special forum branch for custom forks of mangos would be really appreciated. For example Mangosr2.

I disagree;

We introduced at SD2 forums a sub-forum for development related to special core patches (ie vehicles), and no one ever cared to post there - so I doubt this will actually work.

The sad truth is, that most ppl are just leeching and not care about developing (or even reasonable bug-reporting / feedback) at all. And especially such ppl would even faster switch to custom forks as this r2 branch than now (without _anyone_ profiting from this)

Link to comment
Share on other sites

Another valid point, Schmooz. However, in counter to that and my own opinion above, I'd like to propose looking toward the positive aspects of aggregating the community, assuming there are enough of those in the UDB and SD2 communities that also support such a move.

So what do the rest of you see being the benefits of bringing the three major components of the MaNGOS scene together under one roof?

Link to comment
Share on other sites

In my opinion, everything should be under one roof. Quite easier to report non-working stuff cuz if a newbie posts sd2 error, we can simply move the topic to sd2 space. Also, assigning the leading devs at each of the component sections as mods would improve relationships and keep the forums clean.

I myself would stick with mangos even if it didnt had sd2 or database. But this is a learning project, why not learn complex system management in the same time ?

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Privacy Policy Terms of Use