The Mana World - User contributions [en]

Archive:PVP proposal from Crush

2009-12-20T09:30:32Z

Kane:

{{Category_gameconcept}}
{{Status_red}}
{{Opinions|
{{Pro|Pauan}}
{{Pro|Crush}}
{{Pro|Yosuhara}}
{{Pro|jaxad0127}}
{{Pro|AtmoLaguuna}}
{{Pro|Kage}}
{{Pro|Kane}}
|
{{Contra|Dr Wahl}}
{{Contra|Sunfire}}
}}

My idea of PvP combat is to restrict PVP to personal duels and combat between guilds. Guilds can declare war on each other and then the members of the guilds can fight against each other whenever and wherever they want except in towns. To make pvp more attractive i propose a honor point concept.

The reason I favor this system is that i want to give players the possibility to stay completely out of pvp when they want while giving people who enjoy pvp a competitious and rewarding atmosphere. By focusing on guild vs. guild pvp i want to encourage team oriented pvp combat while avoiding unfair fights party vs. single players, avoid ganking (acting friendly until the other player is occupied, then attacking him. When someone is in an enemy guild you know you can't trust him) and give the players a group they identify with so that they know what they are fighting for.

==Personal duels==
When you want to fight someone, you can challenge him to a duel. He can then decide if he wants to fight you or not. When he doesn't it counts as an automatic win for you. When you win a duel against an opponent who is equally strong or stronger than you level-wise you gain some honor points. When you lose against a lower enemy you lose some honor point. When you win against a weaker enemy or lose against a stronger enemy (like it should be expected) nothing happens.

==Guild war and peace==
Every guildleader can declare war on other guilds. When he does so the members of both guilds receive a warning. About an hour after the guildleader declares war pvp is enabled between members of the two guilds everywhere except towns. The leaders of both guilds can offer peace at any time. When the offer is accepted pvp is immediately disabled between both guilds. Every kill of a member of an enemy guild gives an honor point for every guildmember and every death of a guildmember by the hands of an enemy guildmember means the lose of an honor point for every guildmember.

The idea is that when you are in a (wrong) guild you have the thrill of being attackable everywhere, but you know exactly who your enemies are. And when attacked by an overwhelming force you also know who to ask for help (that guys who lose honor points when they let you die). It also brings the interesting aspects of diplomacy (avoiding making the wrong enemies, threat other guilds with declaration of war, form alliances) and strategic warfare (keep members of enemy guilds away from key resources to weaken them) into the game.

When you are fed up with being attacked everywhere because your guild pissed off all the big pvp guilds you can still leave the guild and become a guildless player again.

==Honor points==
Collecting honor points in pvp combat should give both the individual character advantages as it gives the guild advantages when it got members with many honor points.

Players could have the following advantages when they collect enough honor points:
*A good position on a public scoreboard
*Access to special quests
*Access to prestige equipment
*Advances when dealing with npcs
*Of course they will be more popular in guilds because the guilds honor points are the sum of the honor points of their members.

Guilds could have the following advantages when the sum of the honor points of their members is high:
*A good position on a guild scoreboard
*The right to have a guild emblem
*Access to guild equipment (like shields or capes with the guild emblem visible)
*More organizational guild features
**Giving guild members special tasks like recruiter, treasurer etc. that give them some privileges of the guild leader
**higher member limit
**creating private chat channels in which other people can be invited
**option to form sub guilds
**etc.
*Access to a private guild headquarter ranging from a little meeting hut to a huge castle (on an instanced map).
*Permission to attack other guilds headquarters.

==Guild Headquarter Raid==
Another idea to make guild wars more interesting. This idea is loosely inspired by the guild war system of Ragnarok Online.

===General idea===
The idea is that guilds can attempt to invade the guild headquarter (HQ) of an enemy guild and steal their guild flag to humiliate the guild and steal a lot of honor points from them. In contrary to the Ragnarok Online guild wars system this can be done at any time. The attacking guild will usually outnumber the defending guild because they will usually planed the attack in advance and arranged that as many people as possible take part while the defending guild is caught by surprise and there will usually only a few people be online that are scattered all over the world. To counterbalance this strategical disadvantage of the defending guild the following system is designed to give the defenders a big tactical advantage.

===Preparation===
To attack a HQ the attacking guild has to schedule the raid at an npc. Every guild can only raid another guild every 24 hours. Of course only guilds that have a guild HQ can be raided.

Now both guilds get a message and have a half hour to prepare for combat. The attacking guild meets on a special map while the defending guild meets in their HQ. After the half hour preparation time the attacking guildmembers are teleported onto the map of the HQ. The position of the attacking guild should be a random area outside of the HQ. Random to avoid spawn camping of the defending guild.

===Setup and goal===
While a smaller HQ got a simple layout and is difficult to defend, a large HQ should have a much more complex layout with many points that give the defending guild a tactical advantage. But all HQs got two important rooms.

The first is a spawn room. It should be close to the entrances. When the defenders die they respawn in this room a few seconds later. Attackers can not enter the spawn room nor can they attack the defenders that are in it.

The second is the flag room which is usually in a position that is hard to reach for the attackers but easy to reach from the spawn room. In the flag room is the flag of the defending guild which they have to protect. The flag is basically an item that can only be picked up by the attacking team and is dropped when the character who got it dies.

The mission of the attacking guild is to get into the flag room, take the flag and bring the flag out of the HQ. Guildmembers that die respawn at their usual spawn location in the normal game world and have no chance to get back into the combat.

The mission of the defending guild is to eliminate all attackers before they can bring the guild out of the HQ. When they die they respawn after some seconds in the spawn room.

===Outcome===
When one of the guilds reaches their goal a lot of honor points from the loser are transfered to the winner. The result could be that the defenders have to move into a smaller HQ or that the attackers lose the right to attack again.

When the defending guild lost they have to invest a minor sum of gold to buy a new guild flag for their HQ. They can't use the facilities of their guild HQ but they can not be attacked either until they did so. This is a precaution against inactive guilds serving as honor farms for active guilds or attacking the same guild over and over again with different guilds.

===Strategies===
The preferred strategy of the defenders should be to take out the attackers one by one so that they can use their ability to respawn to their advantage. The attackers should try to stay together and rush into the flag room as fast as possible to make use of their superiority. Besieging the spawn room to prevent the defenders from recapturing key positions while a task force captures the flag can also be a successful strategy.

==Comments==

This rules quite suites me, but i don't agree that player should automatically win, when his oponent refuse to accept challenge... What if he's busy, or he just don't want to fight? Should the challenger take advantage of this? --[[User:Yosuhara|Yosuhara]] 15:18, 21 September 2006 (CEST)

I agree with Yosuhara. Why not have a third option, "declined"? If a player refuses your challenge it will add 1 to the "declined" option. This way you can easily see how many fights the person has undertaken while also providing an accurate assessment. Also, how will you calculate who won? Obviously it will be determined by who dies, but what about monsters, etc.? Perhaps while two players are dueling they cannot be targeted by ANY outside forces (monsters, friends, etc.)? This keeps things fair and prevents people from ganging up on others (except in party vs. party of course). '''--''' [[User:Pauan|Pauan]] 08:04, 23 December 2007 (CET)

The whole guild wars thing seems to open to abuse. I can imagine that some larger guilds might bully the smaller or weaker guilds by declaring war on them, ruining the game for anyone in those guilds because they are not strong enough either in statistics, numbers, or both to defend against the guild warring against them. I would suggest that guild leaders can only declare war against a guild that is roughly equal or greater in power and/or numbers to the other guild. '''--''' [[User:Falcata|Bobby Jim]] 14:36, 24 December 2007 (CET)

:I've seen rules to prevent attacks from high level players/factions on low level players/factions in a lot of games of a lot of different genres. And these rules always left loopholes in practice or even had abuse potential on their own. But when you think that you can design any rules on this topic that really work then feel free to do so. --[[User:Crush|Crush]] 03:41, 25 December 2007 (CET)

Also, I can easily see abuse of the guild headquarter raid. A guild could quite easily gain honor points quickly by continually raid the guild HQ of another, weaker guild. '''--''' [[User:Falcata|Bobby Jim]] 14:36, 24 December 2007 (CET)

:I fixed your concerns by 1. denying guilds to do more raids than one every 24 hours and 2. removing the defeated guild from both the benefits and disadvantages of guild HQs until they feel ready for it again. --[[User:Crush|Crush]] 03:41, 25 December 2007 (CET)

Also, what if a guild doesn't have or want an HQ? What then? '''--''' [[User:Falcata|Bobby Jim]] 14:36, 24 December 2007 (CET)

:Having a guild HQ is purely optional and a guild without a guild HQ can not be raided. --[[User:Crush|Crush]] 03:41, 25 December 2007 (CET)

What are the advantages of having a guild HQ? [[User:Feline monstrosity|Feline monstrosity]] 21:52, 15 May 2008 (CEST)
:I wrote some ideas about this aspect here: http://forums.themanaworld.org/viewtopic.php?f=4&t=2912&p=25354 --[[User:Crush|Crush]] 00:36, 16 May 2008 (CEST)

GvG gets odd when a player is in both guilds. Normal PvP should still be available in special arenas. Party vs Party might be usable for even more special areas. — [[User:Jaxad0127|<span style="color: #160196">Jaxad</span>]][[User Talk:Jaxad0127|<span style="color: #5B038F">0127</span>]] 01:11, 29 May 2009 (UTC)

Forks

2009-12-18T05:02:51Z

Kane: /* Soul Keepers Online */

The open source nature of The Mana World allows everyone to use it as a base for creating an own game. A lot of teams have made use of this opportunity. Projects listed on this page don't work with the official client. Those that are are listed on the [[Servers]] article.

==Active forks==
These are projects which are still in active development.

===Aethyra===
A fork of TMW based on the eAthena branch with most of the content from the original TMW, with plenty of custom content.

* http://www.aethyra.com

===Mundo Dos DragÃµes ( World of Dragons )===
A Brazilian fork of TMW based on the eAthena branch with a completely new game world made from RPGMaker tiles.

* http://www.mundodosdragoes.org

===My Path Online===
A fork of Mana based on the Manaserv branch with a completely redesigned world using both TMW tiles and many other custom tiles from around the world.

* http://www.mypathonline.com

==Inactive forks==
These are projects based on TMW which are unfortunately not active anymore.

===Sirus Online===
An eAthena-based branch formed by people frustrated with the management of Endless Online. It had a quite good start until most players and some developers decided to rather play and develop the original TMW.

===Damasca===
A project very similar in scope to The Mana World, although programmed in C# instead of C++. When the development slowed down because of insufficient manpower it was attempted to rescue the project by using TMWserv and the TMW client which were already much further in their development. Unfortunately it did not turn out so well.

* http://www.damasca.net

===Evol Online===
A French fork of TMW which used the TMW software with a completely new world made from RPGMaker XP graphics. It was inactive for a long time due to financial problems but the creator plans to revive the project soon with a codebase based on the 0.0.26 relase of tmw.

* http://www.evolonline.info/

Development:Git repository

2009-12-09T20:31:47Z

Kane:

{{Status_outdated}}

'''Please note most of the information here is now out of dated, but still great for reference. I suggest you checking out the Mana Source Documentation for more info on the latest repositories.'''
http://doc.manasource.org/git_repository

We are using the version control system Git as our main collaboration tool. You can use it to obtain all the sourcecode and content files you need to take part in the development or to create your own fork. See [http://en.wikipedia.org/wiki/Git_(software) the wikipedia article about Git] and [http://git-scm.com/ the Git homepage] for details about Git.

== The primary repository ==

=== Initial setup ===

With Git, we'll have one repository for each project. The central repositories through which we cooperate are hosted on [http://gitorious.org/ gitorious.org]. Gitorious is a friendly website that is also open source. On Gitorious the main repository for each project is called ''mainline''. Once you click to the mainline repository, you can see several ways to clone it (the new <code>svn checkout</code>).

We've categorized all projects related to The Mana World, so you can easily see the complete [http://gitorious.org/search?q=category%3Athe-mana-world list of The Mana World projects] on Gitorious. The projects have different clone URLs for read-only or developer access. The URL for developer access is called the "push URL", since it allows you to push commits into the repository via ssh. The list below is for your convenience.

{|border="1" cellspacing="0" cellpadding="5"
! Project
! Read-only URL
! Push URL (Developers only)
! Atom feed
|-
| '''[http://gitorious.org/tmw TMW client]'''
| git://gitorious.org/tmw/mainline.git
| git@gitorious.org:tmw/mainline.git
| [http://gitorious.org/tmw/mainline/commits/master/feed.atom Atom]
|-
|colspan=4|This repository contains the client for The Mana World
|-
| '''[http://gitorious.org/tmwdata TMW client data]'''
| git://gitorious.org/tmwdata/mainline.git
| git@gitorious.org:tmwdata/mainline.git
| [http://gitorious.org/tmwdata/mainline/commits/master/feed.atom Atom]
|-
|colspan=4|This repository has the client data.
|-
| '''[http://gitorious.org/tmw/music TMW music]'''
| git://gitorious.org/tmw/music.git
| git@gitorious.org:tmw/music.git
| [http://gitorious.org/tmw/music/commits/master/feed.atom Atom]
|-
|colspan=4|This repository has the background music for the client.
|-
| '''[http://gitorious.org/tmwserv-data TMW server data]'''
| git://gitorious.org/tmwserv-data/mainline.git
| git@gitorious.org:tmwserv-data/mainline.git
| [http://gitorious.org/tmwserv-data/mainline/commits/master/feed.atom Atom]
|-
|colspan=4|This repository contains the data for TMWServ.
|-
| '''[http://gitorious.org/tmw/website TMW website]'''
| git://gitorious.org/tmw/website.git
| git@gitorious.org:tmw/website.git
| [http://gitorious.org/tmw/website/commits/master/feed.atom Atom]
|-
|colspan=4|This repository has our website.
|-
| '''[http://gitorious.org/tmw-eathena eAthena server]'''
| git://gitorious.org/tmw-eathena/mainline.git
| git@gitorious.org:tmw-eathena/mainline.git
| [http://gitorious.org/tmw-eathena/mainline/commits/master/feed.atom Atom]
|-
|colspan=4|This repository contains our hacked up eAthena.
|-
| '''[http://gitorious.org/tmw-eathena-data eAthena data]'''
| git://gitorious.org/tmw-eathena-data/mainline.git
| git@gitorious.org:tmw-eathena-data/mainline.git
| [http://gitorious.org/tmw-eathena-data/mainline/commits/master/feed.atom Atom]
|-
|colspan=4|This repository has the data for our eAthena.
|-
| '''[http://gitorious.org/tmwart TMW Art]'''
| git://gitorious.org/tmwart/mainline.git
| git@gitorious.org:tmwart/mainline.git
| [http://gitorious.org/tmwart/mainline/commits/master/feed.atom Atom]
|-
|colspan=4|This repository has some sources for our artwork.
|}

Git uses ssh's private/public key authentication for identifying committers. For development purposes you should clone the "push url", but this requires that you have:

# Signed up to gitorious.org
# Generated a private/public ssh keypair (if you haven't got this already)
# Filled in your public key in your account details on Gitorious

=== Cloning ===

If you simply <code>git clone</code> the URL without any additional arguments, it will create the repository in a directory called "mainline". This is generally not what you want. Hence, after the clone url, you should pass the name of the directory you want to have created (just like with Subversion):

$ git clone <clone_url> project

If you want to have all projects in one place, you probably want to do something like this:

$ mkdir tmw
$ cd tmw
$ git clone git@gitorious.org:tmw/mainline.git tmw
$ git clone git@gitorious.org:tmw-eathena-data/mainline.git eathena-data
etc.
or for all of them in one go (after the cd tmw step):
$ for repo in tmw tmwdata tmw-eathena tmw-eathena-data ; do git clone git://gitorious.org/${repo}/mainline.git $repo ; done

The way Gitorious works, we can't have one top-level "tmw" project under which we put all these repositories, since they're really separate projects. Gitorious allows multiple repositories for each project, but they are clones of each other (you can only create new ones by cloning existing ones). This allows anybody (not just the development team) to make clones and start hacking on them. Changes can easily be merged from one one repository to another. So instead of all the inconvenience with TMW forks we had in the past, now comes the time to encourage people to clone!

==== Shallow cloning for non-developers ====

One of our repositories, tmwdata, has grown quite large cause of its long history filled with relatively large binary files. If you are only interested in getting the latest version, and have no need to be able to push back changes, then you can make a shallow clone:

$ git clone --depth 1 git://gitorious.org/tmwdata/mainline.git tmwdata

== Working with git ==

=== Commit ===

From now on, a commit is something you do locally. Others won't see your change on Gitorious unless you push it there. You'll notice committing is very fast, and you can commit multiple times before you decide to push. You can also make corrections to your last commit.

Before you start committing, it is important to identify yourself to git, so that it can include the correct authorship information with your commit. You are no longer identified with a username, as was the case with Subversion. You can read exactly how to do this, as well as other useful information geared towards people switching from Subversion, on this page:

* '''Git - SVN Crash Course:''' http://git.or.cz/course/svn.html

=== Pushing ===

Once you have committed some stuff, you can push these to the repository on Gitorious using <code>git push</code>. This works since by default the push command pushes to a ''remote'' called ''origin'', and this remote is automatically set up when you clone. However, the push will fail if there have been new commits on the remote repository. In that case, you'll first have to pull in these changes (just like with Subversion, however Subversion allowed this as long as the same files weren't touched, git doesn't).

=== Pulling ===

When you want to get the latest changes from the repository on Gitorious, you generally use <code>git pull</code>. However, note that this command does not work when you have local changes. Also, when you have local commits, the pull command will generate a merge commit (and before that you may have to resolve some conflicts).

If you don't want to create merge commits, but would rather stack your local commits on top of any incoming commits, you should use <code>git pull --rebase</code>. This ''rebases'' your local commits on top of the incoming ones. You should never do this when you have pushed these commits elsewhere, so only do it when you are sure the commits are only on your machine.

If you have local changes and want to update your checkout, then there are several options:

* You commit your local changes, and do a pull, optionally with --rebase.
* Or you use <code>git stash</code> to place your local changes on a "hidden" stash. Then, after pulling, you apply your changes again with <code>git stash apply</code>.
* Or you create a patch of your local changes that you apply again after the pull. This approach sometimes makes sense, but I would say in general it's the more clumsy way to go. There are git commands that help you with this though.

=== Resolving conflicts ===

Rather similar to Subversion. When there are conflicts, a merge or a rebase will add conflict markers into files. Use <code>git status</code> to see which files remain in conflict and use <code>git add</code> on files to mark them as resolved. When you did a merge and you have resolved all conflicts, you commit. When you were doing a rebase of several commits, you do <code>git rebase --continue</code> instead.

=== Patch making ===

Git has an easy way to send patches to other people to review and commit for you. After you have made a commit, <code>git format-patch</code> will make a patch out of it. The patch includes your author information the commit message you gave, and all the changes to be done. The recipient can just <code>git am [patch file]</code> to apply the commit. After it has been pushed, you'll need to remove the patch from your local repository, <code>git reset --hard HEAD^</code> will do that. If you don't do that, you'll get a conflict when your patch is pulled from the central repository.

=== Good to know ===

Git has several useful commands to figure out the current state of your repository, your files and what recently changed. Below is a non-exhaustive list of commands that are useful to know:

* '''git branch''': Without any parameters, this command lists your local branches, and indicates which branch you're currently on.
* '''git whatchanged''': This shows a list of all commits on the current branch similar to <code>git log</code>, but with a list of the files that have been touched in each commit as well.
* '''git status''': This shows all kind of things about your current checkout: which files changed, untracked (unknown) files, added or removed files, files that have conflicts (during merge), etc. It also shows the status of your index, which is what git will commit once you do <code>git commit</code>. If you're new to git I would recommend to wait a bit with learning how to use the index, but not to avoid it forever.

There are also additional applications that help you with using git:

* '''gitk''': A simple but effective tool that visualizes the history and some of your current state. Run with <code>--all</code> to have it show all branches, otherwise it will just show stuff relevant to your current branch.
* '''tig''': A textual interface, rather similar to an email reader.
* '''git gui''': A gui tool like gitk which helps you prepare and perform your commits. Also makes it easier to understand the index concept.

=== git on Windows ===

When using git on Windows you might use [http://code.google.com/p/msysgit/ msysgit]. If you notice that some files seem to have changed after doing a fresh clone, you may want to disable <code>core.autocrlf</code> using <code>git config core.autocrlf false</code>. However, this is not recommended for contributors since the setting makes sure you don't commit Windows style newlines into the repository. When encountering this problem it is usually best to consult other developers about the affected files.

Development:Git repository

2009-12-09T20:22:29Z

Kane:

{{Status_outdated}}

We are using the version control system Git as our main collaboration tool. You can use it to obtain all the sourcecode and content files you need to take part in the development or to create your own fork. See [http://en.wikipedia.org/wiki/Git_(software) the wikipedia article about Git] and [http://git-scm.com/ the Git homepage] for details about Git.

== The primary repository ==

=== Initial setup ===

With Git, we'll have one repository for each project. The central repositories through which we cooperate are hosted on [http://gitorious.org/ gitorious.org]. Gitorious is a friendly website that is also open source. On Gitorious the main repository for each project is called ''mainline''. Once you click to the mainline repository, you can see several ways to clone it (the new <code>svn checkout</code>).

We've categorized all projects related to The Mana World, so you can easily see the complete [http://gitorious.org/search?q=category%3Athe-mana-world list of The Mana World projects] on Gitorious. The projects have different clone URLs for read-only or developer access. The URL for developer access is called the "push URL", since it allows you to push commits into the repository via ssh. The list below is for your convenience.

{|border="1" cellspacing="0" cellpadding="5"
! Project
! Read-only URL
! Push URL (Developers only)
! Atom feed
|-
| '''[http://gitorious.org/tmw TMW client]'''
| git://gitorious.org/tmw/mainline.git
| git@gitorious.org:tmw/mainline.git
| [http://gitorious.org/tmw/mainline/commits/master/feed.atom Atom]
|-
|colspan=4|This repository contains the client for The Mana World
|-
| '''[http://gitorious.org/tmwdata TMW client data]'''
| git://gitorious.org/tmwdata/mainline.git
| git@gitorious.org:tmwdata/mainline.git
| [http://gitorious.org/tmwdata/mainline/commits/master/feed.atom Atom]
|-
|colspan=4|This repository has the client data.
|-
| '''[http://gitorious.org/tmw/music TMW music]'''
| git://gitorious.org/tmw/music.git
| git@gitorious.org:tmw/music.git
| [http://gitorious.org/tmw/music/commits/master/feed.atom Atom]
|-
|colspan=4|This repository has the background music for the client.
|-
| '''[http://gitorious.org/tmwserv-data TMW server data]'''
| git://gitorious.org/tmwserv-data/mainline.git
| git@gitorious.org:tmwserv-data/mainline.git
| [http://gitorious.org/tmwserv-data/mainline/commits/master/feed.atom Atom]
|-
|colspan=4|This repository contains the data for TMWServ.
|-
| '''[http://gitorious.org/tmw/website TMW website]'''
| git://gitorious.org/tmw/website.git
| git@gitorious.org:tmw/website.git
| [http://gitorious.org/tmw/website/commits/master/feed.atom Atom]
|-
|colspan=4|This repository has our website.
|-
| '''[http://gitorious.org/tmw-eathena eAthena server]'''
| git://gitorious.org/tmw-eathena/mainline.git
| git@gitorious.org:tmw-eathena/mainline.git
| [http://gitorious.org/tmw-eathena/mainline/commits/master/feed.atom Atom]
|-
|colspan=4|This repository contains our hacked up eAthena.
|-
| '''[http://gitorious.org/tmw-eathena-data eAthena data]'''
| git://gitorious.org/tmw-eathena-data/mainline.git
| git@gitorious.org:tmw-eathena-data/mainline.git
| [http://gitorious.org/tmw-eathena-data/mainline/commits/master/feed.atom Atom]
|-
|colspan=4|This repository has the data for our eAthena.
|-
| '''[http://gitorious.org/tmwart TMW Art]'''
| git://gitorious.org/tmwart/mainline.git
| git@gitorious.org:tmwart/mainline.git
| [http://gitorious.org/tmwart/mainline/commits/master/feed.atom Atom]
|-
|colspan=4|This repository has some sources for our artwork.
|}

Git uses ssh's private/public key authentication for identifying committers. For development purposes you should clone the "push url", but this requires that you have:

# Signed up to gitorious.org
# Generated a private/public ssh keypair (if you haven't got this already)
# Filled in your public key in your account details on Gitorious

=== Cloning ===

If you simply <code>git clone</code> the URL without any additional arguments, it will create the repository in a directory called "mainline". This is generally not what you want. Hence, after the clone url, you should pass the name of the directory you want to have created (just like with Subversion):

$ git clone <clone_url> project

If you want to have all projects in one place, you probably want to do something like this:

$ mkdir tmw
$ cd tmw
$ git clone git@gitorious.org:tmw/mainline.git tmw
$ git clone git@gitorious.org:tmw-eathena-data/mainline.git eathena-data
etc.
or for all of them in one go (after the cd tmw step):
$ for repo in tmw tmwdata tmw-eathena tmw-eathena-data ; do git clone git://gitorious.org/${repo}/mainline.git $repo ; done

The way Gitorious works, we can't have one top-level "tmw" project under which we put all these repositories, since they're really separate projects. Gitorious allows multiple repositories for each project, but they are clones of each other (you can only create new ones by cloning existing ones). This allows anybody (not just the development team) to make clones and start hacking on them. Changes can easily be merged from one one repository to another. So instead of all the inconvenience with TMW forks we had in the past, now comes the time to encourage people to clone!

==== Shallow cloning for non-developers ====

One of our repositories, tmwdata, has grown quite large cause of its long history filled with relatively large binary files. If you are only interested in getting the latest version, and have no need to be able to push back changes, then you can make a shallow clone:

$ git clone --depth 1 git://gitorious.org/tmwdata/mainline.git tmwdata

== Working with git ==

=== Commit ===

From now on, a commit is something you do locally. Others won't see your change on Gitorious unless you push it there. You'll notice committing is very fast, and you can commit multiple times before you decide to push. You can also make corrections to your last commit.

Before you start committing, it is important to identify yourself to git, so that it can include the correct authorship information with your commit. You are no longer identified with a username, as was the case with Subversion. You can read exactly how to do this, as well as other useful information geared towards people switching from Subversion, on this page:

* '''Git - SVN Crash Course:''' http://git.or.cz/course/svn.html

=== Pushing ===

Once you have committed some stuff, you can push these to the repository on Gitorious using <code>git push</code>. This works since by default the push command pushes to a ''remote'' called ''origin'', and this remote is automatically set up when you clone. However, the push will fail if there have been new commits on the remote repository. In that case, you'll first have to pull in these changes (just like with Subversion, however Subversion allowed this as long as the same files weren't touched, git doesn't).

=== Pulling ===

When you want to get the latest changes from the repository on Gitorious, you generally use <code>git pull</code>. However, note that this command does not work when you have local changes. Also, when you have local commits, the pull command will generate a merge commit (and before that you may have to resolve some conflicts).

If you don't want to create merge commits, but would rather stack your local commits on top of any incoming commits, you should use <code>git pull --rebase</code>. This ''rebases'' your local commits on top of the incoming ones. You should never do this when you have pushed these commits elsewhere, so only do it when you are sure the commits are only on your machine.

If you have local changes and want to update your checkout, then there are several options:

* You commit your local changes, and do a pull, optionally with --rebase.
* Or you use <code>git stash</code> to place your local changes on a "hidden" stash. Then, after pulling, you apply your changes again with <code>git stash apply</code>.
* Or you create a patch of your local changes that you apply again after the pull. This approach sometimes makes sense, but I would say in general it's the more clumsy way to go. There are git commands that help you with this though.

=== Resolving conflicts ===

Rather similar to Subversion. When there are conflicts, a merge or a rebase will add conflict markers into files. Use <code>git status</code> to see which files remain in conflict and use <code>git add</code> on files to mark them as resolved. When you did a merge and you have resolved all conflicts, you commit. When you were doing a rebase of several commits, you do <code>git rebase --continue</code> instead.

=== Patch making ===

Git has an easy way to send patches to other people to review and commit for you. After you have made a commit, <code>git format-patch</code> will make a patch out of it. The patch includes your author information the commit message you gave, and all the changes to be done. The recipient can just <code>git am [patch file]</code> to apply the commit. After it has been pushed, you'll need to remove the patch from your local repository, <code>git reset --hard HEAD^</code> will do that. If you don't do that, you'll get a conflict when your patch is pulled from the central repository.

=== Good to know ===

Git has several useful commands to figure out the current state of your repository, your files and what recently changed. Below is a non-exhaustive list of commands that are useful to know:

* '''git branch''': Without any parameters, this command lists your local branches, and indicates which branch you're currently on.
* '''git whatchanged''': This shows a list of all commits on the current branch similar to <code>git log</code>, but with a list of the files that have been touched in each commit as well.
* '''git status''': This shows all kind of things about your current checkout: which files changed, untracked (unknown) files, added or removed files, files that have conflicts (during merge), etc. It also shows the status of your index, which is what git will commit once you do <code>git commit</code>. If you're new to git I would recommend to wait a bit with learning how to use the index, but not to avoid it forever.

There are also additional applications that help you with using git:

* '''gitk''': A simple but effective tool that visualizes the history and some of your current state. Run with <code>--all</code> to have it show all branches, otherwise it will just show stuff relevant to your current branch.
* '''tig''': A textual interface, rather similar to an email reader.
* '''git gui''': A gui tool like gitk which helps you prepare and perform your commits. Also makes it easier to understand the index concept.

=== git on Windows ===

When using git on Windows you might use [http://code.google.com/p/msysgit/ msysgit]. If you notice that some files seem to have changed after doing a fresh clone, you may want to disable <code>core.autocrlf</code> using <code>git config core.autocrlf false</code>. However, this is not recommended for contributors since the setting makes sure you don't commit Windows style newlines into the repository. When encountering this problem it is usually best to consult other developers about the affected files.

Forks

2009-12-09T19:59:31Z

Kane:

The open source nature of The Mana World allows everyone to use it as a base for creating an own game. A lot of teams have made use of this opportunity. Projects listed on this page don't work with the official client. Those that are are listed on the [[Servers]] article.

==Active forks==
These are projects which are still in active development.

===Aethyra===
A fork of TMW based on the eAthena branch with most of the content from the original TMW, with plenty of custom content.

* http://www.aethyra.com

===Mundo Dos DragÃµes ( World of Dragons )===
A Brazilian fork of TMW based on the eAthena branch with a completely new game world made from RPGMaker tiles.

* http://www.mundodosdragoes.org

===Soul Keepers Online===
A fork of Mana based on the Manaserv branch with a completely redesigned world using both TMW tiles and many other custom tiles from around the world.

* http://www.soulkeepersonline.com

==Inactive forks==
These are projects based on TMW which are unfortunately not active anymore.

===Sirus Online===
An eAthena-based branch formed by people frustrated with the management of Endless Online. It had a quite good start until most players and some developers decided to rather play and develop the original TMW.

===Damasca===
A project very similar in scope to The Mana World, although programmed in C# instead of C++. When the development slowed down because of insufficient manpower it was attempted to rescue the project by using TMWserv and the TMW client which were already much further in their development. Unfortunately it did not turn out so well.

* http://www.damasca.net

===Evol Online===
A French fork of TMW which used the TMW software with a completely new world made from RPGMaker XP graphics. It was inactive for a long time due to financial problems but the creator plans to revive the project soon with a codebase based on the 0.0.26 relase of tmw.

* http://www.evolonline.info/