Incoming changes

[Unkle Nuke]

Transports is part of what I refer to as the "big three", along with opvp and vehicles, regarding major core features for 3.3.5a.

If they must be prioritized, I'd pick Vehicles over NPCs On Transports because early WotLK quests and some boss battles need working Vehicles. Transports aren't a real issue until later in the game. Although, it would be good to finally have crews on the boats and zepplins instead of being alone on a ghost ship! lol

[kennumen]

Transports is part of what I refer to as the "big three", along with opvp and vehicles, regarding major core features for 3.3.5a.

If they must be prioritized, I'd pick Vehicles over NPCs On Transports because early WotLK quests and some boss battles need working Vehicles. Transports aren't a real issue until later in the game. Although, it would be good to finally have crews on the boats and zepplins instead of being alone on a ghost ship! lol

Not to turn this in a "I want feature X!" thread but why transport NPCs? I don't recall them ever having any function (other than a brief moment of immersion). Personally I'm looking forward to LFD a lot more (along with Vehicles and World PvP, I think we all agree on those two).

... Then again there was that one BG with the flying airship.

[SADraco]

If you look at the gunships in icecrown - it has crew on them that gives quests and so forth - that is why the i think it is important that we try getingthis right - also i agree vehicles are alos for pvp and ulduar

[Nyds]

What about pathfinding implementation on mangos zero?

[Unkle Nuke]

faramir was the primary developer of mmaps. There was work in progress to backport movemaps to Zero, with plans for One to follow soon after.

So far, faramir and the rest of the mmaps team have yet to resurface. I'm not sure any of them know the MaNGOS Community is back online or that it has a new URL.

Being open source, everyone is welcome to work on any of the various cores. You can even take a crack at making mmaps work with Zero yourself.

[Nyds]

I'm currently looking into porting the mmaps from the One branches, but can anyone point me towards the most recent commits?

[TheLuda]

There alreay is a mmaps branch on mangos zero. Zero needs splines backported and combined with mmaps before mmaps can be useful.

[Nyds]

Fair enough. I'm not up to speed with how the spline system would be implemented, but I'll see if I can contribute to backporting it.

[TheLuda]

Page six of the mangos-one commit history on github has the first commits for splines.

[kupix_]

it would be great to split urgent needs for each mangos version and prepare road map for each of them (many things are done, but maybe some need to be improved). it would be great to find/prepare/provide decent tools to manage mangos (divided for a mangos version and for a purpose: mangos server, users, db). on higher level of abstraction, maybe some parts of the system need to be redesign?

those are just ideas for (possible) incoming changes

[apendix]

maybe will be good step merge all changes from SD2 https://github.com/scriptdev2/scriptdev2/commits/master to https://github.com/mangos/mangos, like TC has, PVE script in core together, not like an "addon" for now

[Schmoozerd]

Keeping SD2 external has many advantages

[Xfurry]

maybe will be good step merge all changes from SD2 https://github.com/scriptdev2/scriptdev2/commits/master to https://github.com/mangos/mangos, like TC has, PVE script in core together, not like an "addon" for now

I don't see any problem in having them separated. Maybe the thing which we can do, is move SD2 under the same organization, so we would have mangos and SD2 in the same place, but clearly it's better to have them as distinct projects.

[TheLuda]

We could move them into one organization and make scriptdev2 a git submodule instead.

[antiroot]

I was under the impression that SD2 and other projects like UDB included content basically copied from the game which I thought was something that should not be part of mangos, or would the inclusion of SD2 into mangos not include the text/database content?

[faramir118_]

We could move them into one organization and make scriptdev2 a git submodule instead.

Yes please

[Schmoozerd]

I disagree to moving sd2 around

We had this topic lots of times and enough reasoning already - so except there are new arguments we can skip this discussion in my opinion

[lillecarl]

git submodule sounds great =) Even better IMHO would be to integrate it tho ^^,

