4.0.3 server is live *.*

[Raffa50]

i found catusemu

it works whit 4.0.3

ally whit this project?

it is possible to make a cata server, so now??? hurry up, mangos!

[Auntie Mangos]

First: CactusEMU is pretty easy to spot.

Second: this is touching the client, and modifying it.

Third: download it, try to build a server and login, and see for yourself. Not much use in making a party.

Nothing is live yet.

[vladex]

well first of all i think mangos wont hurry , because that ain't so easy, CactusEmu is trinitycore based so a code convertion is needed but that isn't the problem, the real porblem is that we haven't even finished a fully Wotlk functional server with everything it needs,second there isnt any concludent database for cataclysm that has some things implemented.

In my opinion it will take 4-5 months to reach cataclysm ,(ofc not fully working), just think of the major changes , how could you rush ?

[Unkle Nuke]

Here's a big concern:

With so many radical changes to the client, will there even be the possibility of backporting fixes for MaNGOS 4.x to 3.x? If not, then what becomes of development for 3.3.5?

I know 1.12 has found its own dev team and 2.43 does see some backported fixes from 3.3.5. Though 2.43 does have some patches, work on the database and scripting seems to have disappeared completely.

Will 3.3.5 die off or be rescued from the dustbin of obsolescence by a devoted group of developers?

[VladimirMangos]

Creating mangos-0.17 (current master version) branch planned before switch to 4.x when/if it happens.

My experience with backporting changes to mangos-0.12 and mangoszero show that lot easy backport by steps (master->0.12->zero) that directly (master->zero for example). So have branch not add more problems. Current backporting problem mostly in lot work not with current changes, but with big queue old chnages that still not backprted from master to 0.12.

For example 0.12 and zero mostly sync in code and when some feature backported to 0.12 it very easy in most cases backported to zero. If at some moment we will have sync sources in master and 0.12 then will not hard (except special cases) support all branches sync. Including with additional mangos-0.17 branch as it will created.

Yes, 4.x affect hard to spell code because different dbc structure but this is mostly textual diff some code lines. it still expected same spell functionality. Ofc specific spells/effects/auras work affected more. But this is not new. Any client version support switch triggering same problems. Also with proper selected spell data access API possible make differences in dbc structure in many places not visible for generic code directly.

Most problem with 4.x support at high level (in additional real problem with random opcodes and proper authorization and encoding/decoding packets at low level) in wide use features that base at parts already existed in 3.x clients but missing in mangos core and ofc lot new features.

Though 2.43 does have some patches, work on the database and scripting seems to have disappeared completely.

Maybe development client specific parts different from 3.3.5a sd2 version not active but compatibility patches and repos updates. Same for version specific DB projects. You possible miss related links to projects or sections in master related projects.

[Patman128]

Most problem with 4.x support at high level (in additional real problem with random opcodes and proper authorization and encoding/decoding packets at low level) in wide use features that base at parts already existed in 3.x clients but missing in mangos core and ofc lot new features.

I think this is the biggest problem: everyone is rushing for 4.x support when most of the new features build on 3.x features that aren't even in mangos yet! Things like vehicles which are in pretty much every zone (!) in 4.x are not even working in 3.x mangos yet.

[cyberium]

I think this is the biggest problem: everyone is rushing for 4.x support when most of the new features build on 3.x features that aren't even in mangos yet! Things like vehicles which are in pretty much every zone (!) in 4.x are not even working in 3.x mangos yet.

Why?

I think there is a lack of cooperation between developers, all af us are working for what we want but there is some part of the code as required more than one developper at same time.

Vehicule patch require lot of SQL modification as well code modification and probably more sniffing stuff.

Start with actual code is possible but require same kind of cooperation you can see on mmapredux patch to get some advencement.

If you look "accepted" section you will see last update concern only some little part of the code (almost spell) except vmaprewrite.

Anyway i know it's not easy to focalise dev on a point and make cooperation work.

[rulebreaker]

I think this is the biggest problem: everyone is rushing for 4.x support when most of the new features build on 3.x features that aren't even in mangos yet! Things like vehicles which are in pretty much every zone (!) in 4.x are not even working in 3.x mangos yet.

Yeah but whose fault is that? my belief its the guys who control the mangos repo.

There are a few vehicle patches out there that work fine but are not coded to mangos spec, yet this project is so picky for perfection it wont entertain these patches for integration.

When your dealing with hundreds of programmers working for free, the turn around time is going to be very slow, so i say compromise and vote on the patches that get the job done with minimal breakage.

Its not like we are a multinational corporation selling a retail piece of software, its ok for things not to be perfect.

