Jump to content

Incoming changes

Guest theluda_

By Guest theluda_
in Archived Announcements

Recommended Posts

Guest

Guest

Posted
Posted

Projects need a roadmap, and projects obviously need someone provide guidance, rules and regulation.

You asked for it, here it is. From now on, TheLuda and Salja will be you nannies. We will define a roadmap and tasks that need completion, and everyone is free to pick an item from the list, and work on it.

Tasks will be created as issues on github, and you may attach patches, pull requests, comments, while we will provide guidance and improvement suggestions where needed. This will ensure that patches submitted will quickly move from our forums to a dedicated patch branch in git, and can be move to a release for everyone to enjoy as soon as possible.

A set of coding standards, and code style guides will be provided, and these will be considered mandatory.

Roadmap

  • Bring vehicles to mangos.
  • Bring outdoor pvp to mangos.

Further roadmap items will be selected once these tasks are finished.

Link to comment
Share on other sites
  • Replies 77
  • Created
  • Last Reply
lillecarl Advanced Member

lillecarl

Posted
Posted

One thing that would be awesome for future would be to instead of having people (like faramir etc..) fork mangos they should create a git branch with a descent self explanatory branch name. To keep mangos development a bit centralized, so we know where to find all those awesomeness things :)

I think something that should be focused is: Vehicles, Spells, Vmap4 =)

EDIT: What is the openpvp you are talking about really?

Link to comment
Share on other sites
lillecarl Advanced Member

lillecarl

Posted
Posted
Open PvP means that all required features to make PvP in world regions such as Silithus or Zangarmarsh, etc. work. There have been many discussions about what is missing in the old forums by Xfurry and others.

On my mangos one i see the "flags to take over" in Hellfire. Is that openpvp? To have those areas properly working and captureable?

Couldnt this be ported from trinitycore? I guess they have had this system for a long time and should be quite well implented by now? :o

Link to comment
Share on other sites
stfx_ Advanced Member

stfx_

Posted
Posted
Couldnt this be ported from trinitycore? I guess they have had this system for a long time and should be quite well implented by now? :o

No trinitycore does not have a good opvp implementation since it hasnt really worked on after it was implemented some years ago. However Xfurry and me (main props to Xfurry) have been working on a different approach in the last few months which doesnt seem to work too bad :)

Related to the changes:

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.

This would also suggest to possibly use branches for new subsystems (opvp) or a dev branch. Which finally brings me to the question why we still need commit ids which are hard/annoying to work with when using pull request/merging a lot/having many branches? If you still want to keep the sql safety mechanic we could change the sql updates to have the change date and not the revision id in it.

Link to comment
Share on other sites
lillecarl Advanced Member

lillecarl

Posted
Posted
no its missing in master one zero but xfurry and stfx have start for few time https://github.com/xfurry/mangos

The how do you explain my printscreen i just took? ;)

EDIT: How do i delete posts when im retarded and cannot read what stfx said?

yepp Hellfire is opvp zone.

Then its partly implented in mangos one? Because i see the 0/3 info bar on top while in hellfire :P

No its not yet implemented (only dummy word states are sent). No trinitycore does not have a good opvp implementation since it didnt really was continued after it was implemented some years ago. However Xfurry and me (main props to Xfurry) have been working on a different approach it in the last few months which doesnt work too bad :)

Related to the changes:

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.

This would also suggest to possibly use branches for new subsystems (opvp) or a dev branch. Which finally brings me to the question why we still need commit ids which are hard/annoying to work with when using pull request/merging a lot/having many branches? If you still want to keep the sql safety mechanic we could change the sql updates to have the change date and not the revision id in it.

I think commiting id's is a complete waste IF someone comes up with a better way to track database changes.

(Maby insert rows into db_version for each branch and keep track of them in some kewl way idk this is out of my current logic)

Link to comment
Share on other sites
evilatwow Advanced Member

evilatwow

Posted
Posted

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.

This would also suggest to possibly use branches for new subsystems (opvp) or a dev branch.