EDIT: At least implement script system. Scripts can be scriptdevs "problem" but having the script system inside the core eases up a lot of things for people with less knowledge about linkers and how they work (me)

[shlainn]

We should hightlight the fact that we try to change the mangos commit policy.

It was: Only commit proper / 100% correct code

It will be: Commit early and often. Dont mind if its WIP. It is intended to be a steady development process.

So, it has been a while. Any update on this topic?

[Unkle Nuke]

My biggest question regarding "commit early, commit often" concerns development versus usability.

With some recent commits causing bugs or breaking the compile, it seems there is a need to assure end-users of some reliability in building and operating their server.

My question is this:

Is there a good reason to not have the MaNGOS source split into two branches, one for the current development and another for code that is considered stable enough for actual deployment?

Almost every project I've seen has "stable" and "unstable", or "test", branches. Playerbot follows this convention, for example. I think it's a good method to adopt, since more frequent commits means code is not as carefully vetted. Not every user wishes to be on the bleeding edge of bug testing.

So how about having "MaNGOS-stable" and "MaNGOS-test" branches, or whatever appropriate labels, to allow devs to still go crazy while providing end-users some comfort that their server will compile and at least run without a complete meltdown?

[pomser_]

My biggest question regarding "commit early, commit often" concerns development versus usability.

With some recent commits causing bugs or breaking the compile, it seems there is a need to assure end-users of some reliability in building and operating their server.

My question is this:

Is there a good reason to not have the MaNGOS source split into two branches, one for the current development and another for code that is considered stable enough for actual deployment?

Almost every project I've seen has "stable" and "unstable", or "test", branches. Playerbot follows this convention, for example. I think it's a good method to adopt, since more frequent commits means code is not as carefully vetted. Not every user wishes to be on the bleeding edge of bug testing.

So how about having "MaNGOS-stable" and "MaNGOS-test" branches, or whatever appropriate labels, to allow devs to still go crazy while providing end-users some comfort that their server will compile and at least run without a complete meltdown?

I Agree with UnkleNuke.

Having a stable version and a 'beta-version' would be the most proper and professional way to develop mangos.

[Schmoozerd]

The main argument against this has always been that in this case most ppl would only use the dev branch, so this would actually just mean to push things even though one is not really confident about the changeset.

Also in a dev branch we would not use our revision numbers, which _might_ make bugreports less easy to read.

[shlainn]

I was under the impression that mangos used tags to label stable revisions...

Any way guys, this is a learning project - and to my knowledge learning is done from mistakes. If a new feature breaks the build, it is an opportunity for all of us to learn something. mangos pushes out revisions pretty fast anyway, so mistakes are corrected pretty quickly. IMHO.

[VladimirMangos]

Alternative to problematic from revisions support (also DB/scripts compatibility, etc) maybe more oftent releases creating with tags.

Release expected to be done for some stable state of code before some unsafe changes, so can be considered as stable point.

In like case DB/scripts devs also can easy support like relase but publish related DB/scripts releases.

[X-Savior_]

I agree with Vladimir and Schmoozerd.

I do not see the problem with the projects being separated. I mean I can see the pros and cons of separate and unified under one roof.

It was my understanding that the 3 projects have been separated for legal reasons since the beginning of time. Has this concept been revoked now in favor of a single project site with everything operating there?

One thing that STILL upsets me and I would like to get resolved is the fact ACID and TBC-DB have their own repos yet the focus here is to get everyone using the mangos repo. This duplication of data makes no sense. Why are people not just getting it right from the source repo.... why the middle person.

Another issue is the fact Mangos provides all the tables for the Database in separate files... This is fine but I think we should still be offering up the original release file archive as per normal (If you want to break down to tables feel free separately) but I just don't see the purpose of making more work then required. All it does is take away from the limited time we all have doing the development

So if the projects are truly going to unify under one roof some of these issues need to be resolved.

I am easy going and am open to suggestions. Of course having all projects located on a single forum and working together has many benefits... but many obstacles that need to be addressed also.