The Mana World - User contributions [en]

Main Page

2007-11-09T20:41:15Z

Silene: Added link to image recoloring

{| cellspacing="3" cellpadding="3" width="100%"
|colspan="2" style="border: 1px solid lightgrey;"|
{| cellspacing="0" cellpadding="0"
| style="vertical-align: center; text-align: center; padding: 0px 20px 0px 20px; font-style: italic;"|Welcome to The Mana World wiki! This wiki is meant to provide information to our players, to provide an easy way to contribute to the development of certain parts of the game and to improve collaboration between people on the development team. We hope you will find what you are looking for. To be able to edit you have to login, but signing up is free and requires no activation.
|[[Image:Tmw logo.png|100px]]
|}
|-
|width="50%" style="border: 1px solid #e0c8b8; color: #000; background-color: #faeee6" valign="top"|
== Project information ==
* [[Project description]]
* [[Screenshots]]
* [[Developers]]
* [[FAQ]]
* [[System requirements]]
* [[Roadmap]]
* [[Ports]]
* [http://themanaworld.svn.sourceforge.net/viewvc/themanaworld/tmw/trunk/ChangeLog?view=markup ChangeLog from SVN trunk]

==== Reference ====

* [[Getting started]]
* [[Dependencies]]
* [[Servers]]
* [[Guilds]]
* [[Stats]]
* [[Monster reference]]
* [[Item reference]]
* [[Config settings]]

==== Organization ====

* [[Suggestions]]
* [[Bugs]]
* [http://themanaworld.org/archive/galerie.php Gallery]
* [[Developer meetings]]
* [[Quotes]]
* [[Summer 2005 real life developer meeting]]
|width="50%" style="border: 1px solid #c9c9ff; color: #000; background-color: #f3f3ff" valign="top"|
== Development ==

=== In Progress ===

:'''World:''' [[Backstory]], [[Geography]], [[Creatures]], [[Organizations]], [[Elements]]

:'''Game:''' [[Game systems]], [[Creature proposal]], [[Weapons]], [[Realtime action combat protocol|Realtime combat]]

:'''Graphics:''' [[Assignments]], [[Concept art]], [[Playerset development|Playersets]], [[Hairset development|Hairsets]], [[:Special:Newimages|New Images]]

:'''GUI / Interface:''' [[GUI development]], [[Menu interface system]]

:'''Sound:''' [[SFX|SoundFX]], [[Music]]

:'''Server:''' [[Server development]]

:'''RFCs:''' [[Rendering]], [[Action layers]], [[Improvement of the collision layer system|Collision system]], [[Being movement system|Movement system]], [[Logging]], [[Party system]]

=== Reference ===

:'''Game:''' [[Map development]], [[NPC development]], [[eAthena Scripting Standards]]

:'''Graphics:''' [[Guidelines]], [[Equipment development|Equipment sheets]], [[Tileset development|Tilesets]], [[Monsterset development|Monster sheets]], [[Particle engine]], [[Image dyeing]]

:'''GUI / Interface:''' [[Keyboard usage]]

:'''RFCs:''' [[Animations]]

:'''General:''' [[Joining the project]], [[Making a new release]], [[Hacking]], [[Translations]]

:'''Documentation:''' [http://themanaworld.org/tmwdox/ Client], [http://themanaworld.org/tmwservdox/ Server]

=== Outdated ===

:[[Important NPCs]], [[Finished NPCs]]
|-
|style="border: 1px solid #C58917; color: #000; background-color: #FFE87C" valign="top" colspan="2" |
== Currently active sections on the wiki==
*[[User:Crush/Wiki_Cleanup|Game system cleanup]]
*[[Backstory|Prehistory of the mana world]]
*[[Argaes|Argaes, the first continent]]

|}
__NOTOC__ __NOEDITSECTION__

Development:Image dyeing

2007-11-09T20:40:06Z

Silene: Description of image recoloring

== Simple colors and palettes ==

A pixel has a simple color if it is not black and if its non-zero RGB components are all equal.

There are seven simple colors:

* '''R'''ed
* '''G'''reen
* '''B'''lue
* '''C'''yan
* '''M'''agenta
* '''Y'''ellow
* '''W'''hite (gray, that is)

For a given color, there are 255 different values of pixels (from components equal to 1 to components equal to 255). For gray pixels, this is actually their intensity.

All the pixels of a given color can be dyed with a particular palette. A palette is a sequence of RGB colors, e.g. <tt>8c4b41,da9041,ffff41</tt>. Pixels of value 255 are transformed to color <tt>ffff41</tt>. Pixels of value 0 (unavailable) are left unchanged to black, that is <tt>000000</tt>. Other colors are applied to equally-spaced pixel values between these extreme values, so <tt>8c4b41</tt> to value 85, and <tt>da9041</tt> to value 170.

The color sequence can have from one color to 255 colors. For values with no explicit color, the associated color is linearly interpolated between the two closest value.

Pixels with complicated colors or without any dedicated palette are left unchanged by image recoloring. At most, the system allows to dye 1785 sets of pixels in an image independently.

== Specifying palettes ==

Whenever an image (usually a <tt>.png</tt> file) is specified in a <tt>.xml</tt> file, a palette can be appended to its name. The image is then automatically dyed on loading. For example, if one changes an image resource from <tt>foo.png</tt> to <tt>foo.png|W:#ffff00</tt>, then all the gray pixels of <tt>test.png</tt> will be replaced by shades of yellow, proportionally to their intensity.

Several palettes (one per simple color) can be appended to an image. For example, green and red pixels are recolored independently for image <tt>foo.png|G:palette1;R:palette2</tt>.

Palettes can either be specified as the name of a file containing a palette (format not yet defined) or directly defined as a color sequence. A sharp symbol '''#''' is prepended to this sequence, so that the system understands that the colors are embedded in the resource name.

== Dyeing sprites ==

When indicating the dyeable colors in an image, some palettes can be left unspecified. For example, the resource name <tt>foo.png|G;R:palette1;Y</tt> means that green, red, and yellow, pixels of the image have to be dyed. But no palettes are specified for green and yellow pixels.

These palettes will be specified at a higher level. If the <tt>foo.png</tt> file is part of a sprite description named <tt>bar.xml</tt>. Then palette specifications can be appended to the file name, e.g. <tt>bar.xml|palette2;palette3</tt>. These additional palettes are then propagated to any image loaded by <tt>bar.xml</tt> with unspecified palettes. So the <tt>foo.png</tt> is finally recolored with the dye <tt>G:palette2;R:palette1;Y:palette3</tt>.

Here is a simple example taken from actual game data. The <tt>data/monsters.xml</tt> file contains the descriptions of all the monsters. For black scorpions, the definition begins with

<monster id="1009" name="Black scorpion">
<sprite>monster-scorpion.xml|#0d1313,435a5a,879999,ffffff</sprite>
<sound event="hit">scorpion-hit1.ogg</sound>
...

The <tt>data/graphics/sprite/monster-scorpion.xml</tt> then describes the animation of any scorpion, whatever its color. It contains this line:

<imageset name="base" src="graphics/sprites/monster-scorpion.png|W" width="48" height="45" />

The <tt>monster-scorpion.png</tt> file is a grayscale image, hence the '''W''' color specifier, so that all its pixels are blackened (or dyed to brown or red for other species of scorpions). If it contained some non-gray pixels, these would not be recolored by the palette specified in the <tt>monsters.xml</tt> file.

== Implementation remark ==

Palettes have to be specified as part of the image and sprite resource names, so that they can be properly cached. If they were not, there would be collisions: All the recolored sprites would have the same color, the first one to be put in the cache for a given sprite definition. Since they are part of the resource names, they may as well be part of the filenames written in <tt>.xml</tt> files.

Archive:Translations

2007-08-18T12:14:17Z

Silene: Mentioned potfiles.

{{Status_yellow}}
Translations in The Mana World are handled by the
[http://www.gnu.org/software/gettext/ gettext] system. This page
presents an overwiew in the context of the game. Please refer to the
[http://www.gnu.org/software/gettext/manual/gettext.html manual] for
additional details.

== Gettext for users ==

Translations are supposed to work out-of-the-box. If they are not,
complain to the maintainer of your binary package. This section is
dedicated to users compiling <tt>tmw</tt> themselves.

When configuring, the script should tell you that Native Language
Support (NLS) is enabled. It just requires the presence of gettext on
your computer. From there, just compile and install like you usually
do, and it should work just fine. You just need to have properly set up
your system with respect to locales. If console applications, e.g.
<tt>man</tt>, are translated, then The Mana World will also be.

Note that the ''install'' part is mandatory for gettext to work. You
cannot run the program from your compilation directory and expect it to
be translated. Here is a work around:

./configure --localedir=$PWD/locale # plus your special options
make # compile as usual
cd po ; make install # whenever your .po file is modified

If you are not using the configure script, you need to tell your
compiler to set two macros. The <tt>ENABLE_NLS</tt> macro should be 1.
The <tt>LOCALEDIR</tt> macro should point to a directory structure
<tt>xy/LC_MESSAGES/tmw.mo</tt> you created. The <tt>tmw.mo</tt> file
is obtained by running the <tt>msgfmt</tt> tool.

== Gettext for translators ==

When creating a translation for a not yet supported language, get the
identifier of your language, as defined by ISO 639. It is usually two
letter long. Let us suppose it is ''xy''. Copy the <tt>po/tmw.pot</tt>
to <tt>po/xy.po</tt>, and add <tt>xy</tt> to the <tt>po/LINGUAS</tt>
file. That is all.

Now you can use your favorite text editor to modify the <tt>po/xy.po</tt>
file. There are also a few dedicated editors. For example, gtranslator in
Gnome and kbabel in KDE. The <tt>.po</tt> format is simple: on one
''msgid'' line, you read the original English sentence, on the next
''msgstr'' line, you write your translation. The encoding of your file
should be UTF-8, as it is the internal format of the game, and we do not
want it to waste time on converting between different charsets.

From time to time, modifications to the English strings will be merged
to your <tt>.po</tt> file. When it happens, translate the new empty
entries, and modify the old entries marked as ''fuzzy''. Then submit the
new file.

Sentences containing percent characters (especially when preceded by the
''c-format'' comment) need special care. They start special sequences that
ends with a letter. The game will replace them by words (<tt>%s</tt>) or
numbers (<tt>%d</tt>) or some other things. As a consequence, their order
need to be strictly respected in order not to crash the game. If
respecting the order makes it impossible to translate in your language,
you can use positional markers instead:

#, c-format
msgid "%s owns %s in one language"
msgstr "%2$s is owned by %1$s in another language"

== Gettext for developers ==

When you just needs the translation of a literal string (one given between
quotes), you can use the underscore macro.

displayToUser(_("For long swords, size does matter."));

If you are in a context where you cannot execute this macro, you can delay
the translation. Using a macro is still mandatory so that the strings can
automatically be extracted for translators.

static char const *msg = N_("For long swords, size does matter.");
...
displayToUser(gettext(msg));

A point has to be stressed: Using the <tt>_()</tt> and <tt>N_()</tt> macros on
anything else than a literal string, e.g. a variable or an expression, is
plain wrong.

You should also avoid crafting sentences by concatenating words, as it makes
it impossible to translate.

displayToUser(std::string(id1) + _(" owns ") + id2); # bad
displayToUser(strprintf(_("%s owns %s"), id1, id2); # good

Log messages and messages for internal errors (e.g. not caused by the user)
should not be translated. They will usually be sent back as bug-reports,
and we want to understand them.

Files containing translatable strings must have their name listed in
<tt>po/POTFILES.IN</tt>.

== Gettext for translation manager ==

As <tt>.po</tt> and <tt>.pot</tt> files indicate at which positions the
strings were extracted, adding or removing a single line to a source file
would be enough to completely modify all the files of the <tt>po</tt>
directory. As a consequence, a developer should never update the
translations after modifying a source file, so as to not pollute the
svn repository.

When preparing a release, during string freeze, one single developer (it
does not have to be always the same one, but it can help in case of
gettext version discrepancies) should be chosen to run

cd po ; make update-po

and commit the resulting modifications. Then, just before releasing, once
translators have sent or committed their modifications to <tt>.po</tt>
files, it should be run again, so that packagers have access to updated
files.

Archive:Translations

2007-08-07T06:54:20Z

Silene: A few additional comments on gettext

Translations in The Mana World are handled by the
[http://www.gnu.org/software/gettext/ gettext] system. This page
presents an overwiew in the context of the game. Please refer to the
[http://www.gnu.org/software/gettext/manual/gettext.html manual] for
additional details.

== Gettext for users ==

Translations are supposed to work out-of-the-box. If they are not,
complain to the maintainer of your binary package. This section is
dedicated to users compiling <tt>tmw</tt> themselves.

When configuring, the script should tell you that Native Language
Support (NLS) is enabled. It just requires the presence of gettext on
your computer. From there, just compile and install like you usually
do, and it should work just fine. You just need to have properly set up
your system with respect to locales. If console applications, e.g.
<tt>man</tt>, are translated, then The Mana World will also be.

Note that the ''install'' part is mandatory for gettext to work. You
cannot run the program from your compilation directory and expect it to
be translated. Here is a work around:

./configure --localedir=$PWD/locale # plus your special options
make # compile as usual
cd po ; make install # whenever your .po file is modified

If you are not using the configure script, you need to tell your
compiler to set two macros. The <tt>ENABLE_NLS</tt> macro should be 1.
The <tt>LOCALEDIR</tt> macro should point to a directory structure
<tt>xy/LC_MESSAGES/tmw.mo</tt> you created. The <tt>tmw.mo</tt> file
is obtained by running the <tt>msgfmt</tt> tool.

== Gettext for translators ==

When creating a translation for a not yet supported language, get the
identifier of your language, as defined by ISO 639. It is usually two
letter long. Let us suppose it is ''xy''. Copy the <tt>po/tmw.pot</tt>
to <tt>po/xy.po</tt>, and add <tt>xy</tt> to the <tt>po/LINGUAS</tt>
file. That is all.

Now you can use your favorite text editor to modify the <tt>po/xy.po</tt>
file. There are also a few dedicated editors. For example, gtranslator in
Gnome and kbabel in KDE. The <tt>.po</tt> format is simple: on one
''msgid'' line, you read the original English sentence, on the next
''msgstr'' line, you write your translation. The encoding of your file
should be UTF-8, as it is the internal format of the game, and we do not
want it to waste time on converting between different charsets.

From time to time, modifications to the English strings will be merged
to your <tt>.po</tt> file. When it happens, translate the new empty
entries, and modify the old entries marked as ''fuzzy''. Then submit the
new file.

Sentences containing percent characters (especially when preceded by the
''c-format'' comment) need special care. They start special sequences that
ends with a letter. The game will replace them by words (<tt>%s</tt>) or
numbers (<tt>%d</tt>) or some other things. As a consequence, their order
need to be strictly respected in order not to crash the game. If
respecting the order makes it impossible to translate in your language,
you can use positional markers instead:

#, c-format
msgid "%s owns %s in one language"
msgstr "%2$s is owned by %1$s in another language"

== Gettext for developers ==

When you just needs the translation of a literal string (one given between
quotes), you can use the underscore macro.

displayToUser(_("For long swords, size does matter."));

If you are in a context where you cannot execute this macro, you can delay
the translation. Using a macro is still mandatory so that the strings can
automatically be extracted for translators.

static char const *msg = N_("For long swords, size does matter.");
...
displayToUser(gettext(msg));

A point has to be stressed: Using the <tt>_</tt> and <tt>N_</tt> macros on
anything else than a literal string, e.g. a variable or an expression, is
plain wrong.

You should also avoid crafting sentences by concatening words, as it makes
it impossible to translate.

displayToUser(std::string(id1) + _(" owns ") + id2); # bad
displayToUser(strprintf(_("%s owns %s"), id1, id2); # good

Log messages and messages for internal errors (e.g. not caused by the user)
should not be translated. They will usually be sent back as bug-reports,
and we want to understand them.

== Gettext for translation manager ==

As <tt>.po</tt> and <tt>.pot</tt> files indicate at which positions the
strings were extracted, adding or removing a single line to a source file
would be enough to completely modify all the files of the <tt>po</tt>
directory. As a consequence, a developer should never update the
translations after modifying a source file, so as to not pollute the
svn repository.

When preparing a release, during string freeze, one single developer (it
does not have to be always the same one, but it can help in case of
gettext version discrepancies) should be chosen to run

cd po ; make update-po

and commit the resulting modifications. Then, just before releasing, once
translators have sent or committed their modifications to <tt>.po</tt>
files, it should be run again, so that packagers have access to updated
files.

Main Page

2007-08-06T12:51:43Z

Silene: Added link to gettext documentation

{| cellspacing="3" cellpadding="3" width="100%"
|colspan="2" style="border: 1px solid lightgrey;"|
{| cellspacing="0" cellpadding="0"
| style="vertical-align: center; text-align: center; padding: 0px 20px 0px 20px; font-style: italic;"|Welcome to The Mana World wiki! This wiki is meant to provide information to our players, to provide an easy way to contribute to the development of certain parts of the game and to improve collaboration between people on the development team. We hope you will find what you are looking for. To be able to edit you have to login, but signing up is free and requires no activation.
|[[Image:Tmw logo.png|100px]]
|}
|-
|width="50%" style="border: color: #000;"|
|-
|width="50%" style="border: color: #000;"|
|-
|width="50%" style="border: 1px solid #C58917; color: #000; background-color: #FFE87C" valign="top"|
<div align="center">
=== Top Priority Projects! ===
Please direct your primary attention to these pages:
<hr>
:[[Backstory]], [[Things to do]], [[Roadmap]], [[Assignments]]</div>

|width="50%" style="border: 1px solid #E8A317; color: #000; background-color: #FFF380"|
<div align="center">
=== Important Projects ===
These pages are important, but not top priority. You should focus on these second:
<hr>
:[[Geography]], [[Concept art]], [[Monsterset development|Monsters]], [[Tileset development|Tilesets]], [[Creatures]], [[Action layers]]</div>

|-
|width="50%" style="border: 1px solid #e0c8b8; color: #000; background-color: #faeee6" valign="top"|
== Project information ==
* [[Project description]]
* [[Screenshots]]
* [[Developers]]
* [[FAQ]]
* [[System requirements]]
* [[Roadmap]]
* [[Ports]]
* [http://themanaworld.svn.sourceforge.net/viewvc/themanaworld/tmw/trunk/ChangeLog?view=markup ChangeLog from SVN trunk]

==== Reference ====

* [[Getting started]]
* [[Dependencies]]
* [[Servers]]
* [[Guilds]]
* [[Stats]]
* [[Monster reference]]
* [[Item reference]]
* [[Config settings]]

==== Organization ====

* [[Suggestions]]
* [[Bugs]]
* [http://themanaworld.org/archive/galerie.php Gallery]
* [[Developer meetings]]
* [[Quotes]]
* [[Summer 2005 real life developer meeting]]
|width="50%" style="border: 1px solid #c9c9ff; color: #000; background-color: #f3f3ff" valign="top"|
== Development ==

=== In Progress ===

:'''World:''' [[Backstory]], [[Geography]], [[Creatures]], [[Organizations]], [[Elements]]

:'''Game:''' [[Game systems]], [[Creature proposal]], [[Weapons]], [[Realtime action combat protocol|Realtime combat]]

:'''Graphics:''' [[Assignments]], [[Concept art]], [[Playerset development|Playersets]], [[Hairset development|Hairsets]], [[:Special:Newimages|New Images]]

:'''GUI / Interface:''' [[GUI development]], [[Menu interface system]]

:'''Sound:''' [[SFX|SoundFX]], [[Music]]

:'''Server:''' [[Server development]]

:'''RFCs:''' [[Rendering]], [[Action layers]], [[Improvement of the collision layer system|Collision system]], [[Being movement system|Movement system]], [[Logging]], [[Party system]]

=== Reference ===

:'''Game:''' [[Map development]], [[NPC development]], [[eAthena Scripting Standards]]

:'''Graphics:''' [[Guidelines]], [[Equipment development|Equipment sheets]], [[Tileset development|Tilesets]], [[Monsterset development|Monster sheets]], [[Particle engine]]

:'''GUI / Interface:''' [[Keyboard usage]]

:'''RFCs:''' [[Animations]]

:'''General:''' [[Joining the project]], [[Making a new release]], [[Hacking]], [[Translations]]

:'''Documentation:''' [http://themanaworld.org/tmwdox/ Client], [http://themanaworld.org/tmwservdox/ Server]

=== Outdated ===

:[[Important NPCs]], [[Finished NPCs]]
<br><br><br><br><br>
|}
__NOTOC__ __NOEDITSECTION__

Archive:Translations

2007-08-06T12:49:59Z

Silene: Added part about managing translations

Translations in The Mana World are handled by the
[http://www.gnu.org/software/gettext/ gettext] system. This page
presents an overwiew in the context of the game. Please refer to the
[http://www.gnu.org/software/gettext/manual/gettext.html manual] for
additional details.

== Gettext for users ==

Translations are supposed to work out-of-the-box. If they are not,
complain to the maintainer of your binary package. This section is
dedicated to users compiling <tt>tmw</tt> themselves.

When configuring, the script should tell you that Native Language
Support (NLS) is enabled. It just requires the presence of gettext on
your computer. From there, just compile and install like you usually
do, and it should work just fine. You just need to have properly set up
your system with respect to locales. If console applications, e.g.
<tt>man</tt>, are translated, then The Mana World will also be.

Note that the ''install'' part is mandatory for gettext to work. You
cannot run the program from your compilation directory and expect it to
be translated. Here is a work around:

./configure --localedir=$PWD/locale # plus your special options
make # compile as usual
cd po ; make install # whenever your .po file is modified

== Gettext for translators ==

When creating a translation for a not yet supported language, get the
identifier of your language, as defined by ISO 639. It is usually two
letter long. Let us suppose it is ''xy''. Copy the <tt>po/tmw.pot</tt>
to <tt>po/xy.po</tt>, and add <tt>xy</tt> to the <tt>po/LINGUAS</tt>
file. That is all.

Now you can use your favorite text editor to modify the <tt>po/xy.po</tt>
file. There are also a few dedicated editors. For example, gtranslator in
Gnome and kbabel in KDE. The <tt>.po</tt> format is simple: on one
''msgid'' line, you read the original English sentence, on the next
''msgstr'' line, you write your translation.

From time to time, modifications to the English strings will be merged
to your <tt>.po</tt> file. When it happens, translate the new empty
entries, and modify the old entries marked as ''fuzzy''. Then submit the
new file.

Sentences containing percent characters (especially when preceded by the
''c-format'' comment) need special care. They start special sequences that
ends with a letter. The game will replace them by words (<tt>%s</tt>) or
numbers (<tt>%d</tt>) or some other things. As a consequence, their order
need to be strictly respected in order not to crash the game. If
respecting the order makes it impossible to translate in your language,
you can use positional markers instead:

#, c-format
msgid "%s owns %s in one language"
msgstr "%2$s is owned by %1$s in another language"

== Gettext for developers ==

When you just needs the translation of a literal string (one given between
quotes), you can use the underscore macro.

displayToUser(_("For long swords, size does matter."));

If you are in a context where you cannot execute this macro, you can delay
the translation. Using a macro is still mandatory so that the strings can
automatically be extracted for translators.

static char const *msg = N_("For long swords, size does matter.");
...
displayToUser(gettext(msg));

A point has to be stressed: Using the <tt>_</tt> and <tt>N_</tt> macros on
anything else than a literal string, e.g. a variable or an expression, is
plain wrong.

You should also avoid crafting sentences by concatening words, as it makes
it impossible to translate.

displayToUser(std::string(id1) + _(" owns ") + id2); # bad
displayToUser(strprintf(_("%s owns %s"), id1, id2); # good

== Gettext for translation manager ==

As <tt>.po</tt> and <tt>.pot</tt> files indicate at which positions the
strings were extracted, adding or removing a single line to a source file
would be enough to completely modify all the files of the <tt>po</tt>
directory. As a consequence, a developer should never update the
translations after modifying a source file, so as to not pollute the
svn repository.

When preparing a release, during string freeze, one single developer (it
does not have to be always the same one, but it can help in case of
gettext version discrepancies) should be chosen to run

cd po ; make update-po

and commit the resulting modifications. Then, just before releasing, once
translators have sent or committed their modifications to <tt>.po</tt>
files, it should be run again, so that packagers have access to updated
files.

Archive:Translations

2007-08-06T10:29:28Z

Silene: Added part for developers

Translations in The Mana World are handled by the
[http://www.gnu.org/software/gettext/ gettext] system. This page
presents an overwiew in the context of the game. Please refer to the
[http://www.gnu.org/software/gettext/manual/gettext.html manual] for
additional details.

== Gettext for users ==

Translations are supposed to work out-of-the-box. If they are not,
complain to the maintainer of your binary package. This section is
dedicated to users compiling <tt>tmw</tt> themselves.

When configuring, the script should tell you that Native Language
Support (NLS) is enabled. It just requires the presence of gettext on
your computer. From there, just compile and install like you usually
do, and it should work just fine. You just need to have properly set up
your system with respect to locales. If console applications, e.g.
<tt>man</tt>, are translated, then The Mana World will also be.

Note that the ''install'' part is mandatory for gettext to work. You
cannot run the program from your compilation directory and expect it to
be translated. Here is a work around:

./configure --localedir=$PWD/locale # plus your special options
make # compile as usual
cd po ; make install # whenever your .po file is modified

== Gettext for translators ==

When creating a translation for a not yet supported language, get the
identifier of your language, as defined by ISO 639. It is usually two
letter long. Let us suppose it is ''xy''. Copy the <tt>po/tmw.pot</tt>
to <tt>po/xy.po</tt>, and add <tt>xy</tt> to the <tt>po/LINGUAS</tt>
file. That is all.

Now you can use your favorite text editor to modify the <tt>po/xy.po</tt>
file. There are also a few dedicated editors. For example, gtranslator in
Gnome and kbabel in KDE. The <tt>.po</tt> format is simple: on one
''msgid'' line, you read the original English sentence, on the next
''msgstr'' line, you write your translation.

From time to time, modifications to the English strings will be merged
to your <tt>.po</tt> file. When it happens, translate the new empty
entries, and modify the old entries marked as ''fuzzy''. Then submit the
new file.

Sentences containing percent characters (especially when preceded by the
''c-format'' comment) need special care. They start special sequences that
ends with a letter. The game will replace them by words (<tt>%s</tt>) or
numbers (<tt>%d</tt>) or some other things. As a consequence, their order
need to be strictly respected in order not to crash the game. If
respecting the order makes it impossible to translate in your language,
you can use positional markers instead:

#, c-format
msgid "%s owns %s in one language"
msgstr "%2$s is owned by %1$s in another language"

== Gettext for developers ==

When you just needs the translation of a literal string (one given between
quotes), you can use the underscore macro.

displayToUser(_("For long swords, size does matter."));

If you are in a context where you cannot execute this macro, you can delay
the translation. Using a macro is still mandatory so that the strings can
automatically be extracted for translators.

static char const *msg = N_("For long swords, size does matter.");
...
displayToUser(gettext(msg));

A point has to be stressed: Using the <tt>_</tt> and <tt>N_</tt> macros on
anything else than a literal string, e.g. a variable or an expression, is
plain wrong.

You should also avoid crafting sentences by concatening words, as it makes
it impossible to translate.

displayToUser(std::string(id1) + _(" owns ") + id2); # bad
displayToUser(strprintf(_("%s owns %s"), id1, id2); # good

== Gettext for translation manager ==

Archive:Translations

2007-08-06T09:54:02Z

Silene: The part for translators

Archive:Translations

2007-08-06T09:06:34Z

Silene: First part of a gettext-dedicated page

Translations in The Mana World are handled by the
[[http://www.gnu.org/software/gettext/ gettext]] system. This page
presents an overwiew in the context of the game. Please refer to the
[[http://www.gnu.org/software/gettext/manual/gettext.html manual]] for
more details.

== Gettext for users ==

Translations are supposed to work out-of-the-box. If they are not,
complain to the maintainer of your binary package. This section is
dedicated to users compiling <tt>tmw</tt> themselves.

When configuring, the script should tell you that Native Language
Support (NLS) is enabled. It just requires the presence of gettext on
your computer. From there, just compile and install like you usually
do, and it should work just fine. You just need to have properly set up
your system with respect to locales. If console applications, e.g.
<tt>man</tt>, are translated, then The Mana World will also be.

Note that the ''install'' part is mandatory for gettext to work. You
cannot run the program from your compilation directory and expect it to
be translated. Here is a work around:

./configure --localedir=$PWD/locale # plus your special options
make # compile as usual
cd po ; make install # whenever your .po file is modified

== Gettext for translators ==

== Gettext for developers ==

== Gettext for translation manager ==

Development:Joining the project

2007-07-28T12:38:51Z

Silene:

So you want to join this project, but you have little or no idea how to get into? The Mana World development team is not a closed circle like other projects. You needn't apply to anyone or ask for "being taken into the team". You don't have to ask for permission to work on something or wait for someone to assign a task to you. A team member is basically everyone who volunteers to do something for the project.

But keep in mind that we do have a quality standard and will not add game content that isn't good enough in the teams opinion. Also it might be good to ask what is needed and what is being worked on to make sure that you aren't wasting your time.

This page should provide you with the necessary starting points. It can always be rather difficult to know what to start with, especially when you're just jumping in. However, any help is most welcome and with some time you should be able to decide what you want to work on yourself.

== General organisation ==

To know what is currently happening or what could be worked on, we have a few important pages on the wiki. The [[roadmap]] provides a planning for upcoming releases, where sometimes tasks are assigned or listed to be picked up by somebody. There is a [[bugs|bugs page]] holding a list of known problems which are generally free for anybody to look into. Finally there is the [[suggestions|suggestions page]] where anybody can put his wishlist for the game, and where anybody can look for inspiration when looking for something to do.

These pages and others are linked from the organisation section on the [[Main Page|main page]].

It is very important for you to be available for discussion with other developers on [http://forums.themanaworld.org/viewtopic.php?t=747 our IRC channels] from time to time, as we do most of our discussions there. We also have two important mailing lists, one for development discussion and one that shows all changes made to the source code, that you should subscribe to:

* http://lists.sourceforge.net/lists/listinfo/themanaworld-devel<br>The developers mailing list where discussion about the project happens.
* http://lists.sourceforge.net/lists/listinfo/themanaworld-commit<br>The commit mailing list, so that you can easily stay up to date about the latest change to the source code.

Finally, although not required, you are invited to visit our forums:

* http://forums.themanaworld.org/

== Programmers ==

Our current projects include the existing client which is used with eAthena (a Ragnarok Online server emulator), and a new client/server combination which isn't used yet but is being worked on. For the currently used eAthena client, check out <code>tmw/branches/0.0</code>. For the new client/server combination, check out both <code>tmwserv/trunk</code> and <code>tmw/trunk</code>. See our [https://sourceforge.net/svn/?group_id=106790 Subversion project page] about how to do this. Try to browse the source to see if you can get a bit familiar with them.

When you are searching for something you could do you should check our bug- and task tracking system on http://mantis.themanaworld.org. It lists a lot of small and large problems on many different areas. Just pick one that interests you.

Your first contributions could be in the form of patches submitted to the SourceForge patches tracker or the developer mailing list. Please check the [[Hacking|hacking guidelines]] before writing your patches. If it turns out you like the project and you want to keep contributing for a long period, we'll consider giving you write access to subversion and from then on you can commit your changes to the source yourself.

== Artists ==

Our graphic design team can always use help. May it be just an inventory icon, a [[Monsterset development|new monster]] or a [[Tileset development|complete Tileset]]. Improving existing graphics is also always welcome. When you want to do a task, then you should announce it on the [http://forums.themanaworld.org/viewforum.php?f=8 Graphic Development Forum], post regular updates there and add yourself to the [[Assignments]] Page. But be sure to read our [[Guidelines|style guidelines]] first.

You should also hang out on our graphic design channel #tmwart [http://forums.themanaworld.org/viewtopic.php?t=747]. It is good for a little brainstorming session or for showing small pieces of work you don't want to show to the whole community yet.

== Mappers ==

Creating maps is a task that does not require much experience but is a great way to add more value to the game. More information about how to map can be found on the article [[Mapping Tutorial]]. Be sure to check out our [[Map development|Map development guidelines]], too.

Archive:Combat system

2007-07-12T09:30:23Z

Silene:

{{Category_gameconcept}}
{{Category_programming}}
{{Status_outdated}}
== '''Does it work?''' ==

I'm convinced that the greater majority of the developers of TMW are looking for a free-form style of combat that set SoM apart from other RPGs of its class. This system requires skill and alertness on the part of the player, as well as preparedness and training on the part of the character in order for fights to succeed. It also engages the player in combat, by giving him total control over his character's actions.

The real issue with a realtime combat system is feasibility and server traffic. Our theoretical server has about 1mbps upstream, so we have to make packets as small and infrequent as possible.

When a player gives a command to the game, such as cast spell, move left, use potion, etc. A packet of data is sent to the server. The client can requlate actions so that no more than 1 can be performed every 500ms, so as to prevent high downstream server traffic. A player command packet contains 1 variable, a short integer which is the ID of the given command. A packet of this size takes approximately 2 bytes of space.

The server takes this command and interprets it into character movement. When the servers clock cycle reaches a certain interval (250ms for example), it builds an update packet for each player. This update packet contains information on each Being '''within the player's viewpoint only'''- it's position(x,y) as well as the action that being is currently performing. The client recieves this data, then interprets it into a visual model. The size of a packet like this (containing 3 short intergers) is approximately 6 bytes per onscreen character.

'''Math Time:'''
In a heavy load area (50 characters), the update packet contains 300 bytes of data.

We are able to send 1,048,576 bytes per second, or 262,144 per quarter second on our projected server limit. This equates to serving up to 873 high traffic area players per quarter-second without a flaw. If the number of players increases beyond the server's capacity, the server's response interval can be cut in half to accomidate twice as many high-traffic players. Needless to say, this packet rate and size is small enough to run easily on even the slowest modems.

In a more common scenario, however, the player will only need about 10 active characters onscreen, which means 60 bytes per packet, or 4369 players supported by the server under this method, and all within the projected server limit (which means no lag, at least not serverside).

:If this page gets rewritten, it should take into account a lot more things into its calculations. In particular, if you consider the IP+UDP+enet overhead and the seven monsters walking around a player on average, you have to add at the very least 100 bytes at each tick and for each player. So for the high traffic area example, you are down to 650 players. And for the more common scenario, you are down to 1600 players. And with the 100ms tick of the current tmwserv, you are down to 250 players and 650 players respectively. [[User:Silene|silene]] 11:30, 12 July 2007 (CEST)

As you can see, this method is more than able to cope with realtime combat, and a player feels only a quarter of a second delay '''maximum''' before his command executes on his own screen and on everyone elses. That's an acceptable delay to trade for realtime combat.

:This delay has to take into account the communications. Assuming 75ms communications and four ticks per second, you get 275ms on average and 400ms on maximum. With the current tmwserv, it is 200ms on average and 250ms on maximum. [[User:Silene|silene]] 11:30, 12 July 2007 (CEST)

----
== '''This is it''' ==

Ok, so here's the breakdown of the real time, active, directly controlled combat.

Movement - players move when they send a command to move. There are two types of move command-initial movement and end movement. An initial movement packet tells the server to start moving the player until the end movement packet is recieved. This is sent when the key (or mouse click) is first pressed. The second is the end movement packet. The end movement packet tells the server to stop moving the character at a regular rate. This way, movement can be smooth and continuous, rather than pixel by pixel, like some have suggested it will end up.

First off, players have a bar in the screen that measures time, since the last attack. When the player presses the attack key, and the bar is full, he makes an attack (there are no intermediate attacks, to reduce downstream server traffic).

Charge attacks exist too. To execte a charge attack, the player can hold a button. when the button is pressed, the server gets a start message. When it is released, he sends another attack message. The server calculates the amount of time between the two packets, then executes the corresponding charge attack. There are 10 attacks for each weapon type, and they are learned at weapon skill levels that are multiples of 10. Also, to perform a charge attack, the player must be wielding a weapon of the correct type, and that weapon must be built with synthesis up to level X. (see the EquipmentSystem for more information on weapon synthesis). While charging, the player moves a bit slower than normal.

When the player wishes to use a spell, he opens the context ring menu, (spacebar or right click with the mouse), selects the proper spell, then chooses the appropriate target within range (be it an area or a being). The player then goes through a short spellcasting animation, during which time he can be interrupted by a critical attack (10% or more of his HP in damage). After that, the spell is cast and executed. Spell casting is also regulated by the time bar, however, some spells may cause a freeze longer than normal after being cast. This depends on the specific spell, as well as the caster's magic level (higher mastery = lower freeze)

While I personally believe the mouse is one of the great evils of computer gaming, some members of the team feel that it is a necessary evil to include in the system. For this purpose, I've created a list of mouse controls and corresponding keyboard controls.

Move - Hold the left mouse button in the general area of the screen you want to
move. The character will follow the mouse to that point.
Attack - a fast click near the player causes him to attack.
Charge - holding the mouse directly over the character for a moment causes him to
start charging. To move while charging, drag the mouse away from the
player without letting go of the left button.

I'm not totally sure about how the mouse controlled model will work, but we can edit it as needed to ensure that it engages players in the same way as keyboard control.

On a final note, some have expressed concern with lag issues as associated with our current system. The main argument is that if a long lag hits, players will be at the whim of monsters without a chance to respond. However, since the client and server will be sending packets constantly back and forth (for movement, attack, or even when idle) it is easy to fix the system such that monsters cannot attack a player who has not sent an update packet in the last 2 seconds or so (remembering that monsters, like players, can only attack twice a second at best, and usually only once). This will avoid players having to worry about death simply because of lag.

User:Silene

2006-08-26T22:08:08Z

Silene: A few details about myself

I am mainly a C++ programmer and I am working on an old Linux platform. I enjoy contributing to 2D free software games, going from one project to another depending on my mood.

I heavily contributed to [http://www.wesnoth.org/ Battle for Wesnoth], till the first stable release (1.0) got out. I then worked on [http://www.freeciv.org/ Freeciv]. Nowadays, I am helping with the programming of the [http://www.themanaworld.org/ Mana World] own server. On the serious side, I am also one of the authors of a [http://www.boost.org/ Boost] library. My name can be found in the changelogs of several other projects, [http://gcc.gnu.org/ GCC] for example.

In the real life, I am finishing a PhD thesis on formal certification of numerical applications. The [http://lipforge.ens-lyon.fr/www/gappa/ Gappa] tool resulted from this work; it was essential in designing the [http://lipforge.ens-lyon.fr/www/crlibm/ CRlibm] project. More details on myself can be found on my [http://perso.ens-lyon.fr/guillaume.melquiond/ homepage]. You can contact me at [mailto:guillaume.melquiond@gmail.com guillaume.melquiond@gmail.com] if you ever need to.

Development:Developers

2006-08-26T21:25:04Z

Silene: Going with my real name

== Active ==
{| border="0" cellspacing="0" cellpadding="5" width="100%" style="border-bottom: 2px solid #efdead"
! style="background:#efdead;" width="150px" align="left" | Name
! style="background:#efdead;" width="200px" align="left" | Occupation
! style="background:#efdead;" width="150px" align="left" | Location

{{dev1| [[User:Bear|Bear]] | Scripter | USA}}
{{dev2| [[User:Bertram|Bertram]] | Programmer, Debian package maintainer | France}}
{{dev1| [[User:BjÃ¸rn|BjÃ¸rn Lindeijer]] | Lead Programmer | The Netherlands}}
{{dev2| [[User:Crush|Crush]] | Pixel artist, mapper, programmer | Germany}}
{{dev1| [[User:deviexx|deviexx]] | Content manager | }}
{{dev2| [[User:Doener|Doener]] | Programmer | Germany}}
{{dev1| [[User:ElvenProgrammer|ElvenProgrammer]] | Project leader, programmer | Italy}}
{{dev2| [[User:Irukard|Irukard]] | Pixel artist | Poland}}
{{dev1| [[User:maci|maci]] | User support | Germany}}
{{dev2| [[User:hackgrid|Matt]] | Blabbering idiot | Germany}}
{{dev1| [[User:Modanung|Modanung]] | Pixel artist, concept artist | The Netherlands}}
{{dev2| [[User:Nym|nym]] | Programmer | Australia}}
{{dev1| [[User:Pajarico|Pajarico]] | Art, writer | Spain}}
{{dev2| [[User:Pauan|Pauan]] | Graphics artist | USA}}
{{dev1| [[User:Platyna|Platyna]] | Slackware package maintainer | Poland}}
{{dev2| [[User:Rotonen|Rotonen]] | Head of art, story and music | Finland}}
{{dev1| [[User:Silene|Guillaume Melquiond (Silene)]] | Programmer | France}}
{{dev2| [[User:Talaroc|Talaroc]] | Pixel artist | }}
{{dev1| [[User:Tuxtgz|Tuxtgz]] | Webinterface-Programmer|Germany}}
|}

== Retired ==
{| border="0" cellspacing="0" cellpadding="5" width="100%" style="border-bottom: 2px solid #efdead"
! style="background:#efdead;" width="75px" align="left" | Name
! style="background:#efdead;" width="200px" align="left" | Occupation
! style="background:#efdead;" width="200px" align="left" | Location

{{dev1| [[User:Gagaofdeath|Andrej Sinicyn]] | Programmer | Germany}}
{{dev2| [[User:Catfish_Man|Catfish_Man]] | Mac port | USA}}
{{dev1| [[User:Clef|Clef]] | Pixel artist | }}
{{dev2| [[User:Demon|Demon]] | Pixel artist | }}
{{dev1| [[User:Golgo|Golgo]] | Pixel artist | }}
{{dev2| [[User:Javila|Javila]] | Programmer | Brazil}}
{{dev1| [[User:kindjal|kindjal]] | Programmer | France, currently Italy}}
{{dev2| [[User:Kinetic|Kinetic]] | Pixel artist | USA}}
{{dev1| [[User:Kyokai|Kyokai]] | Game systems designer | }}
{{dev2| [[User:Maester Pixel|Maester Pixel]] | Pixel artist | USA}}
{{dev1| [[User:Magick|Magick]] | Musician | }}
{{dev2| [[User:Mkael|Mkael]] | Concept artist | Finland}}
{{dev1| [[User:Mra|Mra]] | Programmer | Germany}}
{{dev2| [[User:Neko-mon|Neko-mon]] | Pixel artist | Brazil}}
{{dev1| [[User:Sora|Sora]] | Pixel artist | Poland}}
{{dev2| [[User:Sull|Sull]] | Pixel artist | Canada}}
{{dev1| [[User:Usiu|Usiu]] | Programmer | Poland}}
|}

File talk:ManaWorldMap.jpg

2006-08-26T20:12:50Z

Silene: Comments on the Manaworld map

I have several concerns about this map. The biggest is the river system. Fact: water flows from mountain sources to the sea by following the strongest slope. As a consequence,
* Rivers don't go from the sea to the sea.
* Rivers do not run alongside the coasts.
* Deltas exist only when the ground is really flat.
* Water does not flow out of a lake by the same point it flows in it.
On the positive side, I find that the land masses are well balanced.
--[[User:Silene|silene]] 22:12, 26 August 2006 (CEST)

Archive:Communication protocol

2006-08-14T21:00:34Z

Silene: Added connect messages

Here be documented our own communication protocol. For the latest list of all messages and their contents, see [http://svn.sourceforge.net/viewcvs.cgi/themanaworld/tmwserv/trunk/src/defines.h?view=markup defines.h].

== Server structure ==

When we talk about the server, we mean the combination of several services that will run in parallel. The ''account server'' handles player accounts and their characters. The ''game server'' handles the maps, beings and items. Finally the ''chat server'' handles chat channels. In order to eventually balance the load on processing and bandwidth, and also to be prepared for hardware failures, we envision the possibility to run multiple of the same server.

== Login sequence ==

The client starts with connecting to the account server. This server allows the client to register or login, to manage the characters in an account and to select a character to play.

<pre>
1a. PAMSG_REGISTER { L version, "username", "password", "email" }
APMSG_REGISTER_RESPONSE { 0 }

1b. PAMSG_LOGIN { L version, "username", "password" }
APMSG_LOGIN_RESPONSE { 0 }

(for each char)
APMSG_CHAR_INFO { B slot, S name, B gender, B hair style, B hair color,
B level, W money, W*6 stats }

2a. PAMSG_UNREGISTER { }
APMSG_UNREGISTER_RESPONSE { 0 }

2b. PAMSG_LOGOUT { }
APMSG_LOGOUT_RESPONSE { 0 }
...

2c. PAMSG_CHAR_SELECT { index }
APMSG_CHAR_SELECT_RESPONSE { 0, token, "gameserver", W port, "chatserver", W port }
PGMSG_CONNECT { token }
GPMSG_CONNECT_RESPONSE { 0 }
PCMSG_CONNECT { token }
CPMSG_CONNECT_RESPONSE { 0 }
</pre>

== Movement and combat ==

Protocol in development, see article about the [[being movement system]].

=== Switching maps ===

While walking around the player will come upon locations that bring him to other maps. It is possible that the new map is hosted on another game server. Since the game servers are not connected to each other, they will ask the account server for the details of the other server and for a magic token. This information will then be sent to the client along with the map change message.

<pre>
1a. (if the map is not on the same map server)
GAMSG_PLAYER_MAP_CHANGE { newmap }
AGMSG_PLAYER_MAP_CHANGE_REPONSE { 0, token, "gameserver", W port }

GPMSG_PLAYER_MAP_CHANGE { "mapname", x, y, B new server [, token, "gameserver", W port] }

(if the map is not on the same map server)
PGMSG_CONNECT { token }
GPMSG_CONNECT_RESPONSE { 0 }
</pre>

== Chatting ==

<pre>
1a. PCMSG_CHAT { "message", channel }
1b. PCMSG_ANNOUNCE { "annoucement" }
1c. PCMSG_PRIVMSG { "username", "message" }
2a. CPMSG_ERROR { error }
2b. CPMSG_ANNOUNCEMENT { "annoucement" }
2c. CPMSG_PRIVMSG { "username", "message" }
2d. CPMSG_PUBMSG { channel, "username", "message" }
</pre>

'''Notes'''

''Maybe it would be nicer to have the annoucements simply occur on a special dedicated channel. This would make implementation easier. Also, I think it's fine to also send a username for these messages.'' --[[User:BjÃ¸rn|BjÃ¸rn]] 12:44, 26 July 2006 (CEST)

Archive:Communication protocol

2006-07-26T18:44:05Z

Silene: Fixing discrepancies between the code and the wiki (and hence deprecating a note)

Here be documented our own communication protocol. For the latest list of all messages and their contents, see [http://svn.sourceforge.net/viewcvs.cgi/themanaworld/tmwserv/trunk/src/defines.h?view=markup defines.h].

== Login sequence ==

<pre>
1a. PAMSG_REGISTER { "version", "username", "password", "email" }
APMSG_REGISTER_RESPONSE { 0 }

1b. PAMSG_LOGIN { "version", "username", "password" }
APMSG_UNREGISTER_RESPONSE { 0 }

2a. PAMSG_UNREGISTER { }
APMSG_UNREGISTER_RESPONSE { 0 }

2b. PAMSG_LOGOUT { }
APMSG_LOGOUT_RESPONSE { 0 }

2c. PAMSG_CHAR_LIST { }
APMSG_CHAR_LIST_RESPONSE B number, { B index, S name, B gender, B hair style, B hair color,
B level, W money, W*6 stats, S mapname, W*2 position }

...
</pre>

'''Notes'''

''It has been decided that a separate request for the character list is not necessary. The list will be sent automatically after a succesful login.''

''We probably do not need the index byte for each character. The list can be assumed to be contiguous and characters can be referred to with the index they have in the list.''

''Why is the version a string? It's only for checking compatibility, right?'' --[[User:BjÃ¸rn|BjÃ¸rn]] 12:47, 26 July 2006 (CEST)

== Movement and combat ==

Protocol in development, see article about the [[being movement system]].

== Chatting ==

<pre>
1a. PCMSG_CHAT { "message", channel }
1b. PCMSG_ANNOUNCE { "annoucement" }
1c. PCMSG_PRIVMSG { "username", "message" }
2a. CPMSG_ERROR { error }
2b. CPMSG_ANNOUNCEMENT { "annoucement" }
2c. CPMSG_PRIVMSG { "username", "message" }
2d. CPMSG_PUBMSG { channel, "username", "message" }
</pre>

'''Notes'''

''Maybe it would be nicer to have the annoucements and errors simply occur or special dedicated channels. This would make implementation easier. Also, I think it's fine to also send a username for these messages.'' --[[User:BjÃ¸rn|BjÃ¸rn]] 12:44, 26 July 2006 (CEST)