I'd say yes on the use of branches for anything non trivial with a "commit early and often" policy. They are cheap anyway in git. Otherwise you risk getting stuck on parts that don't work properly yet half of the time, becasue there's always something that'll be in an early WIP phase. The "commit early and often" policy works fine, but imho it does not when applied to a single branch. Then it becomes "bugs 'n frustration early and often" :P

Link to comment
Share on other sites
TheLuda Advanced Member

TheLuda

Posted
Posted

Which is why we will follow a workflow based on github issues from now on. Branches by default will be based on a github issue. Always. Thus if an issue and the connected branch can not satisfyingly be solved, the branch would be dropped, and the issue would be closed.

Link to comment
Share on other sites
lillecarl Advanced Member

lillecarl

Posted
Posted
Database migrations pretty much are versioned instructions for upgrading and downgrading database schemas.

A well known example from the Ruby world is Ruby on Rails migrations. While an implementation would be different in C/C++, the Rails guide does a pretty good job explaining what migrations do.

litesql is a C++ library which pretty much does that.

Why wasn't this implemented four years ago!?!?!

Link to comment
Share on other sites
apendix Advanced Member

apendix

Posted
Posted

I dont know, but wouldn´t be better to work on cataclysm only because wotlk content patch is now a little bit outdated? MaNGOS has the best YTDB db team, so there is no problem with WOW world content, bcs YTDB has many contributions etc.

So "new" project = new content support

Link to comment
Share on other sites
Christian Schamara Advanced Member

Christian Schamara

Posted
Posted
I dont know, but wouldn´t be better to work on cataclysm only because wotlk content patch is now a little bit outdated? MaNGOS has the best YTDB db team, so there is no problem with WOW world content, bcs YTDB has many contributions etc.

So "new" project = new content support

Before we start with cataclysm some things must be done and we need developers for cataclysm.

Link to comment
Share on other sites
Xfurry Advanced Member

Xfurry

Posted
Posted
Why vehicles?

Vehicles are required to support most of what makes WotLK great. And future Cataclysm support without vehicles simply would suck.

Why open pvp?

Because world PvP is awesome sauce.

Outdoor PvP is fully implemented here: https://github.com/xfurry/mangos (thanks to Stfx for help).

There are still a few missing parts, and small issues (especially in Halaa script) but this is playable, and it's a really nice experience :)

PS. Of course this doesn't include Wintergrasp, but it won't be a big deal to extend the current Outdoor PvP classes to support Battlefields. ;)

Link to comment
Share on other sites
lillecarl Advanced Member

lillecarl

Posted
Posted
Why vehicles?

Vehicles are required to support most of what makes WotLK great. And future Cataclysm support without vehicles simply would suck.

Why open pvp?

Because world PvP is awesome sauce.

Outdoor PvP is fully implemented here: https://github.com/xfurry/mangos (thanks to Stfx for help).

There are still a few missing parts, and small issues (especially in Halaa script) but this is playable, and it's a really nice experience :)

PS. Of course this doesn't include Wintergrasp, but it won't be a big deal to extend the current Outdoor PvP classes to support Battlefields. ;)

The question is: Should it be implemented now, or should it wait until someone takes care of Halaa issue? I think everything will get more love in mangos repo :)

Link to comment
Share on other sites
Xfurry Advanced Member

Xfurry

Posted
Posted

The question is: Should it be implemented now, or should it wait until someone takes care of Halaa issue? I think everything will get more love in mangos repo :)

The core part can be implemented. This means GO type 29, and the Zone script, and OutdoorPvP main classes support.

Basically there are some issues / research items related to spawning / despawning gameobjects and creatures for the functionality of these scripts.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

Go to topic listing

Contact Us

To contact us click here
You can also email us at [email protected]

Privacy Policy | Terms & Conditions

Repositories

The Link to the master list
of MaNGOS repositories:
Copyright © getMaNGOS. All rights Reserved.

This website is in no way associated with or endorsed by Blizzard Entertainment®
×
×
  • 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