Hell I'm the Director of Network Ops "With a C, C++ and C# background" for a Pharmaceutical company in the US that builds software for other Pharmaceutical companies and our code is so sloppy its laughable but it sells and the client does not care, its gets the job done.

Just my thought, It is not my intent to offend.

[roby10]

"Its not like we are a multinational corporation selling a retail piece of software, its ok for things not to be perfect."

-it's even better

-it's not ok for things not to be perfect....

if you'd like a stable version of "vehicle patch"(as you mentioned there) wait for mangos's version... if not... you know what you have to do

[b482519]

"Its not like we are a multinational corporation selling a retail piece of software, its ok for things not to be perfect."

-it's even better

-it's not ok for things not to be perfect....

if you'd like a stable version of "vehicle patch"(as you mentioned there) wait for mangos's version... if not... you know what you have to do

Try doing it with MMaps, Playerbot, AHbot, Vehicles, A-H Grouping, Vellums, OutdoorPvP, and at least half a dozen of other similarly "unworthy" modifications, and see how much time it'll take you to sort through merging conflicts alone.

[Diablox]

It looks like this discussion is pointless. Mangos team will not change the way they do and i hope they don't change (also the sheep will go berserk and kill all devs. We don't want that ). If they did then mangos will be same as every other project. And trinity will run out of things to do if mangos just accepts every single patch that show up on the forums.

P.S. This is way offtopic

[kich0]

MaNGOS care about code quality and long-term proper implementation instead of functionality and short-term hacks.

Anyway please stay on topic.

[Demelion]

Mangos is great i won't like to see it changed as it is. i remember the first releases when 2.0 was out they where patches in the core modifecation section an long time before mangos inported it and it sould stay that way if you think you can make an patch so mangos can suport 4.0.x than do so and share it on the core modification section keep it updated and who knows maybee your patch will land up in the source when they deside to suport 4.x.

it always worked for me like that and im glad mangos do it that way becose than some DB projects at least can inport some stuff before it goes live on real mangos.

So when you think you can make an patch so mangos can suport 4.x then do so and share it in core modification section and keep it updated and so on.

[Sleighyah]

MaNGOS care about code quality and long-term proper implementation instead of functionality and short-term hacks.

Anyway please stay on topic.

The issue is that in many places this isn't the case. Multiseat mounts don't work yet, for example, or mounts like Invincible or The Headless Horseman's mount are capable of flying in Azeroth (3.x, not 4.x).

Don't even get me started on Death Knights (especially their initiation quest chain).

[zergtmn]

