4.0.3 server is live *.*

[Lynx3d]

I guess this was also in response to the "our company creates sloppy code" argument from before...just because one company produces shitty code doesn't mean all do or that we should follow them.

And since we are no company, you should understand that we neither are bound to create "production quality" code nor have "industry leading feature portfolio"...

Anyway, Kich0 already told the primary goal, and IMHO other projects of all kinds have sufficiently proven that stuff can easily fall apart if you accept any half-baked solution, for reasons already mentioned too...

[Patman128]

Now if you excuse me, I'm off to conduct Phase I of a double-blind, randomized, multi-million-dollar clinical trial of my Saturday breakfast. This is how BIG Pharma gets things done, and I'll be damned if I'll ever be forced to adopt a lesser standard.

Maybe you aren't doing the testing, but your food is being tested somewhere by someone and approved. End users aren't expected to have to test mangos thorough; the developers and patch writers are, and when the patch is crap, it gets rejected, like a load of corn flakes tainted with arsenic.

[b482519]

Maybe you aren't doing the testing, but your food is being tested somewhere by someone and approved. End users aren't expected to have to test mangos thorough; the developers and patch writers are, and when the patch is crap, it gets rejected, like a load of corn flakes tainted with arsenic.

Thank you for speaking your mind and finally having the guts to compare inexperienced volunteer patch writers to insidious poisoners. These malevolent a-holes gotta be shot in sight, if you ask me.

[Patman128]

Maybe you aren't doing the testing, but your food is being tested somewhere by someone and approved. End users aren't expected to have to test mangos thorough; the developers and patch writers are, and when the patch is crap, it gets rejected, like a load of corn flakes tainted with arsenic.

Thank you for speaking your mind and finally having the guts to compare inexperienced volunteer patch writers to insidious poisoners. These malevolent a-holes gotta be shot in sight, if you ask me.

No, sometimes food doesn't get tested and bad things get in. People get hurt. That's what happens when you don't test anything. Your stupid analogy < my refutation.

I'm done. And your sarcasm just makes you look like an asshole. If you want to shoot people, I recommend you start with yourself.

</trollbait>

ON FREAKING TOPIC:

I think a better patch testing environment needs to be created here. Patch authors should provide clear instructions on what to check to see if their patch works (as well as examples). An index of users on here that operate test servers would be nice as well as it allows patch authors to easily contact them (though the downside: maybe operators don't want spam from patch authors. )

A centralized "patch manager" for downloading/installing patches for mangos would be nice too (though obviously some conflicts can't be resolved automatically.) It would at least make it easier for less experienced users to help. There are tons of posts for "how to install patch" so at least it would make that easier (as well as make tracking what you have installed much, much simpler)

[Nick Taylor]

Wasn't third party patch integration part of the goal of TrinityCore when those people split off from MaNGOS along with integrated scripting and database? Just curious if anyone with any experience with that has a point of view, could be an interesting example of how to properly manage this sort of issue.

MaNGOS is also an open-source project, in which the code is supposed to be provided, improved upon and bug-tested by the community. The example that there exists safeguards in other systems for quality assurance, is somewhat irrelevant as they have the resources and manpower to properly implement the infrastructure to be able to do this on their own, MaNGOS does not.

A solution could be to get some trusted community members (or release it to the public, does not really matter), and create a development branch with the most viable patches implemented, such as vehicles and MoveMaps, and let them run loose. This would be a more controlled and centralised version of the classic open-source model. As these patches reach a point where the are reasonably stable, and cause an acceptable amount of issues with MaNGOS (such as slight lag, or making the server crash if it is run for some absurdly long amount of time), and be put into the master branch, where the classical open-source model takes over, and people come back and report issues that can only be discovered with thousands of people testing.

[qsa]

A solution could be to get some trusted community members (or release it to the public, does not really matter), and create a development branch with the most viable patches implemented, such as vehicles and MoveMaps, and let them run loose....

If the authors of those patches we talk about, was not comfortable enough adding them into "under review" section (aka: marking them as ready). I find it really arrogant of people who had very little to none input, claim otherwise (aka: add them NOW!11).

Correct me if I'm wrong on this one, but all the patches people whine about aren't anywhere near "under review" section.

There's phrase fits this perfectly : Everybody want to go to haven, but nobody want to die.

PS: sorry for quoting you Nick, its nothing personal, it just emphasizes my point better.

EDIT: As for so called "tester community" - I can count the number of people who actually properly report bugs in patches on the fingers of my two hands.

Most are just using them with no freedback. Just take a look at some threads we have now, where people practically have to beg to get some feedback (see relocation, thread packets, etc).

Funny enough, as a rule of thumb, those who complain are never those who do the testing/reporting.

There are always exceptions, but I'm talking about general.

On same occasion, I would like to say thanks to all the guys and gals to whom the above do not apply. Keep up the good job!

[VladimirMangos]

mangos different from normal open source projects. Many points already has been provided lot times in years. Oh... ok. But can be repeated.

What we have in normal open sources projects: some final release that have at some point complete set features.

So most users happy with release until next release ready. They mostly ignore development branches. This is possible because features selected by project team.

What we have in mangos. It's _always_ in beta state without some complete set features. Features list set _not_ mangos team. And users look at this known features set also. In result any developement branch better from user point any previouse release because have more _expected_ features. So creating any special _public_ development branch will just meaning all will use it and ignore release btanch. So what reason in diff branches? Mangos team _have_ development branches in your meaning for really deep changes req. for next version support. 400 branch is good example. For less deep changes as i point above have branch just useless lost team time.

[b482519]

If the authors of those patches we talk about, was not comfortable enough adding them into "under review" section (aka: marking them as ready). I find it really arrogant of people who had very little to none input, claim otherwise (aka: add them NOW!11).

Correct me if I'm wrong on this one, but all the patches people whine about aren't anywhere near "under review" section.

Correct me if I'm wrong, but it seems hard to be excited about being an active contributor when you see something like that vellum patch that was submitted for review back in May of 2009, with nearly each of the posts that date back to November 2009 saying that the patch works fine and questioning why it is being ignored by the development team. That place is a programmer's version of limbo, and one can only wonder how many contributors didn't even bother submitting their second patch after seeing what happened (or rather didn't happen) to their first one. Whatever project's goal and standards are, I think that by allowing the patch submissions to rot there nearly indefinitely, the developers are only shooting themselves in the foot. You can't expect any serious cooperation with this kind of indifferent approach.

[qsa]

I know I shouldn't reply to this one, but I just can't resist. Forgive me.

Tell me b482519, are you speaking from personal experience?

You must be one of those folks, who after years of contributing to this project, still do not see any of his hard labor rewarded. Must be so frustrating.

Wonder no more, the only two thing prevents people from submitting their patches is laziness and oversize ego.

You are right about one thing, its hard to be exited by actually contributing something.

Trolling on the other hand, is much much better. After all, its so lonely under the bridge.

Cheers, you made me smile.

[b482519]

Tell me b482519, are you speaking from personal experience?

As a matter of fact, I am. Not that your lack of knowledge about me and my contributions to this and other branches of this project should be considered relevant to any factual impersonal claims about the quality of the project as a whole.

Listen, the way I see it, we can approach this in two ways.

One way is the way things seem to be going now. Aside from unsubstantiated ad hominem, it all basically comes down to saying "if you don't like the way we do things in our project, go away" — or, depending on the sophistication of the speaker, "go shoot yourself". Naturally, if you want to be childish, vindictive, and suppressive of criticism, this whole discussion is already pointless.

The second way is to discuss these things using a more objective and reality-based approach. And we can argue all we want, but the indisputable fact of the matter is simple: the official version of the server evolves significantly much faster than its open-source counterpart. If this project wants to persist, it seems that you don't have much choice here but to take a good critical look at your policies and development pipeline and concede that you need a better and faster way of doing things and that maintaining status quo may not be such a great idea after all.

Now, I've seen some of your silly sounding posts that claim that Cataclysm is "just stupid", "now it's all about the money", "They totally forgot about the Lore", "They RUINED WoW! THANK GOD I HAVE MaNGOS to rely on!!!!!!", etc. If that's what you choose to believe, fine. As I said, if you find that type of self-aggrandizing, self-deceptive reasoning comforting, it's probably better to stop discussing these things altogether. If not, then you have to stand before the fact that the latest expansion not only added a thousands of additional components like zones, mobs, quests, spells, events, and encounters, but it made thousands of changes and improvements to the previously existing content as well. And when it comes to the server mechanics, that "more of the same" claim is also not right. The new content is ridden with unique elements. As one example, instead of previously nearly ubiquitous "classic" quests like "go to zone X, kill 20 mindlessly roaming mobs", nearly every single quest chain now has at least one quest that features unique or advanced quest mechanics like vehicles, scripted NPCs, phasing, cinematics, or unrepeatable spells. That's quite a lot.

In contrast, the holy trinity of Mangos, SD2, and UDB is still missing most of the advanced stuff from the original game and its first two expansions. Features like vehicles, phasing, pathfinding, object interactivity, outdoor PvP, advanced NPC interactions (formation movement, dialogues, etc), and even some of most basic encounters in such ancient zones as ZF or AQ20 need to either be improved or written from scratch. After 5 years in development, the main repository still doesn't have full script and spell support for some of the most well-known vanilla encounters. Cataclysm shipped with 6 new dungeons and 4 new raids. While the key Mangos developers are still figuring out a way to update to 4.0, the upcoming 4.1 patch will add yet another raid and another dungeon to this ever growing list. When and if Mangos finally switches to 4.x.x, it will probably take the developers years to implement one half of Cataclysm's content. By that time Blizz will release another 5 or 6 major patches, possibly even another expansion or two. Should then the developers afford to examine a gift horse's mouth with a microscope?

Not in my view. I have experience in programming and I have a general idea of the overall quality of the project's code. It's nowhere near as perfect and "hack-free" as at least some of you seem to believe it is. As someone mentioned earlier, this entire project itself can be seen as nothing but one big hack. Both in that it cannot possibly hope to emulate each of the mechanics of the official servers in theory and in that it often fails to emulate even some of the most basic and well-understood of these mechanics in actual practice. Qsa, without mmaps, the complete inadequacy (not to mention, "non-Blizz-likeness") of the exiting pathfinding code is a very good example of the quality of entire project. You of all people should know that. You also seem to forget that mmaps began as an improvement to the already existing classes and functions of Mangos. If the main repository hadn't contained any movement-related code at all (according to the puristic approach enforced by the devs), I doubt that this ambitious and spectacular project would ever have been started at all.

So, to an outsider, it seems that up to a very recent point the developers were perfectly happy to include crappy, inadequate and incomplete code of their own. In which case, why should the rest of us suddenly be nothing but infallible perfectionists whose coding skills can satisfy the most stringent standards of a major English bank? Think what you will of me, but I'm probably one of the biggest supporters of the project there is. And as a supporter, I'd say that unless you remove most of your all of your own half-assed code from the main branch, you should stop acting so surprised when some of your most hypocritical proclamations sometimes get met with expressions of incredulous sarcasm.

To sum this verbal diarrheal discharge up, I can definitely see Vladimir's point that Mangos is different from normal open source projects. One can rarely find a popular open source project where any of his potential contributions will seem preemptively unwelcome. Is it no one out there who wants to help you, period, or could it possibly be the case that some of your most unreasonable practices scared most of potential help away? In an SD2 discussion, someone (not me) once said that he would submit 90% of his scripts for the SVN if he knew that at least 40% of them would be accepted. I think that expresses my own view very neatly. Patches like AHBot are hugely popular and mostly harmless. Why on earth would you not incorporate them into the main branch? Perhaps even less Blizz-like submissions like Playerbot (invaluable for small population servers) could get in, disabled by default and manageable through the ini file. Maintaining an "all-popular-patches-in" branch of the project with fewer restrictions on the quality of submitted content could not only appease most of the critics and turn some of us "lazy trolls with oversize egos" to more active contributing, but be used as a testing ground for any submitted content for the official branch. Are you really that certain that all of its potential benefits wouldn't outweigh its costs?

[Sleighyah]

If you want your patch implemented, why don't you just diff it and add it into your source, compile, and profit?

Edited:

My issue is with the way the actual core is written more than anything, so I'm not going to complain about contributors, even though the two are linked in a very major way.

[caeruleaus]

learning project. enough said.

[VladimirMangos]

It's nowhere near as perfect and "hack-free" as at least some of you seem to believe it is.

None from devs say this. But I sure that current mangos code lot better that in past from this point. Policy avoid increase hack code amount without _real_ reason for rare specific cases.

Patches like AHBot are hugely popular and mostly harmless. Why on earth would you not incorporate them into the main branch?

I personally not like idea use fake player for work, because this auto-add not safe code work in this part because we have after normal and fake players. About harmless, in current version maybe, but long time i read diff crash raports related to it. In AHBot case i agree that maybe good have like _feature_ in to core but fake player use let me think that need for _me_ at review search alt. way implemention, so _possible_ need rewrite, so _possible_ need many time research and etc, so i look another not less prio problems existed in mangos that from my expection need expected less time for resolve.

This in my personal case applied to any other cases (and later not related to AHBot directly). I have many diff problems/features in hand and only can work at single, so mostly select what look clear for fast adding, or more priority _for_me_ or interesting by self _for_me_.

Yes, this make big patches "all fix/implement in one patch" low chance for my review. But i sure _any_ big monster patch can be implemented as series clean one per patch feature aspect implementing, progressive in series. If someone can't look at some feature implementing as some steps and subgolds that can be implemented independently he is bad developer.

[cyberium]

Yes, this make big patches "all fix/implement in one patch" low chance for my review. But i sure _any_ big monster patch can be implemented as series clean one per patch feature aspect implementing, progressive in series. If someone can't look at some feature implementing as some steps and subgolds that can be implemented independently he is bad developer.

I realy understaind what you say.

But unfortunaly, there is some bad exemple of small unreviewed code from long time or old one recently accepted but in "under_review" from a long time...

So how the chance you will accept a patch will improve nothing, perhaps modify some functionality and introduce some regression, but needed in "future" patch with new absolutly working feature?

So yes it's hard to manage and i am not here to say you "do this or that" and i respect your choice. I will continue helping until i want and it's your responsability to do what you want with provided code. Anyway send it to trash is the easyest way.

Friendly.

[Ambal]

b482519 just don't realize simple thing: developer manpower is what big projects like mangos lacks in order to catch Blizz. This is also what delays Code Review stage for BIG patches like mmaps, vehicles as well as all others. - we don't want to submit patch just because "it is a suppa-cool feature we don't have in the core" but in most cases we don't have enough ppl to review your changes, sorry.

Blizz has dozens of programmers who are paid big money in order to earn even more $$$ to Blizz. If you need numbers, WOW team has ~30 programmers and ~320 QAs to bring success to this game. How many of those has mangos? I doubt your so lovely TrinityCore has the same set of features as offy WoW servers.

P.S. b482519, you remind me burlex who was very nice programmer, but also an expert in blaming everything around in mangos but not offering any help to our project. Noone needs your whines on this forum, sorry.

P.P.S. Talking about sh*tty code that works you are so proud of: If your sh*t does not smell, it is still sh*t, isn't it? Customers don't care about code quality - it is your problem in any way as well as set of features you need to implement in order to make everyone happy. But maintaining crappy codebase is PITA - I've spend 71 hours instead of 30 hours planned by project manager in order to make sh*t work nicely. :mad:

[VladimirMangos]

Just remark at:

So how the chance you will accept a patch will improve nothing, perhaps modify some functionality and introduce some regression, but needed in "future" patch with new absolutly working feature?

We often add patches that not imporve anything for end user but imporve code stly for example, or rewrite code in better way

internal logic but not resolve any known problems for end users. More, also added patches that can be from end user point look like regressions in some parts but from our point do something in more correct way, like: old way work in A and B cases but totally in hack way just by chance, new code work _correctly_ base at new known data for A but now B cases broken. So we can add changes need for implement something but not req. directly, just need prove that this will need really and this right way do this.

[scargo]

Just my point of view, seems to me that no one consider some other aspect, i'm talking of the vehicle sistem, the lack of this feature is an heavy gameplay block. For someone the actual, and only, patch we have is a crap, ok, it could be, but what else we can do, have we to modify the db so the quest is left-click-done ?

As this thread should be titled "how an experienced user should bloody-bash an unexperienced one and win" i can figure the anwser "if you can't live with it it's not my business", Stated this, as an end user, i would ask you devs to have little more patience, just because if you do not have the time/datas/else to implement it you shoul not use terms like "half-baked code" (and this is the less offensive), and hopefully helps, so the so blamed code impact with the less damage

With respect

[qsa]

As long as people thing of this project in terms of "product", we'll always have this discussions.

This approach implies all the above. Things like "features first", "quick and dirty", "results now".

I think in terms of educational project. Therefore, I tend to disagree.

Sure, working features are nice. But considering very limited manpower, you cannot get everything at once.

Work being done by volunteers, you cannot force anyone doing something they do not like/don't consider critical/don't have time for/whatever.

So, what exactly is your point guys? That we lack talented people who will work for free? I fully agree.

What I disagree about, is forcing people to spent their time on what you want. This is what its basically what it is about.

You want vehicles/etc implemented. None on the staff have the time/will to do it. Simple.

You want something done, you got to do it yourself.

For some peculiar reason you expect things to be handled from above or something. How does this approach work for you in other aspects in life?

There are projects which focus on features. It is not (as I like to believe) mangos's main goal.

This is one, among other thing that allowed it become what it is now.

If you like "product" approach better, thats OK. There are wonderful projects which support this set of ideas.

But coming here from those projects, claiming that mangos should change its model? It just smells bad, I'm sorry.

b482519: You can be superb deity all I care, but I can give you the credit only for what I see.

Posts you made, are consist mostly of criticism.

I failed to see any valid point for improvement. By that, I mean : things that should be, and can be done in reasonable manner.

Without those, it sounds very similarly to plain flaming.

You know what they say: "It's such a shame all the people who really know how to run this country are too busy driving cabs and cutting hair".

As for mangos being "if you don't like the way we do things in our project, go away" :

From my personal experience, this is by far the most open minded oss filled with helpful people.

Try doing the same thing in ANY successful open source project.

Make an account in mozilla dev forums and say that their management technique suck donkey balls and you propose to improve it by XYZ. I'd love to see the responses you get.

The reason is simple : stability is what make those things tick.

But with all your experience in the field, you already know it, don't you?

I do tend to believe it's since you may actually care. I do appreciate it. Shame if I'm wrong.

Best regards.

[Sleighyah]

Mozilla's management technique doesn't suck donkey balls.

[Diablox]

Mozilla's management technique doesn't suck donkey balls.

Try reading the whole post not just parts...

[Sleighyah]

Mozilla's management technique doesn't suck donkey balls.

Try reading the whole post not just parts...

I did read the whole post. Thanks for checking, White Knight.

[davemm]

Mozilla's management technique doesn't suck donkey balls.

Try reading the whole post not just parts...

I did read the whole post. Thanks for checking, White Knight.

If you HAD read the whole post, you would have noticed that at no point was ANYONE calling Mozilla's management technique "donkey balls".

So, please take some time to re-read it, and please refrain from any further name calling.

Up till now this discussion, while heated, has been fairly polite and good natured, we do not need people coming in a trying to start a flame war.

[dpedroia15]

I know that we don't want to flood the repo with many inexperienced developers, but wouldn't it make sense to give more people the ability to review patches and commit them?

I would agree that we definitely don't have enough developers to keep up with Blizzard. At the moment, we only have 24 part-time developers. Yet there are many people on this forum that have proven they can write code up to the standard of MaNGOS (e.g. qsa, cyberium).

The more people that we have who would be able to review and commit patches, the more work we would get done.

[Auntie Mangos]

This is going way off topic. 4.0.3 is not related to our methods of doing things.