[The issue is that in many places this isn't the case. Multiseat mounts don't work yet, for example, or mounts like Invincible or The Headless Horseman's mount are capable of flying in Azeroth (3.x, not 4.x).

Don't even get me started on Death Knights (especially their initiation quest chain).

It is impossible to implement DK quests without hacks currently. See what Kich0 said.

[VladimirMangos]

The issue is that in many places this isn't the case. Multiseat mounts don't work yet, for example, or mounts like Invincible or The Headless Horseman's mount are capable of flying in Azeroth (3.x, not 4.x).

Don't even get me started on Death Knights (especially their initiation quest chain).

This not bugs but not implemented features. I think you not understand difference bugs from missing features.

[Mister D]

As I understand it, the problem with 4.x support is some encrypted communications between server and client, (correct me if I'm wrong). So a hack to get 4.x support would be modifying the client, but that is not an option for legal and practical reasons, and it's simply not a pretty solution.

But would it be an option to use mangosclient and add 4.x support to that while keeping client-server communications as before, as a stop-gap measure?

So instead of using a modified client, use an opensource one? I'm not much of a programmer, and I don't know the ins and outs of mangos yet, not the server-client communications, but if those communications are the only real issue it seems like this could be a temporary solution, but it would be nice to support the retail client in the end.

And of course patches shouldn't be accepted lightly, badly written or non-standard code will make managing the code much more difficult and will eventually slow down progress. You may be able to impliment new features faster in the short term, but it will become more and more difficult to do over time.

[Sleighyah]

This not bugs but not implemented features. I think you not understand difference bugs from missing features.

I'm a developer by trade mate, I know what the difference is. My point is that they're not implemented. Regardless of what you want to call them, they've been around since about 3.0 and they're not working. When I replied to Kich0 in my original post, I was saying that functionality in this case wasn't in place. The features are missing. I never mentioned anything about bugs, so please refrain from judging my ability to understand simple differences when it's actually in my day-to-day work.

[qsa]

This not bugs but not implemented features. I think you not understand difference bugs from missing features.

I'm a developer by trade mate, I know what the difference is. My point is that they're not implemented. Regardless of what you want to call them, they've been around since about 3.0 and they're not working. When I replied to Kich0 in my original post, I was saying that functionality in this case wasn't in place. The features are missing. I never mentioned anything about bugs, so please refrain from judging my ability to understand simple differences when it's actually in my day-to-day work.

You can always use your skills for something good, instea ...

This topic makes kitty sad.

[Nick Taylor]

The problem I see is that the developers expect a standard of coding that can only be achieved by a team working on the patch, not just the one or two developers that usually work on them.

For example, take some of the many vehicle patches out there. The MaNGOS developers (although I could be completely wrong about this) do not want to incorporate these patches due to their inherent instability and incompatibility with current revisions of MaNGOS. However the problem with this logic is that incompatibility issues will only be resolved by incorporating the code into the project, as it is absurd to suggest that for every revision, these patch developers update their code to work, as some of the larger ones (such as vehicle support), are entangled with much of the existing code.

The issue of instability could also be solved by incorporating this, as due to MaNGOS being an open-source project, the problem will be solved, if you let the community have the chance to even try.

I understand the sentiment of this practice, but in reality, it proves to be impractical. MaNGOS itself isn't perfect, so why does it require third party developers to be?

[Sleighyah]

You can always use your skills for something good, instea ...

This topic makes kitty sad.

I'm a web developer, not an app developer. I don't know much of C or C++.

[Sleighyah]

The problem I see is that the developers expect a standard of coding that can only be achieved by a team working on the patch, not just the one or two developers that usually work on them.

For example, take some of the many vehicle patches out there. The MaNGOS developers (although I could be completely wrong about this) do not want to incorporate these patches due to their inherent instability and incompatibility with current revisions of MaNGOS. However the problem with this logic is that incompatibility issues will only be resolved by incorporating the code into the project, as it is absurd to suggest that for every revision, these patch developers update their code to work, as some of the larger ones (such as vehicle support), are entangled with much of the existing code.

The issue of instability could also be solved by incorporating this, as due to MaNGOS being an open-source project, the problem will be solved, if you let the community have the chance to even try.

I understand the sentiment of this practice, but in reality, it proves to be impractical. MaNGOS itself isn't perfect, so why does it require third party developers to be?

If MaNGOS took a more modular approach, patches would work nicer.

I'm not meaning 'shit codebase restart', but it should be becoming progressively more modular in style.

Edit:

Ah, no auto-merging of posts on this forum. Apologies for double posting.

[VladimirMangos]

However the problem with this logic is that incompatibility issues will only be resolved by incorporating the code into the project, as it is absurd to suggest that for every revision, these patch developers update their code to work, as some of the larger ones (such as vehicle support), are entangled with much of the existing code.

You miss another part: at adding to official repo support this changes compatibility just move from 3rd party creators to team and resolving all problems also because team can't ignore this problems after adding anymore. So ofc for 3rd party creators and users all move to nice way all except team members that now need fix all bugs and etc. Ofc, we know that community will provided good support in this but anyway this will let less time for our current projects also important from _our_ point for mangos. This not meaning that any patch must be ideal, in fact i more often partly rewrite patch before adding to report that add it as-is, but need some expection that added patch will not eat all next time for weeks in fixing (weeks just example ).

But in most cases patch not added because it not reviewed because lack of time for someone review it or lack need info for sure that sugested way correct in general. This most sad and often case.

[Ambal]

MaNGOS itself isn't perfect, so why does it require third party developers to be?

On my job (I work for HUGE English bank), before you commit into the main repo, you have to pass Core Review, then the Test Team have to verify that our patches pass regression tests and do not cause ANY sorts of troubles. Only then you have the right to submit your code and wait for Production Release to prove you wrong - if bugs are uncovered at this stage, your changes are rolled back and you start scratching your head again. This is how BIG business needs things to be done.

We all know such intentions "I'm so tired updating my patch, plz, commit my work, I'll fix bugs later" because we all were 3rd party developers before invited to the team. But practice says that in some cases, authors just disappear or not willing to solve issues right away, and only mangos developer team is left because we have responsibilities!

[b482519]

MaNGOS itself isn't perfect, so why does it require third party developers to be?

On my job (I work for HUGE English bank), before you commit into the main repo, you have to pass Core Review, then the Test Team have to verify that our patches pass regression tests and do not cause ANY sorts of troubles. Only then you have the right to submit your code and wait for Production Release to prove you wrong - if bugs are uncovered at this stage, your changes are rolled back and you start scratching your head again. This is how BIG business needs things to be done.

And that's exactly what semi-legal volunteer hobby project with zero budget needs to emulate, the development cycle and project management techniques of something like Lloyds Banking Group, a major security-obsessed financial institution with more than £1 trillion in total assets and more than £40 billion in annual revenues. Good point.

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.